Путеводитель по оценкам задач и котики

Эта статья появилась по материалам моего выступления на Agile Days 2023. И в целом очень похожа на доклад своей повествовательной манерой. А также тут будет много котиков, чтобы не было скучно читать

Я решил поговорить об этой, казалось бы зажеванной теме по одной простой причине: у меня вызывает недоумение почему многие путаются в оценках. Поэтому я решил немного уменьшить эту путаницу и помочь коллегам использовать оценки по назначению.

В рамках этой статьи мы не будет обсуждать вот такие сложные штуки и особенно забористую научную информацию. Я не буду воскрешать COCOMO II и напоминать всем о том что такое функциональные точки.

Оценку в целом часто путают с похожими понятиями и вкладывают в нее тождественный смысл: это прогноз, цель, обязательства, план. Поэтому давай пойдем от обратного и ответим на вопрос “чем оценка не является”.

Прогноз - это предсказание о будущем состоянии некого объекта управления. Под объектом здесь и далее будут иметься в виду то что мы изучаем. Например, объект управления - команда, стрим, отдел.

У предсказания должна быть степень уверенности - точность прогноза.

При прогнозировании мы должны:

Цель - это некое конечное состояние, желаемый результат, которого стремится добиться объект управления.

Например скрам-команда стремится к цели продукта.

Обязательства - это преданность соблюдению договоренностей. Как пример в scrum это выражается через приверженность цели спринта.

Команда берет на себя обязательства достигать ее и ориентироваться в принятии решений в первую очередь на цель.

План - это инструкция, которое определяет действия, необходимые для достижения определенной цели.

Обычно он включает в себя шаги для достижения цели, ответственных за их выполнение, а также сроки и метрики для оценки результатов.

Типичные пример плана, это хорошо оформленная задача в jira. Особенно хороший пример формат user story.

Если сравнивать эти определения, то получится примерно такая табличка.

Прогноз это предсказание. Отвечает на вопросы “сколько” и “насколько это точно”.

Для этого нам нужны данные из прошлого и аппарат прогнозирования, которому их можно скормить. Часто и тем и другим служит человеческий разум.

Цель нужна чтобы объяснять зачем мы что либо делаем. Для нее нам нужно предположение о желаемом состоянии (прогноз).

Обязательства закрепляют взаимодействие. Кто и что должен сделать.

Для них нам нужно знать конечную цель и иметь общее представлении о взаимодействии.

План нужен чтобы окончательно убрать неопределенность и ответить разом на все вопросы.

Зачем, что, как мы делаем, кто это делает и где граница того что делать надо и не надо.

Для плана нам нужно знать цель, обязательства и прогноз.

Оценка - это установление наличия и степени проявления той или иной характеристики в объекте.

Оценка делается упростить жизнь, приведя множество сведений, которых мы знаем о задаче к какой-то одно величине, которой нам удобно оперировать.

Она отвечает лишь на вопрос “сколько чего-то” и не создает никаких рамок, как план или обязательства. В этой статье я не буду делать сильного различия между оценками и прогнозами, так как уже привык думать прогнозами)

Как это выглядит на примере, если примерять разные понятия к одной и той же ситуации - упал биллинг.

Даже если вы прочитали все что было выше, все равно останется соблазн путать эти определения. Это соблазн проистекает из того что эти понятия вложены друг в друга, как матрешка.

Вы можете помочь сами себе выбрать подходящее понятие для конкретного случая задавая вопросы. Например такие:

Есть достаточно ограниченное количество видов оценок задач. Любую оценку можно отнести к какому-то одному:

Почему отдельно выделил крайний срок от продолжительности? Потому что для крайнего срока нужно надо либо исходно знать ограничение по времени, либо крайний срок получается путем совмещения даты старта и продолжительности.

Давайте также пройдем краткий экскурс в свойства оценок. Есть ряд характеристик, по которым типы оценок можно сравнивать: объект измерения, аддититивность, однородность, погрешность:

Получается про любой вид оценок мы можем сказать: что оа измеряет, насколько точно, можно ли складывать оценки и можно ли их домножать на некие коэффициенты.

Давайте посмотрим какие свойства есть у каждого вида оценок. Как пример рассмотрим продолжительность, она измеряет время выполнение задачи. Такие оценки можно складывать и они сравнимы. Возьмем задачу в 10 дней. Она займет либо 5, либо 20 дней. Так тоже бывает.

Поясню насчет свойств, которые могут вызвать споры. Это мое личное мнение, которое я составлял на основе наблюдений и некоторых простых математических проверок, вроде проверки пространства на линейность, а также брал из научных источников.

Таблицу можно использовать как алгоритм выбора вида оценки и подбирать под ваш контекст то что вам удобно.

Также таблицу можно перевести в алгоритм. Получится что-то вроде этого.

У скрама существует краткое руководство, где описана его суть. В нем упомянут только размер. Утверждается «работа может быть разного размера или предполагаемого усилия» , гайд не предписывает, как должна выполняться эта оценка.

