О чем говорит Velocity.
Концепция Velocity означает:
Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.
Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.
Но даже в этом случае Velocity не показывает:
- Была ли решена проблема клиента.
- Занимаемся ли мы самыми приоритетными проблемами клиента.
- Объем поставленной ценности.
- Степень удовлетворенности клиента.
Velocity лишь показывает, что команда была чем-то занята.
Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?
Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов.
Velocity компонентных команд = 0
Самая стабильная скорость у компонентных команд. Потому что она всегда равна нулю. Компонентные команды по определению не в состоянии конвертировать элементы Бэклога Продукта в ценность для клиентов. Для этого необходима, как минимум, интеграция с другими компонентными командами.
Когда у команды Undone
Самая опасная, с моей точки зрения, динамика запускает в случае, когда Команда Разработки не в состоянии поставлять каждый Спринт готовый к релизу инкремент продукта. Это значит, что Releasable = DoD + Undone. Давайте сначала рассмотрим системную диаграмму, которая показывает связь между объемом DoD и организационной гибкостью.
Чем сильнее DoD, тем меньше объем несделанной (Undone) работы в Спринт. Несделанная работа ограничивает команду в количестве потенциально возможных релизов и, как следствие, объеме получаемой с рынка обратной связи. Чем объемнее обратная связь с рынка, тем больше Владелец Продукта может принять решений по ре-приоритезации Бэклога Продукта. Это и есть организационная гибкость — быстрая смена направления развития продукта. Ощутимые результаты могут подтолкнуть Скрам-команду предпринять дополнительные действия для создания еще более сильного и исчерпывающего DoD.
Усиливая DoD, Velocity становится более реалистичной
Как отражается усиление DoD на Velocity? Команда за тот же период времени (Спринт) должна выполнять больший объем работы над инкрементом продукта. Velocity, как минимум, в краткосрочной перспективе снизится. И это не страшно, потому что мы оптимизируем скорость потока ценности (фичи начинают быстрее “пробегать” от разработки до релиза). Velocity становится более реалистичной.
Насколько вероятно, что Команда Разработки будет предпринимать действия по усилению DoD, зная, что ее эффективность оценивают по Velocity?
Ответ лежит на поверхности. Это маловероятно. Таким образом:
Фокус на Velocity убивает организационную гибкость.
И я, будучи молодым и неопытным Скрам-мастером много лет назад, излишне фокусировал свои команды на скорости, снижая их гибкость и увеличивая количество несделанной (Undone) работы.
Теперь мой совет начинающим Скрам-мастерам теперь звучит так:
Забудьте о Velocity, если ваша команда не может поставлять потенциально готовый к релизу инкремент каждый Спринт. Фокусируйтесь на усилении DoD.
Что же тогда мерять
Я рекомендую фокусироваться на метриках, которые показывают способность быстро доносить ценность на рынок и удовлетворять потребности клиентов. Например, компания Scrum.org разработала концепцию доказательного менеджмента (Evidence-Based Management), и предлагает набор метрик, показывающих:
- Способность команды создавать ценность в долгосрочной перспективе
- Скорость поставки ценности и метрики, измеряющие поток (Time 2 Market).
- Фактическую ценность, поставленную на рынок.
Завершая
Хочу есть раз повторить основную мысль, которую хотел донести с помощью этой статьи. Основная идея Скрама — создание потенциально готового к релизу инкремента каждый Спринт. Если ваша команда уже там, то концепция Velocity полезна и действительно демонстрирует скорость, с которой команда конвертирует элементы Бэклога Продукта (PBL) в готовый к релизу инкремент. Если нет, займитесь усилением Definition of Done (DoD) и оптимизацией потока.
Основные мысли статьи
- Velocity означает Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.
- Velocity не показывает решаются ли проблемы клиентов, поставляется ли ценность, оценивая лишь объем выработки.
- Velocity показывает, что команда была чем-то занята.
- Velocity компонентных команд всегда равна нулю.
- В случае существования Undone и сохранения фокуса на Velocity, команда не заинтересована в усилении DoD и, как результат, организационной гибкости.
- Фокус на Velocity убивает организационную гибкость.
- Фокусируйтесь на фактически доставленной на рынок ценности.
