Привет! Меня зовут Елена, я недавно перешла работать в SM Lab руководителем продукта Портал поставщика. Портал – это рабочее место поставщиков товарной продукции в Спортмастер и Остин. Решение представляет собой трехслойную систему со множеством интеграций и витиеватым функционалом. Локализация интерфейсов, инструкций и обучающих курсов на трех языках, в миссии – простота и удобство пользования.
В SM Lab продуктовый подход, поэтому я зашла в готовую команду. Её особенность в том, что она достаточно большая – 17 человек. В этой статье я хочу рассказать о том, как мы внедрили относительные оценки работ и что получили в результате.
Оценка в лоб
Наш продукт востребованный, важный и ценный для бизнеса, поэтому передо мной прямо с порога возникла задача оценки сроков реализации очередной доработки.
Что делать? Собрала команду, мы вместе спроектировали решение, декомпозировали его на задачи, оценили каждую, просуммировали трудозатраты, округлили в большую сторону, еще раз посмотрели на итоговую цифру, подтвердили, я передала прогноз бизнесу и выдохнула. А потом подсчитала, сколько стоила подготовка прогноза, и ужаснулась.
Во-первых, 17 человек – это немало, и 1.5 часа командной встречи — это почти чел/неделя.
Во-вторых, команда работает по Kanban, и у нас нет выделенного времени на подобные мероприятия.
В-третьих, product lead до меня 3 года работал в продукте, поэтому мог дать верхнеуровневую оценку без привлечения команды, т.е. без лишних трудозатрат.
Взвесив все это, я поняла, что, если резко не научусь ускорять и удешевлять подготовку оценки, у меня просто разовьется комплекс вины перед заказчиком.
Так как продукт живой, времени до следующего запроса от бизнеса было немного, а тут еще и конец финансового года замаячил с дорожной картой на следующий год…
Как быть? Я вспомнила про относительные оценки. На самом деле, я никогда ранее сама с ними не работала, но, как и многие, читала, слышала, могла поддержать разговор.
Относительные vs Абсолютные
Что я знала об относительных оценках? Относительные оценки противопоставляют абсолютным оценкам.
Абсолютная оценка – это оценка в человеко-часах.
Абсолютная оценка – родная дочка «водопадного» подхода. Получили проект, разбили на задачки, подсчитали затраты в часах для каждого участника, согласовали с заказчиком, пошли копать. При этом абсолютная оценка не такая точная, как хотелось бы. Причин много: и специалисты – большие оптимисты при оценке своих работ, и работы по проекту не всегда предсказуемы, и по 8 часов непрерывно никто не сидит над задачами, и прочее.
Вместе с гибким подходом к разработке появляются относительные оценки.
Относительные оценки – это оценки через сравнение. Например, эта задача такая же простая, как та задача, или эта задача такая же непонятная и геморройная сложная, как вот та.
Единицы измерения относительных оценок самые разные:
• Сторипойнты (1SP, 2SP, 3SP, 5SP, 8SP)
• Размеры маек (S, M, L, XL)
• Животные (хомяк, котик, барбос)
и многие другие.
Как применять?
Если требуется оценить выполнение задач одним специалистом, проще применить алгоритм абсолютной оценки: спросить, сколько времени он потратит на решение каждой задачи, и подсчитать сумму.
Если необходимо оценить выполнение множества задач кросс-функциональной командой, лучше использовать относительные оценки. Например, если над каждой задачей работает аналитик, разработчики front, rest, бд, тестировщик, собирать оценки с каждого - тот еще квест.
Было бы здорово придумать свои оригинальные единицы измерения, но времени для творчества не было, а размеры маек в общем-то тоже
относились к нашей тематике.
Как мы внедрили относительные оценки?
Буквально по щелчку пальцев????
1. На ретроспективе посмотрели закрытые задачи за прошедший месяц.
2. Выделили командой самые простые и быстрые – проставили им размер S.
3. Выделили следующие по сложности задачи – проставили им размер M.
4. Аналогично выделили размеры для задач и L и XL.
5. Занесли описание размеров с примерами в базу знаний Confluence.
На ближайшей встрече по декомпозиции сразу указали в Jira размеры в майках для задач. По мере работ провели небольшое повторное обсуждение и внесли уточняющие примеры в базу знаний.
Больше мы описание размеров в Confluence не правили – двух встреч по 15 минут нам было достаточно, чтобы зафиксировать правила оценки задач в майках для нашего продукта.
Внедрить относительные оценки - легко, потому что, на самом деле, в жизни мы их все уже внедрили. Когда мы обсуждаем новые задачи между собой, мы говорим: «Это легкотня» или «Это ппц», или «Тут надо подумать». Это и есть относительные оценки: мы интуитивно даем оценку через сравнение с задачей из своего прошлого опыта.
Как в теории перейти от оценок задач к прогнозам реализации user-stories?
Чтобы от прошлого перейти к будущему, нужно выполнить следующие шаги:
1. Перевести майки в сторипойнты: XS (1SP), S(3SP), M(5SP), L(8SP), XL(13SP).
Стандартно для ориентировочного шага между относительными оценками применяют коэффициенты из ряда Фибоначчи (1, 2, 3, 5, 8..). Почему не 1, 2, 4, 8, 16? Чтобы не усложнять. Если решить, что задача M в 2 раза больше, чем задача S, невольно при оценке будешь задумываться – а точно ли в 2 раза? Шаг у ряда Фибоначчи позволяет больше абстрагироваться от оценки в часах.
2. Подсчитать среднюю скорость команды:
где SP1...SPN – количество в сторипойнтах, а n – количество спринтов или релизных циклов.
Чем большее количество спринтов участвует в подсчете, тем более усредненной и точной будет рассчитанная скорость. Из формулы важно исключить дефекты и другие непредвиденные вбросы, таким образом мы заложим ресурс на работу с задачами такого рода в будущем.
3. Скорректировать скорость с учетом мощности команды:
где P-количество участников команды, D-количество дней, T-рабочее время.
Если впереди сезон отпусков, мощность команды уменьшится, а значит, уменьшится и скорость.
Как мы в команде перешли к прогнозам на практике?
1. Закрыли 3 релизных цикла по 1,5 недели.
2. Я посмотрела статистику закрытия задач без учета проблем с приоритетом critical, сформулировала прогнозы реализации 7-ми user stories (у нас – эпиков) ближайшей бизнес-инициативы (3 месяца).
3. В конце ежедневной летучки за 10 минут согласовала прогнозы с командой.
4. Представила бизнесу наш прогноз и показала, как он был рассчитан.
На подготовку прогноза я потратила примерно 2 часа. Представляю, сколько времени мы с командой из 17 человек потратили бы на абсолютную оценку реализации 100+ задач.
Относительные оценки хороши тем, что снимают вопросы типа: «А кто так оценил? Я тогда болел?» или «А почему заложили так мало времени? Надо было побольше». Точнее, не снимают вопросы, а дают ответ – всегда можно объяснить и показать на закрытых задачах, как на пальцах, почему сформирован именно такой прогноз.
При этом, прогнозы в относительных оценках легко объяснимы бизнесу, и это еще один плюс в копилку.
Безусловно, за следующие 3 месяца работы над бизнес-инициативой мы то немного опаздывали по срокам, то слегка опережали их. Тем не менее, прогнозы, полученные таким нехитрым и дешевым (ура!) способом, позволили нам с командой реализовать большую бизнес-инициативу из семи эпиков вовремя.
Помимо прочего, тот факт, что команда сама утвердила подход к расчету сроков, и, фактически, сами дедлайны для ближайшей доработки, очень мотивировало каждого участника вложиться в достижение нашей общей командной цели.
И немало важным бонусом стало то, что, привнеся этот новый подход к оценке задач, я смогла повысить доверие команды ко мне и моим начинаниям.
В следующий раз расскажу об одном любопытном кейсе, с которым мы столкнулись при внедрении относительных оценок.
Надеюсь, мой опыт покажется кому-нибудь из вас интересным и полезным.
Спасибо, что дочитали до конца!
Комментарии (17)
AlexunKo
22.11.2022 03:32+1Если требуется оценить выполнение задач одним специалистом, проще применить алгоритм абсолютной оценки: спросить, сколько времени он потратит на решение каждой задачи, и подсчитать сумму.
Как все просто и предсказуемо.
easchabanova Автор
22.11.2022 08:21Потом использовать формулу по 3-м точкам, результат умножить на фокус-фактор, поделить на...))) снова не просто)))
RuslanShevyrev
22.11.2022 08:21+1Еще в книге Чистый Agile описывалось, как они оценивали трудоемкость.
Брали первую задачу, она к примеру занимала 3 часа. А потом оценивали сложность задачи относительно первой голосованием. Собирали всю команду и спрашивали во сколько по вашему эта задача тяжелее эталонной (первой). Они на бумажке писали числа и потом их ответы усредняли. По-моему еще откидывали самый маленький результат и самый большой. В итоге получали оценку команды, во сколько данная задача сложнее первой и получали ее трудоемкость.easchabanova Автор
22.11.2022 08:26Похоже на покер планирования! Думаю, если небольшая команда - очень применимо! А на удаленке - особенно!)) Как говорится, совместить приятное общение с полезным процессом оценки) А вы пробовали?
RuslanShevyrev
22.11.2022 09:27Когда я работал в одной команде мы пытались что то подобное внедрить, но там все застопорилось на том, что оценку задачам выдавал отдел аналитики и изменить это в компании силами своей команды мы не смогли. А сейчас от меня предварительной оценки вообще не требуют)
easchabanova Автор
22.11.2022 09:51Наверное, снова упирается во время( Если собирать оценки - это прям затратно(( а вам хотелось бы участвовать в подготовке прогнозов реализации по задачам своей команды?
kolipass
22.11.2022 17:08+1В Essential Kanban есть раздел про прогнозирование, а в красной(синей) книге про канбан метод использование оценок, полученных от экспертов, рассматривается как ненадёжный, подрывающий основы SLA механизм.
Не пробовали опираться на подобные инструменты?easchabanova Автор
23.11.2022 08:16Спасибо за ссылку на книгу! Именно такую не читала, с удовольствием посмотрю)
По поводу вероятностного прозгнозирования - мне оно близко, потому что это объяснимая заказчику математика. Но считаю, что в жизни метод Монте-Карло и пр применимы только если на входе разделять user-story по объему и сложности + собирать данные для похожих user-story + именно на основе этих данных строить вероятностные прогнозы.
Даже в примере из Essential Kanban прогноз звучит как: с 50% вероятностью - 06.05, с 85% вероятностью - 20.05, с 95% вероятностью - 27.06. Разброс дат - 2 месяца, причем, если внимательно посмотреть на график попаданий, то там не 95%, а, скорее, 5%:)
А вот если на входе поделить user-story по размеру и сложности. Например, 1) есть класс user-story, который содержит 1-3 простые понятные задачи 2) есть класс user-story, который содержит 3-10 простые понятные задачи и тд...то для каждого класса user-story диапазон вероятностных дат поставки будет намного уже, при этом он будет таким же правдивым. И так как этот класс надо определять на входе, это снова похоже на относительные оценки - только не задач, а user-story.
Очень интересный вопрос, как раз хочу в него зайти, но не с целью прогнозирования сроков, а поисследовать скорость команды.
Результатами обязательно поделюсь)
kolipass
23.11.2022 16:17Предлагаю перед изучением скорости команды, всё таки сходить к Андерсену в синюю(красную) книгу. Там путёво рассказано, как всё таки мерить пропускную способность команды. Эта метрика покажет как следить за скоростью и прогнозировать.
easchabanova Автор
23.11.2022 16:35Эту книгу я как раз читала) Интересно, а в работу вашей команде все user-story одинакового размера поступают? Так бывает?)
Считаю, если пропускную способность оторвать от размера и сложности задач, На графике увидеть ускорение или замедление не получится. В один период реализовано 4 объемных user-story, в следующий - 4 мелкие, а остальное время команда учились, например. Вот на графике без привязки к размеру и в том, и в другом случае будет 4 user-story.
shabanista
23.11.2022 12:59+1Хороший подход к оценкам, интересно увидеть продолжение, как на основе этих оценок рождаются сроки и как несколько сторей вводятся на ПРОД
funca
На самом деле нет. Разработка это не как станок, это как футбол. То что ваши спортсмены в прошлом квартале забили 5 мячей и пропустили 2, ровным счетом ни чего не говорит о том, сколько они забьют или пропустят в следующем году. Можно устраивать тотализатор и принимать ставки.
В абстрактно-математическом смысле, расчет статистической вероятности выпадания орла или решки подразумевает, что вы кидаете одну и ту же абстрактную монетку, одним и тем же абстрактнвм способом в одних и тех же абстрактных условиях. Но для реальных данных, будь то ретроспективные, или прогнозируемые - контекст все время разный. Поэтому отклонения будут непременно. Раз так, то ключевой момент здесь это не точность прогнозов, а интерпретация отклонений, с пользой для
себядела. Все что нужно - это внедрить подходящий ментальный фреймворк (ну или миф).Договорились с ними на оценку по ретроспективе? - отлично! Теперь у вас есть моральное право митинговать риски, делегируя последствия за факапы либо в никуда, либо в внутрь них же самих. Все же верят
трем видам лжистатистике? Ну дескать вот раньше все успевали, а тут не успели, видимо не доработали, расслабились - значит сами виноваты. На такие ритуалы и в самом деле нет смысла тратить кучу ресурсов - меньше времени на раздумья, больше времени мячи гонять. Ну, а заказчику регулярно напоминать: estimates are NOT commitment.easchabanova Автор
Интересная тема, на какой вид спорта похож процесс разработки:)) Думаю, зависит от уровня специалистов в команде. Иногда на наш футбол, где все мало предсказуемо, а иногда на синхронное плавание:) Я согласна, что любые прогнозы - это всегда не 100% вероятность, поэтому жалко тратить время синхронистов на уборку бассейна:)))
funca
Классная метафора. :) Просто так не бывает. Бывает так, что у вас нет отдельного
вечно-бесплатногоресурса ни на уборку, ни на ремонт бассейна. Все сами. Сами все делаем, сами выступаем, сами иногда обделываемся (физиология, пресловутый человеческий фактор) и сами же потом чиним и убираем. Ну или откладываем уборку с починкой в беклог задачза которые нам ни кто ни когда не заплатит. А пока пытаемся производить на публику тот же эффект, делая те же фигуры, но уже в немножко мутной и слегка попахивающей воде, под чуть-чуть протекающей крышей. Публика негодует и отказывается платить. Мы признаем ошибки на ретро и обещаем в следующем спринте показать ещё больше трюков, занырнув вообще на самую глубину)).Разработка ещё похожа на дженгу, только наоборот: мы строим башню, добавляя кубики разного размера (M, L, XXL, вот это вот все)
до тех пор, пока она не развалится. Ну и если на начальных этапах стройка идёт быстро потому, что кубики, даже самые огромные, встают просто на ровный стол, то дальше у них появляются зависимости, когда их приходится ставить уже друг на дружку. Маленькие на большие, большие на маленькие. Хорошо если у всех был четкий план и кубики на нижних ярусах стоят ровно и надёжно. Но нередко бывает, что кто-то поспешил все успеть и поставил свой маленький кубик немножко криво, или не убрал за собой лишнее. Таким образом у новой смены прибавляется немножко работы и эстимации даже для самых простых задач начинают плыть в далёкие края.А бывают моменты, что очередной точно такой же кубик нужно запихнуть в середину. Ну вот так получилось. То есть для этого надо теперь или пересобрать половину башни, или нагородить каких-то ацких подпорок. И тогда объем работы увеличивается уже не на немножко, а может и ни в какой бюджет.
В общем, я это к чему. Планы ни что, планирование - все. И сокращать на это время - правильно. Но
кажущиеся на первый взглядразмеры кубиков это лишь пол беды. Многое зависит от архитектуры и согласованности работы команд. Если пытаться заменить всем этим планированием и проектирование, то вы просто сократите время до катастрофы).easchabanova Автор
Во всем с вами согласна!!! Спасибо за такое интересное сравнение! Возьму на вооружение!)