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