Понимание Story Points: практики, примеры и методы

Story points (SP) являются ключевым компонентом Agile-методологий (в особенности Scrum), используемых для оценки усилий, необходимых для разработки пользовательских историй, на основе сложности, трудозатрат и неопределенности, но не времени.

В этой статье мы попробуем дать всестороннее понимание story points, рассмотреть различные методы оценки, включая Planning Poker, а также рассказать про альтернативный метод оценки, который использует часы.

Story points измеряют относительные усилия, необходимые для создания пользовательской истории или задачи. Вместо оценки в часах или днях, Story Points используют относительную шкалу (часто в виде последовательности Фибоначчи), отражающую сложность, риск и затраченные усилия. Это помогает командам понять объем работ, не привязывая оценки к конкретным срокам.

Почему используют Story Points?

Оценивайте истории пользователей относительно других задач, уже известных задач. Этот сравнительный подход помогает оценить необходимые усилия, исходя из известных сложностей.

Пример:

Оцениваемая пользовательская история: «Я, как пользователь, хочу иметь возможность сбросить свой пароль, используя безопасную ссылку электронной почты для того чтобы воспользоваться системой если я забыл свои данные».

Предыдущая реализованная пользовательская история: «Я, как пользователь, хочу иметь возможность войти в систему, используя имя пользователя и пароль для того чтобы получить доступ к системе». (Оценка в 5 SP)

Оценка: учитывая дополнительную сложность реализации, функция сброса пароля может быть оценена в 8 SP.

Использованный метод: Метод сравнения: сравнивая с эталонной историей (история входа в систему), команда определяет относительную сложность новой задачи.

Почему 8 SP? Дополнительные задачи по обеспечению безопасности и интеграции делают процедуру сброса пароля более сложной, чем функция входа в систему, что оправдывает более высокую оценку.

Привлекайте всех членов команды, чтобы использовать различные точки зрения и добиться более точной оценки.

Пример:

Оцениваемая пользовательская история: «Мне, как администратору, нужно ежемесячно составлять отчеты об активности пользователей для того чтобы понимать, сколько времени они проводят в системе».

Обсуждение в команде: Разработчики оценивают это в 5SP, в то время как тестировщики предлагают 8 SP из-за возможных проблем в тестировании, в точности данных при формировании отчетов.

Оценка: после обсуждения команда согласовывает 8 пунктов истории.

Использованный метод: Метод консенсуса: обратная связь от различных ролей обеспечивает всестороннее понимание сложности задачи.

Почему 8 SP? Проблемы, связанные с точностью данных и формированием отчетов, усложняют задачу, что отражает более высокую оценку.

Planning Poker — это метод оценки на основе консенсуса, при котором члены команды используют карты со значениями Story Points для оценки задач. Каждый участник в частном порядке выбирает карту, представляющую его оценку, кладет ее на стол рубашкой вверх. После одновременного раскрытия карт команда обсуждает расхождения и приходит к консенсусу.

Пример:

Оцениваемая пользовательская история: «Я, как пользователь, хочу фильтровать результаты поиска по диапазону дат, для того, чтобы сделать поиск более точечным и точным».

Процесс оценки: члены команды выбирают карты со значениями от 3 до 5 баллов.

Оценка: команда обсуждает различные оценки, рассматривает сложность внедрения фильтра и соглашается на 5SP.

Используемый метод: Planning Poker: он способствует обсуждению и консенсусу посредством одновременного раскрытия карт и переговоров.

Почему 5 баллов? Эта функция отличается умеренной сложностью из-за дополнительной логики фильтрации, позволяющей получить оценку в 5 баллов после обсуждения в команде.

Создайте эталонную пользовательскую историю с известным уровнем затрат и используйте ее для оценки историй других пользователей.

Пример:

Базовая (эталонная) история: «Как пользователь, я хочу посмотреть данные своего профиля». (Оценивается в 3 SP)

Новая пользовательская история: «Как пользователь, я хочу обновить данные своего профиля, в том числе загрузить фотографию профиля, для того чтобы обогатить данные».

Оценка: Новая пользовательская история предполагает дополнительные функциональные возможности, поэтому команда оценивает ее в 5 SP.

Использованный метод: Базовое сравнение: оценка основана на сравнении с известной эталонной историей.

Почему именно 5 SP? Дополнительная сложность обновления деталей и загрузки изображения увеличивает трудозатраты, что приводит к более высокой оценке.

