Vasya Pupkin
Хорошее замечание. Тогда скажите, пожалуйста, на сколько спринтов вперед у вас оценен бэклог? Вырисовывается понимание - что _весь_ бэклог оценен и распланирован исходя из ритма команды, так?
Естественно он может пополняться, но если, например, мы взяли проект - вы, получается, делаете его декомпозицию сразу же - всего известного на момент старта, в противовес тому, что "давайте разложим и проценим 1-2 месяца работ, а вот это все - когда дело дойдет"?
Иными словами весь заявленный scope оценивается и декомпозируется сразу же, а поступающие запросы на изменения просто изменяют бэклог и также оцениваются по мере поступления, бэклог переприоретизируется и переразбивается на спринты (в соответствии с тем же ритмом команды)?
Я правильно идею уловил?
По моим наблюдениям (на НАШЕМ продукте) планирование бэклога на два Спринта вперед бессмысленно. Ситуация меняется каждую неделю. Мы готовим задачи примерно за неделю до Планирования. И даже в этом случае они тухнут иногда. Полная неопределенность. Хотя есть и дедлайновые истории, например, требования регулятора. Если мы говорим о проектной разработке, то там ситуация совсем другая. Ты понимаешь Скоуп на весь срок проекта, появляется возможность долгосрочного планирования. Потому смысл в Спринтах теряется. не нужен там Аджайл как правило. Если вспомнить Сноудена с его фреймворком Кеневин, то мы почти в Хаосе и следующий шаг нам становится понятным только после того как мы сделаем предыдущий (НА НАШЕМ Продукте) . Мы больше не знаем чем знаем, когда пробуем работать с какой-то гипотезой. Мы не знаем что у нас получится и в какой степени мы достигнем целей. В этом смысле теряется роль экспертов-аналитиков. Все меняется так быстро, что завтра их знания устаревают и они перестают быть экпертами. В проектах мы знаем результат заранее, нужно лишь его достичь.