#мнение
Story Points. Изобретение дьявола. Часть 1
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
Миф 1. СП это из Scrum
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
Миф 2. СП это относительные оценки
Тут происходит путаница из-за того что СП часто отождествляют с методом покер-планированием. Покер-планирование это метод, который придумал Джеймс Греннинг на основе метода Дельфи , а популяризировал его все тот же Майкл Кон. Это метод экспертной оценки, но не задач, а вообще оценки любых показателей и призван для нивелирования влияния мнения лидера (если тимлид сказал что надо 5 дней на задачу, то попробуй ему возрази) и для шаринга знаний о сущности работы.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Миф 3. СП это оценка сложности.
Само себе определение СП путает. СП - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
- Объем работы (как много времени потребуется чтобы сделать работу);
- Сложность работы (величина умственной нагрузки);
- Неопределенность (риски и неуверенность что это можно сделать).
Миф 4. Можно переводить СП в часы
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
- Логический. Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды;
- Математический. Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться;
- Смысловой. Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Если все таки очень хочется конвертировать. Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".
Что забавно, изначально СП предполагались как идеальные дни, которые конвертировались в обычные умножение на коэффиент нагрузки, равный примерно 3
Story Points. Изобретение дьявола. Часть 1
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
Миф 1. СП это из Scrum
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
Миф 2. СП это относительные оценки
Тут происходит путаница из-за того что СП часто отождествляют с методом покер-планированием. Покер-планирование это метод, который придумал Джеймс Греннинг на основе метода Дельфи , а популяризировал его все тот же Майкл Кон. Это метод экспертной оценки, но не задач, а вообще оценки любых показателей и призван для нивелирования влияния мнения лидера (если тимлид сказал что надо 5 дней на задачу, то попробуй ему возрази) и для шаринга знаний о сущности работы.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Миф 3. СП это оценка сложности.
Само себе определение СП путает. СП - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
- Объем работы (как много времени потребуется чтобы сделать работу);
- Сложность работы (величина умственной нагрузки);
- Неопределенность (риски и неуверенность что это можно сделать).
Миф 4. Можно переводить СП в часы
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
- Логический. Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды;
- Математический. Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться;
- Смысловой. Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Если все таки очень хочется конвертировать. Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".
Что забавно, изначально СП предполагались как идеальные дни, которые конвертировались в обычные умножение на коэффиент нагрузки, равный примерно 3