Любой, кто хоть раз называл срок «сделаю за два дня», знает, чем это кончается. Проходит два дня — задача готова наполовину, потому что всплыл забытый случай, сломался соседний сервис или вмешалась встреча, которую нельзя было пропустить. Оценка в часах выглядит точной, но эта точность обманчива: мы плохо предсказываем время, зато неплохо чувствуем, что одна задача крупнее другой. На этом наблюдении и строится оценка в Agile — story points, Planning Poker и velocity. Разберём, как это работает и, главное, где команды чаще всего спотыкаются.
Почему оценка в часах врёт
Оценка в часах кажется естественной: заказчик спрашивает «когда», мы отвечаем «через столько-то». Проблема в том, что абсолютное время зависит от кучи вещей, которые в момент оценки неизвестны.
- Разные люди — разная скорость. Задача, которую опытный разработчик закроет за час, у новичка займёт день. Чью оценку записывать в план?
- Неопределённость прячется в деталях. «Добавить поле в форму» звучит на 15 минут, пока не выясняется, что поле надо валидировать, сохранять в двух местах и показывать в отчёте.
- Мешают перерывы и переключения. Реальный рабочий день — это не восемь часов чистого кода. Встречи, обсуждения, помощь коллеге. Оценка в часах притворяется, что всего этого нет.
- Число становится обещанием. Стоит назвать «4 часа» — и это превращается в обязательство, за срыв которого будто бы стыдно, хотя вы просто угадывали.
Ключевая идея Agile-оценки: мы гораздо лучше сравниваем, чем измеряем. Спросите, сколько минут идти до магазина — ответы разойдутся. Спросите, что дальше — магазин или парк — и все ответят одинаково. Это и есть относительная оценка: не «сколько времени», а «насколько крупнее по сравнению с чем-то знакомым».
Story points — оценка сложности и объёма относительно эталона
Story points — это условные единицы, которыми команда измеряет не время, а совокупную «величину» задачи: сколько в ней работы, насколько она сложная, сколько в ней неопределённости и риска. Точных часов в points нет и быть не должно.
Работает это так. Команда выбирает эталонную задачу — небольшую, понятную, которую все делали и хорошо представляют. Ей назначают, например, 2 points. Дальше каждую новую задачу сравнивают с эталоном: «это примерно как эталон» → 2, «раза в три больше и с непонятным куском» → 5 или 8.
Обычно берут не подряд идущие числа, а последовательность, где шаг растёт — например, ряд Фибоначчи:
| Points | Что примерно означает |
|---|---|
| 1 | мелочь, почти ничего |
| 2 | эталон, всё понятно |
| 3 | чуть больше, без сюрпризов |
| 5 | заметная задача, есть нюансы |
| 8 | крупная, местами неясная |
| 13 | очень большая — лучше разбить на части |
Растущий шаг не случаен. Чем крупнее задача, тем хуже мы её понимаем, поэтому и точность оценки падает — различать «21 или 22» бессмысленно, а «13 или 21» — осмысленно. Если задача тянет на 13 и выше, это сигнал разбить её на несколько поменьше: большие оценки почти всегда прячут неразобранные детали.
Важное свойство points: они «свои» для каждой команды. Пятёрка в одной команде и пятёрка в другой — это не одно и то же, потому что эталон у всех свой. Сравнивать points между командами бессмысленно (к этому ещё вернёмся).
Planning Poker — команда оценивает вместе
Оценивать в одиночку опасно: один человек видит только свой кусок работы. Planning Poker — простой ритуал, который заставляет высказаться всех.
Ход такой:
- Ведущий зачитывает задачу, команда задаёт вопросы, пока смысл не станет ясным.
- Каждый участник втайне выбирает оценку — картой из колоды (1, 2, 3, 5, 8, 13…) или пальцами.
- Все вскрывают выбор одновременно — чтобы никто не подстраивался под «авторитетного» коллегу.
- Если оценки близки — берут общую и идут дальше.
- Если разошлись сильно (кто-то поставил 2, кто-то 13) — обсуждают именно это расхождение.
Самое ценное здесь — не число, а расхождение. Оно почти всегда означает, что люди поняли задачу по-разному. Тот, кто поставил 2, не знает про интеграцию со старой системой. Тот, кто поставил 13, помнит, как в прошлый раз это заняло неделю. Разговор вытаскивает скрытые предположения и риски на поверхность — и часто именно тут выясняется, что задачу вообще надо переформулировать. Совпавшие с первого раза оценки, наоборот, скучны: они не приносят новой информации.
Одновременное вскрытие — тоже не мелочь. Если сначала высказывается самый громкий или самый старший, остальные подстраиваются, и обсуждение теряет смысл. Тайный выбор сохраняет независимые мнения.
Velocity — сколько команда закрывает за спринт
Оценили задачи в points, взяли их в спринт, довели до готовности. Сумма points завершённых задач за спринт называется velocity. Если за спринт закрыли задачи на 8, 5, 3 и 5 points, velocity этого спринта — 21.
Одно число ни о чём не говорит, а вот несколько подряд — уже да. Возьмём последние спринты: 19, 22, 20, 21, 18. Видно, что команда стабильно закрывает около 20 points. Это и есть рабочий инструмент планирования: в backlog осталось задач на 100 points → при velocity ~20 понадобится примерно пять спринтов. Не гарантия, а обоснованный прогноз, который постепенно уточняется.
Velocity естественно «плавает» от спринта к спринту — болезни, отпуска, праздничные недели, попавшаяся сложная задача. Поэтому опираются не на последнее число, а на среднее за несколько спринтов, и относятся к нему как к диапазону, а не к точке. Новой команде velocity вообще недоступна первые несколько спринтов — ей просто не с чем сравнивать, эталон и ритм ещё не устоялись.
И главное, ради чего стоит держать velocity: это инструмент прогноза для самой команды, а не оценка её работы для кого-то сверху. Как только velocity начинают требовать «повышать» — она ломается.
Частые ошибки
Разберём грабли, на которые наступают чаще всего.
Points превращают в часы. «5 points — это же примерно день, да?» Стоит завести такую таблицу перевода — и весь смысл относительной оценки исчезает. Points снова становятся временем, со всеми его проблемами. Points остаются points: их не переводят в часы, ими только сравнивают задачи между собой.
Velocity используют как метрику продуктивности. «В прошлом спринте 20, в этом 18 — стали хуже работать?» Нет. Velocity зависит от того, какие задачи попались и как их оценили. Команду легко «мотивировать» — она начнёт завышать оценки, и velocity красиво вырастет, хотя работы сделано столько же. Число будет расти, польза — падать. Как только velocity становится целью, она перестаёт быть честным измерением (это классический эффект: любая метрика, ставшая целью, портится).
Velocity сравнивают между командами. «У той команды velocity 40, у нас 20 — они вдвое быстрее». Это бессмыслица: points у каждой команды свои, эталоны разные. Сравнивать их velocity — как сравнивать рост в разных, неизвестных единицах. Velocity имеет смысл только внутри одной команды и только во времени.
Оценивают ради оценки. Иногда команда часами полирует оценки задач, до которых руки дойдут через полгода и которые к тому времени десять раз изменятся. Оценка нужна, чтобы принять решение — взять ли в спринт, успеем ли к сроку. Если решение от точности оценки не зависит, детальная оценка — просто потраченное время.
Есть и радикальная альтернатива — подход #NoEstimates. Его идея: если задачи в backlog разбиты на достаточно мелкие и примерно однородные, можно вообще не оценивать их в points, а просто считать количество завершённых задач за период. Разбитые до сравнимого размера штуки закрываются с похожей скоростью, поэтому счёт задач даёт прогноз не хуже velocity, но без ритуала оценки. Подход не универсален — он требует дисциплины в дроблении задач, — но полезен как напоминание: оценка не самоцель, а средство. Если счёт задач отвечает на вопрос «когда успеем», сложная оценка может быть и не нужна.
Коротко
- Оценка в часах обманчива: время зависит от исполнителя, скрытых деталей и перерывов; сравнивать задачи мы умеем лучше, чем измерять их.
- Story points оценивают величину задачи (объём, сложность, риск) относительно эталонной задачи, а не время; шкала с растущим шагом (ряд Фибоначчи) отражает падение точности на крупных задачах.
- Planning Poker — тайная одновременная оценка всей командой; ценность в расхождениях, которые вскрывают разное понимание задачи и риски.
- Velocity — сумма points, закрытых за спринт; по среднему за несколько спринтов строят прогноз («сколько спринтов на оставшийся backlog»), а не точную гарантию.
- Velocity — инструмент прогноза для самой команды, а не KPI: как только её требуют «повышать», оценки раздувают и число теряет смысл.
- Points нельзя переводить в часы, а velocity — сравнивать между командами: и то, и другое имеет смысл только внутри одной команды.
- Не оценивайте ради оценки; альтернатива #NoEstimates предлагает считать количество мелких однородных задач вместо points.
Что почитать дальше
- Scrum — спринты, роли и ритуалы, в которых живут оценка и velocity.
- Kanban — поток без спринтов, где вместо velocity смотрят на пропускную способность и время выполнения.