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

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

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

Методология — правила и способы разработки, которые основаны на теории.

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

Чтобы понять, какая методология подходит под ваши запросы, мы собрали их особенности и сравнили их. 

Waterfall

Это метод разработки, где все этапы выполняются «каскадом» — сначала заканчивают один, потом начинают другой.

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

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

Обычно водопадная модель — это 5 последовательных этапов:

1. Сбор требований и формирование ТЗ. Детально описывается план будущих работ, определяются функциональные и нефункциональные требования, роли для каждого сотрудника, планируется время на выполнение и оцениваются возможные риски..  

2. Проектирование. Разрабатывается архитектура и логика будущего решения, определяются необходимые технологии, языки программирования и другие инструменты для реализации проекта согласно требованиям. 

3. Разработка (реализация). Происходит непосредственное создание продукта строго в соответствии с утвержденным ТЗ и проектной документацией. Любое отступление от плана требует формального согласования или не допускается. Этот этап часто становится самым длительным.

4. Тестирование. Готовый продукт тщательно проверяется на работоспособность, соответствие требованиям ТЗ и наличие багов перед его выпуском.

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

Как это выглядит. Заказчик передал требование добавить страницу «Контакты» на сайт. Дальше сотрудники действовали по алгоритму:

1. обсудили требование, продумали, как должна выглядеть страница;

2. нарисовали макет будущей страницы;

3. программист создал страницу по готовому макету;

4. проверили, правильно ли она отображается;

5. внедрили страницу на сайт.

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

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

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

Максим Якубович

Плюсы Waterfall

Если в крупном проекте нужно четко следовать ТЗ и точно планировать каждый шаг — каскадный метод подойдет. Разработку по Waterfall можно сравнить со строительством дома — нельзя менять ТЗ каждую неделю и переносить готовые комнаты, иначе такое строение быстро рухнет.

Еще каскадная модель подходит, если:

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

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

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

• Гибкость нужна только на ранних этапах. До начала разработки команда может обсудить и внести изменения в проект.

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

По каскадной модели работают тендеры от государства. Если любой государственной компании нужен подрядчик на работы — они действуют последовательно по этапам: 

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

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

Недостатки каскадной модели

Waterfall  не подойдет, если на проекте:

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

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

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

• Нельзя менять процесс. Все могут работать только по инструкциям и правилам, нет места для инициативы и перемен.

• Клиент и заказчик не в фокусе. Они не участвуют в процессе разработки, поэтому в результате продукт может им не подходить.

Agile

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

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

Кажется, что при работе по Agile документация не нужна, но это не так. Даже креативным проектам нужна документация, просто в фокусе работающий продукт, а не бумаги. Работать без правил и регламентов не получится даже по Agile. 

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

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

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

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

Взаимосвязанная работа команды и заказчика помогает быстрее принимать решения и не допускать недопониманий. Разные отделы могут слышать друг друга и помогать в работе.

Роман Казаков, эксперт в управлении продуктами

Плюсы Agile

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

Какие еще достоинства есть у работы по Agile:

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

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

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

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

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

Такой подход к работе может не понравиться вашей команде, потому что:

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

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

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

• Почти готовый продукт может оказаться не нужен. Если продукт больше не интересен конечному пользователю, то команда меняет цель проекта. Когда сотрудникам нужно полностью переделывать или «выбрасывать» готовое рабочее решение, это сильно демотивирует их.  

Что выбрать: «каскад» или «гибкость» 

Чтобы вам было проще, мы собрали основные параметры подходов в таблицу.

Agile-методики: Scrum и Kanban

Внутри семейства Agile есть множество методик, например, часто используют Kanban и Scrum. У них есть схожие черты — команды обоих фреймворков:

• сами организуются вокруг проекта, у каждого специалиста кросс-функциональные навыки;

• визуализируют поток работы через реальные или виртуальные доски;

• ценят обратную связь и вносят корректировки в продукт под бизнес-требования;

• работают сообща — решают проблемы и делятся опытом, ведут коммуникации по продукту и обсуждают проделанную работу;

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

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

Роман Казаков, эксперт в управлении продуктами

Теперь давайте разберем подробнее каждую модель.

Scrum

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

В команде почти всегда есть:

• владелец продукта — действует в качестве посредника между конечным потребителем и командой разработки;

• скрам-мастер — помогает выстраивать взаимодействие между сотрудниками и работать в соответствии с ценностями Agile;

• разработчики — реализуют ТЗ и создают продукт.

Чтобы во время спринта и после него проанализировать работу, на каждом этапе проводится минимум 4 встречи:

• планирование;

• daily;

• тестирование и обзор;

• ретроспектива.

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

Как это работает. Если команда разрабатывает функцию «Корзина покупок» для интернет-магазина, ей может понадобиться 2 спринта:

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

   • сотрудники обсуждают, кодируют и тестируют только эту функцию, проводят короткие встречи для синхронизации;

   • в результате спринта получают работающую корзину, показывают заказчику и собирают обратную связь.

2. Ставят цель «добавить возможность изменять количество товара и удалять его из корзины» на основе отзывов и комментария заказчика.

   • разработчики реализуют новый функционал и тестируют его;

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

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

Роман Казаков, эксперт в управлении продуктами

Kanban

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

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

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

Роман Петров, Agile Coach в Сбере

Каждый этап — отдельная колонка, по которой проходит задача перед завершением. 

Часто эти колонки называются по основным этапам:

• «Очередь»;

• «Выполняется»;

• «Выполнено».

При визуализации работ стоит расставить промежуточные точки для контроля. Это поможет избежать аврала и поможет контролировать весь поток работ в рамках команды.

Денис Бартоломе, бизнес-тренер

Любую задачу команда превращает в карточку, размещает на доске и перемещает по мере выполнения. 

Обычно команда устанавливает лимит на количество задач, которые могут быть в работе одновременно. Для этого часто используют WIP-лимиты —  предельное количество задач в колонке, дорожке или на доске. 

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

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

Максим Якубович

Что нужно запомнить

У каждого метода есть свои плюсы:

• Каскадная модель хорошо работает в типовых проектах, где есть четкие регламенты и жесткая структура, а встречи команды во время работы почти не нужны.

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

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

Scrum больше подходит командам, если они:

• планируют быстрее и чаще выпускать улучшенные версии продукта;

• экспериментируют во время разработки, реагируют на изменения;

• постоянно собирают обратную связь и меняют продукт на ее основе;

• не пытаются выпустить продукт или его версию в определенную дату.

Не получится сразу всё продумать и учесть, выполнить только зафиксированные объемы работ. Часть информации вы получите позже, из обратной связи или комментариев клиентов. Это важно всегда помнить.

Роман Казаков, эксперт в управлении продуктами

Kanban-метод хорошо справляется, если команде нужно:

• прогнозировать точный результат;

• визуализировать работу, процессы, сроки и ответственных;

• найти и исправить «узкие» места;

• с определенной точностью прогнозировать сроки сдачи и результат;

• распределять роли и нагрузку в команде;

• определить и выполнить подвисающие задачи. 

Подробнее о фреймворках, их различиях и особенностях рассказывали в статье «Kanban VS Scrum: в чем разница».

Постепенно идите к поставленным целям. Не пытайтесь поменять все в один момент — внедряйте и адаптируйте новые процессы частями. Учитывайте мнение команды и действуйте не для того, чтобы улучшить отчеты, а ради реальных результатов.

Григорий Меньших, Product Owner

Чтобы точно выбрать фреймворк и метод — выясните, какие требования и условия у вашего проекта. Если вы правильно определите методику, то будет проще разработать и выпустить на рынок готовый продукт.