Оценка задач и приоритеты

Зачем оценивать

Чтобы спланировать спринт, команде нужно понимать, сколько работы она успеет. Для этого задачи оценивают. Но точно предсказать время программиста трудно: всплывают ошибки, непонятные требования, зависимости от других команд.

Поэтому многие команды оценивают не в часах, а относительно: «эта задача примерно в два раза сложнее той». Для этого есть стори-пойнты (story points) — условные единицы сложности. Обычно берут числа, похожие на ряд Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Чем больше задача, тем больше разрыв между соседними числами: точно отличить 13 от 14 всё равно невозможно.

Оценка учитывает не только объём работы, но и сложность и неопределённость. Задача «поменять текст на кнопке» — 1. «Подключить оплату через новый банк, с которым ещё не работали» — 13: много неизвестного.

Покер планирования

Оценивают всей командой — так учитывается взгляд и разработчика, и тестировщика. Популярный способ — покер планирования (planning poker):

1. Владелец продукта зачитывает историю, команда задаёт вопросы.
2. Каждый молча выбирает карточку с оценкой.
3. Все показывают карточки одновременно.
4. Если оценки разошлись, те, у кого самая большая и самая маленькая, объясняют почему.
5. Оценивают ещё раз, пока не сойдутся.

Одновременный показ нужен, чтобы мнение первого или самого опытного не повлияло на остальных. А обсуждение расхождений — главная польза: «я поставил 2, потому что такое уже делали» — «а я 13, потому что у нового банка другой API». Кто-то знает о риске, которого не видят другие.

Скорость команды

Скорость (velocity) — сколько стори-пойнтов команда в среднем делает за спринт. Считают только полностью готовые задачи. Если за последние три спринта сделано 28, 32 и 30, скорость около 30.

Скорость — ориентир для планирования: в следующий спринт стоит брать около 30 стори-пойнтов. Взять 50, потому что «надо успеть», — значит заранее сорвать цель спринта.

Скорость нельзя сравнивать между командами: у каждой свои единицы. И нельзя делать её целью «ускориться любой ценой» — тогда команда просто начнёт завышать оценки.

Что брать в первую очередь

Порядок задач в бэклоге решает владелец продукта. Он учитывает:

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

Простой способ — матрица «ценность — сложность»: сначала то, что ценно и просто, потом ценно и сложно. Задачи «мало ценности, много сложности» стоит пересмотреть: может, их вообще не делать. Похожий метод MoSCoW — «обязательно, желательно, можно, не будем» — разобран в курсе «Продюсер игр».