{"id":8545,"title":"\u041f\u043e\u043f\u0440\u043e\u0431\u0443\u0439\u0442\u0435 \u0437\u0430\u043a\u0443\u043f\u0438\u0442\u044c\u0441\u044f \u0431\u0430\u0442\u0430\u0440\u0435\u0439\u043a\u0430\u043c\u0438 \u0438 \u043d\u0435 \u043f\u0440\u043e\u0433\u043e\u0440\u0435\u0442\u044c","url":"\/redirect?component=advertising&id=8545&url=https:\/\/vc.ru\/special\/isource&placeBit=1&hash=2b5b7b247ca83e67628673cba216c312801b86af12a116e7df5c8ab9fae04e8c","isPaidAndBannersEnabled":false}
Маркетинг
Артем Летюшев

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

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

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

Миф 1. СП это из Scrum

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

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

Миф 2. СП это относительные оценки

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

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

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

Миф 3. СП это оценка сложности.

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

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

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

  • Объем работы (как много времени потребуется чтобы сделать работу);
  • Сложность работы (величина умственной нагрузки);
  • Неопределенность (риски и неуверенность что это можно сделать).

Миф 4. Можно переводить СП в часы

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

Логический

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

Математический

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

Смысловой

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

https://t.me/kanban_talks/44571 Павел Ахметчанов

Если все таки очень хочется конвертировать.

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

Миф 5. Емкость команды в СП выражает ее эффективность и можно по ней сравнивать команды

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

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

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

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

Миф 6. Сначала оценим СП аналитика, потом разработчика, потом тестировщика

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

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

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

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

Нет никакого отдельного "аналитика". Он часть Dev team

Миф 7. При декомпозиции задачи также декомпозируется ее оценка в СП

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

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

  1. Нарезать истории на подзадачи никому кроме команды и не надо. Они сами себе её нарежут так, как им удобно. Декомпозиция нужна именно для увеличения знаний о задаче и удобства работы с ней. Не для оценки;
  2. Оценивать подзадачи тоже не надо, никому не интересно, сколько будет делаться конкретная подзадача, всем интересен конечный результат - готовая задача.
Способов декомпозировать море, но не надо оценивать декомпозированное в СП

Миф 8. СП можно складывать

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

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

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

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

Миф 9. СП лучше часов. Штуки задач лучше СП. NoEstimates!!!

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

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

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

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

Миф 10. СП подходят для долгосрочного планирования

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

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

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

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

0
4 комментария
Популярные
По порядку

Итог: сферический спринт в вакууме стоил 16 сторипоинтов в феврале и 19 в марте.

Кстати, Кто-нибудь помнит, зачем нам эта информация?) Нет? Вот и я тоже не помню. Но мы это апроксимировали, апроксимировали, да не выапроксимировали. Инкремент спринта есть, но выпуск на а проду мы перенесли, у нас тестер приболел. Блять, оно в сторипоинтах, которые ни к чему не привязаны и ни на что не влияют вообще хоть кому-то остаётся нужным и зачем?)

2

Так вам эта информация исключительно чтобы понимать сколько усилий вы приложили тогда то и тогда то. Аппроксимировать всего 2 точки не получится.

СП влияют на прогнозирование ваших усилий и выбор задач в спринт, вам мало?)

0

Ээ, нет уж, вы или крестик снимите или трусы оденьте: не влияют же никак на набор задач в спринт, вон же написано "не суммируются". А если я начну это учитывать (т.е. суммировать) - то я ж нарушу это правило?) Они ж не оценка и не мера. Они именно тот самый сферический конь в вакууме для измерения разных удавов в разных попугаях. Хуй знает, правда, че тогда удава в удавах не измерять, а спринт в единицах задач. Т.е. я могу спринт оценить постфактум в сторипоинтах и мерить ускорение команды в сторипоинтах, но фактически это не будет значить ничего, ведь сторипоинт - это единица производительности именно этой команды (со всём текущим набором знаний) в этот конкретный момент времени на тот конкретный набор задач. Даже мать его эталон нельзя придумать, потому что иначе этот глобальное наебалово вскроется и станет обычным планированием по часикам. Живут себе внутри команд задачи по вотерфоллу (ну может у вас тестер параллельно там заходит, А я чет команд таких не знаю), всё задачи на доске с учётом загрузки нужных спецов разгребаются (считай, канбан), абсолютно заменимых внутри команды людей и компетенций ваще никогда не бывает (фронтенд-ПМ после копирайтера - МЛ разработчика пилит. Ну да ну да, пошёл я нахер), А в целом всё живут по Скраму, но нет)

1

хороший статья!

0
Читать все 4 комментария
Финалисты 6-го отбора RITA
Кейс про Амазон: Почему так сложно скопировать «Голубой океан»?

«Лучше быть первым, чем потом доказывать, что вы лучше» - утверждает выдающийся маркетолог Джек Траут, автор «Маркетинговых войн» и других бестселлеров. На этом принципе во многом построена концепция «Голубых океанов».

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

По данным Startup Genome, 9 из 10 стартапов терпят неудачу. Возможных причин «смерти» много: недостаточно протестированная гипотеза, неподтвержденная юнит-экономика, неверная стратегия или просто неудача в подходе к продажам.

Что Tele2 предлагает клиентам в «черную пятницу»

На главной распродаже года клиентов компании ждут сразу несколько интересных предложений: скидки на смартфоны, пакеты SMS и безлимитный трафик на YouTube, Яндекс.Карты, Яндекс.Навигатор.

Из науки в IT: как создать свой стартап и стать преподавателем

Как перейти в IT из другой сферы? Как разработать курс, которому нет аналогов? Как студенту получить максимум пользы от занятий? Рассказывает преподаватель OTUS Сергей Окатов, руководитель курсов «Kotlin Backend Developer» и «Kotlin Developer. Basic».

Сервис Boxberry по доставке посылок из США в Россию не умеет забирать посылки из почтового отделения, товар потерян?

Прочитала статью и решила воспользоваться сервисом, заказав товар на eBay.com:

Потратили $1 млн на клинику для профилактики здоровья зубов в Москве — и через десять месяцев закрыли проект

История о неудачном запуске монопродукта в стоматологии — его пришлось переформатировать.

Та самая клиника
Ускореная доставка AliExpress
Бот, который сделает маму счастливее

Kind Bot напечатает и отправит по почте фото вашей маме. В 2 клика.

Хочу кухню как у подруги: зачем в Циан сделали поиск квартир по фото

Рассказывает Юлия Зыкова, руководитель команды «Аудитория» в Циан.

Ложь, статистика и бизнес-анализ (в ИТ)

Давайте посмотрим, кто такой бизнес-аналитик (сначала не в ИТ, потом в ИТ), чего от него ждут, чем он должен заниматься и что он делает на самом деле.

null