Agile или Waterfall — какой вариант соответствует вашему бизнесу?

Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».

Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»

Agile — система идей и принципов «гибкого» управления проектами, на основе которых разработаны популярные методы Scrum, Kanban и другие. Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочий код или продукт.
Waterfall — методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.

Что такое Agile

Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.

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

  1. Люди и взаимодействие важнее процессов и инструментов
  2. Работающий продукт важнее исчерпывающей документации
  3. Сотрудничество с заказчиком важнее согласования условий контракта
  4. Готовность к изменениям важнее следования первоначальному плану.
Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.

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». Победителей не судят...

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

Водопадная модель разработки waterfall

В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:

  1. Системные и программные требования: закрепляются в PRD (документе требований к продукту).
  2. Анализ: воплощается в моделях, схемах и бизнес-правилах.
  3. Дизайн: разрабатывается внутренняя архитектура программного обеспечения, способы реализации требований. Это не только об интерфейсе и внешнем виде ПО, но и о его внутренней структурной логике.
  4. Кодинг: непосредственно пишется код программы, идёт интеграция программного обеспечения.
  5. Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
  6. Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.
Компания Toyota, популяризовавшая методологии Lean и Kanban, до конца 2000-ых пользовалась каскадной моделью разработки ПО для нужд производства.

Преимущества и недостатки Waterfall

В число наибольших преимуществ методики Waterfall вошли:

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

Среди недостатков водопадного метода можно выделить:

  • лишенный гибкости процесс — так, если проект требует больше временных и финансовых ресурсов, чем возможно, то под нож пойдёт фаза тестирования. Согласно исследованиям консалт-группы Rothman, стоимость исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время полноценного многоэтапного тестирования в процессе разработки
  • «стойкость» к изменениям — жёсткий каркас из этапов разработки и условие предоставление только готового продукта определяют невозможность вносить изменения во время разработки
  • инерционность — на первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат, изменения функционала или концепции до выпуска готового продукта невозможно
  • повышенный риск — классическая система тестирования подразумевает отдельно тестирование каждого из компонентов проекта, в том числе, во взаимодействии с другими. При использовании Waterfall происходит тестирование готового продукта.

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

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


Сравнительная таблица

Agile

Waterfall

Суть

Гибкая модель разработки, основанная на
итеративных принципах

Каскадная система разработки, основанная на жёсткой последовательности процесса разработки

Дата создания

2001 г.

1956 г., 1961 г., 1970 г.

Разработчики

Группа IT-специалистов (США)

Г. Беннингтон, Хозьер, В. Уолкер Ройс

Принципы применения

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

  • жёсткая последовательность этапов разработки
  • переход к новому этапу — только после успешного завершения предыдущего
  • фиксированная стоимость продукта
  • заказчик не привлекается к непосредственному процессу разработки
  • изменения могут быть внесены только после завершения всего процесса разработки.

Плюсы

  1. высокий уровень взаимодействия между членами команды проекта
  2. быстрый результат (рабочий код) в итоге «спринтов»
  3. стимулирование изменения и улучшений продукта во время его разработки
  4. непосредственное вовлечение заказчика к рабочему процессу.

  1. понятная и чёткая схема рабочего процесса
  2. возможность просчёта точного количества затраченных на проект ресурсов
  3. не требует затрат по налаживанию коммуникаций между всеми членами команды.


Минусы

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


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


Компании-практики

Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)

Cisco Ericsson AB, Toyota (до 2010)

Подойдёт вам, если...

  1. над проектом работает опытная, высококвалифицированная команда
  2. вы работаете над стартапом
  3. нужно быстро получить рабочую версию продукта
  4. заказчик выступает в качестве партнёра, а не инвестора
  5. продукт разрабатывается в сфере, подверженной постоянным изменениям.

  1. большая часть или вся работа над проектом проводится на аутсорсе
  2. у вас есть чёткая концепция продукта, который хотите получить
  3. вы не ограничены во времени и ресурсах создания продукта
  4. создание продукта или бизнеса построено на соблюдении строгой последовательности выполнения задач.

