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

28 апр. 2020 г. 4 min read

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

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

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

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

Сердцем Скрама является Спринт, период времени не более одного месяца, в течение которого создается потенциально готовый к релизу инкремент продукта (Руководство по Скраму, 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.
  • Масштабируемый Скрам — все тот же Скрам: один Бэклог Продукта, один Владелец Продукта, один готовый к релизу инкремент.
Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.