Поскольку я нигде не видел такого подхода в литературе и не встречал в жизни, мне не терпится рассказать про эту простую идею. Итак, ситуация.
Проект идет двухнедельными итерациями. Заказчику слишком не терпится ждать конца итерации. И хочется запускать новые фичи в работу раз в 3 дня или типа того.
Естественно, делать трехдневные спринты — дикий оверхед (более частое планирование, ретроспективы, прогон тестирования). Помог бы канбан, но использовать не хотим т.к. нужно будет полностью отдать тестировщика команде разработки в этот проект, а это — дорого. Кроме того, мы заинтересованы в планировании долгосрочной загрузки команд (если вдруг фонтан задач иссякнет — мы бы хотели знать про это недельки за две, чтобы перепланировать команду на другой проект). Итого:
Мы хотим:
- Планировать на 2 недели или более.
Заказчик хочет:
- Cтавить в работу мелкие фичи раз в 3 дня.
Все хотят:
- Избежать дополнительных расходов на QA, планирование, ретроспективы.
Спринт планируется как обычно, но добавляется пара резервных задач. Формулировка их пока не известна. Но точно известно, что эти задачи в сумме не должны превышать 20 часов.
Возможное решение (кликабельно):
Раз в 3 дня (например, в четверг и во вторник), заказчик может докинуть задачек, но не более, чем на резервные 20 часов. Если задачек не добавили — просто берем и делаем следующую фичу из бэклога. Понятно, что при таком процессе жизненно необходимо постоянное обновление демо-сервера, иначе новые фичи могут быть не совсем адекватны. Но это у нас есть ;-).
Из минусов подхода можно отметить:
- Выполнение новой фичи в спринте не гарантировано (например, если команда будет не успевать или неправильно оценит скоуп новой фичи).
- Команде или менеджеру нужно будет потратить какое-то время на оценку фичи.