Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу

Начнем с того, что Agile и Waterfall – подходы к управлению разработкой, Scrum – это Agile-фреймворк, а Kanban – метод. При этом мы собрали все сущности в одну статью и сравнили их между собой, потому что на это есть спрос.

Рекомендуем дочитать до конца – мы не только объясняем термины, но и отвечаем на интригующие вопросы:

• в чем сила – в Agile или Waterfall и почему их любят сравнивать;
• почему Waterfall – мифический подход к управлению разработкой;
• насколько корректно сравнивать между собой Scrum с Kanban и можно ли их использовать вместе.

Прежде чем начнем, не можем не рассказать о себе. Neogenda – это консалтинговая компания. Мы помогаем компаниям освоить современные подходы и методы менеджмента. На нашем счету более 100 управленческих кейсов, 5 000 учеников и 40 лет практики. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие компании, которые вам скорее всего тоже известны. Если вы считаете, что ваш бизнес может стать прибыльнее за счет грамотного внедрения современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.

А теперь начинаем.

Waterfall

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

Этапы работы над проектом по разработке программного обеспечения (ПО). Иллюстрация взята из статьи «Managing the Development of Large Software Systems» 1970 года. Эту статью считают родоначальницей подхода, на нее даже ссылаются в Википедии. Интересный факт: слово Waterfall в ней ни разу не упоминалось – оно придумалось кем-то позже

Если слегка упростить схему, разработка по Waterfall делится на 6 основных этапов:

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

А теперь к самому интересному: почему столь известный Waterfall не то, что не работает, а вообще, – миф?

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

Например, в той же «Managing the Development of Large Software Systems», Уинстон Ройс заявляет, что работа по такому подходу может послужить причиной 100 % перерасхода ресурсов, моделируя подобную ситуацию. Если вам знаком английский, можете прочесть работу и убедиться в этом сами. Забавно, что некоторые люди считают Уинстона основоположником каскадного подхода.

Иллюстрация из той же статьи, которая подсвечивает момент, где автор демонстрирует инкрементальный(!) подход к разработке. Здесь Уинстон представляет принцип «Сделай дважды», говоря о том, что перед релизом финальной версии ПО нужно заблаговременно создать ее рабочий прототип, чтобы не столкнуться с неприятностями при сдаче финальной версии

Еще более интересный пример. Еще раньше, в 1956 году Гербер Беннингтон выступил с докладом «Production of Large Computer Programs». В докладе рассказывается о том, что команда Гербера занималась тестированием при разработке ПО параллельно с кодингом. Выходит, что итеративный подход к разработке стали использовать в работе чуть ли не над первыми программами.

Иллюстрация из доклада Гербера, которая показывает взаимосвязь между этапом разработки и тестирования

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

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

Подытожим. Waterfall стоит рассматривать как полную противоположность гибкой разработке, хотя полноценный каскадный подход никто и не использует. Существуют различные методологии, которые в той или иной степени склоняются больше к гибкому или каскадному подходу к разработке. Ближе к Waterfall находятся V-Model, PMBOK, PMI и PRINCE2, которые тоже критикуют за излишние ограничения. Но они отлично подходят для управления проектами, которые легко довести до конца в запланированных бюджетных и временных рамках.

А теперь расскажем о полной противоположности Waterfall – Agile.

Agile

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

Несмотря на то, что такие Agile-фреймворки, как Scrum, Crystal Clear, RAD и XP появились в двухтысячных годах, принято считать, что Agile окончательно сформировался в 2001 году. Именно тогда был опубликован Agile-манифест, который включает в себя четыре ценности и двенадцать принципов Agile.

Скриншот для тех, кто поленился открыть ссылку на Agile-манифест

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

Если охарактеризовать Agile-подход в двух словах, можно сказать, что он итеративный и инкрементальный. Согласно Agile работа над ПО ведется итерациями – многократными цикличными процессами, которые позволяют достичь лучшего качества. Итерации заканчиваются инкрементами – новыми версиями ПО, в которых появляются дополнительные функции или оптимизируются старые.

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

Теперь вы можете подумать: зачем нужны более жесткие и более гибкие фреймворки? Неужели мировое IT-комьюнити светлых и дотошных умов не выявило опытным путем лучшее решение? Ответим ниже.

