Scrum Story Points. Изобретение дьявола

Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты/Story Points. Для краткости их буду указывать по тексту как СП.

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

СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.

Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.

Тут происходит путаница из-за того что СП часто отождествляют с методом покер-планированием. Покер-планирование это метод, который придумал Джеймс Греннинг на основе метода Дельфи , а популяризировал его все тот же Майкл Кон. Это метод экспертной оценки, но не задач, а вообще оценки любых показателей и призван для нивелирования влияния мнения лидера (если тимлид сказал что надо 5 дней на задачу, то попробуй ему возрази) и для шаринга знаний о сущности работы.

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

Сами по себе СП не являются относительными изначально.

Само себе определение СП путает. СП - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы.

Казалось бы в чем разница между усилиями и трудозатратами?

Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:

Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:

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

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

Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.

Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".

Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному.

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

И как в поговорке "к сожалению к рукам сотрудника прилагается и остальной человек".

Не нужно оценивать эффективность по количеству СП и тем более сравнивать 2 команды. ты сравниваешь одни уникальные усилия с другими уникальными усилиями. Оценивайте результат.

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

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

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

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

Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.

Ну и плюс немного дополнительных умозаключений:

Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.

Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет).

Также появляется интересный вывод - capacity это не сумма СП, а просто их количество.

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

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

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

А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.

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

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

Но Майкл Кон так не думает)

Так как оценка СП выражает объем, риски и сложность, то оценивать весь беклог в них и потом использовать на планировании спринта оценку в СП, которую поставили полгода назад бессмысленно. Даже если объем работы не поменялся, то изменилась сложность (люди не стоят на месте, они развиваются или деградируют + меняется состав команды) + могла изменится неопределенность (какие-то риски ушли, какие-то появились).

Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют velocity. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем "50/50, или сделаем или нет".

#scrum #agile #kanban #projectmanagement #project_management