В конце прошлого столетия доминирующей методологией разработки программного обеспечения была «водопадная», или «каскадная», модель [1] — последовательное выполнение заранее определенных этапов (рис. 1), каждый из которых занимал существенное время и завершался достижением заранее согласованных результатов. При этом переход на следующий этап во многих случаях происходил только после полного и формального завершения предыдущего. Дополнительный отличительный признак такой модели — функциональная специализация исполнителей отдельных этапов: аналитиков, архитекторов, разработчиков, тестировщиков и пр.

Рис. 1. Пример водопадной модели разработки программного обеспечения
Рис. 1. Пример водопадной модели разработки программного обеспечения

 

При разработке крупных информационных систем, конечную функциональность которых можно определить и зафиксировать в самом начале работ, а также при отсутствии требований максимально быстрого завершения полного цикла разработки водопадная модель позволяет получать качественные результаты на выходе при достаточно детальном контроле расходов. Однако бурное развитие технологий выявило недостатки этой модели, негативно влияющие на взаимодействие внутренних или внешних заказчиков компании с исполнителями (собственными разработчиками компании либо сторонними программистами). В новых рыночных условиях от основного бизнеса часто требуется быстро выводить на рынок новые продукты, однако типичный цикл разработки — от начала проекта до получения первого работающего результата — по водопадной модели занимает от 6 до 18 месяцев, а в крупных организациях — 2–3 года. Кроме того, при появлении потенциально перспективных рыночных возможностей требования заказчиков могут меняться по ходу проекта разработки, что крайне сложно учесть при создании ИТ-системы без изменения сроков либо снижения качества выходных результатов (рис. 2).

Рис. 2. Классическая пирамида взаимосвязанных ограничений проектного управления
Рис. 2. Классическая пирамида взаимосвязанных ограничений проектного управления

 

Все это привело к накапливанию напряжения между заказчиками и исполнителями, между основным бизнесом и разработчиками ПО. Ответом стали инновационные подходы к программированию: Кен Швейбер предложил Scrum, а Кент Бек — экстремальное программирование (XP). Однако применение новых идей дало весьма скромные результаты, поскольку фокусировалось лишь на одном из этапов цикла разработки ПО — на программировании, тогда как изначально задача ставилась намного шире. Требовалось еще что-то, что позволило бы упростить и ускорить выполнение всей цепочки жизненного цикла ПО. В 2001 году Швейбер, Бек, Роберт Мартин и примкнувшие к ним коллеги по цеху обсудили...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF