Нет устойчивого мнения о том, какая из методологий лучше или хуже для ИТ-проектов. Есть разные проекты, которые требуют от нас достижения уникальных результатов в срок с определенными ресурсами и качеством. В зависимости от типа проекта, который определяется такими показателями как:
- окружение проекта;
- ограничения от руководства и других заинтересованных лиц;
- риски;
- уровень команды;
и пр..
Одна из этих двух методологий будет более подходящей.
Клиенту не интересно ваше знание методологий — ему нужен результат.
Для успешного завершения комплексного проекта Руководителю проекта не достаточно знать, как работать с распределенными командами, большими бюджетами, высокими рисками, большим количеством заинтересованных лиц и т. д. Это поможет реализовать проект, но не будет гарантией успешного проекта.
Комплексный проект может включать в себя этапы работ с поставками в совершенно разных индустриях. Зачастую успешность комплексного проекта зависит от того, насколько правильно руководитель проекта выбрал подходящую методологию и смог ее внедрить для достижениях требуемых результатов на конкретно взятом этапе.
На сегодняшний день практически все проекты зависят от ИТ или имеют этап работ, связанный с разработкой или поставкой ИТ-решений.
Для больших комплексных проектов 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 |
|
|
Слабые стороны
Waterfall |
Agile |
|
|
Когда использовать
Waterfall |
Agile |
|
|
Какой вывод можно сделать?
Два подхода со своими плюсами и минусами, каждый из которых прекрасно подходит для применения в проектах с совершенно разными входными данными и требованиями.
Не исключена ситуация, когда обоими методами можно реализовать поставку поставку одного и того же продукта, но на старте каждого из проектов входные данные по таким ключевым параметрам, как стоимость, время, квалификация команды, требования к качеству, конечный пользователь и т. д., существенно влияют на выбор методологии.
Задача руководителя проекта — выбрать наиболее подходящий способ для достижения целей проекта. Waterfall, RUP, Scrum, RAD, XP, FDD, TDD и другие методологии вам помогут этого добиться, если вы понимаете разницу между ними, их принципы, слабые и сильные стороны. В некоторых случаях, это не выбор между методологиями, а правильная комбинация подходов для каждого из этапов проекта.
Waterfall и Agile могут быть оптимально применены в одном проекта.
“Как эффективно комбинировать Waterfall и Agile в одном проекте?” — тема нашей следующей статьи.