Что такое Story Points в Agile и как их оценить?

Что такое Story Points в Agile?

Story Points — это измерение для оценки работы, выполненной посредством внедрения гибких фреймворков, таких как Scrum и eXtreme Programming.

Реализация пользовательской истории — сложная задача. Команда может столкнуться с риском; сложности и т.д. в процессе разработки. Этот уровень сложности измеряется командой разработчиков с помощью абстрактной меры, называемой стори-пойнтом. Поэтому баллы в agile используются как метрики в agile-разработке. Он рассказывает команде о том, насколько сложной является реализация истории.

Сессии подготовки бэклога продукта выполняют оценку точек истории, которые затем оцениваются командой разработки продукта и командой тестирования. Это сделано для того, чтобы повысить эффективность планирования спринта. Уход за бэклогом продукта — это грубая оценка, которая проверяет:

• Готов ли план спринта к эффективному выполнению.
• Достаточно ли информации для решения вопросов.
• Является ли разумным план спринта, основанный на пользовательской истории.

Agile Story Points оценивает три основных компонента:

• Риск: для конкретного элемента риски, связанные с ним, представляют собой расплывчатые требования, изменения в процессе и зависимость от третьей стороны.
• Сложность: представляет собой уровень сложности разработки функции.
• Восприятие: определяет знакомство с функцией членов команды и то, насколько однообразны определенные задачи в рамках разработки.

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

Оценка Story Points в Agile

Шаги для оценки Agile Story Points

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

Чтобы начать с оценки стори-пойнтов в agile, у команды должна быть базовая история, которая не обязательно должна быть маленькой, но которая может найти хороший отклик внутри команды. За этим следует определение размера историй на основе базовой истории. С помощью эталонных рассказов следует присвоить рассказу баллы. Каждой истории присваивается количество баллов.

Преимущества размера

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

• Обзор объема работ можно посмотреть.
• Объем работы можно определить с разных точек зрения.
• Любое ложное предположение можно исправить.
• Вещи, которые не могут быть точными, убираются.

Размер производится с учетом следующего:

• Объем работы, которую необходимо выполнить
• Сложность работы
• Риск или неопределенность при выполнении работы
• Время / продолжительность

Спринты можно планировать более точно, следуя приведенному ниже процессу:

Трехэтапный процесс оценки сюжетных баллов :

1. Использование ряда последовательности Фибоначчи.

• Традиционная оценка человеческого дня была заменена на оценку сюжетных баллов с помощью чисел Фибоначчи, т.е. 1, 2, 3, 5, 8, …
• Линейная шкала не используется, поскольку она предлагает элементы, недостаточно дифференцированные для определения оценки. Однако ряд Фибоначчи может оценить незначительные скачки в задаче.
• Ряд Фибоначчи представляет собой последовательность чисел, где следующее число в последовательности является суммой двух предыдущих чисел. Для оценки сюжетных баллов в Agile последовательность Фибоначчи изменена на 0,5, 1, 2, 3, 5, 8, 13,…

2. Определение матрицы

• Определяется базовая линия для каждой сюжетной точки.
• Базовый уровень включен в матрицу как значение 1. Он установлен в качестве стандарта для наименьшего количества риска, повторения и т. д.

3. Планирование покера

С помощью покера планирования команда договаривается о правильном приблизительном значении сюжетных баллов для каждого элемента.

Принцип планирования покера заключается в следующем.

• При планировании спринта каждый разработчик и тестировщик получает набор карточек. На картах изображен ряд чисел Фибоначчи.
• Элемент из таблицы невыполненных работ выбирается для опроса и уточнения характеристик элементов.
• В конце обсуждения тестер и разработчик в частном порядке выбирают карточку, отражающую оценку предмета.
• Затем карты раскрываются оценщиками. Они переходят к чистому пункту, если достигается консенсус. Для различных карт обсуждение ведется лидерами до тех пор, пока не будет достигнут консенсус.

