[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Всем привет! Меня зовут Роман Баранов, я Agile-тренер компании ScrumTrek, аккредитованный тренер Международного консорциума ICAgile и сертифицированный Professional Scrum Master по версии scrum.org. На прошлой неделе Алексей рассказал ваш о том, что же такое Agile и зачем он нужен. На этой неделе мы с вами изучим один из самых популярных Agile-подходов, который называется Scrum. Но прежде чем перейти к этой теме, давайте еще раз поймем главное отличие всех Agile-подходов от любых других. Это отличие называется итеративная и инкрементальная разработка. До появление Agile-манифеста в 2001 году стандартом де-факто в индустрии разработки программного обеспечения был так называемый «Водопадный подход», по-английски называется Waterfall. Автором этого подхода был Уинстон Ройс, который описал его в своей статье «Управление разработкой больших программных систем». Согласно ему, проект по разработке программного обеспечения разбивается на последовательные этапы, включающие сбор и анализ требований, проектирование архитектуры, программирование, тестирование и, наконец, внедрение системы. А пока очередной этап не завершится, мы не можем приступить к следующему. И, правда, как же можно начать проектировать систему, если мы еще не знаем требований к ней? Или тестировать то, что еще не запрограммировано? Звучит логично, не правда ли? Проблема с водопадным подходом известна любом программисту и менеджеру проекта, который его применял. Как бы тщательно мы не согласовывали требования с заказчиком на первом этапе, на этапе внедрения ему обязательно что-нибудь не понравится, не говоря уже о том, что сами эти требования могут меняться прямо в процессе разработки. Эта проблема стала поводом для множества шуток в IT-сообществе. Как же решить эту проблему? Самое очевидно решение, которое лежит на поверхности: а давайте будем общаться с заказчиком почаще и показывать ему наши даже промежуточные результаты на каждом этапе? Такой подход называется итеративным. Итеративный подход снимает некоторые риски, но не гарантирует главного: в конце каждой итерации заказчик не обязательно получает полностью готовую к использованию систему, а значит в самом конце все равно может получить не то, что ему действительно нужно. Как же все-таки решить проблему несоответствия результата ожидания заказчика и изменение требований прямо в процессе? Ответ на этот вопрос дал Agile-манифест, и идея звучит просто: а давайте не просто строить работу максимально короткими циклами (итерациями), но в конце каждой такой итерации поставлять заказчику новую версию системы с новыми функциями, которые он может сразу же использовать. Так, новая версия системы с новыми функциями называется инкрементом продукта, а подход в целом получил название итеративный и инкрементальный. который также можно назвать Agile-подходом. Давайте подведем итог: в водопадном подходе разработка разбивается на последовательные этапы, а заказчик и конечный пользователь получает ценность в виде системы только в самом конце проекта. В итеративном подходе работа в проекте выполняется короткими итерациями с целью частой коммуникации с заказчиком. А в итеративном и инкрементальном подходе, который также называется Agile-подходом, в конце каждой итерации заказчик получает небольшой, но цельный инкремент продукта с новыми функциями, которые он может сразу же использовать. В следующем видео мы с вами подробнее рассмотрим один из самых популярных Agile-подходов, который называется Скрам. [ЗВУК]