Каждая команда, в которой я работал последние 10 лет, использовала Scrum. И почти каждый раз это было как забивать шурупы молотком - вроде работает, но зачем?
Как выглядит Scrum, когда он не подходит
Стандартная ситуация: бизнес меняет приоритеты чаще, чем длится спринт. Что делает команда? Придумывает костыли.
Мы считали статистику - сколько "внезапных" задач прилетает за спринт. Планировали буферы. Использовали исторические данные для предсказания объема изменений. Спринты стабилизировались.
А потом на ретро мы обсуждали, как сделать так, чтобы спринт не ломался. И тут я задал себе вопрос: а зачем мы вообще боремся за сохранение искусственного ограничения?
Мы взяли молоток и тратили ретро за ретро, придумывая, как использовать его как монтировку. Вместо того чтобы просто взять монтировку.
4 слоя оверхеда
Когда Scrum не подходит бизнесу, но ты продолжаешь его использовать, получается цепочка:
- Создаешь искусственное ограничение - спринт фиксированной длины
- Команда тратит ресурсы, чтобы в него вписаться - буферы, перепланирование, статистические модели
- Команда тратит ресурсы, чтобы объяснить бизнесу это ограничение - "нет, в этот спринт уже не влезет"
- Бизнес тратит свои ресурсы, чтобы адаптироваться - планирует запросы заранее, ждет следующего спринта
Четыре слоя оверхеда. Ради процесса, который должен был все упростить.
Почему Kanban работает лучше
Kanban - это конвейер. Берешь задачу, делаешь. Одно правило: начал - закончи. Ты уже вложил ресурсы, получи бизнес-ценность, ради которой начинал.
Следующая задача? Может поменяться в любой момент. И ничего не ломается.
Одно простое правило вместо десятка костылей.
Бизнес может менять приоритеты без чувства вины за "сломанный спринт". Команда перестает тратить энергию на защиту коммитментов, которые уже не отражают реальность.
А как же планирование?
"Но без спринтов нельзя планировать" - самое частое возражение. Можно.
Планирование есть. Ретро есть. Ты просто убираешь ту часть, которая создавала трение.
Для прогнозирования сроков я использую trailing velocity - сколько story points команда закрывает в неделю за последние 4 недели и за последние 12 недель. Это дает стабильную статистику и честный прогноз.
Работает лучше любого спринтового коммитмента, который все равно летит после первого спринта.
Когда многоспринтовое планирование - потеря времени
Я видел, как продакты расписывали по 5 спринтов вперед. Красивые таблицы, все разложено по командам и капасити.
После первого же спринта приоритеты менялись, появлялось новое понимание, и все эти планы превращались в "ну, примерно, в общем направлении идем".
С Kanban проще. Есть роадмап - примерное направление. Есть бэклог с приоритетами. Есть trailing velocity для прогнозов. Хочешь поменять приоритет - просто меняешь. Конвейер продолжает работать.
Итого
Scrum отлично работает там, где бизнес стабилен и приоритеты не меняются быстрее спринта. Но если твоя реальность - постоянные изменения, попробуй убрать искусственные ограничения и дать конвейеру просто работать.
А у тебя какой опыт? Работает ли Scrum в твоей команде или тоже чувствуешь, что что-то не так?
Искусственный интеллект, Технологии, Программирование