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

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

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

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

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

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

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

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

• Знать как вел себя объект в прошлом - нр, данные о числе сделанных задач в прошлых спринтах;
• Иметь аппарат для прогнозирования - нр, линейная регрессия или тимлид-фронтенда Саша;
• Знать точность этого аппарата - знать как часто и насколько он ошибается, у линейной регрессии в точность около 30-50%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Какую ценность несет для тебя оценка?
• Что ты получаешь благодаря тому, что задача оценена?
• Как ты будешь использовать эту оценку?

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

• Продолжительность. Тут все понятно, это всем знакомые часы, дни, недели и более экзотические, вроде идеальных часов.
• Усилие. Степень нагрузки, которую вызывает выполнение задачи. Типичный пример это сторипойнты.
• Емкость. Количество единиц работы в единицу времени, например число задач делающихся за спринт.
• Ресурсы. Количество чего-то, что необходимо для выполнения работыНапример, людей, команд, серверов и тд. На этой оценке я не буду подробно останавливаться.
• Стоимость. Сколько нужно денег для выполнения задачи.
• Крайний срок. Собственно любые дедлайны.

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

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

• Объект измерения. Тут все просто, это то что мы собственно оцениваем. Сроки, деньги, ресурсы и тп;
• Аддитивность. Это такое свойство, которое означает, что значение величины, соответствующее целому, равно сумме частей. Ну те суммируются ли оценки и равна ли оценка задачи сумма оценок подзадач;
• Однородность. У нее сложноватое определение: функция произведения величины и коэффициента равна произведению функции величины на коэф. Т.е. можем ли взять и умножить оценку например на число пи. Из однородности следует 1 важное следствие - можем ли мы вообще сравнивать оценки друг с другом;
• Погрешность измерения. Отклонение измеренного значения величины от её истинного значения. Вот эта разница между оценкой и фактом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 1 раунд. Каждый участник берет несколько карточек и распределяет их по шкале в соответствии со своим мнением. Все что не понятно попадает под знак вопроса;
• 2 раунд. Обсуждается все что не получило оценку и оказалось под “?”;
• 3 раунд. Каждый участник может перемещать уже разложенные карточки по своему усмотрению;
• В какой-то момент переходы взад и вперед прекратятся. Оценка готова.

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

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

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

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

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

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

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

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

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

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

• Задача перешла в статус ин прогресс. Она выполнена на 30%;
• Задача перешла в код ревью. Прогресс уже 70%;
• Задача в статусе дан. Она готова.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Что мы вкладываем в понятие “оценка”?
• Что мы оцениваем?
• Зачем мы оцениваем?
• Что мы будем делать с оценкой?

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

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

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