Но руководство по Scrum напоминает о необходимости использовать подход, учитывающий сложность разработки программного обеспечения, и рекомендует не позволять оценке заменить важность самого эмпиризма. Оценки это скорее мера обсуждения и понимания. И нужны только для этого.

Еще нужно учитывать, что существует не только скрам-команда, есть стейкхолдеры и им могут быть нужны другие оценки.

Ремарка про сторипойнты. Они не часть скрама и их нет в руководстве. Но они являются распространенной практикой, которую любят сочетать со скрамом, хотя иногда это даже противоречит его принципам (посчитали капасити и набираем задач под завязку).

Все вкладывают в них разный смысл и это превратилось в феномен каргокульта. Изначально они были идеальными человекоднями, сейчас некая комплексная мера.

Далее будет скорее авторская терминология, но нечто похожее вы наверняка видели и схема будет вам знакома.

Исторические оценки. Это любые оценки, которые основаны на данных из прошлого. Мы уже делали подобное и можем прикинуть каким будет результат в этот раз.

Эту информацию мы можем получить из разума людей - спросить их, узнать экспертное мнение, отсюда название.

Либо можем взять из каких-нибудь инструментов управления, например таск-трекера или гита.

Аналоговые оценки также основаны на данных из прошлого. Разница с историческими в том что работу делали не мы и используем мы данные не о своем прошлом, а о чужом.

Например, кто-то в другой команде делал похожую задачу, мы можем пойти спросить сколько она заняла.

Бывает в бенчмарк, это непосредственно сопоставительный анализ.

А прототип, когда мы делаем некое представление результата и уточняем у других оценку.

От ограничений. Интересный способ, который используется в областях со слишком большой неопределенность, когда мы почти ничего не знаем о результате.

В таком случае мы можем вместо оценки установить величину, которую мы максимально готовы инвестировать в задачу.

Идея проста - делаем ровно столько сколько уложится в ограничение, например 3 дня на изучение АПИ, дальше презентация того что получилось.

Параметрические. В целом похожи на исторические и по аналогу, но есть нюанс. Этот вид оценок требует разделения на элементарные операции, которые всегда одинаковы. Например, 1 обработка 1с пишется за 2 часа, если в задаче есть 5 обработок за 10 часов.

Как видите, когды вы задаетесь вопросом, а как нам оценивать задачи, не обязательно всегда спрашивать разработчиков.

Так как самым популярным на данный момент способом получения оценок является “пойди спроси людей”. Да и в скраме разработчики ответственны за оценки в бэклоге продукта, поэтому мы остановимся на теме экспертных оценок поподробнее.

Из моего опыта в командах нет единого понимания что мы оцениваем и каким образом. Вот так часто случалось раньше у нас на Product Backlog Refinement в стриме.

Поэтому самая полезная практика - выровняться в понимании того что вы оцениваете и как. Достаточно поговорить с командой и зафиксировать договоренности. Если вы используете относительные оценки, полезно где-то закрепить шпаргалку о что есть оценка и что точка отсчета.

Давайте поговорим про конкретные техники. Например покер планирование, популярный инструмент приведения группы к консенсусу. Ее часто отождествляют со сторипойнтами и относительной оценкой. На самом деле это скорее техника фасилитации, которую можно применять к любым оценкам.

Работает это так: заказчик рассказывает суть задачи, участники скрыто голосуют своими оценками одновременно, затем вскрываются, обсуждают самые противоречивые оценки и так голосуют до тех пор пока не придут к консенсусу по оценка. Суть в снижении влияния какого-то авторитета и в подсвечивании рисков.

Магическая оценка занятная техника, суть которой в том чтобы разместить на шкале оценок известную задачу и остальные задачи расположить относительно нее в несколько раундов.

Выбирается любая удобная шкала (нр, ряд Фибоначи). На ней устанавливается известная задача:

У этого метода есть усовершенствования, например ведерки “bucket system”.

Аффинитивная группировка. Первая задача читается членам команды и размещается на стене.

Читается вторая задача, и команду спрашивают, меньше она или больше первого элемента; размещение на стене соответствует ответу команды (больше справа, меньше слева).

Читается третья задача, и у команды спрашивают, меньше она или больше первого и/или второго тикета; элемент размещается на стене соответственно.

Это проделывается со всеми задачами. Для каждой группы потом просто назначается подходящая по смыслу оценка.

Еще иногда случается, когда у нас еще недостаточно информации для оценок. Поэтому стоит воспользоваться спайком. Спайк - это задача на исследование, чтобы лучше узнать о проблеме и возможных способах решения (типичный НИОКР на короткой дистанции).

Часто возникает комичная ситуация, спайк пытаются оценить.

Выход есть - не оцениваем сам спайк, оцениваем сколько времени мы готовы инвестировать в исследование и ставим ограничение срокам, когда по их истечению надо просто рассказать результаты.

Рассмотрим сперва полезные практики для отслеживания прогресса.