Заполненную матрицу полезно использовать оценщикам в качестве ориентира во время покера планирования. Это обеспечивает большую согласованность между задачами. Кроме того, максимальный предел оценки составляет 13, если он больше 13, то целесообразно разбить задачу на более мелкие элементы. Кроме того, если оценка задачи меньше 1, рекомендуется включить ее в другую задачу.

Еще 8 шагов оценки для успешной оценки очков истории в Agile:

1. Определение базовых историй

• Одним из важных шагов для оценки точек истории в Agile является определение базовой истории, которая используется в качестве эталона для относительного размера невыполненной работы.
• Базовая история берется из более ранней истории, выполненной командой разработчиков, или из текущего невыполненного проекта.
• Понимание базовой истории должно быть одинаковым для всех членов команды. Другими словами, команда должна быть уверена в исходной истории.

2. Обсудить требования

• Детали истории должны быть обсуждены, а пояснения, связанные с пользовательской историей, должны быть предоставлены владельцем продукта или бизнес-аналитиком.

3. Записывайте важные вещи

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

4. Важные вопросы, которые следует задать

Несколько вопросов слишком важны, и команда разработчиков должна задать их себе.

• Чему должны научиться члены команды, прежде чем приступить к дизайну?
• Каково требование кода для истории? Какой длины требуется и есть ли подобные коды, написанные командой разработчиков ранее.
• Для принятия клиентами, сколько работы требуется?
• Есть ли какие-либо внешние зависимости, которые есть у истории?
• Есть ли у кого-нибудь в команде опыт работы с той же историей?
• Есть ли в этой истории какая-то простота или связанная с ней сложность с точки зрения бизнес-логики или с технической точки зрения?
• Насколько гарантировано своевременное получение зависимостей?

5. Очки для относительного сравнения

• Рассказу должны быть присвоены относительные баллы для сравнения.
• Истории должно быть присвоено такое же количество баллов, т. е. 1, за истории, которые имеют тот же объем работы, что и истории с уже заданным размером.
• Для более сложных историй следует присваивать пропорционально более высокое значение.
• Если история менее сложна благодаря полученным знаниям из предыдущей истории, но почти аналогична этой истории, следует присвоить более низкое значение.

6. Консенсус должен быть достигнут среди всей команды в соответствии с размером истории.
7. Должна быть проверка того факта, что между историями существует внутренняя согласованность.
8. Следует убедиться, что через повторяющиеся интервалы все 1 одинаковы или все 2 совпадают и т. д.

Преимущества оценки Agile Story Point

Применение оценки к стори-пойнтам в agile дает преимущества как разработчикам, так и владельцам продукта.

Преимущества, предлагаемые разработчикам:

• Применение оценки позволяет разработчикам узнать, сколько планирования требуется для спринта, и, следовательно, может выполнять работу в устойчивом темпе.
• Избегают чрезмерного планирования спринта.
• Стратегия внедрения и требования, необходимые для продукта, хорошо понятны благодаря обсуждениям и разработкам.

Преимущества, предлагаемые владельцам продукта:

• Можно сосредоточиться на долгосрочной доставке продукта.
• Можно оценить «соотношение цены и качества» или «окупаемость инвестиций».
• Технические риски больших предметов видны владельцам продукта.

Изучайте онлайн-курсы по программному обеспечению от лучших университетов мира. Участвуйте в программах Executive PG, Advanced Certificate Programs или Master Programs, чтобы ускорить свою карьеру.

Резюме

Подобно тому, как гибкая методология требует практики, оценка сама по себе — это практика, которая со временем станет лучше. Внедрение оценки Agile Points приносит пользу как разработчикам, так и владельцу, что в конечном итоге приводит к эффективному решению.

Если вы хотите освоить разработку программного обеспечения, тогда приходите и ознакомьтесь с курсом Executive PG Program in Software Development — Specialization in Full Stack Development, предлагаемым upGrad.

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