Гибкий VS жесткий подход: что выбрать вам

Гибкий подход оптимален в работе над продуктом.

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

Работать над продуктом в жестких рамках неэффективно, потому что лишь малая часть идей продуктовой команды принесет ценность для пользователей, а значит, и для бизнеса. Только одно из 10 решений приводит к росту бизнеса – это конвенциональная мудрость мирового комьюнити продакт-менеджеров. Любое решение стоит ресурсов – часов работы продуктовой команды, которые могли бы заниматься чем-то более полезным или не работать вообще, не сжигая бюджет бизнеса.

Для того, чтобы определить верное решение, которое принесет выгоду, используют разные методы: например, А/Б-тестирование. Грубо говоря, это сравнение двух равнозначных вариантов: скажем, двух страниц сайта, чтобы посмотреть, на какой странице пользователи чаще оформляют заказы. По данным блога VWO, только один из восьми А/Б-тестов заканчивается успехом – остальные не выявляют статистически значимый результат. На один тест может уйти 10, 20, 30 и больше часов работы продуктовой команды – представьте, сколько это в деньгах.

А теперь вопрос: как представить работу над продуктом в рамках жесткого фреймворка? Обновления продукта еще можно подогнать под жесткий подход, где вместо требований заказчика будут гипотезы, основанные на продуктовых метриках. Но работа над продуктом с нуля обернется эпичным провалом. Гипотезы команды и заказчика, указанные в требованиях, будут не более, чем гипотезами: а значит, тратой бюджета в никуда.

Иногда пользователям нужно всего-ничего: поэтому лучше стартовать с MVP, постепенно добавляя новые функции

Жесткий подход оптимален в работе над проектом.

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

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

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

А теперь рассмотрим фреймворки, с помощью которых можно систематизировать гибкий подход к разработке – Agile и Scrum.

Scrum

Scrum – это фреймворк для организации работы продуктовой команды согласно подходу Agile. Это фреймворк, а не методология, потому что методологию можно внедрять частично, а у Scrum есть официальное руководство с условиями – все из них нужно соблюдать, иначе процесс нельзя будет назвать Scrum. При этом фреймворк достаточно «просторный»: его можно использовать совместно с другими методами и практиками, если те не будут противоречить условиям, описанным в руководстве.

Что нужно, чтобы внедрить Scrum

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

Спасибо, что не суисайд-сквад

Поскольку Scrum во многом нацелен на укрепление отношений между членами команды, она не должна быть большой. По нашим наблюдениям, в Scrum-команде должно быть от 3 до 7 специалистов. Для меньшего числа участников внедрять Scrum неэффективно, а если их будет больше, улучшить взаимодействие людей в команде будет невозможно. Просто не получится уделять достаточно внимания каждому из участников команды и его взаимоотношениям с другими участниками. А организация сплоченной, открытой и самоорганизующейся команды – одна из ключевых целей Scrum.

Как устроен Scrum

По сути, фреймворк нужен, чтобы команда за счет грамотной организации процессов регулярно обновляла продукт, с каждым разом делая его ценнее для пользователей. Этому служат все цели, что преследует Scrum.
Работа команды делится на циклы, которые называются спринтами (Sprint). У каждого спринта формируется цель (Sprint Goal), которая является релизом новой или улучшенной функции продукта. Чаще всего спринты длятся от 2 до 8 недель. Если сделать их дольше, они больше подвержены рискам, таким как невыполнение цели.

Участники Scrum-команды относятся к одной из трех ролей:

• Разработчики (Developers) – специалисты, которые работают над продуктом. Несмотря на название роли, у них может быть любая специальность.
• Владелец продукта (Product Owner) – чаще это доверенное лицо со стороны владельца продукта. Дело в том, что вряд ли настоящий владелец сможет активно вовлекаться в работу – не хватит времени. Роль выполняет строго один человек, который при необходимости будет представлять интересы возможных стейкхолдеров. Он приоритизирует задачи команды и следит за тем, чтобы продукт развивался в нужном направлении.
• Скрам-мастер (Scrum Master) – специалист, ответственный за внедрение Scrum, а через это – за формирование самоорганизованной эффективной команды. Скрам-мастером часто является специалист извне, потому что перейти на Scrum своими силами непросто. Если команда долго работает по Scrum, роль скрам-мастера может взять на себя один из разработчиков. При этом он должен четко разделять две выполняемые роли и ответственно относиться к каждой из них.

