> Как оцениваются задачи с помощью сторипойнтов

Короткий ответ

Сторипойнты - это относительная оценка сложности, объёма и неопределённости задачи, а не времени в часах. Команда сравнивает задачи между собой по шкале Фибоначчи и договаривается о едином baseline. Оценка отражает effort, complexity и risk, а не производительность отдельного разработчика. На senior-уровне важно объяснить, что сторипойнты нужны для планирования и прогнозирования, а не для контроля людей.

Подробное объяснение

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

Ключевые измерения, которые обычно закладываются в сторипойнты:

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

Шкала Фибоначчи (1, 2, 3, 5, 8, 13, 21) используется не случайно. Чем больше задача, тем выше неопределённость, поэтому шаг между оценками растёт. Это заставляет дробить крупные задачи и снижает ложную точность. Если задача получает 13 или 21, это сигнал декомпозировать её.

Важно, что сторипойнты - это командная, а не индивидуальная метрика. Они не должны использоваться для оценки скорости конкретного разработчика. Velocity команды - это производная величина для прогноза, а не KPI. На senior-уровне нужно уметь объяснить разницу между story points, ideal days и real time, а также почему смешивать их в одной команде опасно.

Есть несколько распространённых подходов к оценке:

• Planning Poker: каждый участник одновременно показывает карту, расхождения обсуждаются.
• Bucket system: задачи раскладываются по заранее заданным корзинам.
• T-shirt sizes: S, M, L, XL с последующим маппингом в числа.
• Dot voting: быстрый способ для больших бэклогов.

Выбор метода зависит от зрелости команды и объёма бэклога. Главное - сохранять консистентность baseline и пересматривать его при смене состава команды или технологического стека.

На практике

На практике сторипойнты работают только при наличии reference stories. Команда выбирает 2-3 эталонные задачи с известной оценкой и сравнивает новые задачи с ними. Например, "добавить поле в форму" - это 2, "сделать новую страницу с интеграцией API" - это 5, "переписать модуль авторизации" - это 13.

Типичный процесс выглядит так:

1. Product Owner описывает задачу и критерии приёмки.
2. Команда задаёт уточняющие вопросы.
3. Каждый оценивает задачу независимо.
4. Расхождения в 2-3 раза обсуждаются, а не усредняются молча.
5. Если консенсус не достигнут, задачу декомпозируют или выносят spike.

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

Velocity считается как сумма сторипойнтов, закрытых за спринт. Она полезна для прогноза на 2-3 спринта вперёд, но нестабильна на коротких отрезках. Также важно учитывать, что velocity падает при онбординге новых людей, смене стека или росте технического долга.

Как отвечать на собеседовании

На собеседовании стоит начать с определения: сторипойнты - это относительная оценка сложности, объёма и неопределённости. Затем объяснить, что они не равны часам и не должны использоваться для оценки индивидуальной производительности. Далее описать процесс: reference stories, planning poker, обсуждение расхождений, декомпозиция крупных задач. В конце добавить, что velocity - это инструмент прогноза для команды, а не KPI. Хороший ответ показывает понимание trade-off между точностью и стоимостью оценки.

Что проверяет интервьюер

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

Типичные ошибки

• Путать сторипойнты с часами или ideal days.
• Использовать сторипойнты для оценки отдельных разработчиков.
• Усреднять оценки молча, без обсуждения расхождений.
• Оставлять крупные задачи с оценкой 13 или 21 без декомпозиции.
• Менять baseline без пересмотра reference stories.
• Сравнивать velocity разных команд напрямую.
• Игнорировать неопределённость и риски при оценке.
• Превращать velocity в KPI и давить на команду ради роста цифры.