Story Points и Относительная Оценка: Разъяснения
Разберитесь в Story Points и относительной оценке в Scrum. Узнайте, почему команды их используют, как они работают и какие преимущества дают для планирования и прогнозирования, объяснено простым языком.
Многие Scrum команды используют Story Points для оценки трудозатрат на выполнение Элементов Бэклога Продукта. Эта практика, называемая относительной оценкой, помогает командам планировать свою работу, не увязая в точных временных обязательствах. Это не требование Руководства по Scrum, но широко принятая техника, которая поддерживает эмпиризм и самоорганизующиеся команды. Цель состоит в том, чтобы понять размер работы относительно другой работы, а не предсказывать точные часы или дни.
Что такое Относительная Оценка?
Относительная оценка означает сравнение одной рабочей задачи с другой. Вместо того чтобы сказать 'это займет 8 часов', команда может сказать 'это вдвое больше, чем та другая задача, которую мы делали'. Такой подход признает, что предсказание точного времени для сложной, новой работы затруднительно и часто неточно. Сосредоточившись на относительном размере, команды могут принимать более последовательные решения. Это смещает акцент с продолжительности на воспринимаемые трудозатраты, сложность и риски.
Почему Story Points?
Story Points, это абстрактные единицы. Они не привязаны к часам или дням. Эта абстракция помогает избежать распространенной ловушки преобразования оценок в фиксированные сроки, что часто приводит к давлению и неточным прогнозам. Story Points поощряют обсуждение между Разработчиками о предстоящей работе, что приводит к общему пониманию. Когда команда присваивает Story Points, она учитывает такие факторы, как:
- Трудозатраты, необходимые для выполнения элемента.
- Сложность элемента.
- Неопределенность или связанные риски.
- Зависимости от других систем или команд.
Руководство по Scrum гласит, что Разработчики несут ответственность за создание плана Спринта, который включает выбор и оценку Элементов Бэклога Продукта. Story Points поддерживают это, не требуя от Владельца Продукта диктовать, как должна быть выполнена работа. Именно Разработчики лучше всего подходят для оценки работы.
Как Команды Используют Story Points
Как правило, команда устанавливает базовый уровень. Они выбирают небольшой, хорошо понятный Элемент Бэклога Продукта и присваивают ему низкое значение, скажем, 1 или 2. Затем все остальные элементы оцениваются относительно этого базового уровня. Общие последовательности для значений баллов включают последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21...) или ее упрощенную версию. Эта нелинейная шкала отражает возрастающую неопределенность, которая сопутствует более крупным элементам; 13, это не просто три 5, а подразумевает большую неизвестность.
Во время Уточнения Бэклога Продукта Разработчики обсуждают элементы и присваивают баллы. Если возникает широкое разногласие, это сигнализирует о различном понимании работы, что побуждает к дальнейшему обсуждению. Этот процесс формирует общие знания и общее определение 'готово' для элемента. Владелец Продукта обеспечивает прозрачность, понятность и уточнение Бэклога Продукта, но оценка трудозатрат является ответственностью Разработчиков.
Velocity и Прогнозирование
После нескольких Спринтов появляется 'Velocity' команды. Velocity, это сумма Story Points для всех Элементов Бэклога Продукта, успешно завершенных в Спринте. Это эмпирическая мера. Это историческое среднее значение, которое помогает команде прогнозировать, сколько работы они могут реально взять в будущие Спринты. Это инструмент для Разработчиков, чтобы управлять своей собственной производительностью, и для Владельца Продукта, чтобы принимать обоснованные решения о будущей разработке продукта. Velocity, это командная мера, а не индивидуальная, и ее не следует использовать для сравнения команд или отдельных лиц.
Владелец Продукта может использовать Velocity для прогнозирования того, когда может быть выполнена большая часть работы, основываясь на общем количестве оставшихся баллов в Бэклоге Продукта. Это прогноз, а не гарантия. Scrum Команда постоянно инспектирует и адаптирует этот прогноз по мере получения новой информации. Ключевыми являются прозрачность и частые корректировки.
Распространенные Ошибки, Которых Следует Избегать
Не относитесь к Story Points как к мере продуктивности отдельных лиц. Это подрывает командное сотрудничество и прозрачность. Не переводите Story Points в часы. Это сводит на нет цель относительной оценки и вновь вводит проблемы временной оценки. Story Points, это инструмент коммуникации для Разработчиков, чтобы помочь им понять и спланировать свою работу, а также для Владельца Продукта для прогнозирования. Это не контракт и не метрика производительности.