Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1342 / 255 | Длительность: 10:06:00
Лекция 3:

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >

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

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

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

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

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

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

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

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

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

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

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

В PMBOK 3-й версии формально была закреплена только методика каскадной модели и не были предложены альтернативные варианты, известные как итеративное ведение проектов или Agile.

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

Итеративный подход в разработке программного обеспечения - это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл PDCA: планирование - реализация - проверка - оценка.

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

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

С PMBOK 4-й версии был достигнут компромисс между приверженцами каскадной модели разработки ПО и профессионалами, делающими ставку на итеративные методы. Это привело к тому, что начиная с 2009 года Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе плюсы как от водопадной методологии, так и от достижения итеративных методов.

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

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

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

В последней версии PMBOK уже идет речь об итеративно-инкрементальном подходе как об основном рекомендованном. PMI в процессе разработки собственной Agile-сертификации.

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

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

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

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

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

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

"Каскад":

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

Agile:

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

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

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

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

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

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

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

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

< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Александр Борисенко
Александр Борисенко

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Дмитрий Марушко
Дмитрий Марушко
Беларусь, Минск
Александр Юрченко
Александр Юрченко
Россия, г. Москва