Менеджмент цифрового продукта. От идеи до идеала

➠ непонятные цели поставленных задач или беспричинную срочность;

➠ двоевластие;

➠ недоступность владельца продукта или стейкхолдеров;

➠ выработку человеко-часов важнее ценности поставки,

то, скорее всего, Scrum/Agile внедрен в компании декларативно, а за фасадом скрываются совсем другие процессы.

В этом случае Scrum может показать обратную эффективность.

3.1.3.5. Связь между Scrum и водопадом

Когда функциональность ближайшего релиза определена, команда может использовать водопадный подход для планирования задач каждого участника внутри спринта, чтобы оптимальным способом достичь результатов. Но стоит добавить, что для оптимизации работы внутри спринта водопад не является единственной и лучшей практикой. Например, есть такие практики как «роение» (англ, swarming), которую мы обсудим в и. 3.2.4.2.

3.1.3.6. Kanban

Kanban (яп. , – вывеска, рекламный щит) – это важнейший элемент бережливого производства, который глубоко интегрирован в гибкие подходы к разработке.

Изначально Kanban был создан для визуализации прохождения артефактов в процессе производства Toyota.

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

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

На рис. 3.5 представлен пример Kanban для цикла дискавери.

Рис. 3.5. Пример Kanban для управления циклом открытий

Следует обратить внимание на ограничение количества спикеров в каждой ячейке (практика WIP limit[33]). Подобный подход не дает возможности сфокусироваться на одной работе за раз и, не накапливая промежуточные артефакты, доводить дело до конца.

Еще одна важная практика 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. Часто в этом значении используется термин «пилотный проект».