Скрам начинается с готового к релизу инкремента

Фейковые Спринты

Работая с большим количеством продуктовых групп и компаний, мы замечаем паттерн — команды не умеют создавать готовый к релизу инкремент каждый Спринт. Команды опираются не на свои возможности, а на опыт других команд/компаний: начинают работать двухнедельными Спринтами.

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

Сердцем Скрама является Спринт, период времени не более одного месяца, в течение которого создается потенциально готовый к релизу инкремент продукта (Руководство по Скраму, 2017).

Спринт контролирует риски

В продуктовой разработке инновации обычно создаются в трех категориях. Первая — пользовательский опыт (UX). Первый iPhone хороший пример того, как уникальный пользовательский опыт сделал продукт невероятно успешным. Вторая категория — технологии. Появление на рынке LED телевизоров и DVD-плееров в свое время было новым словом в технике. Третья категория — бизнес-модели. Платформы AirBnb, Uber, облачный сервис Amazon изменили наше представление о том, как можно строить бизнес. По сути, речь идет о трех видах риска, с которыми работают в продуктовой разработке: 

  • Desirability:  пользовательский опыт и функциональность продукта востребована клиентами. 
  • Feasibility: техническое решение реализуемо.
  • Viability: продукт приносит прибыль, бизнес-модель масштабируется.

Спринт — ключевой инструмент управления рисками. Как минимум раз в Спринт команда создает готовый к релизу инкремент, чтобы снижать каждый из трех видов рисков.

Спринты поддерживают предсказуемость, обеспечивая инспекцию и адаптацию прогресса к достижению Цели Спринта, по крайней мере, каждый календарный месяц. Спринты ограничивают стоимость риска календарным месяцем (Руководство по Скраму).

Хочу поделиться историей из своего личного опыта. Восемь лет назад я был начинающим Скрам-мастером и работал со своей первой Скрам-командой. Во время недельного старта мы определили видение и Бэклог Продукта, сформировали DoD, который обеспечивал releasable. Начало было многообещающим. 

Через несколько Спринтов мы получили первую эмпирическую информацию. Провели релизное планирование с Владельцем Продукта и выяснили, что функциональность, на которую он рассчитывал, не будет готова даже через год, исходя из эмпирической информации. 

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

На Команду Разработки стали оказывать давление, чтобы увеличить количество выдаваемых фичей в Спринт. Я как Скрам-мастер не смог защитить команду, команде пришлось жертвовать качеством и скоро Definition of Done (DoD) стал неактуален и забыт. Команда перестала заниматься авто-тестированием и следить стандартам качества кода. За несколько месяцев, несмотря на то, что это был небольшой стартап, технический долг вырос как снежный ком. 

Наконец, Владелец Продукта принял решение о выходе в релиз. Команда не смогла это сделать сразу. Ей понадобился месяц. Результаты первого релиза были крайне неутешительными. Фичи, на которые делали ставки, оказались никому не нужны. Продукт, как говорится, “не взлетел”. У стартапа оставалось финансирования на полгода. И когда Владелец Продукта понял, что стартап теперь находится на грани выживания, осознал необходимость в быстрой проверке гипотез, которые бы сделали функциональность привлекательной (desirable). К сожалению, накопленный за месяцы технический долг теперь жестко ограничивал Владельца Продукта в возможности качественных частых релизов. 

Итересно, чем все закончилось? Финал истории: продукт, о котором вы никогда не узнаете, потому что он мертв. Вот так несоблюдение правил Скрама и, в первую очередь, создания готового к релизу инкремента как минимум раз в Спринт — помешали бизнесу взять контроль над рисками и создать успешный продукт.

Чем определяется длина Спринта

Готовый к релизу инкремент тесно связан с длиной Спринта. С точки зрения системного мышления, оптимальная длина Спринта является результатом двух балансирующих петель. Первая из них — объем риска, который берет Владелец Продукта. Чем больше длина Спринта, тем больше объем риска и его стоимость.

Но Скрам понимает, что люди бывают излишне оптимистичными, как в той истории, которой я поделился. Поэтому максимально допустимый объем риска в Скраме — месяц. С другой стороны, длина Спринта ограничивается возможностями Команды Разработки. Уменьшая длину Спринта, транзакционные расходы, скорее всего, возрастают (встречи, ручное тестирование и т.д.). Это снижает эффективность разработки (efficiency) и повышает ее стоимость. Таким образом длина Спринта — договоренность Скрам-команды об отрезке времени, за который бизнес готов брать на себя определенный объем риска, а Команда Разработки может поставить готовый к релизу инкремент как минимум раз в Спринт.

В течение многих лет я, как практикующий Скрам-мастер, толерантно относился к тому, что мои команды не могут за двухнедельный Спринт поставлять готовый к релизу инкремент. И да, мы работали фейковыми Спринтами. Сейчас, когда я начинаю работать с новой командой, мы формируем Definition of Done (DoD) = releasable и начинаем соблюдать его с первого же Спринта. И тогда часто выясняется, что две недели — не самый оптимальный таймбокс. И команды начинают работать Спринтами длиной три или даже четыре недели, потому что накладные расходы слишком велики, чтобы поставлять готовый к релизу инкремент каждый Спринт. В хорошем Скраме команды никогда не жертвуют качеством и прозрачностью артефактов.

Масштабируемый Скрам — тот же Скрам

Мой опыт последних лет связан исключительно с масштабируемой разработкой, когда много команд работают из одного Бэклога Продукта с одним Владельцем Продукта. Меняется ли что-то в этом случае? Мы часто повторяем, что масштабируемый Скрам — всё тот же Скрам.

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

  • Исходя из текущего уровня инженерных практик команды, какая должна быть оптимальная длина, если каждый Спринт должен заканчиваться готовым к релизу инкрементом?
  • Учитывая, что Definition of Done (DoD) = releasable, какой реалистичный объем работы вы возьмете в Спринт?

Ответы на эти вопросы могут вас удивить. 

Основные мысли статьи:

  • Спринт фейковый, когда он не завершается готовым к релизу инкрементом.
  • Спринт контролирует три вида риска: desirability (привлекательность), feasibility (техническая реализация), viability (монетизация).
  • Длина Спринта определяется объемом допустимого риска, который берет на себя бизнес, и способностью Команды Разработки поставить готовый к релизу инкремент.
  • Стартуйте с Definition of Done = releasable.
  • Масштабируемый Скрам — все тот же Скрам: один Бэклог Продукта, один Владелец Продукта, один готовый к релизу инкремент.

Рекомендуемые тренинги

Сертификационный тренинг Professional Scrum Master (PSM) от Scrum.org. Глубоко погружаемся в Скрам, его принципы и масштабирование. Обсуждаем типичные кейсы, возникающие в работе Скрам-мастера. Учимся работать на уровне команды, продуктовой группы и организации.

Продвинутый курс Professional Scrum Master II (PSMII) + Scrum Patterns для Скрам-мастеров с опытом больше года. Решаем кейсы, изучаем интересные техники фасилитации, применяем системное мышление, Скрам-паттерны и готовим вас к сертификации Professional Scrum Master (PSMII).

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *