Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1967 / 503 | Длительность: 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 >
Владислава Шевелкина
Владислава Шевелкина

Добрый день!
Предполагается ли выдача сертификата на английском языке?
В разделе сертификат только на русском.

Грета Березовская
Грета Березовская