Еще одна важная практика Kanban – четкие критерии перехода из стадии в стадию.
Третий инструмент, «плавательные дорожки» (swimlane), позволяет видеть зависимости между двумя командами, которые работают в продукте, и приходить на помощь в случае, если у кого-то происходит «пробуксовка».
Kanban позволяет быстро выявлять проблемы в процессе. В случае, показанном на рис. 3.5, у второго владельца продукта происходит «затоваривание», он набирает много задач и из-за потерь на переключении падает фокус. При этом много задач застревает в накопителях, а значит, он не доводит дело до конца. У третьего владельца продукта проблемы другого рода – у него есть пустые ячейки, что говорит о том, что время, возможно, расходуется недостаточно эффективно.
3.1.3.7. Связь между Scrum и Kanban
Kanban может использоваться Scrum-командой для ежедневного отслеживания прогресса – движения элементов функциональности (пользовательской истории) от ToDo[34] к Done или для движения задач разработчиков в процессе выполнения одной пользовательской истории в отдельной дорожке (такой Kanban называется Scrum-доска или Scrum-борд).
Рис. 3.6. Scrum-доска (слева) и Kanban-доска статуса функциональности (справа) для управления спринтом в режиме «роения»
В примере на рис. 3.6 команда взяла в спринт три истории и разбила реализацию каждой из них на задачи отдельных исполнителей. Современные таск-трекеры типа Jira могут отображать Scrum-доску в двух представлениях: в разрезе задач и в разрезе поставленной функциональности (историй). Если все задачи по истории перенесены в Done, то и история переносится в Done. Подобный подход позволяет делать акцент на том, чтобы двигались пользовательские истории (конечный артефакт, ценный для пользователей), а не на том, как двигаются задачи разработчиков (промежуточный артефакт). Это позволяет избежать ситуации, когда к концу спринта закрыто большинство задач, но не сделано ничего ценного. Вторая хорошая практика – фокусироваться на одной истории за такт (практика «роение»). Это дает максимальный фокус и уменьшает потери при переключении между историями.
3.1.3.8. Бережливый стартап
Когда создается что-то новое, чего не было в опыте, мы действуем в хаотичном мире, и здесь лучше всего работает паттерн «действуй – ощущай – отвечай». В отличие от комплексного мира, где понятны направление и цель, в хаотичном работает модель постижения через действие – мы понимаем, куда двигаться дальше, только когда сделаем шаг.
Мы не можем спрогнозировать, будут ли пользователи покупать наш продукт, значит единственный вариант – провести эксперимент. Тут на помощь приходит упомянутый выше бережливый стартап. Суть подхода заключается в том, чтобы как можно быстрее пройти цикл «разработай – протестируй – доработай (или брось)».
Бережливый означает, что проверить потенциальную жизнеспособность продукта нужно с минимальным количеством отходов.
Для этого из продукта и из процесса его разработки нужно убрать все лишнее, чтобы минимальными затратами и максимально быстро проверить гипотезу жизнеспособности. Такой продукт называется минимально жизнеспособным продуктом или общепринятым сокращением MVP. Часто в этом значении используется термин «пилотный проект».
Представим, что мы решили запустить новый для себя бизнес по продаже винтажных велосипедов.
Вариант 1. Гипертрофированный водопадный подход:
➠ Закупить партию велосипедов.
➠ Арендовать склад.
➠ Арендовать магазин.
➠ Заказать брендинг для компании.
➠ Заказать дизайн интерьера.
➠ Сделать ремонт в магазине.
➠ Пошить униформу.
➠ Нанять персонал.
➠ Сделать сайт с каталогом продукции.
➠ Заказать в рекламном агентстве кампанию.
Вариант 2. Гипертрофированный Lean startup подход:
➠ Дать бесплатное онлайн-объявление о том, что продается винтажный велосипед, используя фото из интернета.
➠ В случае, если кто-то откликнется, перепродать велосипед, доставив самостоятельно.
➠ Проанализировать, может ли бизнес быть прибыльным и как увеличить объем продаж:
➠ заказ напрямую у поставщика;
➠ закупка оптом;
➠ организация собственной службы доставки;
➠ др. вариант.
➠ Итеративно внедрять улучшения в бизнес, чтобы дать ценность максимальному количеству пользователей.
Очевидно, что оба примера гипертрофированы и используются для того, чтобы максимально эффективно показать разницу в подходах.
34
ToDo (образовано от