Comments 35
Хм, интересный подход… Но изменилось ли что-нибудь при таком подходе в конечном счёте?
Сервис стал более предсказуемым
Он правда таковым стал?
Каков процент тасок того или иного типа реально попадает в новые договорённости (интересны именно таски, которые были выполнены уже после новых договорённостей), и на каком объёме задач этот анализ построен?
И устраивает ли "заказчика" такой процесс?
Еще момент. SLA стоит пересматривать с какой-то периодичностью. На него могут влиять различные факторы: от расширения команды до «лето это особенное время».
И кстати, а почему "время производства задачи" идёт именно от "готово к разработке", а не от старта технического ревью? Это же ведь обязанность тех. команды? Или в новом процессе нет никакого технического ревью? А как тогда определяется тип задачи (блокер/важная/регулярная)?
А как тогда определяется тип задачи
Это определяется не на тех. ревью. Есть квоты: может быть всего 2 важные задачи. А мы добираем 4. Соответственно, две из четырех идут как регулярная работа. А какая задача важнее определяет заказчик (Ваня). Мы лишь ограничиваем его.
а не от старта технического ревью?
Можно и от старта технического ревью считать. Нужно просто договориться где точка коммита. И согласны ли вы на такой риск — давать коммит по задаче, до того как обсудили тех. решение. Мы решили, что для нас «готово к разработке» это отличный вариант.
Ну и у нас, все-таки, вероятностное распределение. Мы действительно что-то выпускаем раньше потому что делаем/тестируем быстрее, но это только какой-то % от всех задач конкретного класса обслуживания. И это тоже можно проанализировать, вы можете добавить к своим классам обслуживания еще тип работ. Например, можно дать отдельный SLA по багам в классе обслуживания «Важный».
оценка задачи определяет сколько ресурсов на нее требуется
и нужно для планирования спринтов
а время появления в проде определяет то, в какой спринт попадет эта задача
В статье же предлагается объединить оценку трудоемкости и планирование спринтов(не связанные в общем вещи) в одной оценке.
Довольное странное решение, если учесть что то когда брать задачу зависит от бизнес приоритетов, и слабо завязано на трудоемкость выполнения.
Скорее всего это местная специфика, когда все поступающие задачи обязательно делаются в порядке поступления. Бывает и другая организация, когда по итогам оценки трудоемкости приоритет задач может меняться, вплоть до отказа от задачи.
Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.
Вероятно, потому, что оценка отвечает на вопрос "сколько" и не отвечает на вопрос "когда".
Помогает понять, сколько задач можно запихнуть в спринт. А в чем их измерять — в story points, человеко-часах, футболках или тортиках — не суть важно.
Я же вам сказал — «приходите завтра». А вы всё время сегодня приходите...
А с вероятностью 90% это займет 14 дней.
По-моему, формулировка не верна. Такой вывод можно было бы сделать, если бы 90% задач были в сегменте «14» на оси LT
Кажется, вы имели в виду: с вероятностью 90% задача доедет до прода в течение 14 дней. Т.е., 90% задач уезжали на прод раньше чем за 14 дней.
Если спринт недельный, то и таски должны быть выкачены через неделю. А то, что у вас таска кочует из спринта в спринт — неправильная декомпозиция и оценка.
Тут очень сильно зависит от того, какой запрос (и майндсет) у продакта. Если он приходит с вопросами «через сколько времени такая-то задача будет на проде», то твоя идея (и канбан) работает хорошо. Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам. Если продакт мыслит потоком отдельных плюс-минус изолированных задач — канбан. Если еженедельными инкрементами — скрам.
Если вы можете запланировать себе на месяц работы и гарантировать, что ничего нового не прилетит за этот месяц — это круто! А если вы еще и выполните всё, что на месяц напланировали — значит у вас нет проблем! У нас так не получается, поэтому мы используем такой подход.
Мы договорились на ограничение по количеству задач в классе обслуживания: нельзя взять больше двух блокеров, нельзя взять больше двух важных задач.
Как вы поступаете в случаях, если от заказчика приходит больше двух блокеров? Например это разные заказчики, и каждый их них аргументирует почему эти задачи важны именно сейчас.
Как вы поступаете в случаях, если от заказчика приходит больше двух блокеров?
Ресурс разработки в любом случае ограничен. Придется выбирать, что из этого несет больше ценности или у какого таска стоимость задержки выше. Когда хотя бы один блокер вылетит из системы — будет возможность поднять приоритет еще какому-то элементу.
Например это разные заказчики, и каждый их них аргументирует почему эти задачи важны именно сейчас.
В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.
В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.
Алгоритм со слотами в общих чертах понятен, хотя если опишите более подробно кейсы, буду очень благодарен.
Но больше даже интересно именно взаимодействие с клиентами, которые аргументируют важность их задач здесь и сейчас.
хотя если опишите более подробно кейсы
Когда в «Готово к разработке» остается 1 — 2 элемента, то инициируется встреча по пополнению. У каждого заказчика есть квота и он может отдать только определенное кол-во своих задач.
Но больше даже интересно именно взаимодействие с клиентами, которые аргументируют важность их задач здесь и сейчас.
В подходе описанном выше возможен еще и дополнительный эффект. Например, заказчики могут начать договариваться между собой и предоставлять друг другу эти самые квоты: «Петя мне очень надо, дай мне свой слот, а я тебе в следующий раз дам вообще 2 своих!». У нас примерно так и происходит (только у нас нет квот). Задачу в разработку может поставить только менеджер продукта (по сути, он SRM). И он договаривается с заказчиками.
Попробуйте сделать правила работы явными. Если все, в том числе вы сами, будете понимать по каким критериям вы решаете, что одно важнее другого и опишете эти правила — уже станет легче.
Майки, деньги, два торта: как мы разучились оценивать задачи