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

Что нужно знать об 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-метод подойдет для команд, которые хотят:

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

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

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