По какой системе оценки задач работаешь

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

Моя базовая система: Story Points и Фибоначчи через призму «ёмкости»

Основной подход, который я считаю наиболее эффективным — это оценка задач в Story Points по последовательности Фибоначчи (1, 2, 3, 5, 8, 13...). Ключевой момент: сторипоинты оценивают не время, а относительную сложность, объем работы, риски и неопределенность.

• 1, 2, 3 — задачи, которые полностью понятны, требуют минимальной сложности и почти не несут рисков.
• 5, 8 — задачи средней сложности, где есть некоторые неизвестные или интеграционные моменты.
• 13+ — это «красный флаг». Задача слишком велика и должна быть разбита (сплитована) на более мелкие. Оценка в 13+ поинтов почти всегда означает, что мы не до конца понимаем, что нужно делать.

Критически важно: мы оцениваем не в вакууме, а относительно эталонной задачи (бенчмарка), которую вся команда понимает и принимает за, например, 3 или 5 поинтов.

Процесс оценки: Планирование покера (Planning Poker)

Я активно использую и фасилитирую сессии Planning Poker с участием всей команды (разработчики, тестировщики, иногда дизайнер и продакт).

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

// В процессе обсуждения выясняем:
// - Есть ли готовый дизайн ошибок? (+ к сложности, если нет)
// - Нужна ли интеграция с бэкендом для проверки уникальности email? (+ к сложности)
// - Какие браузеры нужно поддерживать? (+ к сложности для старых IE)
// - Есть ли в кодовой базе похожие реализации, которые можно переиспользовать? (- к сложности)

Каждый участник анонимно «выкладывает карту» с оценкой. Если оценки сильно разошлись (например, кто-то дал 3, а кто-то 8), то те, кто дал крайние оценки, аргументируют свою позицию. Это не спор, а выявление скрытых допущений и рисков. Часто в ходе дискуссии выясняется, что один разработчик учел время на написание тестов, а другой — нет, или кто-то знает о подводном камне в API.

От абстрактных поинтов к прогнозам: Velocity и Ёмкость

Сама по себе оценка в сторипоинтах бесполезна без исторических данных. Мы отслеживаем Velocity (скорость команды) — сколько поинтов команда стабильно завершает за спринт. Это не KPI для гонки, а инструмент прогнозирования.

На каждом планировании спринта мы смотрим на:

1. Исторический velocity (усредненный за последние 3-5 спринтов).
2. Ёмкость (capacity) команды в предстоящем спринте (отпуска, больничные, митинги, техдолг).

# Упрощенный пример прогноза:
Средний velocity команды = 40 story points
Ёмкость в следующем спринте ↓ на 25% из-за двух отпусков
Прогнозная ёмкость = 40 * 0.75 = 30 story points

Таким образом, мы берем в спринт задач не более чем на ~30 поинтов, что делает план реалистичным и снижает стресс.

Альтернативы и когда их применять

• T-Shirt sizes (XS, S, M, L, XL): Отлично подходит для самых ранних этапов (дорожная карта, бэклог продукта), для грубой приоритизации. Я часто начинаю с нее, прежде чем перейти к более детальным сторипоинтам.
• Временные оценки (часы/дни): Использую крайне редко и только внутри команды для очень небольших, технических задач (например, «исправить баг в известном месте»). Главный минус — такая оценка становится обязательством и провоцирует срезы по качеству, если «не укладываешься».
• #NoEstimates: Интересная философия, которую я уважаю. Вместо оценок мы просто считаем количество завершенных задач за итерацию и работаем с самым приоритетным бэклогом. Может работать в зрелых командах с очень маленькими и однородными задачами, но часто менее предсказуема для стейкхолдеров.

Почему я против оценки в «часах/днях» для фич:

1. Психологический якорь: Оценка в 8 часов сразу воспринимается как обещание. Пропадает пространство для исследования, рефакторинга и неожиданных проблем.
2. Сравнение разработчиков: «Петя сделал за 6 часов, а Вася за 10» — это токсично и не учитывает разный опыт и контекст.
3. Неточность: Человек крайне плохо предсказывает время, особенно в условиях неопределенности. Мы гораздо лучше оцениваем относительную сложность («это в 2 раза сложнее, чем та задача»).

Итог: Моя предпочтительная система — это гибкий, командный и относительный подход через Story Points, подкрепленный данными о скорости команды и регулярным ретроспективным анализом причин расхождений в оценках. Это создает культуру открытости, непрерывного обучения и реалистичного планирования, а не культуру обвинений и переработок. Я готов адаптировать этот подход под процессы вашей компании, так как понимаю, что каждая команда находится на своем этапе Agile-зрелости.