Три уровня использования оценок задач

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

Содержание:

• Нулевой уровень. Информация о конкретной задаче.
• Первый уровень. Принятие решений в рамках текущей итерации*.
• Второй уровень. Решения в рамках следующей итерации.
• Третий уровень. Решения в рамках нескольких итераций.
• Заблуждения.
• Итоги.

*Итерации - временные промежутки работы команды одинаковой длины.

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

Итак.

Главная сложность при работе с оценками состоит в том, что она как шашлык: нет единственно верного рецепта, чтобы каждый остался довольным (и от процесса, и от результата). Не говоря уже об «оценочных веганах», в каждый удобный момент отстаивающих своё право не оценивать. Что ж, у каждого своя правда, не нам судить.

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

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

Самое простое - через оценку узнавать о деталях предстоящей реализации фичи. Тут, аки Гендальф на третий день с востока, команде на помощь приходит армия из способов оценок: хоть часами, хоть стори-пойнтами; хоть покером, хоть корзинками; хоть индивидуально, хоть командой.

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

На данном уровне имеет значение оценка конкретной задачи.

Забегая вперёд, на следующих уровнях используется исключительно сумма оценок задач.

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

На данном уровне оценка используется для:

• уточнения деталей. При несовпадении мнений об оценке, члены команды обмениваются информацией о нюансах задачи и возможных рисках в реализации. В дальнейшем это упрощает работу над задачей;
• приоритизации задач. Очевидно, что при прочих равных, в работу целесообразней взять задачу с меньшей оценкой. Либо же отдать предпочтение оценённой задаче (ввиду большей предсказуемости работы над оной);
• прогнозирования сроков выполнения задачи (в случае использовании абсолютных оценок, вроде часов или дней. В случае относительных оценок [их иногда называют «попугаями»], размер оценки не коррелирует со сроком реализации).

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

Я предлагаю три временных уровня. Каждый уровень требует определённых действий в плане работы с оценкой, причём каждый следующий включает действия/правила предыдущего.

На нулевом уровне разные команды используют разные подходы и инструменты для оценки, но для корректного перехода на следующий уровень необходимо:

• использовать относительные оценки, т.е. значения, оценивающие ресурсоёмкость задачи, а не временные затраты;
• ИЛИ использовать абсолютные (обозначающие временные значения: часы, дни и т.п.), предполагающие не общее время выполнения задачи (включая ожидание от смежных команд и т.п.), а исключительно временные ресурсы исполнителей (членов вашей команды)

Нулевым этот уровень назван из-за того, что институт оценки пока не имеет системности, а после взятия задачи в работу - оценка часто перестаёт иметь значение. В свою очередь, следующие уровни позволяют принимать решения, связанные не с конкретной задачей, а с управлением рабочего процесса в целом.

Инструмент визуализации - BurnDown Chart, он же - Диаграмма сгорания. Представляет собой график между горизонтальной и вертикальной осью, где по оси X - дни итерации, по оси Y - сумма оценок всех задач, запланированных на итерацию.

От исходной суммы оценок задач к последнему дню итерации строится "Линия идеального сгорания" (см. иллюстрацию). Именно она помогает принимать решение касательно ситуации текущего дня.

При работе команды, ежедневно сумма оценок незакрытых задач уменьшается (разумеется, если команда закрывает задачи :D)

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

Особенно полезным график оказывается во время "вбрасывания" в работу незапланированных задач.

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

Для корректной работы BurnDown Chart необходимо:

1. Все задачи, попадающие в работу (как в результате планирования, так и в ходе работы) должны быть оценены. Это позволяет визуализировать текущее положение дел относительно Линии идеального сгорания.

2. По окончании итерации, оценка незавершенных задач должна быть приведена к актуальному состоянию (задачу следует переоценить, т.е. оценить оставшуюся по задаче работу). Это обеспечит равномерность "сгорания" задач на графике следующей итерации (не будет задач-пустышек, большая часть работы над которыми была выполнена во время прошлой итерации. Такие задачи "сгорают" быстрее остальных и вводят команду в заблуждение).

3. Уровень декомпозиции должен позволять закрыть задачи за 1-2 дня. Это обеспечит более быструю обратную связь от системы.

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

Для графика не имеет значения единица измерения оценки задач. Механизм работает одинаково и для абсолютных значений (часы-дни), и для относительных (story point’s). Единственное условие - единица измерения должна быть метрической (т.е., к примеру, оценка в «майках» [XS, S, M, L, XL] будет требовать конвертации в число. В таком случае я рекомендую сразу использовать оценки в числовом виде).

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

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

Допустим, на итерацию запланировано 10 задач, и каждая задача оценена в 10 условных единиц (часов, стори-пойнтов, попугаев, не важно. Для простоты примера, давайте остановимся на стори-пойнтах - s.p.).

Из запланированных 10 задач, 8 были завершены полностью, 1 сделана примерно на половину, и ещё к одной даже не приступили. А еще «прилетели» 4 незапланированные задачи, каждая предварительно оценённая в 10 s.p. (для простоты примера), три из которых благополучно закрыты. Итого, завершено 11 задач, 2 начаты и не завершены и 1 осталась не тронутой (см.иллюстрацию).

