Гадание на кофейной гуще ☕️
Или как ответить на вопрос бизнесу: когда задача будет готова наконец?

Во все времена все в IT искали ответ на вопрос — как же так оценить задачи, чтобы не сильно ошибиться, и времени поменьше потратить.
Нашли ли? Я бы сказала, ещё в поиске.

❤️ ❤️ Есть два полярных решения

— простой, быстрый и не очень точный — прикинуть, сколько делать задачу, то есть прикинуть время её выполнения;

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

❔ Какой метод выбрать, зависит от ваших целей

Понять загрузку команды? — Тогда можно обойтись простой оценкой.

Постараться очистить бэклог от необязательных, но больших задач — Подойдёт что-то среднее.

Определить стоимость проекта для бизнеса или точный срок? — Тут уже нужна более точная оценка.

Первое, что надо сделать, прежде чем оценивать задачи, — надо понять, зачем это нужно.

Обзор на методы, которые подробно я описала в статье — ссылку дам ниже, чтобы вас не отвлекать:

1️⃣ На коленке, или Trivial

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

План «Швейцарский шоколад»: СТО или лид команды просто называет время выполнения задачи «из головы», основываясь на опыте команды (иногда нет!).

+ Плюсы: высокая скорость оценки.

✓ Подходит, когда бизнес выбрал делать долго, качественно и дорого.

– Минус: неточная оценка + нужен опытный СТО или тимлид, который сможет определить масштаб бедствия.


2️⃣ Декомпозируем задачи, или Simple

Цель: всё ещё достаточно получить порядок цифр, но объём или сложность задач слишком большая.

План «Швейцарский сыр»:
1. Задача декомпозируется на 1 шаг вглубь — уточняются особенности функциональности.
2. Методом пристального анализа оценивается время выполнения декомпозированной задачи.

+ Плюс: точность выше на 1 балл из 10.

✓ Такая оценка подходит, когда разработка всё ещё ведется без ограничений по срокам — дорого, качественно и долго, но у бизнеса и команды появляется запрос на нивелирование рисков.

– Минус не стала дублировать из первого типа.


3️⃣ Точное, но долгое, или Hard

Этот подход отличается от всех предыдущих тем, что оценивается не время, а объём задач, а

время и скорость вычисляются.

План «Швейцарские часы»:

1. На первой итерации:
+ оценивается объём задач;
+ измеряется реальное время, которое они делались;
+ вычисляется скорость команды.

2. На следующей итерации:
+ оценивается объём задач;
+ из данных о скорости из первой итерации и объёма вычисляется время выполнения задач.

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

Плюсы:
+ получается максимально точный прогноз времени из известных мне (но всё равно это не 10/10);
+ можно собрать спринт с прогнозируемым и продуманным временем реализации.

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

Минусы:
– процесс оценки занимает много (очень много) времени — для сложных задач могут уходить дни на оценку всей команды.
– первую оценку по времени можно получить только после проведения первой итерации


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

Скажите, что было совсем не понятно? С чем не согласны или, может быть, согласны?

👑 Ну и читайте статью — я там целый трактат написала.