Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ?
Спасибо
Здравствуйте, vladpol, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
Классический ответ — занимается техническим долгом.
Но я бы не стал искать точных ответов в "теории", ничем хорошим это не закончится.
Здравствуйте, vladpol, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
Здравствуйте, vladpol, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
Зависит от ответа на вопрос "продаем, или покупаем?"
Здравствуйте, vladpol, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
В реальности — согласовывает это с продакт овнером. Не всегда делать больше, чем планировалось — гут.
В идеале — берет еще задач из беклога, на ретроспективе обсуждает причины недоестимейта и учитывает факт оверделивери в следующем спринте
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ?
Помимо описанных моментов у меня сразу возник вопрос — а почему реализовала досрочно? Неправильная оценка?
У нас периодически есть небольшой перехлест по задачам — на планировании спринта ставят задачи, которые по планам скорее всего не будут сделаны, но если возникнет свободное время их можно брать в работу.
Помогает, например, когда в этапе реализации приоритетной задачи возникает блокер и у разработчика появляется время.
Здравствуйте, vladpol, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
По классике берет еще story из backlog. В реале — все зависит от специфики проекта и от решения продакт овнера. Например, если из за новой стори есть риск поломать текущую стабильную сборку( что решается в принципе принципом — каждая story в своей ветке).
Здравствуйте, Владислав, Вы писали:
V>Подскажите, что говорит теория о случае когда команда досрочно до конца спринта выполнила все юзер стори на которые закомитилась? Берет следующие из бэклога? Отдыхает ? V>Спасибо
Качестве опорных "теорий" возьмем
1. Теория Ограничений Систем
2. XP/Agile/XSCRUM
3. Стандартное управление компанией.
4. PMBoK
С одной стороны, брать следующие без согласования с Владельцем Продукта она не может. Это приводит к перерасходу бюджета проекта (2).
С другой стороны простой команды тоже не хорошо, это приводит к потере прибыли Компании (3).
Поэтому варианта два:
1. применять среднесрочное планирование, планировать спринты на 1-2-3 вперед, чтобы можно было брать из следующего. Это снизит риск простоя. И будет получено согласование Владельца Продукта. (4, 2)
2. Собирать преждевременное ДЕМО , закрывать спринт. Далее на ретроспективе Проводить анализ причин и менять процесс так чтобы этого в будущем не случилось. (2)
В случае если работа сделана, но следующая работа зависит от другой группы, то команда ОБЯЗАНА отдыхать (1).
Иначе:
1. есть риск сделать НЕНУЖНУЮ работу, которую не готовы принять (заказчик, следующая группа), что приведет к увеличению ЗАПАСОВ (1).
2. есть риск зависнуть на не востребованной работе дольше, чем планировалось и не быть готовым начать вовремя. Другими словами, увеличится риск доступности ресурса (1).
