Никому не нужный «театр оценок»

Давайте будем честными: планирование с помощью покерных карт — это, по сути, ритуальный театр, который никому на самом деле не нравится. Вам знакома эта сцена. Кто-то выкрикивает: «Планирование с помощью покерных карт!», и внезапно все замолкают, лихорадочно пытаясь понять, является ли эта конкретная функция входа в систему пятёркой или восьмёркой (или и тем и другим, в зависимости от количества кофе, выпитого разработчиком утром).

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

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

Почему точки историй стали якорем

Точки историй были придуманы как решение реальной проблемы. У оценки на основе часов есть документированные недостатки — она подчёркивает индивидуальные различия в производительности, создаёт стресс и катастрофически не учитывает перерывы, встречи и того человека, который задавал вам «быстрые вопросы» в течение двух часов. Точки историй обещали решить эту проблему, будучи относительными и абстрактными.

Но где-то между теорией и практикой что-то пошло не так. Оценка точек историй стала ритуалом. Команды часами проводили сессии уточнения, debating, является ли задача тройкой или пятёркой (спойлер: всегда получалось восемь). Заинтересованные стороны научились переводить точки историй обратно в часы, несмотря ни на что, сводя на нет всю суть. Расчёты скорости превратились в программирование культов карго — команда добросовестно отслеживала их, не используя при этом для чего-либо значимого.

Самое ужасное? Точки историй создали ложную точность. Ваша команда знает, что задача «примерно похожа на другую задачу», но вдруг вы начинаете делать вид, что понимаете точное соотношение усилий между историей в 5 очков и историей в 13 очков. Вы этого не понимаете. Никто не понимает. Вы просто указываете на числа.

Введение в подход без оценок

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

Это не новая мысль — несколько команд, работающих на основе фактических данных, успешно применяли этот подход. У подхода есть определённые предпосылки, но когда эти условия существуют, он приносит облегчение.

Предпосылки (это важно)

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

  • Чистый код и низкий технический долг: вы должны иметь возможность двигаться быстро, не борясь с устаревшими системами. Задачи должны быть просты в реализации, не требуя археологических раскопок в чьём-то рефакторинге 2019 года. Если ваша кодовая база — кошмар, оценочные ритуалы — это наименьшая из ваших проблем, но они также маскируют реальную проблему.
  • Упорно небольшие пользовательские истории: ваша команда должна уметь разбивать работу на действительно мелкие части. Мы говорим о таких, как «Добавить поле электронной почты в форму регистрации», а не «Реализовать систему аутентификации». Это сложнее, чем кажется. Многие команды думают, что разбивают задачи на мелкие части, пока не попробуют этот подход на практике.
  • Стабильная базовая скорость: вам нужны исторические данные о том, сколько историй ваша команда выполняет за спринт (примерно). В идеале 2–3 спринта завершённой работы для установления базовой линии. Без этого вы действуете вслепую.
  • Уверенность команды и зрелость: ваша команда должна быть уверена, что небольшие истории действительно малы, а заинтересованные стороны должны понимать, что предсказуемость достигается за счёт последовательности и истории, а не точности оценок.

Механика: как это работает на практике

Вот как выглядит подход без оценок на практике:

1. Определение «готовой истории»

Сначала ваша команда определяет, что представляет собой одну единицу работы. Это crucial, потому что «одна история» становится вашей основной единицей планирования:

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

Для типичной команды разработчиков это может означать максимум 4–8 часов работы на историю. Ограничение по размеру намеренно — оно вынуждает к приоритизации и предотвращает разрастание объёма работы в рамках одного элемента.

2. Подсчёт выполненных историй

Вместо точек историй вы отслеживаете количество историй. В конце каждого спринта вы спрашиваете: «Сколько историй мы выполнили?» Вот и всё. Никаких расчётов скорости. Никаких диаграмм сгорания. Просто сырые цифры.

Спринт 1: выполнено 8 историй
Спринт 2: выполнено 7 историй
Спринт 3: выполнено 9 историй
Спринт 4: выполнено 8 историй
Среднее: 8 историй за спринт

Это становится вашей базовой линией планирования. Если вы последовательно выполняете 8 историй за спринт и в вашем списке продуктов 80 чётко определённых историй, вы смотрите на примерно 10 спринтов работы. Простая математика, без необходимости абстрактных рассуждений.

3. Планирование спринта без оценки

Планирование становится удивительно простым:

  1. Отсортируйте бэклог по приоритету (вы должны делать это в любом случае).
  2. Подсчитайте истории сверху вниз, пока не достигнете своего исторического среднего значения.
  3. Это ваша цель на спринт.
  4. Назначайте во время спринта, а не до, потому что вы обнаружите зависимости и блокировщики, как только люди начнут работать.

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

Сравнение подходов: визуальная схема

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

graph TD A["Выбор подхода к оценке"] --> B{Профиль команды?} B -->|Новая для Agile| C["Идеальные дни/часы
Простые для понимания
Создают стресс со временем"] B -->|Зрелые команды
Сложная работа| D["Точки историй
Абстрактные относительные усилия
Требуют дисциплины"] B -->|Зрелые команды
Небольшие истории
Чистый код| E["Подсчёт историй/без оценки
Максимальная простота
Высокая предсказуемость"] C -->|Эволюционировать к| D D -->|Переходить к| E E -->|Лучше всего работает| F["Последовательная скорость доставки
Простое планирование
Уверенность заинтересованных сторон"] style E fill:#90EE90 style F fill:#FFE4B5

Реальная реализация: пошаговое руководство

Давайте рассмотрим, как команда может перейти к планированию на основе подсчёта историй. Это предполагает, что у вас уже есть достаточно функционирующая настройка Agile.

Этап 1: Установление базовой линии (2–3 спринта)

Что вы делаете: продолжайте использовать точки историй, если вы их сейчас используете, но также отслеживайте количество историй. Это даст вам параллельные данные.

# В вашем шаблоне ретроспективы спринта добавьте:
- Выполненные истории (количество): ___
- Общий балл по историям: ___
- Истории по размеру (среднее количество баллов на историю): ___

Отслеживайте эти данные тщательно. Вы увидите закономерность. Некоторые команды обнаруживают, что выполняют 6–12 чётко определённых историй за спринт; другие — 15–20. Число имеет меньшее значение, чем последовательность.

Этап 2: Переопределение размера истории (1 сессия планирования спринта)

Что вы делаете: ваша команда явно соглашается с тем, что такое «одна история». Сделайте это до смешного конкретным:

Пример истории, которая слишком велика:

  • «Реализовать профили пользователей» (может быть 20+ мелких частей).

Пример истории правильного размера:

  • «Добавить поле имени в профиль пользователя и сохранить в базе данных».
  • «Создать проверку для поля электронной почты при регистрации».
  • «Добавить индикатор загрузки на страницу профиля пользователя».

Упражнение: возьмите свои последние 10 выполненных историй. Нужно ли разбивать какие-либо из них дальше? Если да, это ваш новый базовый размер на будущее.

Этап 3: Эволюция уточнения бэклога (постоянно)

Здесь изменения становятся реальными. Ваши встречи по уточнению переходят от:

Старый подход:

  • Проанализировать историю → Обсудить значение баллов за историю → Консенсус → Переместить в «готово».

Новый подход:

  • Проанализировать историю → Можно ли сделать это за <1