Agile — мировоззрение, которое может проявляться в разных практиках, фреймворках и методологиях разработки. Считается, что Scrum лучше подходит для продуктов и развивающихся проектов. Канбан лучше подходит для поддержки и производства. Мнения могут быть разными. А кто-то вообще использует Scrumban. Он сочетает в себе лучшие функции обоих подходов. Scrumban становится очень популярным в различных сферах. В этой статье расскажем про данный гибрид для разработки продуктов.
В двух словах про Scrum:
- организация разделена на небольшие, кросс-функциональные, самоорганизующиеся команды,
- работа делится на список небольших, конкретных задач с ощутимым результатом,
- список работ рассортирован по приоритету и оценен по усилиям,
- вся разработка разделена на короткие итерации фиксированной длины (до 4 недель),
- после каждой итерации демонстрируется какая-то часть готового продукта,
- после каждой итерации процесс оптимизируется на ретроспективе,
- в начале новой итерации проходит планирование, с учётом отзывов заказчика.
Подробнее: что такое Scrum за 5 минут
В двух словах про Канбан:
- рабочий процесс визуализирован на доске,
- работа разделена на равные части, каждый элемент записан на карточке и повешен на доску,
- используются именованные столбцы, чтобы проиллюстрировать, где находится каждый элемент работы,
- у каждого столбца есть ограничение на количество одновременных карточек (WIP),
- измеряется время цикла — среднее время движения карточек по доске,
- команда старается оптимизировать процесс, чтобы уменьшить время цикла и сделать процесс более предсказуемым.
Подробнее: как управлять бизнесом по Канбан?
В Scrum вы заранее выбираете работу, которую будете выполнять в следующем спринте. У вас есть временные рамки одного спринта, чтобы закончить отобранные задачи.
В Канбан ограничение задаёт только WIP. Это означает, что вы можете изменить элементы в очереди в любое время, а «конца спринта» просто нет. Работа течёт непрерывно.
Scrumban = Scrum + Kanban
Чтобы внедрить Scrumban, не получится отказаться от Scrum с его итерациями. Нужно полностью овладеть и Scrum, и Kanban. Таким образом, неверно думать, что это более лёгкий фреймворк, где-то между двумя большими братьями.
В Scrumban используется доска для визуализации и ограничение на работу в процессе. Элементы из бэклога спринта выполняются последовательно, в колонку "В работе" не попадают сразу все карточки (хотя такое и не противоречит ScrumGuide). Поток работы выравнивается. Команды смотрят на процесс перехода карточек по доске, чтобы увидеть возможности для совершенствования. Kanban работает внутри спринта.
От Scrum в этот метод приходят церемонии, петли обратной связи для прозрачности.
В Scrumban мы можем выполнять планирование итераций через регулярные промежутки времени, синхронизированные с обзором и ретроспективой. При этом цель планирования — не заполнить всю очередь задач заранее, а лишь часть. Это значительно упрощает планирование. Сэкономленное время тем не менее тратится на лучшую подготовку задач.
Кому больше всего подходит Scrumban:
- проекты технического обслуживания,
- событийная работа,
- справочная служба или информационная поддержка,
- удалённые команды, которые работают над запуском новых продуктов,
- работа, предшествующая разработке, исследования,
- тестирование и развёртывание продукта,
- компании, где есть проблемы с чистым Scrum.
Практические черты Scrumban
Если вы собираетесь применять Scrumban, то вот так строится процесс:
- определяется регулярный размер итераций, который подходит для проекта,
- планирование, ревью и ретроспективы не отменяются,
- планирование ведётся для нескольких задач, но команда закладывается на то, что в задачах есть много подводных камней или прилетят другие задачи,
- приоритеты у всех задач расставляются, а сами задачи нарезаются на таски примерно одинакового размера,
- перед тем, как задача берётся в разработку, она должна быть проработана и проанализирована. Визуализация на доске — колонка Ready между Backlog и Doing.
- у колонок проставлен WIP — есть ограничение на количество задач в процессе работы,
- при этом чёткие роли не указаны, они вводятся по необходимости,
- в бэклог проекта попадают только те задачи, которые кем-то «заказаны», при этом отдельного бэклога нет, это колонка на доске всех задач,
- каждый день проводится дейли стендап, а другие церемонии по необходимости (но, как правило, проводятся),
- бэклога спринта нет, не ведётся Burndown, а новые задачи попадают на доску и в работу по необходимости,
- на ретроспективах в первую очередь команда работает над снижением времени цикла.
Но на самом деле, это лишь один из условных примеров реализации Scrumban. Он может корректироваться в сторону Scrum или в сторону Kanban, в зависимости от того, что нужно проекту и команде.
А вы пробовали Scrumban? Как он выглядит в вашей команде?