Стори поинты: как это работает - Аджайл Блог 2018

Стори поинты: как это работает

Сколько усилий нужно потратить на задачу? В условиях неопределенности и сложности ответ лучше дать не в часах. Куда удобнее относительные единицы, из которых самые известные — стори поинты. Мы перевели статью Майка Кона о том, какие факторы нужно учитывать, оценивая работу в стори поинтах, и как согласовывать эти факторы между собой. Бонус — список типичных ошибок в применении стори поинтов.

 

стори поинты

Стори поинты: как это работает

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

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

Вместо единицы, двойки и тройки команда могла бы использовать цифры 100, 200 и 300. Или 1 миллион, 2 миллиона, 3 миллиона. Важно соотношение, а не цифры как таковые.

Что включают в стори поинт?

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

  • Объем работы для выполнения.
  • Сложность работы.
  • Риски или неопределенность при выполнении работы.

Измеряя работу стори поинтами, обязательно оцените каждый из этих факторов.

 

стори поинты

Объем работы

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

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

Второй странице стоит присвоить больше стори поинтов. Может, не в 100 раз больше, хотя на ней и во 100 раз больше полей. В конце концов, существует эффект масштаба, так что в реальности мы можем затратить на вторую страницу всего в 2, 3 или в 10 раз больше усилий, чем на первую.

 

стори поинты

Риски и неопределенность

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

Неопределенность как таковая отражена уже в самой последовательности чисел для стори поинтов, которая напоминает ряд Фибоначчи: 1, 2, 3, 5, 8, 13, 20, 40, 100. Какое бы число вы не выбрали, усредненная неопределенность уже заложена в него — если,, конечно, вы используете именно такое соотношение чисел.

 

стори поинты

Сложность

Также нужно учитывать сложность. Вернемся к нашей странице со 100 полями, между которыми нет взаимодействий.

А теперь представим себе другую страницу со 100 полями. Часть из них — поля с датами и, соответственно, календарными виджетами. В другой части можно вводить только ограниченное количество символов: например, номера телефонов. Есть и поля, в которых проверяется контрольная сумма (например, с номерами банковских карт). Кроме того, есть взаимодействия между полями. Для карты Visa страница должна выдавать поле с трехзначным CVV-кодом, а для карты American Express — с четырехзначным.

Хотя на экране по-прежнему 100 полей, разработка будет сложнее, а значит, займет больше времени. Растет вероятность, что разработчик ошибется и ему придется откатить какие-то из изменений и переделать работу.

Учитывайте все эти факторы

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

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

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

Обратите внимание на Definition of Done

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

Типичные ошибки

  1. Стори поинты не надо сводить только к сложности, неопределенности или объему работы.
  2. Стори поинты не надо переводить в часы — это создаст дополнительные разногласия в оценках.
  3. Стоит избегать усредненных значений (например, когда одна половина команды оценивает элемент на 3 стори поинта, а другая половина — на 5). Если возникает дискуссия, лучше принять больший показатель.
  4. Никогда не меняйте оценку во время спринта, даже если она оказалась некорректной. Она пригодится потом для объективных наблюдений о скорости работы.
  5. Не забывайте оценивать баги — конечно, если у команды нету фиксированного процента времени на устранение багов.
  6. Не присваивайте стори поинты очень мелким задачам (например, четырехчасовому исследованию) — для них достаточно таймбоксов.
  7. Не меняйте оценку по ключевым элементам бэклога в каждом отдельном спринте — так вы не сможете сравнивать между собой разные спринты, а ведь стори поинты служат и этой цели.
  8. Если в новом спринте остается работа с прошлого спринта, не оценивайте ее повторно: во-первых, вы уже знаете ее продолжительность в часах, во-вторых, эа работа потом отразится в скорости (velocity) команды.
  9. Не подстраивайте оценку в стори поинтах под отдельного разработчика.
  10. Если меняется состав команды, нужно настроить оценки заново.
  11. Не подстраивайтесь под оценку самого опытного специалиста на совещании.
  12. Не забывайте обсудить неадекватные оценки на ретроспективе.

 

Переведено и адаптировано командой BrainRain по материалам:

What are story points? (Mike Cohn)

12 common mistakes made when using Story Points (Maarten Dalmijn)

Другие полезные материалы:

Как научить команду оценивать в попугаях (story points) (Тим Евграшин)

Покер планирования — степени двойки (статья Криса Форчьюина в нашем переводе)

 

НАШ БЛОГ

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости