Комментарии 1
Я как-то вступил в достаточно жесткое противостояние с менеджментом на тему Agile и Scrum. Менеджмент требовал полного соответствия комитменту, чтобы велосити был не толькл стабильным, так ещё и рос каждые несколько спиртов, т.к. якобы наша компетенция растет. Причем когда мы говорили, что задача на несколько спринтов и ее хрен нарежешь, заставляли нарезать, и очевидно резали почти наугад и само собой в 90% случаев не попадали, потому что то, что думали будем делать долго, делали быстро, а то, что думали сделаем быстро - делали долго. И рапорты каждый раз по одному месту. И никак этого не избежать, т.к. делали уникальный продукт (аля продвинутый зум со встроенным OBS на webrtc). И менеджмент сам не понимал - результаты на дистанции несколько месяцев феноменальные, а отчёты непонятные. Их прямо ломало от этого, они не могли четко "планировать". Хотя какое тут планирование, неизвестность за каждым углом, сегодня план один, завтра другой и это и есть Agile в своей крайней степени.
Я же объяснял, что менеджменту надо сфокусироваться на продукте, ценности и на оценке ситуации, а не на показателях отчётов по спринту в Jira. Задача будет сделана тогда, когда будет сделана. На планинге скоуп и риски оцениваются приблизительно, на основе того, что команда знает в момент оценки о задаче. Далее команда даёт ежедневный статус апдейт, какое состояние, переоценивает риски. Менеджер должен внимательно слушать, анализировать и если нужно менять вектор, забивая на цели спринта и коммитменты, если появляется что-то более приоритетное или оказывается, что риски были взвешены неправильно и надо срочно менять тактику. О том, почему они были взвешены неправильно и можно ли было что-то изменить обсудите уже на ретро, но выкореживаться, чтобы получить "хороший" отчёт вредит вообще всем.
В этом плане объективно самым гибким методом является scrumban - нет никаких спринтов, команда работает по обстоятельствам. При этом присутствует цикличность ритуалов вроде рефаймерта, демо, ретро, иногда даже хай левел планинга. Но для этого нужно, чтобы либо команда была самоорганизована и сама драйвила продукт (0.1% команд на такое способен), либо чтобы был толковый менеджер, а не "менеджер по методичке".
Менеджеры обиделись, не уверен, что прислушались. А я забил болт на их нытье и делал по кайфу, т.к. знал, что делаю максимум и с точки зрения исполнения быстрее команда не сделает.
От velocity к value: как эволюционирует Agile в 2025 году