В руководстве по Scrum описано пять событий, одно из которых – спринт, а четыре других – встречи скрам-команды, которые проходят в рамках одного спринта.

Какие события входят в спринт:

• Планирование спринта (Sprint Planning). Это встреча, в рамках которой определяется цель спринта. Цель – это новая функция, которую планируется добавить в продукт с его обновлением после завершения спринта. В рамках планирования скрам-команда определяет, какие задачи нужно выполнить в рамках спринта, чтобы достичь цели.
• Ежедневный скрам (Daily Scrum). Это ежедневная короткая встреча, на которой команда «сверяет часы». На ней участники команды поочередно говорят, какие задачи планируют в этот день и с какими рисками при их выполнении они могут столкнуться.
• Обзор спринта (Sprint Review). Так называют встречу, которой завершается спринт. На ней скрам-команда делится результатами работы с заинтересованными лицами со стороны заказчика. Команда анализирует ход спринта, определяя: чего получилось достичь, какие изменения произошли в рамках спринта и над чем планируется работать дальше.
• Ретроспектива спринта (Sprint Retrospective). Это встреча, которая проходит следом за обзором спринта. На ней команда детально анализирует ход завершенного спринта: взаимодействие участников команды и проблемы, которые возникли в ходе спринта. Также изучаются попытки решения проблем: вне зависимости от того, сработали они или нет.
• Уточнение или груминг беклога (Product Backlog Refinement). Это событие отсутствует в руководстве по Scrum, но оно стало популярным среди скрам-команд. На нем участники оценивают трудоемкость и важность задач, которые хранятся в беклоге продукта (Product Backlog). Также команда помогает владельцу продукта сформировать условия задач, чтобы в будущем им было понятно, что именно нужно сделать.
• Если в компании много сотрудников, которые работают над продуктом, формируется несколько скрам-команд. У них даже может быть вертикальная иерархия – одна команда может управлять другими. В этом случае скрам-мастеров недостаточно – внедрение Scrum контролирует более опытный Agile-коуч. Также у Scrum есть аналоги для больших команд, такие как фреймворк LeSS – но об этом расскажем в другой раз.

А теперь рассмотрим Kanban.

Kanban

Kanban – это метод, главная цель которого – визуализация рабочего процесса для его непрерывного улучшения. В отличие от фреймворка, метод можно внедрять выборочно, используя только те инструменты, что подходят конкретно вам. Kanban перекочевал в IT из автомобилестроения – метод придумали в 1960-х годах в Японии, в компании Toyota.

Позже опыт переосмыслил Дэвид Андерсон – признанный эксперт, который внедрял Kanban в такие компании, как Microsoft. Он адаптировал Kanban для интеллектуального труда: когда не видно производственного процесса и он находится в головах людей. Современный Kanban уже сформировал свою инструментальную модель, отличную от когда то сформированных концепций Toyota.

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

Пример простой канбан-доски. Скриншот сделан в сервисе Kaiten

Как видите, канбан-доска напоминает конвейер, по которому движутся задачи. Анализируя ее, можно выявить «бутылочные горлышки» – места, где задачи задерживаются. Например, вы увидели, что много задач зависает на этапе проверки, отчего замедляется их выполнение. Данные позволяют вам решить проблему: например, назначить еще одного сотрудника на проверку задач.
Но канбан-доска – базовый элемент Kanban-метода. Для более точного анализа рабочих процессов используют специальные метрики и дашборды. С ними можно отследить эффективность сотрудников, время выполнения задач, длительность простоя задач на том или ином этапе и многое другое.

Метрики Kanban

Какие метрики есть в Kanban:

• Пропускная способность (Throughput Chart). Измеряет, сколько задач выполнила команда за определенный временной период.
• Время производства (Lead Time). Метрика, которая отслеживает, сколько времени ушло на выполнение задачи с ее создания до завершения (прохождения всех этапов).
• Время цикла (Cycle Time). Метрика, которая отслеживает, сколько времени уходит на выполнение задачи на том или ином этапе.
• Работа в процессе (Work in Progress). Это количество задач, которые находятся в работе в данный момент.
• Заблокированные задачи (Blocked Tasks). Количество задач, которые не выполняются по тем или иным причинам.