Произвольные суммы. Это эмпирические правила, которые не требуют знания о сути работы и сводятся к отслеживанию состояния. Вот пример такого правила 30/40/30:

Получается % прогресса отнимаем от исх. оценки и узнаем сколько осталось. Проценты и этапы могут быть любыми.

Буфер задачи. Эта техника родом из теории ограничения система. Как это задумано. Мы вытаскиваем переоценку из всех задач проекта и складываем в одну заначку, из которой будем таскать при необходимости.

С задачей поступаем аналогично. Мы устанавливаем буфер на непредвиденные случаи, когда что-то идет не по плану. Легкий способ установки буфера состоит в том чтобы поделить оценку пополам и заложить 50% в буфер. Продвинутый способ в том чтобы оценить отдельно каждый риск и просуммировать оценки рисков в буфер.

Как дела у задачи мы можем отслеживать по сгоранию буфера вот по такому графику. По вертикали у нас процент сгорания буфера. По горизонтали общий процент прогресса. По тому в какую зону у нас уходит график мы можем понять как у нас дела. Если график в зеленой зоне все хорошо, в желтой нормально, а в красной надо напрячься.

Также можно постфактум делать проверку оценок. Есть ряд метрик которые стоит выводить на дашборд.

Одна из них результативность - это степень реализации запланированной деятельности.

Рассчитывается по формуле: факт/план * 100%. Ее еще называют относительная погрешность измерения.

Это удобно делать по временным периодам, например спринтам и визуализируется просто линейным графиком.

Кстати эта метрика - основная зона ответственности скрам-мастера, а не эффективность, как многие думают прочитав некорректный перевод в руководстве по скрам. Именно на нее должен обращать наибольшее внимание скрам-мастер и помогать команде растить самоуправление чтобы они учились все лучше преодолевать препятствия.

Коэффициент прогноза - это доля прогнозов из общего числа которых мы считаем сбывшимися.

Как правило сбывшимся прогнозом считаем прогноз с точностью >75%.

У него нет какой-то особой визуализации графически, поэтому покажу просто пример расчета

Ошибка прогноза отражает среднюю приближенность оценки к факту и рассчитывается по след. формуле. Эту формулу еще называют средней ошибкой аппроксимации.

Ее часто используют для проверки прогнозирующих моделей, например линейной регрессии. Или Монте-Карло.

Если размер ошибки менее 15%, можно считать что наш аппарат прогнозирования работает хорошо.

Аналогично считают абсолютную среднеквадратичную ошибку. Да, это очень похоже на формулы стандартного отклонения.

Отдельно люблю наблюдать как люди переводят сп в часы. От этого желания можно избавиться, если посчитать корреляцию.

Коэффициент корреляции - это вероятность взаимосвязи двух переменных, когда изменение одной величины скорее всего как-то влияет на изменение другой.

Здесь речь пойдет про линейную корреляцию. Оно часто рассчитываем по формуле Пирсона. Это упражнение очень полезно проделывать для сторипойнтов, чтобы проверять действительно ли 3 сторипойнта это 3 дня как вы думали).

Корреляция выражается на графика вида “пузырьковая диаграмма”. И ее можно оценить графически, вот по таким правилам. Если точки выстроились в линию, то корреляция равна 1 и она прямая.

Тут образцы проверки корреляции на примере работы разных команд из разных компаний

Отдельно упомяну, что стоит проверять, контролируете ли вы ваш процесс. Может быть вы оцениваете просто хаос и ваши попытки похоже на попытки стрельбы в тире по пьяне. В таком случае не важно как вы оцениваете. Важна управляемость.

Визуализируется это типом графиков “контрольная карта”. Если взять скажем нашу команду и посмотреть на нее как на процесс, то можно взять за выход из процесса например число задач в спринт. Их можно нанести на график, где по вертикали число задач, а по горизонтали спринты. Если посмотреть на график, то окажется что мы делаем то 3, то 5, то 1 задачу. И процесс может быть не просто хаотичным, а неконтролируемым. Графически область контроля выражается через специальные границы, выход за их пределы означает выход процесса из управляемости.

Поэтому не забываем про статистический контроль процесса - управляемость, control chart.

Все определения, графики и материалы которые фигурировали в ходе этой статьи можно найти тут.

Я хочу, чтобы читатель статьи когда речь идет об оценках всегда задумывался над 4 вопросами:

Пример из личного опыта. Я работал с одной командой. Мне не нравились наши оценки в футболках, я как менеджер считал что точность хромает, вроде оценили как S, должно быть готово за неделю, а делается 4. Я пошел к заказчикам узнать что они думают на этот счет, чтобы собрать их мнение как драйвер к изменениям. Ну и заодно их спросил, а зачем им оценки. Получил достаточно занятные ответы.

Оказывается большинство думало, что наши оценки это даты когда будет готовы задачи.

#оценка_задач #оценка_проектов #оценки_времени #управление_проектами