Нет устойчивого мнения о том, какая из методологий лучше или хуже для ИТ-проектов. Есть разные проекты, которые требуют от нас достижения уникальных результатов в срок с определенными ресурсами и качеством. В зависимости от типа проекта, который определяется такими показателями как:

  • окружение проекта;
  • ограничения от руководства и других заинтересованных лиц;
  • риски;
  • уровень команды;

и пр..

Одна из этих двух методологий будет более подходящей.

Клиенту не интересно ваше знание методологий — ему нужен результат.

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

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

На сегодняшний день практически все проекты зависят от ИТ или имеют этап работ, связанный с разработкой или поставкой ИТ-решений.

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

Сейчас не рассматривается ситуация, когда Agile в компании на столько прижился, что стал скорее похож на операционную деятельность чем на проектную.

Есть масса причин, по которым противопоставляют Agile и Waterfall. Кто-то считает, что Waterfall выдохся и не способен быстро реагировать на меняющиеся потребности бизнеса. Другие считают Agile неокрепшим, с дырами в управлении рисками и качеством.

Зачастую, в одном проекте, необходимо комбинировать оба подхода, где разработка ИТ-продукта является важнейшим этапом в проекте и управляется по Agile, т.е. отлично от общего подхода проекта — Waterfall. И здесь тоже происходит “противостояния” подходов.

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

А противостояние создают в том числе и мы — руководители проектов, которые не обладают опытом управления подобными проектами и не знают, как эффективно комбинировать разные подходы и инструменты в одном проекте при работе на разных этапах.

Давайте вспомним историю и принципы каждого из подходов и сравним их.

Waterfall

В достаточно молодой дисциплине управления проектами эта методология является классикой проектного менеджмента. Waterfall — один из самых ранних и устоявшихся подходов и происходит из инфраструктурной, строительной и оборонной индустрий.
Она содержит набор стандартных фаз, которые идут четко одна за другой:

  • Сбор требований (Requirements)
  • Планирование (Design)
  • Разработка/Внедрение (Implementation)
  • Тестирование (Verification/Test)
  • Поддержка (Maintenance)

 

Основной принцип — последующая фаза не может начаться, если не окончена предыдущая.

Так как на заре развития ИТ-индустрии не было формальных методологий по разработке программных продуктов продуктов, Waterfall был адаптирован для этих целей.

Впервые данный подход как адаптированный для разработки ИТ-продуктов упомянул Герберт Бенингтон (Herbert D. Benington) в своей презентации 29 июня 1956 года на Симпозиуме по передовым методикам для цифровых компьютеров (Symposium on advanced programming methods for digital computers).

С тех пор Waterfall очень долго был основной методологией разработки в ИТ индустрии. Был до тех пор, пока проекты по разработке программного обеспечения перестали быть настолько дорогими, что их могли себе позволить только правительственные, военные и крупные коммерческие организации.

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

Достаточно рано стали появляться новые, более гибкие методологии разработок:
1960 — Incremental
1970 — Prototyping
1974 — Adaptive Software Development
1986 — Spiral
1994 — Dynamic Software Development
1995 — Scrum
1996 — RUP

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

2001 год стал если не переломным то как минимум значимым в области управления ИТ-проектами.

Agile

В феврале 2001 года 17 разработчиков собрались на лыжном курорте Юта, США, чтобы обсудить разные подходы и методологии разработки софтверных продуктов, и итогом этих обсуждений стал Agile-манифест.

Agile-манифест разработки программного обеспечения

Вообще, сам факт того, что 17 разработчиков на лыжном курорте были способны выдать такое, заслуживает особого внимания и уважения.

Agile — это в первую очередь набор принципов:

Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.

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

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

На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.

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

Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.

Работающий продукт — основной показатель прогресса.

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

Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

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

Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.

Базируясь на этих принципах, появлялись новые методологии, которые и составляют семью Agile:

  • Extreme programming
  • Scrum
  • Lean Software Development
  • Test Driven Development
  • Feature Driven Development

и др.

Waterfall vs Agile

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

Сильные стороны

Waterfall

Agile

  • Легок для понимания и использования;
  • Детально структурирован, что облегчает его применение к малоопытным командам;
  • Задает стабильные требования к проекту/продукту с самого старта;
  • Проекты легко контролируются, отслеживаются ресурсы, риски, время;
  • Качество имеет первоочередной приоритет по сравнению со стоимостью и временем.
  • Итеративная разработка;
  • Использование временные рамки(time boxes);
  • Конечный пользователь вовлечен в процесс с самого начала;
  • Быстрое получение первой/пробной версии продукта для тестирования;
  • Легко воспринимаются корректировки и изменения в процессе разработки.

 

Слабые стороны

Waterfall

Agile

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

 

Когда использовать

Waterfall

Agile

  • Требования к продукту предельно ясны и стабильны;
  • Известны используемые технологии и инструменты;
  • Проект большой, дорогой и сложный;
  • Примеры:
    • внедрение новой версии известного продукта;
    • внедрение ERP систем.
  • Конечный пользователь вовлечен в проект со старта;
  • Четко определены бизнес-цели проекта/продукта;
  • Небольшой или средний проект, относительно короткий по времени;
  • Состав команды стабильный;
  • Команда с высоким уровнем профессионализма;
  • Технические требования приемлемые, коллериются с технологиями, которые собираются быть использованными для разработки;
  • Система может быть модульной.

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

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

Задача руководителя проекта — выбрать наиболее подходящий способ для достижения целей проекта. Waterfall, RUP, Scrum, RAD, XP, FDD, TDD и другие методологии вам помогут этого добиться, если вы понимаете разницу между ними, их принципы, слабые и сильные стороны. В некоторых случаях, это не выбор между методологиями, а правильная комбинация подходов для каждого из этапов проекта.

Waterfall и Agile могут быть оптимально применены в одном проекта.
“Как эффективно комбинировать Waterfall и Agile в одном проекте?” — тема нашей следующей статьи.