Story points должны предлагать относительную меру без чрезмерной точности. Стремитесь к быстрым, консенсусным оценкам.

Пример:

Оцениваемая пользовательская история: «Как пользователь, я хочу получать уведомления о новых сообщениях для того чтобы быть в курсе всего».

Оценка: команда быстро соглашается на 2 балла истории.

Использованный метод: Быстрый консенсус: направлен на быструю оценку на основе общего понимания.

Почему 2 SP? Функция относительно проста по сравнению с более сложными задачами, что оправдывает более низкую оценку.

В некоторых случаях команды могут оценивать задачи в часах, а не Story points. Этот метод предполагает прогнозирование фактического времени, необходимого для создания пользовательской истории, что может помочь в ситуациях, когда необходимо точное отслеживание времени.

Пример:

Оцениваемая пользовательская история: «Как пользователь, я хочу внедрить двухфакторную аутентификацию, для того чтобы обезопасить свои данные».

Оценка: по оценкам команды, выполнение этой задачи займет около 16 часов.

Используемый метод: Оценка на основе времени: прямое прогнозирование необходимого времени на основе опыта команды.

Почему 16 часов? Задача включает в себя множество компонентов (например, интеграцию SMS-сервисов, изменения пользовательского интерфейса), которые требуют определенного времени.

В Agile-управлении проектами определение того, сколько Story Points человек может обработать за спринт, имеет решающее значение для эффективного планирования спринта. Story Points представляют собой усилия, необходимые для завершения пользовательской истории, а понимание возможностей вашей команды помогает в постановке реалистичных целей и достижении последовательной поставки.

Шаг 1: Определите рабочее время в спринте. Для 2-недельного спринта рассчитайте общее количество доступных рабочих дней и часов.

Пример расчета: предположим, что в 2-недельном спринте 10 рабочих дней. Каждый день состоит из 8 рабочих часов. Общее количество рабочих часов = 10 дней * 8 часов в день = 80 часов.

Шаг 2: Учтите время, не связанное с разработкой. Не все 80 часов будут потрачены на разработку. Члены команды часто проводят время на встречах, груминге и других мероприятиях, не связанных с разработкой.

Пример корректировки: предположим, что 20% времени тратится на мероприятия, не связанные с разработкой. Время, доступное для разработки = 80 часов — (20% * 80) = 64 часа.

Шаг 3: Установите базовое значение Story Points. Story points не переводятся напрямую в часы, но вы можете установить базовый уровень на основе исторических данных. Если команда выполнила задачи схожей сложности в предыдущих спринтах, вы можете оценить, сколько времени обычно требуется на story point.

Пример: если на разработку пользовательской истории на 3 SP обычно уходит 8 часов, то 1 story point может быть примерно эквивалентен 2,67 часа.

Шаг 4: Оценка индивидуальных возможностей. Используя исходные данные, вы можете оценить, со сколькими story points человек сможет справиться за доступное время.

Пример оценки: доступное время разработки = 64 часа. Предполагаемые часы на 1 story point = 2,67 часа.Story points на человека = 64 часа / 2,67 часа на 1 Story point ≈ 24 story points.

Шаг 5: Регулируйте оценку с учетом опыта сотрудника и сложности задач. Учитывайте уровень опыта каждого сотрудника и сложность задач. Менее опытные разработчики могут выполнить меньше задач по сравнению со старшими разработчиками из-за различий в скорости обучения и эффективности.

Пример корректировки: младший разработчик может справиться только с 70% предполагаемых story points, что составит ≈ 17 story points. Старший разработчик может справиться со 100% или более.

Ключевые моменты

Определение того, с каким количеством story points может справиться сотрудник за спринт, требует тщательного учета скорости, возможностей и уровня опыта сотрудника. Используя исторические данные и постоянно уточняя оценки, команды могут более точно планировать спринт, что приводит к лучшим результатам и устойчивой производительности. Регулярный анализ и корректировка story points обеспечивают соответствие процесса изменяющимся возможностям и рабочей нагрузке команды.

Story points — ценный инструмент для Agile-команд, предлагающий относительную меру усилий и сложности. Команда L-TECH использует в своей практике такие методы, как относительная оценка, Planning Poker, сравнение базовых показателей и рассмотрение альтернативных методов, улучшая планирование и доставку спринта. Регулярный обзор, последовательность, четкая коммуникация и сосредоточенность на доставке ценности повышают эффективность Story Points в наших Agile-практиках.