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