Сегодня, как обещала поговорим про канбан-метод. И первый вопрос к вам — работали ли вы по канбан-методу?
Во вчерашнем треде про канбан я мельком затронула тему канбан vs скрам. Сегодня предлагаю об этом порассуждать twitter.com/produnderhood/…
Распространённый паттерн таков: скрам в продуктовой команде, канбан — в сервисной.
Продуктовая команда: нет внешних блокировок, 1 заказчик, фиксированный скоуп спринта.
Сервисная: много заказчиков, внешние блокировки, скоуп изменчив
Почему скрам не ок для сервиса?
Весь подход строится вокруг понятия «инкремент» => мы четко понимаем, что получим в конце спринта. Метрики не учитывают затраты на переключение контекста, если такое произошло. Результат — задачи переходят из спринта в спринт, не завершаясь
Признаки, что скрам сейчас не для вас
- сложно или невозможно сформулировать цель спринта
- каждый спринт часть задач не завершается
- не понятно, что показывать на демо
Как справляется с этим канбан?
Система ограничена количеством рабочих элементов in progress. При этом новую работу мы можем взять не когда система доделала всю работу (спринт), а когда освободился следующий слот. Что взять следующим определяет SRM по понятным для всех правилам
SRM — service request manager, управляет входящим потоком запросов (upstream) от многих заказчиков (или от одного — не важно, сколько их). Именно он решает, что войдёт в систему следующим. Роль похожа на PO в скраме
Когда задача передана в работу (мы взяли обязательства, что поставим ее) за ее поставку в обещанный срок с заявленным качеством отвечает SDM (service delivery manager). Роль похожа на SM в скраме
Вы наверное заметили, что в канбан нет понятия Dev Team. Главное отличие канбан от скрам — мы концентрируемся на рабочих элементах, а не на людях. Все метрики канбан характеризуют рабочие юниты, поэтому метрик типа «счастье команды» не существует
С сервисами разобрались. Что про продукт?
Скрам проявляется во всей красе именно в продуктовой разработке, так как сама идея скрама заточена под инкрементальное развитие и захват рынка. Главное — помнить, что вы = продукт, и не превращаться в сервис
Можно ли реализовать продуктовый подход в канбан? Легко!
Пополнение и освобождение системы — один раз в 2 недели, нужные каденции (дейли, пополнению, планирование поставки, обзор поставки, опс ревью), описание задач в виде US, формулирование цели поставки при планировании
Чем же фактически являются скрам и канбан, и можно ли их сравнивать?
Скрам — фреймворк процесса, заточенный под решение конкретных задач
Канбан — набор практик и принципов, «конструктор», из которого вы можете собрать процесс под ваши цели
Проще говоря, скрам является частным случаем канбан-системы. Со своими особенностями, служащими конкретной цели.
Поэтому скрам можно запросто дополнять другими практиками канбан, надстраивая и расширяя его возможности. Они абсолютно друг другу не противоречат
Получается, еще один миф разрушили 🤗 канбан и скрам — друзья и соратники
Ксю Коновалова