Единственный работающий способ оценки задач

Скрам-покер не работает. Оценка майками - это ещё более сомнительная затея. Но как тогда оценивать задачи?

Попробуем описать рабочую методику.

1. Не делать прямых оценок. Внезапно. Люди плохо оценивают. Люди не умеют оценивать. Совсем. Это тяжело, это субъективно, это страшно. Так зачем это вообще делать? Идеальная методика оценки задач должна быть такой, чтобы во время оценки не нужно было давать прямую количественную или качественную оценку задач. Оценка должна быть вычисляемой на основе чего-то другого. И это другое - результат декомпозиции.

2. Декомпозировать задачи на атомарные шаги-подзадачи. Вот насколько плохо мы умеем оценивать, настолько же хорошо мы умеем декомпозировать, ведь занимаемся этим всё время. Разделение на составляющие - это понятно и привычно.

Мы можем каждую оцениваемую задачу представить в виде списка небольших шагов-подзадач, которые будут предприняты исполнителем во время реализации задачи, получив своего рода to-do list: внести изменения в такой-то сервис, написав функцию, далее реализовать такой-то апи, разобраться с таким-то классом и т.д. Этот список будет более-менее объективен, потому что не зависит от выбора исполнителя. Написать условную деплойку или адаптер для внешнего сервиса нужно будет всякому, кто возьмётся делать задачу: и джуну, и сеньору. При этом выделенные шаги-подзадачи - это не полноценные подзадачи, которые можно оформить в виде, например, Issue в Jira, ведь они зачастую слишком малы и неполноценны в отрыве от оцениваемой задачи. Скорее, это именно этапы в решении задачи. Составление этого списка не будет связано со стрессом, потому что разделение на составляющие никак не характеризует тебя как специалиста и не накладывает на тебя прямых обязательств по сроку реализации. Напротив, почетно найти в задаче такой шаг, который пропустили другие участники команды во время упражнения по декомпозиции.

3. Оценка = число составляющих задачу шагов-подзадач. И вот у нас есть оценка. Оценка задачи в стори поинтах равна числу подзадач в декомпозиции. Логика тут простая: чем больше шагов нужно предпринять в задаче, тем она объемнее и тем бОльную оценку должна получить. Сложный момент в том, как выбрать глубину декомпозиции или, иными словами, размер подзадачи из пункта 2? Не сваливаемся ли мы к прямой оценке задач, от которой хотели уйти? В реальности о размере такой атомарной подзадачи довольно легко договориться, потому что она внезапно интуитивно понятна. Например, в моих командах мы условились, что подзадача должна быть чем-то, что может быть реализовано средним исполнителем за "полдня-денёк", если его никто не будет отвлекать. Это деление показалось всем очевидным, и размерность пунктов декомпозиции обычно не вызывает споров, а всё обсуждение идёт именно про состав списка.