Привет, Хабр! Все знают про сторипоинты, но мало кто понимает, как и зачем оценивать в них задачи. А между тем это мощный инструмент в руках тимлида, который позволяет предсказывать сроки и контролировать нагрузку на команду.

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

Меня зовут Алексей Панаэтов. Я руковожу технической командой Центра Геосервисов в МТС Web Services и сегодня расскажу, как мы оцениваем задачи через их декомпозицию, чтобы на выходе получались понятные всем значения без флера «я так вижу».

Почему оценивать так сложно?

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

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

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

Почему так получается:

• сторипоинт — это максимально невнятная сущность. У него нет четкого определения, и его адепты предлагают руководствоваться ощущениями, а не логикой. Подобный подход, где непонятна даже единица измерения, для участников команды и менеджеров может выглядеть сомнительно;

• оценка в сторипоинтах вкупе с производительностью (velocity) не учитывает теорию ограничений. Агрегатное значение, полученное условным scrum-покером, не берет в расчет зависимость задачи от конкретных исполнителей. Иными словами, число сделанных сторипоинтов в этом спринте очень сильно зависит от распределения задач между участниками команды;

• ставя количественную оценку, ты всегда сам превращаешься в объект оценки. А это стресс. Поставил задаче 8 сторипоинтов? Все, ты «плохой программист». А вот твой коллега оценил ее на 3 — он явно более крутой специалист. И машина у него дороже, кстати.

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

Что не так с основными техниками

Самый известный метод оценки — скрам-покер. И это крайне сомнительная процедура. Вот почему:

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

• не учитывается теория ограничений. В покере игнорируются блокеры в лице особо медленных или загруженных сотрудников;

• недетерминированность. При оценке команда полагается на принцип «я так вижу». Это нормально, если обсуждается кино. Но вкусовщине не место, когда речь идет о трудозатратах и деньгах.

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

Такая техника легче воспринимается командой: вместо невнятных цифр у вас чуть более ясные дискретные размеры. Но с другой стороны, с ее помощью совсем грустно вычислять пропускную способность. Сможем ли мы сделать одну большую задачу, если стабильно выдаем три маленькие? Непонятно…

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

Что же такое сторипоинт?

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

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

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

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

Так как оценивать?

Скрам-покер не работает. Майки — еще более сомнительная сущность. Нужно найти метод, позволяющий получить объективную, не зависящую от исполнителя оценку, которую можно в дальнейшем конвертировать в сроки. И здесь есть несколько простых правил:

Не делайте прямых оценок

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

Декомпозируйте задачи

Насколько плохо мы умеем оценивать, настолько же хорошо мы декомпозируем, потому что занимаемся этим все время. Разделение на составляющие — это понятно, привычно и не страшно.

В рамках оценки мы каждую задачу представляем в виде списка небольших шагов-подзадач, которые будут предприняты исполнителем во время реализации. Так мы получаем своего рода to-do list: написать функцию и внести изменения в сервис, далее реализовать API, разобраться с таким-то классом и т.д.

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

Выделенные шаги — это не отдельные подзадачи, которые можно оформить в виде, например, Issue в Jira. Часто они слишком малы и неполноценны в отрыве от оцениваемой задачи. Скорее, это именно этапы в решении.

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

За итоговую оценку можно взять число полученных подзадач

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

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

В реальности о таком атомарном шаге довольно легко договориться, потому что он интуитивно понятен. Например, в моих командах мы условились, что подзадача может быть реализована мидлом «за полдня-день», если его никто не будет отвлекать. Это деление показалось всем очевидным, и размерность пунктов декомпозиции обычно не вызывает споров, а все обсуждение идет только про состав списка.

Как превратить сторипоинты в сроки?

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

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

Команда должна оценивать объемность задачи в сторипоинтах, подсвечивать зависимости и риски, но дедлайны и ответственность за них — это крест тимлида. Команда может вообще не знать, что там обозначено стейкхолдерам.

Почему сроки называет тимлид:

• на них влияют не только сторипоинты, но и процессы, приоритеты, зависимости, а также непосредственный командный менеджмент, который входит в его зону ответственности;

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

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

В моих командах мы для перевода сторипоинтов в сроки делаем так:

1. Измеряем индивидуальную производительность (число сторипоинтов в неделю) каждого сотрудника.

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

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

4. Проверяем по диаграмме Ганта, что зависимые задачи не конфликтуют по срокам.

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

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

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

Не так страшен черт….

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

Метод декомпозиции, о котором я рассказал, добавляет прозрачности и объективности в оценку задач. Важно помнить, что она ценна не сама по себе, а только когда на ее основе вычисляются сроки или перформанс сотрудников. На этом у меня все. Сил вам в работе и эффективных спринтов!