Я с вами согласен, но я не предлагал объединять планирование спринтов и оценку трудоемкости. У нас нет спринтов. Приоритет так же влияет на то, в какую очередь задача пойдет в работу. У нас заканчиваются задачи -> мы набираем еще -> я могу дать SLA по каждой и озвучить его заказчику.
Когда в «Готово к разработке» остается 1 — 2 элемента, то инициируется встреча по пополнению. У каждого заказчика есть квота и он может отдать только определенное кол-во своих задач.
Но больше даже интересно именно взаимодействие с клиентами, которые аргументируют важность их задач здесь и сейчас.
В подходе описанном выше возможен еще и дополнительный эффект. Например, заказчики могут начать договариваться между собой и предоставлять друг другу эти самые квоты: «Петя мне очень надо, дай мне свой слот, а я тебе в следующий раз дам вообще 2 своих!». У нас примерно так и происходит (только у нас нет квот). Задачу в разработку может поставить только менеджер продукта (по сути, он SRM). И он договаривается с заказчиками.
Попробуйте сделать правила работы явными. Если все, в том числе вы сами, будете понимать по каким критериям вы решаете, что одно важнее другого и опишете эти правила — уже станет легче.
Тут не решается проблема «что выкатить первее». Вы запланировали на месяц 4 фичи в 3 + 5 + 2 + 3 = 13 сторипоинтов. И тут в середине месяце заказчик приносит что-то новое и хочет это дать вне плана. Я могу ответить ему через сколько это «вне плана» появится на проде и как это скажется на остальных фичах в плане срока.
Если вы можете запланировать себе на месяц работы и гарантировать, что ничего нового не прилетит за этот месяц — это круто! А если вы еще и выполните всё, что на месяц напланировали — значит у вас нет проблем! У нас так не получается, поэтому мы используем такой подход.
Как вы поступаете в случаях, если от заказчика приходит больше двух блокеров?
Ресурс разработки в любом случае ограничен. Придется выбирать, что из этого несет больше ценности или у какого таска стоимость задержки выше. Когда хотя бы один блокер вылетит из системы — будет возможность поднять приоритет еще какому-то элементу.
Например это разные заказчики, и каждый их них аргументирует почему эти задачи важны именно сейчас.
В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.
Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам.
Если заказчик не пытается в спринт вбросить что-то, что важнее того, что уже в спринте и если за спринт закрываются все взятые в него задачи — ваш скрам, действительно, работает хорошо)
Многие, почему-то, заострили внимание на этом. Мы пытались ответить заказчику на вопрос «Когда?» и один из вариантов был заложить в Estimate всё, что только можно. Разумеется, это не работает. Я бы мог просто описать метод, которым мы в итоге пользуемся, но решил, что лучше расскажу всё как было. Вдруг это кому-то поможет не наступать на наши грабли.
Я бы, наверное, сформулировал так: с вероятностью 90% это не должно занять больше 14 дней. Интересное замечание, если честно. Озвучивая срок в 14 дней, мы оставляем пространство для маневра и не создаем ложных ожиданий. Т.е., мне кажется, если изменить формулировку, то может и измениться поведение человека. Но, возможно, я перегибаю :)
Если посмотреть данные за последние 3 месяца (~90 тасок) будет около 75% попадания в SLA. Важно анализировать почему мы не попадаем в SLA. Это может быть проблема в сервисе, которую мы не учли и тогда мы можем придумать какое-то решение, внедрить его, посмотреть на метрики. А может быть осознанный выбор согласованный с заказчиком.
Еще момент. SLA стоит пересматривать с какой-то периодичностью. На него могут влиять различные факторы: от расширения команды до «лето это особенное время».
Т.е. у вас никогда не переносились задачи из одного спринта в другой? Просто «появления в проде определяет то, в какой спринт попадет эта задача» звучит как решение всех проблем.
Реальный размер задачи — это время в системе. Вас могут попросить перекрасить кнопку в другой цвет. Это легко, но на проде окажется через неделю просто потому что «не до этого». Сложность/Размерность задачи выравнивается за счет времени в статусах ожидания (в Канбан это называется эффективность потока).
Ну и у нас, все-таки, вероятностное распределение. Мы действительно что-то выпускаем раньше потому что делаем/тестируем быстрее, но это только какой-то % от всех задач конкретного класса обслуживания. И это тоже можно проанализировать, вы можете добавить к своим классам обслуживания еще тип работ. Например, можно дать отдельный SLA по багам в классе обслуживания «Важный».
Это определяется не на тех. ревью. Есть квоты: может быть всего 2 важные задачи. А мы добираем 4. Соответственно, две из четырех идут как регулярная работа. А какая задача важнее определяет заказчик (Ваня). Мы лишь ограничиваем его.
а не от старта технического ревью?
Можно и от старта технического ревью считать. Нужно просто договориться где точка коммита. И согласны ли вы на такой риск — давать коммит по задаче, до того как обсудили тех. решение. Мы решили, что для нас «готово к разработке» это отличный вариант.
Когда в «Готово к разработке» остается 1 — 2 элемента, то инициируется встреча по пополнению. У каждого заказчика есть квота и он может отдать только определенное кол-во своих задач.
В подходе описанном выше возможен еще и дополнительный эффект. Например, заказчики могут начать договариваться между собой и предоставлять друг другу эти самые квоты: «Петя мне очень надо, дай мне свой слот, а я тебе в следующий раз дам вообще 2 своих!». У нас примерно так и происходит (только у нас нет квот). Задачу в разработку может поставить только менеджер продукта (по сути, он SRM). И он договаривается с заказчиками.
Попробуйте сделать правила работы явными. Если все, в том числе вы сами, будете понимать по каким критериям вы решаете, что одно важнее другого и опишете эти правила — уже станет легче.
Если вы можете запланировать себе на месяц работы и гарантировать, что ничего нового не прилетит за этот месяц — это круто! А если вы еще и выполните всё, что на месяц напланировали — значит у вас нет проблем! У нас так не получается, поэтому мы используем такой подход.
Ресурс разработки в любом случае ограничен. Придется выбирать, что из этого несет больше ценности или у какого таска стоимость задержки выше. Когда хотя бы один блокер вылетит из системы — будет возможность поднять приоритет еще какому-то элементу.
В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.
Если заказчик не пытается в спринт вбросить что-то, что важнее того, что уже в спринте и если за спринт закрываются все взятые в него задачи — ваш скрам, действительно, работает хорошо)
Еще момент. SLA стоит пересматривать с какой-то периодичностью. На него могут влиять различные факторы: от расширения команды до «лето это особенное время».
Ну и у нас, все-таки, вероятностное распределение. Мы действительно что-то выпускаем раньше потому что делаем/тестируем быстрее, но это только какой-то % от всех задач конкретного класса обслуживания. И это тоже можно проанализировать, вы можете добавить к своим классам обслуживания еще тип работ. Например, можно дать отдельный SLA по багам в классе обслуживания «Важный».
Это определяется не на тех. ревью. Есть квоты: может быть всего 2 важные задачи. А мы добираем 4. Соответственно, две из четырех идут как регулярная работа. А какая задача важнее определяет заказчик (Ваня). Мы лишь ограничиваем его.
Можно и от старта технического ревью считать. Нужно просто договориться где точка коммита. И согласны ли вы на такой риск — давать коммит по задаче, до того как обсудили тех. решение. Мы решили, что для нас «готово к разработке» это отличный вариант.