О SCRUM и альтернативном подходе.Основная проблема SCRUM в продуктовой разработке — фокус на процесс, а не на продукт.
Если на фичу нужны 3 недели, разработка займёт 3 недели. Тут не помогут:
‣ Фиксированные по времени спринты и burndown chart;
‣ Искусственные встречи: ежедневные стендапы, ретро, груминги и планирования.
‣ Оценка задач через покер по Фибоначчи с запретом брать в спринт что-то более 8 SP.
Наоборот, время на разработку увеличится из-за отвлечения на церемонии. А еще и фичу порежут, если в очередной спринт не поместится целиком.
Не лучше было бы забыть о спринте и сделать хорошо? Важен ведь не инкремент продукта в течение недели (длины спринта). Важно, что увидит 👀 пользователь и как это повлияет на метрики.
Почему бы не определять спринт только целью, отказавшись от времени?Знаю разработчика, который ушел в менеджмент и организовал всё именно так. Получилось похоже на
Scrumban.
В команде 10-12 человек, из них создаются 3 виртуальные команды.
Каждая виртуальная команда работает над своим спринтом.
Цель спринта — фича. Спринт остается открытым, пока фича не готова к релизу.
Если в рамках спринта разработчик закончил свою работу, допускается его перевод в другую виртуальную команду, на устранение техдолга или багов.
Вместо ежедневных стендапов для всех — частные стендапы для виртуальных команд.
Вместо регулярных грумингов и покера — встреча аналитика и разработчика, где вместе разбирают и оценивают задачу.
Во всех непонятных ситуациях менеджер принимает решение, что делать.
Минусы:- Менеджеру приходится заниматься менеджментом.
- Система зависит от менеджера.
Плюсы подхода:+ Меньше простоя.
+ Быстрее time-to-market.
+ Отсутствие иллюзии контроля сроков разработки.
Последний пункт про то, что в SCRUM якобы можно координировать команды спринтами. За 10 лет опыта (аутсорс разработка, Yandex, SberDevice, австралийский стартап) не помню ни одного случая, чтобы за спринт сделали все задачи спринта.
