О SCRUM и альтернативном подходе.

Основная проблема SCRUM в продуктовой разработке — фокус на процесс, а не на продукт.

Если на фичу нужны 3 недели, разработка займёт 3 недели. Тут не помогут:

‣ Фиксированные по времени спринты и burndown chart;
‣ Искусственные встречи: ежедневные стендапы, ретро, груминги и планирования.
‣ Оценка задач через покер по Фибоначчи с запретом брать в спринт что-то более 8 SP.

Наоборот, время на разработку увеличится из-за отвлечения на церемонии. А еще и фичу порежут, если в очередной спринт не поместится целиком.

Не лучше было бы забыть о спринте и сделать хорошо? Важен ведь не инкремент продукта в течение недели (длины спринта). Важно, что увидит 👀 пользователь и как это повлияет на метрики.

Почему бы не определять спринт только целью, отказавшись от времени?

Знаю разработчика, который ушел в менеджмент и организовал всё именно так. Получилось похоже на Scrumban.

В команде 10-12 человек, из них создаются 3 виртуальные команды.

Каждая виртуальная команда работает над своим спринтом. Цель спринта — фича. Спринт остается открытым, пока фича не готова к релизу.

Если в рамках спринта разработчик закончил свою работу, допускается его перевод в другую виртуальную команду, на устранение техдолга или багов.

Вместо ежедневных стендапов для всех — частные стендапы для виртуальных команд.
Вместо регулярных грумингов и покера — встреча аналитика и разработчика, где вместе разбирают и оценивают задачу.
Во всех непонятных ситуациях менеджер принимает решение, что делать.

Минусы:
- Менеджеру приходится заниматься менеджментом.
- Система зависит от менеджера.

Плюсы подхода:
+ Меньше простоя.
+ Быстрее time-to-market.
+ Отсутствие иллюзии контроля сроков разработки.

Последний пункт про то, что в SCRUM якобы можно координировать команды спринтами. За 10 лет опыта (аутсорс разработка, Yandex, SberDevice, австралийский стартап) не помню ни одного случая, чтобы за спринт сделали все задачи спринта.