Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».
Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»
Agile — система идей и принципов «гибкого» управления проектами, на основе которых разработаны популярные методы Scrum, Kanban и другие. Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочий код или продукт.
Waterfall — методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.
Что такое Agile
Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.
Их суть сводится к таким ключевым моментам, определяющим характер гибкой методики разработки:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану.
Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.
Lean — метод, который вырос на основе системы управления производством Toyota Production System. В его основе — философия постоянного совершенствования на всех уровнях организации, где одно из ключевых понятий — ценность (то, за что готов платить заказчик).
Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.
Преимущества и недостатки метода Agile
К преимуществам метода относятся:
- короткие и понятные итерации — циклы разработки длятся от 2 недели до 2 месяцев, по окончанию которых заказчик получает рабочую версию продукта
- высокая степень вовлечения исполнителей, организаторов и заказчиков проекта
- во главе угла стоит рабочий продукт как основной показатель прогресса — это можно рассматривать как плюс, так и минус, ведь в таком случае к команде проекта выдвигаются высокие требования по самоорганизации
- минимизация рисков благодаря гибкой системе внесения изменений;
- популярность метода среди разработчиков программ для управления бизнеса.
Не избежала методология и недостатков, которые органично «дополняют» её достоинства:
- стимулирование постоянных изменений проекта: гибкость разработки продукта может привести к тому, что он никогда не дойдёт до финальной версии
- повышенные требования к квалификации и опыту команды: помимо непосредственно создания продукта команда должна анализировать возможные способы улучшения эффективности собственной работы, беспрерывно обмениваться информацией по проекту, быть мотивированной и самоорганизованной. Далеко не всегда ресурсы проекта позволяют привлечь таких специалистов
- философский характер методологии: Agile — это не чёткая инструкция к действию, а целая философская концепция. Команда не может механически применить механики «гибкой» разработки, нужно принять ключевые принципы системы
- сложность подсчёта итоговой суммы работы: стимуляция изменений и усовершенствования конечного продукта приводит к плавающему значению стоимости проекта. Поэтому Agile не подойдет для управления проектами в строительстве, где составляется четкая смета под всю работу.
Что такое Waterfall
Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.
С методикой Waterfall получилось также, как и с многими изобретениями: свой вклад в создание методологии сделали Герберт Беннингтон в 1956 г. и Хозьер в 1961 г., а Уолкер использовал их наработки, обеспечив себе славу «создателя Waterfall». Победителей не судят...Водопадная модель разработки подразумевает последовательное прохождение процесса, разбитого на стадии. Переход к новому этапу возможен только после завершения предыдущего.
В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:
- Системные и программные требования: закрепляются в PRD (документе требований к продукту).
- Анализ: воплощается в моделях, схемах и бизнес-правилах.
- Дизайн: разрабатывается внутренняя архитектура программного обеспечения, способы реализации требований. Это не только об интерфейсе и внешнем виде ПО, но и о его внутренней структурной логике.
- Кодинг: непосредственно пишется код программы, идёт интеграция программного обеспечения.
- Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
- Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.
Преимущества и недостатки Waterfall
В число наибольших преимуществ методики Waterfall вошли:
- понятная и простая структура процесса разработки — это снижает порог вхождения для команд
- удобная отчётность — можно легко отследить ресурсы, риски, затраченное время и финансы благодаря строгой этапности процесса разработки и детальной документации проекта
- стабильность задач — задачи, которые стоят перед продуктом, ясны команде с самого начала разработки, и остаются неизменными на протяжении всего процесса
- оценка стоимости и сроков сдачи проекта — сроки выпуска готового продукта, как и его итоговая стоимость могут быть просчитаны до момента запуска разработки.
Среди недостатков водопадного метода можно выделить:
- лишенный гибкости процесс — так, если проект требует больше временных и финансовых ресурсов, чем возможно, то под нож пойдёт фаза тестирования. Согласно исследованиям консалт-группы Rothman, стоимость исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время полноценного многоэтапного тестирования в процессе разработки
- «стойкость» к изменениям — жёсткий каркас из этапов разработки и условие предоставление только готового продукта определяют невозможность вносить изменения во время разработки
- инерционность — на первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат, изменения функционала или концепции до выпуска готового продукта невозможно
- повышенный риск — классическая система тестирования подразумевает отдельно тестирование каждого из компонентов проекта, в том числе, во взаимодействии с другими. При использовании Waterfall происходит тестирование готового продукта.
Частично недостатки водопадной модели разработки исправлены в модификациях Waterfall: Сашими, Waterfall с субпроектами и водопадная модель разработки с снижением риска.
Сашими или водопадная модель с наслаивающимися фазами — cамая известная среди них. В ней этапы как и в оригинальной методике идут друг за другом, но при этом перекрываются одна другой во времени.
Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.
Водопадная модель разработки с снижением риска — модификация классического Waterfall, в который добавлены спирали снижения риска, которые разделяют проект на мини-проекты и корреспондируют их одному или нескольким ключевым рискам.
Сравнительная таблица
| Agile | Waterfall |
Суть | Гибкая модель разработки, основанная на | Каскадная система разработки, основанная на жёсткой последовательности процесса разработки |
Дата создания | 2001 г. | 1956 г., 1961 г., 1970 г. |
Разработчики | Группа IT-специалистов (США) | Г. Беннингтон, Хозьер, В. Уолкер Ройс |
Принципы применения |
|
|
Плюсы |
|
|
Минусы |
|
|
Компании-практики | Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.) | Cisco Ericsson AB, Toyota (до 2010) |
Подойдёт вам, если... |
|
|
Не подойдёт, если... |
|
|
Вердикт
Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.
Гибкая модель будет идеальной для IT-компаний, стартапов, проектах в инновационных сферах
Каскадная модель не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы
С учётом особенностей каждой из методик и вашего бизнеса, а также на основе критериев риска, времени и вовлечения заинтересованных лиц вы сможете самостоятельно определить эффективную методологию.
1. Водопад крайне эффективен, так как тред людей направлен на создание целевого продукта, а не на бесконечные вытягивание из заказчиков того, что же они все-таки хотят, переделки ранее сделанного и презентации очередных "сверх ценных" бантиков и рюшечек. Поэтому сроки и бюджет получения целевого продукта минимален и известны в начале проекта.
2. Если заказчику нужен не столько конечный результат, сколько наискорейшее получение самого малого и самого приоритетного функционала, чтобы определиться с приоритетами развития продукта, то тут тоже не нужен никакой Agile. Достаточно выполнить маленький водопадный проект, длительностью 2-4 недели. Потом сразу начать следующий.
3. Если же заказчик не готов брать на себя ответственность за определение конечной цели проекта, как это часто бывает у чинуш при освоении бюджета, то Agile конечно же очень хорошо подходит. Но это уже не разработка, а пособничество в разворовыванию бюджета.
4. Так же хорошо Agile подходит для осуществления процессной, а НЕ проектной деятельности. Например, сопровождение, внедрение ПО, поддержка и постоянное переобучение обучение пользователей.
И добавлю - Agile тем более не подходит для проектного офиса с разделяемыми ресурсами
Вы сами незаметно перешли от каскадной к Agile-методологии.