Стори поинты (Story point)

Story point – это условная единица измерения, позволяющая оценить элементы бэклога продукта. Учитывается при определении производительности команды.

Agile-команды часто используют метод Story Point, чтобы оценить, сколько работы они могут выполнить во время следующего спринта. Команда может начать обзор отставания с фиксированного количества баллов – может быть, 5 или 8 – за весь спринт. Затем они рассмотрят наиболее приоритетные элементы невыполненной работы. В свою очередь, они начнут распределять эти баллы по задачам, которые кажутся наиболее важными или стратегически важными.

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

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

Как вы их оцениваете?

Чтобы оценить количество баллов истории для списка задач, команда разработчиков и владелец продукта работают вместе, анализируя несколько факторов, таких как:

• Объем необходимых усилий
• Сложность задач
• Риск, неопределенность

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

 

Покер планирования

Agile-команды могут оценивать очки разными методами, но покер планирования – один из самых популярных.

При таком подходе команда начинает с колоды карт, каждая из которых имеет номер – 1, 2, 3, 5, 8, 13 и т. д., – представляющие последовательность Фибоначчи в математике.

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

Если команда согласится с тем, что пользовательская история не потребует много работы, она может получить 1 балл по шкале «объем работы». Но если команда не уверена в том, как заинтересованные стороны думают, что стоит за историей, они могут разработать ее неправильно, и ей придется начинать заново. Это должно принести задаче более высокую оценку в баллах по шкале «неопределенности».

Следует ли переводить сюжетные очки в часы?

Одна из самых сложных частей труда разработчика – оценить, сколько работы займет проект. Часто разработчики не имеют возможности узнать, сколько времени займет выполнение задачи, пока они не начнут над ней работать.

Ключевым преимуществом использования Story Points является то, что они позволяют команде разработчиков оценить общие усилия и сложность, а не выделять определенное количество часов на их выполнение.

Кроме того, очки истории могут помочь членам команды, которые могут по-разному рассматривать задачу с точки зрения часов, понять ее сложность или объем работы. Как отмечает Майк Кон из Mountain Goat Software:

«Два разработчика могут начать с оценки данной User Story как одного балла, даже если их оценки фактического времени выполнения задачи различаются. Исходя из этой оценки, они могут затем согласиться оценивать что-то в два балла, если каждый согласен, это займет в два раза больше времени, чем первая история».

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