Пример диаграммы, которая показывает пропускную способность команды в разрезе по дням. Скриншот взят с сайта сервиса Kaiten

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

• WIP-лимиты. Так называется ограничение количества задач в работе. Например, можно поставить лимит в 2 задачи в столбец «Проверка». WIP-лимиты спасают сотрудников от расфокусировки, за счет чего повышается эффективность их работы.
• Приоритеты задач. Задаче можно присвоить особый статус, чтобы сотрудник выполнял ее в первую очередь.
• Блокировка. Специальный статус для отметки задач, которые нельзя выполнить по той или иной причине. При блокировке карточки можно указать причину, по которой она заблокирована: например, не отвечает заказчик. Отслеживание причин блокировки также позволяет выявить закономерности и оптимизировать рабочий процесс.

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

Какие каденции есть в Kanban и как часто их проводят:

• Ежедневная встреча (Daily Meeting). Служит для тех же целей, что и Daily Scrum – «сверить часы».
• Встреча по наполнению очереди (Replenishment Meeting). То же, что и уточнение беклога – определение задач на следующий временной период и их приоритизация. Обычно проводится раз в две недели.
• Встреча по планированию поставки (Delivery Planning Meeting). Встреча, на которой анализируются оставшиеся задачи, которые необходимо выполнить, чтобы доставить клиенту обновленную версию продукта. Обычно проводится раз в две недели.
• Обзор предоставления услуг (Service Delivery Review). Переговоры с заказчиком, на которых уточняется, доволен ли он работой. Обычно проводится раз в две недели.
• Обзор рисков (Risk Review). На этой встрече анализируются причины блокировок задач и предлагаются идеи по их устранению. Проводится примерно раз в месяц.
• Обзор операций (Operation Review). Это встреча представителей разных отделов, которая проводится, чтобы улучшить рабочие процессы между отделами. Проводится раз в месяц.
• Обзор стратегии (Strategy Review). Встреча, на которой отслеживается прогресс выполнения долгосрочных целей и при необходимости корректируется стратегия. Проводится раз в квартал.

Далее рассмотрим, что нужно учитывать, чтобы работать по Kanban.

Как работать с Kanban

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

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

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

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

Улучшайте рабочие процессы. Главная цель Kanban – постоянное улучшение рабочих процессов. Данный принцип напоминает об этой цели.

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

А теперь о самом интересном: можно ли внедрить себе и Scrum, и Kanban.

Можно ли использовать Scrum вместе с Kanban

Сразу ответим: да, можно. Более того, фреймворк и метод отлично сочетаются друг с другом: многие онлайн-сервисы для управления проектами уже оптимизированы под такую систему.

Например, в специализированных сервисах можно создать скрам-доску, которая по сути является канбан-доской с четырьмя столбцами: «Бэклог», «Выбрано в спринт», «В работе», и «Готово». А примером Kanban-метода в Scrum можно считать планирование на основании статистики.

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

Примерно так выглядит доска для Scrum, которая включает в себя инструменты Kanban-метода. Скриншот взят с сервиса WEEEK

Резюмируем

Лучших подходов, методологий и фреймворков для управления процессом разработки нет – все они «заточены» под ту или иную задачу:

• Agile-фреймворки и методы нужны для постоянной работы над продуктом с высокой степенью неопределенности.
• Kanban-метод по мнению его авторов не входит в Agile-когорту. При этом используя определенные наборы инструментов и практик Kanban-метода можно прийти к реализации тех же принципов, что и в Agile. Kanban можно использовать как в продуктовом и проектном управлении, так и в классическом менеджменте.
• Классические фреймворки нужны для управления разработкой конечных проектов с бюджетными и временными рамками. Для этого используют такие методологии, как PRINCE2 и PMI.

И помните, что если вам необходима консультация или помощь по внедрению современных управленческих практик – вы можете обратиться в Neogenda.

Артур Нек

Эксперт и практик в области стратегического менеджмента и организации работы на уровне правления компании. Эксперт и практик по OKR, Agile, Scrum, Канбан Методу, классическому Проектному Управлению — PMI и Prince2. Руковожу изменениями на уровне всего бизнеса, опыт построения предсказуемого потока поставки ценности в компаниях численностью более 5000 человек.