Тендеры и лиды
Информация
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? Дополнительная сложность обновления деталей и загрузки изображения увеличивает трудозатраты, что приводит к более высокой оценке.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12613 тендеров
проведено за восемь лет работы нашего сайта.
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-практиках.