Не подойдёт, если...

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

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

Agile или Waterfall

Вердикт

Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.
Гибкая модель будет идеальной для IT-компаний, стартапов, проектах в инновационных сферах
Каскадная модель не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы
С учётом особенностей каждой из методик и вашего бизнеса, а также на основе критериев риска, времени и вовлечения заинтересованных лиц вы сможете самостоятельно определить эффективную методологию.
ответить
Александр 7 февраля 2018
В части Waterfall полная ерунда, переписанная из рекламы обучения Agile.
1. Водопад крайне эффективен, так как тред людей направлен на создание целевого продукта, а не на бесконечные вытягивание из заказчиков того, что же они все-таки хотят, переделки ранее сделанного и презентации очередных "сверх ценных" бантиков и рюшечек. Поэтому сроки и бюджет получения целевого продукта минимален и известны в начале проекта.
2. Если заказчику нужен не столько конечный результат, сколько наискорейшее получение самого малого и самого приоритетного функционала, чтобы определиться с приоритетами развития продукта, то тут тоже не нужен никакой Agile. Достаточно выполнить маленький водопадный проект, длительностью 2-4 недели. Потом сразу начать следующий.
3. Если же заказчик не готов брать на себя ответственность за определение конечной цели проекта, как это часто бывает у чинуш при освоении бюджета, то Agile конечно же очень хорошо подходит. Но это уже не разработка, а пособничество в разворовыванию бюджета.
4. Так же хорошо Agile подходит для осуществления процессной, а НЕ проектной деятельности. Например, сопровождение, внедрение ПО, поддержка и постоянное переобучение обучение пользователей.
ответить
Чингис 9 февраля 2018
класс, спасибо за развернутый аргументированный комментарий
ответить
Яна 2 апреля 2018
Александр, подскажите, пожалуйста, где можно прочесть подробнее про методологии управления проектами?
Глеб Батищев 7 февраля 2019
Сазерленд Джефф - Scrum. Революционный метод управления проектами
ответить
Влад 7 июня 2019
+++
И добавлю - Agile тем более не подходит для проектного офиса с разделяемыми ресурсами
ответить
Роман 20 января 2020
"маленький водопадный проект, длительностью 2-4 недели"-что-то это напоминает, уж не спринт ли?
Вы сами незаметно перешли от каскадной к Agile-методологии.
+16
ответить
J 28 сентября 2021
Не скроллится таблица с мобильных устройств (safari)
ответить
Dmitriy 28 сентября 2021
Для уточнения деталей и предоставления ответа свяжитесь с нами, пожалуйста, через форму обратной связи https://worksection.com/support.html
ответить
Андрей 18 августа 2022
Берём agile в разработке, а waterfall при готовом продукте всем хорошо, все счастливы.

esc
Поделиться в
или
Бизнес-кейсы
Никита Ловиков, СЕО и основатель веб-студии Letsmake.site, поделился с нами опытом пользования Worksection. Кроме того, Никита рассказал интересные инсайты об успешности и неуспешности проектов, а также...
13 декабря 2023   •   4 min read
Бизнес-кейсы
Вместе с Иваном Тригубом, сооснователем и СЕО компании SPLIT Development обсудили становление его компании и особенности проектов, преимущества Worksection по сравнению с Jira, а также проблемы фикс-прайса...
3 декабря 2023   •   4 min read
Бизнес-кейсы
Евгений Савельев, управляющий партнер юридической компании Avitar, рассказал о работе команды по Worksection, в чем ценность сервиса для юристов и о преимуществах тайм-трекинга. Расскажите о компании...
30 октября 2023   •   3 min read
Начните работу прямо сейчас
Введите, пожалуйста, свой настоящий email 🙂
Вторжение России в Украину Worksection прекратил работу на территории РФ Почему?