Комментарии
Поскольку я нигде не видел такого подхода в литературе и не встречал в жизни, мне не терпится рассказать про эту простую идею. Итак, ситуация.
Свежая идея: Scrum ++
Поскольку я нигде не видел такого подхода в литературе и не встречал в жизни, мне не терпится рассказать про эту простую идею. Итак, ситуация.
Владимир Завертайлов
Владимир Завертайлов
Фото с сайта: successpatheducation.com

Поскольку я нигде не видел такого подхода в литературе и не встречал в жизни, мне не терпится рассказать про эту простую идею. Итак, ситуация.

Проект идет двухнедельными итерациями. Заказчику слишком не терпится ждать конца итерации. И хочется запускать новые фичи в работу раз в 3 дня или типа того.

Естественно, делать трехдневные спринты — дикий оверхед (более частое планирование, ретроспективы, прогон тестирования). Помог бы канбан, но использовать не хотим т.к. нужно будет полностью отдать тестировщика команде разработки в этот проект, а это — дорого. Кроме того, мы заинтересованы в планировании долгосрочной загрузки команд (если вдруг фонтан задач иссякнет — мы бы хотели знать про это недельки за две, чтобы перепланировать команду на другой проект). Итого:

Мы хотим:

  • Планировать на 2 недели или более.

Заказчик хочет:

  • Cтавить в работу мелкие фичи раз в 3 дня.

Все хотят:

  • Избежать дополнительных расходов на QA, планирование, ретроспективы.

Спринт планируется как обычно, но добавляется пара резервных задач. Формулировка их пока не известна. Но точно известно, что эти задачи в сумме не должны превышать 20 часов.

Возможное решение (кликабельно):

Раз в 3 дня (например, в четверг и во вторник), заказчик может докинуть задачек, но не более, чем на резервные 20 часов. Если задачек не добавили — просто берем и делаем следующую фичу из бэклога. Понятно, что при таком процессе жизненно необходимо постоянное обновление демо-сервера, иначе новые фичи могут быть не совсем адекватны. Но это у нас есть ;-).

Из минусов подхода можно отметить:

  1. Выполнение новой фичи в спринте не гарантировано (например, если команда будет не успевать или неправильно оценит скоуп новой фичи).
  2. Команде или менеджеру нужно будет потратить какое-то время на оценку фичи.