Сегодня мы разберёмся в ситуации, когда очки историй становятся для команды самоцелью, и ответим на вопросы: обязательно ли использовать SP, чем их заменяют и как совершенствовать свои оценки.
Обычно, мы работаем с историями и оцениваем их в SP. Если кратко, то Story Points, очки историй, — это относительные баллы вместо оценок на основе времени (типа дней и часов). Чаще всего баллы ставятся по упрощенной версии последовательности Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 20...
Подробнее: Почему при планировании используется последовательность Фибоначчи?
Числа ничего не значат сами по себе, их смысл относителен. Например, 13 баллов означает, что задача требует примерно в четыре с небольшим раза больше усилий, чем задача в 3 балла.
Scrum Guide говорит об оценке следующее: "Работа может быть разного размера и предполагаемых усилий". В нём не прописывается, как проводить эту оценку: через очки историй, часы, идеальные дни, размеры футболок, просто предчувствие... Руководство лишь делает важное замечание, что нужно выбирать подход, который учитывает сложность разработки ПО и важность эмпиризма.
Цель оценки в Scrum
Основная функция оценки — прогнозировать сроки поставки и бюджет (для бизнеса). Более точные оценки представляют собой средство управления рисками. Они позволяют команде получить приблизительное представление о количестве работы, которые они могут выполнить в спринте. Оценка требует обсуждения каждой задачи:
- Что подразумевается сделать в этой задаче? Какую бизнес-ценность получить?
- Как это должно работать?
- Какая работа для этого необходима?
Команда стремится действовать согласно плану, но не обязуется завершить всю работу в рамках спринта, так как могут возникнуть неожиданные проблемы и идеи. Невозможно дать 100% точную оценку сложному процессу. По мере того, как мы работаем, мы обнаруживаем как проблему, так и подходящее решение.
Это обстоятельство подчеркивает, что роль оценок в Scrum совершенно иная. С непониманием этого часто сталкиваются люди, которые привыкли работать по плану.
«Используйте эмпирический процесс Scrum, чтобы извлечь выгоду из изменений, а не контролировать их».
Это даёт нам четыре важных понимания относительно оценок:
- точные оценки невозможны, так как нельзя охватить все сценарии,
- оценка не может быть гарантией,
- сами оценки — закреплённый результат обсуждения,
- вместо планирования наперёд лучше потратить это время на практическое исследование и разработку.
Какой же метод оценки подходит, чтобы команды могли получить представление о работе на спринт? Обязательное условие — при оценке тратить меньше времени и усилий, но добиваться цели планирования.
Есть разные виды оценок, кроме SP.
Оценка на основе времени
Варианты: часы, идеальные дни.
Основным недостатком метода является то, что команда и стейкхолдеры получают иллюзию точности. Если задача оценена на 8 часов или 1 день, она часто интерпретируется как то, что займёт именно это время. Если программист выходит за установленный срок, он ощущает давление.
Другой минус — сложность анализа, так как часы предполагают большую точность, а значит, нужно проводить больше обсуждений и учитывать детали.
Вот поэтому в гибких методологиях появились относительные оценки, такие, как очки историй. Они не основаны на времени и не детализированы больше, чем нужно.
Замена SP
Story point — всего лишь название. Это относительная оценка, значит, значения присваиваются в сравнении задач друг с другом. Этот метод так или иначе используется в остальных методиках, описанных ниже.
SP можно заменять на любое название, но суть оценивания остаётся той же. Вот некоторые варианты:
- тысячи долларов,
- животные в зоопарке (мышь, кролик, лиса, волк, тигр, лев, слон...),
- размеры футболок: XS, S, M, L, Xl, XXL...
В общем, походят любые комбинации и цифры. Главное, чтобы команда имела точное представление о том, какое название обозначает нечто большее, а какое название — нечто меньшее.
Относительное расположение
В группу этих методов входят:
- метод вёдер,
- метод точек,
- деление на маленький/большой/неизвестный,
- выстраивание по порядку.
Метод вёдер
В самой популярной реализации метод тоже предполагает использование SP или другую относительную оценку (большое ведро, корзина, коробка и т. д.).
Расставляются якори, где указан размер. Все карточки с задачами распределяются по группам.
Метод точек
В этом способе у участников есть несколько точек или баллов. Обычно точки используются для расстановки приоритетов, но так могут указывать на относительную сложность задач.
В этом случае:
- Все истории выкладываются на стол.
- Каждый участник распределяет свои точки между карточками, учитывая, что чем больше у задачи точек, тем она кажется команде сложнее.
- Задачи выстраиваются по количеству точек.
В работу можно брать от более легких к более сложным, или наоборот, но это подходит для проектов без задач с дочерними карточками (чтобы их можно было делать независимо друг от друга). Оценка точками используются для оценки небольшого количества задач.
По порядку
С помощью этой техники можно определить примерный размер всех задач проекта. Как это работает:
- берётся первая карточка с User Story, обсуждается. Она будет отправной точкой. Ее кладут на середину стола (или пола).
- Затем вытягивается следующая карточка, команда обсуждает её и решает, она больше или меньше предыдущей. Соответственно, если больше, карточка кладётся справа от первой, если меньше — слева от первой.
- Таким образом раскладываются все карточки: для этого они сравниваются с отправной и соседними.
Деление на большие и маленькие
Данный метод оценки лучше работает для оценивания PBI в бэклоге, но не очень походит для спринта. Деление предполагает, что все истории делятся на три группы:
- маленькие (этот размер выбирается командой, например, не больше дня работы),
- большие,
- неизвестные (требуют исследования или обсуждения).
По количеству PBI
Для этого метода все элементы бэклога должны быть разбиты на таски примерно одинакового размера. Тогда по опыту команда знает, что за спринт каждый из разработчиков может выполнить около 5-6 PBI. Тогда команда набирает истории согласно своей ёмкости.
Детали
В процессе такой оценки определяется максимально возможный размер задачи, например, один человекодень. То есть, все задачи должны занимать не больше дня на их выполнения.
До собственно отбора задач в спринт процесс идёт так:
- история обсуждается участниками, больше, меньше или равна она максимальному значению,
- если задача больше Max, она разбивается на таски, пока они не достигнут максимального допустимого размера и меньше.
- Так происходит со всеми PBI.
Этот метод больше подходит для бэклогов размером до 30 задач.
Советы
Способов оценивания — великое множество. Не так важно, какой выберет команда, главное, чтобы этот способ предполагал следующее:
- он удобен всей команде, каждый понимает оценку однозначно,
- оценку проводит вся команда,
- он занимает адекватное количество времени,
- в процессе оценивания идёт живое общение, каждый вовлечён в процесс.
Совместное обсуждение работы снижает риски, так как коллективно легче предусмотреть разные сценарии, возможные проблемы и упущения.
Зачем вообще оценивать?
Собранная статистика даёт эмпирические данные для анализа. Это помогает планировать релизы и крупные обновления. Тем не менее, некоторые команды считают, что оценка в целом бесполезна. Они входят в движение #NoEstimates, которое выступает за то, чтобы работать понемногу, вводя новые задачи по мере решения старых.
Мы согласны с цитатой Эстер Дерби: "Оценивание полезно, оценки — нет". В процессе планирования важно командное общение и общее обсуждение задачи. Это рождает сотрудничество и даёт каждому разработчику примерный план действий, который он подкрепил мнением команды.
А как оцениваете вы?