В зачёт Velocity следует взять сумму исходных оценок закрытых задач. Но не всех, а только тех, что были изначально запланированы.

Зачем эту нужно? Потому, что если нет явных предпосылок к изменению ситуации, считайте, что следующая итерация пройдет примерно как предыдущая: скорее всего к вам в работу так же прилетит несколько незапланированных задач. А значит, исходя из ваших ресурсов, имеет смысл изначально планировать задачи только на ~80 s.p. (а не на 100, как в прошлый раз - всё равно все не сделаете).

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

Для визуализации описанных данных используйте Velocity Chart.

Данный график содержит набор значений для каждой итерации: запланированный объем работы (сумма оценок запланированных задач), сумма оценок всех реализованных задач и сумма оценок реализованных задач из списка запланированных.

Разумеется, первое значение указывается в начале итерации (по окончанию планирования), остальные - по её окончании.

Для корректной работы Velocity Chart необходимо:

1. Соблюдение рекомендаций для BurnDown Chart. Невозможно «прыгнуть» на данный уровень минуя предыдущий. Например, отсутствие переоценки незакрытых задач между итерациями исказит данные Velocity из-за неоднородности «сжигаемых» задач.

2. Сохранение оценки задачи во время итерации. Другими словами, не следует переоценивать задачи во время работы над ними. Подгонка «под ответ» оценок задач текущей итерации никак не упрощает оценивание следующих задач - в них так же будут неточности в оценках.

3. Включение в зачёт Velocity (факт из плана) только полностью закрытых задач. Если учитывать частичное закрытие, нарушается изначальная цель использования Velocity - прогнозирование объёма задач, которые будут закрыты в следующей итерации.

4. Итерации одинаковой длины. Velocity хранит данные об объеме закрытых задач за временной промежуток определенной длины. Другими словами, данные Velocity об итерации(-циях) одной длины малоинформативны (если не сказать - бесполезны) для итерации другой длины.

Более подробно о способе расчета Velocity читайте здесь

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

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

[Контроль этот тоже можно назвать условным, но эту прозрачность можно сравнить с рентгеном до изобретения МРТ: не очень точно, но лучше так, чем совсем вслепую]

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

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

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

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

Это создаёт большую погрешность в данных графика, чем BurnDown Chart, на котором мы видим более точные оценки проработанных и декомпозированных задач.

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

**Составив детальный план работ [привет, водопад], который, скорее всего, «протухнет» уже после первых итераций.

И, несмотря на схожую визуализацию с BurnDown, «техническое обслуживание» квартального графика заметно сложнее, чем ежедневная актуализация статусов задач.

Для корректной работы графика требуется:

1. Регулярно актуализировать бэклог продукта. При этом, для каждой новой (создаваемой) задачи необходимо указание: должна ли она быть реализована к указанной дате (дате, к которой уходит «линия идеального сгорания графика») или после неё. В данные графика должны попадать только те задачи, которые нужно реализовать к указанной дате.

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

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

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

• непосредственно перенос сроков;
• ускорение разработки (за счёт увеличения команды, или сверхурочной работы);
• снижение объёма задач.

И так как первые два варианта выходят за рамки данной статьи, рассмотрим третий способ.

Говоря о снижении объёма задач в рамках планируемого периода (например, квартала), мы не говорим о переносе какого-то из финальных этапов разработки на следующий период: такой подход ничем не будет отличаться от переноса дат, что часто бывает критичным для бизнеса.

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

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

Декомпозиция задач по этапам работ не позволяет производить приоритизацию (и как следствие - реагировать на отставание/опережение графика).

Декомпозиция от бизнес-ценности даёт возможность гибко подходить к порядку реализации функционала, позволяя менее приоритетные задачи (фичи) реализовать в последнюю очередь (или не реализовать вовсе, в случае отставания или изменения приоритетов).

Разумеется, данный подход имеет смысл и на предыдущих уровнях работы с оценкой.

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

1. Оценка незавершённой за итерацию задачи - это исходная оценка минус выполненная работа. Нет, во время работы над задачей понимание об оставшейся работе могло измениться как в меньшую, так и в большую сторону. Математика в этом случае не работает. Просто потому, что изначальная оценка не безупречна. При переоценке задачи исходная оценка никак не учитывается.

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

3. По сумме оценок закрытых задач можно судить о производительности команды. Увы, оценки работают только «вправо» (по временной шкале относительно текущего дня), и служат для прогнозирования сроков работы и возможной загрузки команды на итерацию. Разумеется, ни кто не помешает вам сложить оценку закрытых задач для какого-либо отчета. Однако, полученные значения никак не коррелируют с производительностью.

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

Список заблуждений, конечно, не исчерпывающий. Более того, порой команды (или кто-то из менеджмента) осознанно пренебрегает правилами работы с оценками в пользу какого-то единственного инструмента.

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

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

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

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

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

Для более детального погружения в поднятую тему рекомендую книгу Майка Кона «Agile: Оценка и планирование проектов». На мой взгляд, в русскоязычном сегменте это пока лучшая компиляция знаний об оценке задач.

Настоящая статья не является пересказом данной книги, но изложенные в ней идеи в значительной степени оказали влияние на формирование описанного выше материала.