Бизнес-инкремент в конце спринта: давайте не будем натягивать настоящую работу на бесполезный формализм ℹ️ В прошлом посте поговорили немного про декомпозицию и затронули тему бизнес-ценности задач. Есть концепция: в конце спринта результатом задачи должен быть полезный бизнес-инкремент. Какая-то завершенная бизнес-ценность. Теоретики скрама очень за это ратуют и говорят, что это самое важное. ❓ Применима ли концепция к реальной разработке? Если мы говорим про большие продукты со сложными внутренними системами, не всегда получается адекватно декомпозировать задачу так, чтобы в конце первой или второй недели получить результат, который сразу даст пользу для бизнеса. Был у нас проект, где очень формально подходили к этому правилу. Команда тратила кучу времени на то, чтобы придумать задачи, которые уложатся в спринт и принесут конечный результат. В итоге получалось так: вроде какой-то результат они несут, а какой — непонятно. Придумывали какой-то бред, лишь бы формально соответствовать критериям. Заказчик считал, что раз формальные критерии соблюдены, все идет как надо. ❓ Когда действительно все идет как надо Есть задачи, которые действительно можно и нужно делать инкрементально. Новая форма на сайте, небольшая фича в интерфейсе, какой-то отдельный API-эндпоинт – это можно сделать за спринт и получить готовую ценность. Но есть задачи, где приходится прям натягивать сову на глобус. Например, рефакторинг архитектуры, миграция базы данных, переписывание легаси-модуля. Формально можно сказать «мы мигрировали 30% таблиц», но бизнес-ценность появится только когда миграция завершится полностью. ❓ К чему стремиться Ну, чтобы в конце спринта был адекватный результат, который приносит пользу. Но подходить к этому правилу нужно гибко. Не обязательно одна задача = один спринт = готовый бизнес-инкремент. Иногда это серия из нескольких задач на несколько спринтов, которая в итоге приведет к завершенной бизнес-ценности. Это нормально для больших и сложных задач. ❓ Что помогает Полезно, например, выделять технический долг и инфраструктурные задачи в отдельную категорию. Не нужно притворяться, что рефакторинг авторизации — это «бизнес-инкремент для улучшения безопасности пользователей». Это технический долг, он важен, но он не дает мгновенной бизнес-ценности. И это ок. Еще работает подход с вехами: разбить большую задачу на несколько спринтов, но четко обозначить, что законченная ценность появится на третьем спринте. Тогда все понимают, к чему идут, и не тратят время на выдумывание промежуточных инкрементов.