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

[gandjustas]

И?

Надо использовать или не надо? Если надо, то каких ограничений придерживаться?

Или использовать что-то другое?

[Renewal_Studio]

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

[Renewal_Studio]

Да, тоже с этим сталкивался. В одной компании даже писал большую SQL-процедуру для перевода СП в часы и вывода в BI для финансистов (так надо было) и объяснить что это булщит не получилось(

[cs0ip]

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

[Renewal_Studio]

Хмм, думаю прямо сейчас у меня руки не дойдут) Но могу ответить кратко в комментарии. СП нужны для ответа на вопрос: "сделается ли задача за спринт?"

По сути его отлично решает, так как позволяет сосредоточить внимание факте сделаем/не сделаем и построить дискуссию вокруг того какие риски или возможности видят оценивающие

При этом создается достаточно абстрактная штука, чтобы всякие эффективные менеджеры отстали от команды с точными сроками

[cs0ip]

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

[Renewal_Studio]

Верно, СП не конвертируются по крайней мере линейно точно во время. Но нам никто не мешает прикинуть сколько рыб влезет в ведро, даже если мы не знаем объем каждой рыбы. Зачем их складывать чтобы сказать сделаем задачу за спринт или нет?)

[gandjustas]

СП нужны для двух вещей:

• отделить оценку срока от оценки объема

• сделать интегральную оценку затрат команды, а не планировать работу каждого специалиста

И обе цели индуцируют недостатки:

• бизнесу нужны сроки, так как зарплаты не зависят от трудозатрат и объема работ

• бизнесу нужна максимальная утилизация каждого сотрудника, а не высокий velocity

• бизнес хочет объективные величины сроков\затрат\результата, а не абстрактные

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

[Renewal_Studio]

Все так. Но если приходить к бизнесу и спрашивать "А можно мы будем требовать таких же прогнозов ценности того что вы приносите, как вы от разработки прогнозов сроков?", то бизнес быстро начнет ворчать не "вашего ума дело"

[cs0ip]

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

В п.2 вы говорите про оценку затрат команды, но затраты как раз в часах, а не в объемах. Я никак не могу понять математику всех этих расчетов, пока магия какая-то. Т.к. интегральная оценка не из воздуха берется, а из частей с помощью определенных операций (сложение, взятие интеграла, пр.), а в статье говорится про то, что складывать нельзя

[Renewal_Studio]

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

А еще продолжительность!=дедлайн!=трудозатраты!=сложность!=объем работы команды за неделю скажем

[gandjustas]

Объем оценить легче чем срок и гораздо точнее. Срок зависит от объема, продуктивности и нагрузки исполнителей, ожиданий, связи и параллелизма задач.

В принципе вся наука типа PERT и сетевого планирования придумана чтобы объемы превратить в сроки.

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