Предпосылки возникновения Agile

3.2. Сравнение каскадного/итерационного/Agile процессов

В "Введение в Agile" мы упомянули о двух противодействующих методологических лагерях классического и нового стиля работы. Настало время обсудить их подробнее.

К первому лагерю относятся так называемые тяжелые, классические подходы к разработке программного обеспечения. Мы кратко рассказали о них в ракурсе исторической ситуации возникновения Agile.

Сейчас рассмотрим их суть, преимущества, недостатки, необходимые условия и возможные результаты их применения.

Первой по значимости и распространенности на сегодняшний момент для процессов управления информационным технологиями является самая известная на сегодня водопадная модель разработки информационных систем. В литературе часто встречаются альтернативные названия этого стиля разработки программных продуктов - каскадный, классический и пр.

Эта модель разработки была впервые презентована в 1970 году в статье Винстона Ройса. Он описал в виде концепции то, что сейчас принято называть "каскадная модель", и обсуждал ее недостатки. В этой же статье он показал, как этот тип процесса разработки программных продуктов может быть доработан до итеративной модели разработки ПО. В оригинальной каскадной модели Ройса следующие этапы процесса были представлены в таком порядке:

• Определение требований.
• Проектирование.
• Конструирование/реализация/кодирование.
• Воплощение.
• Тестирование/отладка/верификация.
• Инсталляция.
• Поддержка.

Переход между фазами возможен только после полного и успешного завершения предыдущей. Следуя предложенной структуре, разработчик переходит от одной стадии к другой последовательно. Сначала полностью завершается первый этап ("Определение требований"), в результате которого появляется полный и исчерпывающий список требований к информационной системе. Только после этого возможен переход к проектированию, в ходе которого разрабатываются документы, подробно, ясно и непротиворечиво описывающие для программистов способ и план реализации зафиксированных требований. Далее начинается этап реализации требований в виде программного кода системы. По сути, этот этап и является ядром разработки программных продуктов. Его результаты будут определять дальнейшее качество последующих этапов и информационной системы в целом. Затем происходит интеграция отдельных компонентов, разрабатываемых различными способами, в единую систему. После того как перечисленные этапы завершены, производится тестирование и последующая отладка продукта. Тут устраняются все недочеты и ошибки, появившиеся ранее. После этого программный продукт внедряется и осуществляется его поддержка - разработка новой функциональности, устранение ошибок и т. д.

Каскадная модель строится на постулате последовательных переходов от одной фазы разработки к другой только после полного и успешного завершения предыдущей. Переходы назад, "перепрыжки" вперед, перекрытия фаз - недопустимы.

Каскадную модель организации процесса разработки программного обеспечения критикуют за недостаточную гибкость, объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Но ее четкая структурированность и формализация являются неоспоримыми ценностями, которые способствуют снижению многих возникающих рисков.

Следующей по значимости и распространению является итеративная модель разработки программного обеспечения.

Итеративные (или инкрементальные) модели используют иной подход к организации деятельности. Взамен единой продолжительной последовательности этапов применяется разбиение жизненного цикла разработки продукта на набор отдельных мини-циклов. Каждый из них включает в себя те же базовые стадии, применяемые в водопадной модели. Мини-цикл - это итерация. В каждой итерации происходит разработка отдельного компонента или компонентов системы (инкремента). Далее реализованный компонент добавляется к уже существующему функционалу.

Итеративная модель, в противовес классической модели, не предполагает полного объема требований для начала работ по реализации продукта. Разработка программы должна начинаться с основных требований к базовой части функционала. Далее, на последующих итерациях, реализованные требования будут дополняться, модифицироваться, приводя к расширению функционала системы. Процесс повторяется, обеспечивая создание новой версии продукта для каждой итерации.

Залог успешного применения этой модели - четко выстроенные этапы тестирования/отладки/верификации требований и тщательная валидация разрабатываемой функциональности в каждой из итераций.

Итеративная модель, по сути, является переходной (от каскадной к Agile) моделью разработки программного обеспечения и, по мнению многих специалистов, оптимальной моделью разработки программного обеспечения.

При сравнении классических (водопадной и итерационной) методик с Agile необходимо осознание того, что каскадная модель - это подход хорошо описанный и детализированный, а Agile - это набор практик и принципов, в которых так или иначе поддерживаются различные методологии гибкой разработки проектов.

Сравнивая эти подходы, следует отметить, что оба имеют набор преимуществ и недостатков. Возможны ситуации, когда обоими методами можно организовать реализацию необходимого программного обеспечения, но на старте процессов разработки входные данные по ресурсным параметрам (стоимость, время, квалификация персонала), а также требования к качеству информационной системы и т. д. существенно влияют на выбор методологии.

В качестве сильных сторон водопадной модели следует выделить следующие:

• Легкость для понимания и последующего применения.
• Подробная структурированность, что облегчает ее применение к малоопытным командам.
• Модель с самого начала задает стабильные требования к проекту/продукту.
• Проекты легко контролируются, отслеживаются ресурсы, риски, время.
• Качество имеет первоочередной приоритет по сравнению со стоимостью и временем.

Agile, в свою очередь, обладает следующими сильными сторонами:

• Итеративный подход к разработке программного обеспечения.
• Использование четких временных рамок.
• Заинтересованные пользователи вовлечены в процесс разработки с самого начала.
• Быстрое получение первой/пробной версии продукта для тестирования.
• Легко воспринимаются корректировки и изменения в процессе разработки.

Слабыми сторонами подходов являются следующие:

"Каскад":

• Требования должны быть определены и детально описаны до начала стадии разработки.
• Высокая цена.
• Медленный темп работы.
• Чувствительность к изменениям.
• Мало возможностей для конечного пользователя повлиять на цели проекта и требования к продукту.
• Зачастую проблемы выявляются только на этапе тестирования.
• Много документации, которая непонятна конечному пользователю или заказчику.

Agile:

• Может привести к низкому качеству продукта.
• Существует риск никогда не достигнуть поставленной цели при инициации процесса.
• Могут возникнуть проблемы с расширяемостью продукта.

На основе приведенных факторов становится возможным сделать целесообразные выводы о ситуациях, когда использование того или иного подхода является оптимальным.

Классические модели предпочтительнее использовать в ситуациях, когда требования к продукту предельно ясны и стабильны, определены используемые технологии и инструменты, речь идет о внедрении большого и сложного программного обеспечения. Примером может служить проекты внедрения ERP-систем.

Agile следует применять в тех случаях, когда конечный пользователь вовлечен в проект со старта, определены бизнес-цели проекта/продукта, проект небольшой или средний, относительно короткий по времени, состав команды стабильный, с высоким уровнем профессионализма, технические требования приемлемые, связаны с технологиями, которые собираются быть использованными для разработки, а информационная система по своей сути является модульной.

Представленные подходы обладают плюсами и минусами, каждый из которых прекрасно подходит для применения в проектах с совершенно разными исходными данными и требованиями.

При выборе методологии необходимо выбрать ту, которая подходит для достижения поставленных целей проекта. Необходимо понимать структуру, принципы, преимущества и недостатки каждой из них. В некоторых случаях это не выбор между методологиями, а правильная комбинация подходов для каждого из этапов конкретного процесса или проекта.

За последнее время изменился рынок потребителей ПО. Вместо больших проектов компании стремятся к использованию маленьких и средних проектов. Компании - разработчики ПО стремятся к более быстрому, частому, регулярному выпуску информационных систем.

Согласно недавнему опросу, 80% решений о внедрении в компании Agile-методологий и идей, принадлежат менеджерам высшего и среднего звена.