Waterfall, Agile, Scrum или Kanban — в чем разница?

Бэтмен или супермен? Agile или Waterfall? Scrum или Kanban? Три вопроса, о которых люди могут спорить часами. Мы не являемся экспертами в области супергероев, но поможем вам разобраться с базовыми терминами методик управления проектами. В статье расскажем, что скрывается за перечисленными понятиями и какой подход лучше выбрать для своего бизнеса.

Что нужно знать о методологиях разработки

📂
Методология — набор методов и принципов, подкрепленных теорией. 

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

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

Ниже расскажем о плюсах и минусах как Waterfall, так и Agile.

Методология водопада

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

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

Еще один принцип каскадного метода разработки — подробная документация. Перед началом работы команда обсуждает каждый аспект будущего продукта и фиксирует все важные моменты (от требований к проекту до расставления дедлайнов).

Классическая водопадная модель состоит из 5 этапов:

  1. Сбор требований к продукту и оформление их в техническое задание. На этом этапе подробно прописывают план работы, распределяют роли в команде, закладывают время на проект и риски.
  2. Проектирование. Здесь прописываются функции и фишки продукта, к примеру, логика и архитектура сайта. После под выбранную концепцию подбирают инструменты: язык программирования, методы и т.д.
  3. Разработка. Этап, на котором сотрудники разрабатывают продукт или пишут код в строгом соответствии ТЗ, макетам и требованиями — и ни шагу в сторону. Этот этап занимает большую часть проекта.
  4. Тестирование. Здесь команда проверяет продукт на соответствие ТЗ и баги, чтобы исправить всё до релиза.
  5. Поддержка. Продукт выпускают и поддерживают его работоспособность на рынке. Разработчики собирают обратную связь от клиентов и улучшают продукт, например, добавляя новые функции.

Какие плюсы есть у подхода

Каскадный метод хорошо подходит для крупных проектов, в которых важно точное планирование и четкое следование ТЗ. Например, при строительстве дома нельзя вносить изменения в проект каждую неделю. Чтобы дом не рухнул, нужно следовать изначальному плану. Также Waterfall подойдет проекту, потому что:

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

Чем плох Waterfall

Каскадный подход может не подойти вашему проекту, потому что:

  • Есть зависимость команд друг от друга. Если одна из команд не успеет выполнить работу к поставленному дедлайну, то это отразится не только на работе их коллег, но и на релизе будущего продукта.
  • Тестирование — один из последних этапов разработки. Ошибку разработчика можно заметить слишком поздно. А откатиться к прошлому этапу для ее исправления сложно и дорого.
  • Чаще всего финальный продукт не ориентирован на клиента и заказчика, т.к. их полностью изолируют от процесса разработки.
  • Низкая вовлеченность в команде. Сотрудники меньше вовлечены в командный проект, потому что каждый работает сугубо над своими задачами, общаясь с коллегами по минимуму.
  • Нет самоуправления. Из-за того, что все работают по оговоренному регламенту и определенным инструкциям, нельзя проявлять инициативу и изменять рабочий процесс.

Методология Agile

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

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

Документация не так важна в Agile, как в каскадном подходе. Но это не значит, что «работать по Agile = работать без документов». В таких командах тоже есть документация, но основной упор делается на работающий продукт.

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

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

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

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

Преимущества Agile

Начнем с плюсов. Благодаря Agile-методологии:

  • Команда открыта к изменениям. Из-за гибкости, можно быстро реагировать на изменения и вносить их, чтобы создать полезный продукт для клиента.
  • Снижается вероятность провала, потому что тестирование и сбор обратной связи от заказчика проходят после каждого спринта.
  • Увеличивается вовлеченность команды. Благодаря постоянному взаимодействию сотрудников и отсутствию микроменеджмента, каждый участник видит свое влияние на проект.
  • Сокращается рутинная работа в духе скрупулезного ведения документов, в которых фиксируется каждый шаг. На первом месте всегда будет работающий продукт.
  • Улучшается коммуникация между сотрудниками. Прозрачные рабочие процессы и общение на равных, где ценен каждый голос, — это философия работы всей команды.

