Почему не работают спринты?
Если в одном (или двух, или даже нескольких) чатиках про техдирство/техлидство/тимлидство сказать слово "agile" или, упаси боже, "скрам", сразу прибегает толпа свидетелей бесполезности спринтов и в подробностях рассказывает ужасы о сектантах скрама, эффективных менеджерах и закидывают ссылками на то, как они убили целый бизнес.
Начинаем разбираться, как они готовили ЭТО. У них есть спринты -- обычно 2-недельные и иногда 3-недельные. На планировании берётся пачка задач из беклога. Демо и ретро обычно нет -- времени на это нет. Ну зачем демо, если на прод выкатили и так всё видно. А на ретро пробовали пару раз -- всё, что надо, сказали, больше говорить нечего. Пользы особо нет -- так зачем тогда всё это? А на серьёзных проектах так не то, что пользы, -- сроки так и так утекают.
Да? Всё вот так вы себе представляете? Тут есть пара ключевых неточностей, которые постоянно ускользают от внимания уважаемых зубров разработки.
Скрам и agile -- это история не про смузи, а спринты -- это не про календарь. Спринт -- это заранее сформулированное бизнес-языком измеримое улучшение продукта.
Это не "возьмём в спринт 100500 задач из беклога и попытаемся сделать, сколько успеем". Это про вполне структурированный список вида:
- Запустить новый платёжный шлюз.
- Уменьшить скорость suggest-поиска с 3 секунд до 1 секунды.
- Согласовать с product owner-ом окончательный вид интерфейса анкеты кредитования.
И под каждую цель прописывается перечень конкретных задач с точной оценкой. Потом эта точная оценка суммируется и проверяется на впихиваемость в спринт. Если не уверены, расписывайте расписания по дням, когда задачи будут выполнены.
Чувствуете? Спринт -- это про прозрачность того, к чему бежим. И в начале сразу понятно -- всё ли сделали, чтобы добежать?
А в конце демо показываем, что прибежали. И ретро -- разбираемся, что делать, чтобы снять все те блокеры, что мешают работать!
