Оценивать баги — да или нет?
В предыдущем посте я разбирал, что делать с багами, найденными во время итерации. После этого несколько человек спросили, хорошая ли идея оценивать баги и, если да, как это делать. Очевидно, вариантов два, и у каждого есть плюсы и минусы. Прежде чем делать выводы, давайте посмотрим на оба. Здесь я исхожу из того, что речь о команде, которая работает спринтами и проводит спринт-планирования.
Не оценивать баги
- Помогает фокусироваться на поставке ценности. Логика в том, что при подсчёте velocity команда учитывает только разработку новых фич — ту часть работы, которая даёт ценность конечному пользователю. Баги считают одним из факторов, снижающих velocity. Это (якобы) делает команду строже к тому, чтобы баги не «утекали», потому что никто не хочет нулевой velocity. Контраргумент: velocity — плохая метрика ценности. На самом деле она измеряет ёмкость команды, что не обязательно равно ценности.
- Долгосрочное планирование становится точнее. При долгосрочном планировании баги редко оценивают — на момент планирования они ещё неизвестны. Если velocity включает только новые фичи и прогноз тоже только новые фичи, можно просто разделить прогноз на velocity и получить дату. Контраргумент: новые фичи постоянно добавляются в бэклог, часто уже после долгосрочного планирования. Они так же неизвестны, как баги, и отказ от оценки багов не упрощает жизнь. Вместо этого учёт типов работы (плановая, внеплановая, баги) даёт данные для корректировки любого долгосрочного прогноза.
- Баги сложно или невозможно оценить. Часто баги оценить гораздо труднее. Особенно старые или найденные в проде: команда уже потеряла контекст. Часто багованный код писала не эта команда. Ответ: новые стори могут быть такими же размытыми и трудными для оценки, как старые баги. Свежие же баги оценить относительно легко — контекст ещё есть, зависимостей в коде меньше.
Оценивать баги
- Команде гораздо проще планировать спринты. В конце концов, velocity — метрика ёмкости, и её цель — помочь команде оценить свою ёмкость на следующий спринт. Задача становится проще, если в расчёт входят все виды работы.
Оценивать или нет?
В целом команды гораздо комфортнее чувствуют себя, оценивая баги, а идея измерять только «новое» не даёт того психологического эффекта, на который рассчитывают. Раньше у меня было жёсткое мнение, и я настаивал не оценивать баги. Со временем понял: важнее держать оценку прозрачной, понятной и последовательной. Поэтому обычно я оцениваю баги вместе с командами. В итоге прогнозирование — работа менеджера / Agile Coach, и если это усложняет вам жизнь, но упрощает команде — выбирайте этот путь.
Как оценивать
Если нужна последовательность оценок, ответ очевиден. Оценивайте так же, как всё остальное. Если оцениваете в story points через Planning Poker — делайте Planning Poker и по багам. Если используете Magic Estimation (мне это полезнее), баги тоже должны быть на доске оценки.