Недостатки подхода

Некоторые разработчики не в восторге от Agile, потому что:

  • Нет четкого плана для проекта. Заказчик может вносить новые требования к продукту в ходе разработки, и финальный продукт может сильно отличаться от того, что было запланировано вначале.
  • Нужна постоянная коммуникация. Некоторым сотрудникам комфортнее работать в одиночку и отчитываться перед руководством после завершения проекта. У заказчика же может просто не быть времени, сил или желания постоянно давать комментарии и общаться с командой.
  • Сложное погружение новых сотрудников. Из-за того, что команда работает небольшими итерациями, нового коллегу придется погружать в несколько прошедших периодов — это огромный объем информации.
  • Проделанная работа может пропасть. Согласно Agile, если продукт потеряет ценность для клиента, команда должна изменить цель проекта. В этом случае почти вся проделанная работа может кануть в лету. Этот момент может тяжело даться сотрудникам и «добить» их мотивацию.

Waterfall vs Agile

Выбирайте Waterfall, если

Выбирайте Agile, если

Заказчик знает, чего хочет. И у него есть проработанная концепция, которую точно не нужно менять

Команда готова адаптировать продукт под меняющиеся требования клиента 

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

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

Заказчик планирует отдать ТЗ проекта разработчикам и не хочет участвовать в каждом этапе проекта

Заказчик хочет активно участвовать в жизни проекта: посещать встречи и давать комментарии

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

Сотрудники работают над новым продуктом, из-за чего приходится тестировать новые гипотезы и пробовать новые методы в работе

Что нужно знать об Agile-методиках

Kanban и Scrum — это методики Agile, они имеют сходства:

  1. Команды Scrum и Kanban  — самоорганизованные и кросс-функциональные.
  2. Оба подхода визуализируют работу с помощью досок: виртуальных или реальных.
  3. Обратная связь о проделанной работе очень ценна. С ее помощью сотрудники могут быстро адаптироваться к изменяющимся бизнес-требованиям.
  4. Всем участникам команды нужно работать вместе: обсуждать продукт, решать проблемы и обмениваться опытом.
  5. Благодаря прозрачным рабочим процессам, команды постоянно совершенствуются.
  6. Задачи берутся в работу в зависимости от их приоритета, который определяется ценностью продукта для клиентов и бизнеса.

Scrum

Scrum — фреймворк для Agile-управления проектами. Каждый проект разбивается на небольшие итерации продолжительностью от 1 до 4 недель — спринты. Если спринт уже начат, то в него не должно вноситься изменений — не получится добавить новые задачи в текущий спринт.

Стандартная Agile-команда включает в себя:

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

Для улучшения рабочего процесса, каждый этап спринта сопровождается встречами:

  • планирование,
  • daily-встречи,
  • обзор и тестирование,
  • ретроспективы.

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

Подробнее о Scrum читайте в этой статье.

Kanban

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

Если Scrum-команда разбивает проекты по времени, то команда, которая работает по Kanban-методу, разбивает проекты на этапы рабочего процесса с помощью канбан-доски.

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

  • «В плане»,
  • «В работе»,
  • «Готово».

Каждая рабочая задача — это карточка на доске, которая постепенно перемещается слева направо. К примеру, можно визуализировать на доске ключевые этапы разработки сайта: «В очереди», «Проектирование», «Дизайн», «Верстка», «Тестирование» и «Готово».

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

Итого

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

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

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

Фреймворк Scrum подойдет для проектов и команд, которые:

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

Kanban-метод подойдет для команд, которые хотят:

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

Подробнее о двух популярных фреймворках и их преимуществах мы рассказали здесь.

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

Внутри Kaiten есть все необходимые инструменты для работы по Agile, Scrum и Kanban

Попробовать