Спасибо Денис. Все верно, есть погрешность.

Это да.

Капасити показывает нам доступную трудомощность (в часах)


А велосити - то, насколько эффективно мы используем эту трудомощность (в сторипойнтах за спринт)

Вижу так

Так Velocity это же  дифференцированнное количество Story Points во ВРЕМЕНИ.

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

Т.е. они используются как надстройка над тем чтобы как-то объем работ сматчить на время

Обычно, да, по крайней мере, там, где я сталкиваюсь

да

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

Ну чисто спринт смэтчить наверное не особо интересно, а вот увидеть чуть подлиннее - как у нас развивается проект, успеваем ли в рамках именно проекта

Когда говорите про проект, имеется ввиду прект с обозначенным сроком?

Разница в соотношение результат/затраты.

Если поставить целью все оценивать до минуты, то вряд ли эта дополнительная точность даст выхлоп, оправдывающий затраты )

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

Да, проект как скоординированная поставка набора элементов, которая оптимизируется в рамках треугольника стоимость-функциональность-срок

А вопрос как ставится
1. Успеем ли мы к этому сроку?
2. Когда сделаем проект?

У этих вопросов совершенно разный методики ответов

Хм ... в тупик поставили, ответы слышал на вопросы в обеих формах )

Конкретика зависит от того, что РП решил оптимизировать, чем решил поступиться

прогноз не ответит на вопрос успеем или нет
это прогноз - "наверно успеем с такойто вероятностью"

1 - й закрытый вопрос, порождает системное размышление и вариации исходя из возможностей
2 - й открытый вопрос, порождает открытое размышление исходя из предположений как бы можно было.

По этому, чаще всего ответить на второй вопрос - это очень сложная задача.
А вот на первый гораздо проще.

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

Это позволяет имплементору лучше сориентироваться и быстрее дать ответ.

О, классное различение, спасибо за наводку!

Второй вопрос да, он ещё ненужную ответственность накладывает. Это как спрашивали - когда будет готова задача? Отвечал: осталось 7 часов, а когда будет готово будет зависеть от того, не отвлекут ли меня другими, более приоритетными задачами

Вообще ассациативно это у меня связывается с методом решения прямой и обратной задачи в математике. Особенно мне близки задачи кинематики, но это совсем узкоспециализированная тема.

Так вот, для решения закрытых систем, где есть четкая связь между аргументом функции и результатом - проще решается прямая задача. F(X) = x^2 (пример)

В том случае когда одно значение аргумента может порождать два разных варианта для функции, применяется обратная задача. Когда мы говорим условия, при  X>2, X<7, будет ли наш ответ F(X) равен этому?

А таких задач в природе куда больше, т.к. по существую своему наш мир (исходя из наших возможностей расчетов) для нас совсем нелинеен.

Интересно, интересно, благодарю, и в этом ещё подкопаюсь!

(сам все воспринимаю во многом по аналогии с физикой, пренебречь несущественным, использовать простые формулы для сложных явлений p=nkT, вот это вот все)

Сделал небольшой пост https://vc.ru/164933 . Любопытно, какое мнение у сообщества, прокомментируйте пожалуйста)

В общем, если вернутся к контексту использования Stopy Points для декомпозированных задач
в рамках одной команды. Когда мы элементы декомпозиции оцениваем отдельно по SP а потом складываем SP и пытаемся запихнуть в Спринт, натягивая на линейку Capacity

Мы по факту сравниваем со временем - успеем или нет.
Но при этом мы вообще не понимаем как матчится SP на время.

Как обычно это делается в метрологии?
1. Берем измеряемые элементы и смотрим как они на шакле себя позицианируют. Например 1SP на время.
2. Получаем распределение
3. Берем наиболее вероятное событие из распределения
4. Фиксируем измерение (округляя) все остальные к наиболее вероятному.

Но тут есть свои но
1. Шкала времени - не формирует нормально распределение, по этому наиболее вероятное событие определяем процентилем
2. Отдельно 1SP нет вообще смысла рассматривать. Т.к. мы не можем поставить чистый эксперемент по решению задач с 1SP, 2SP, 3SP - и как-то выработать общую шкалу по времени.

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

Да, у нас есть вариативность.
И тут мы можем сказать, а давайте пойдем путем великого Уолтера Шухарта, и придумаем пределы для нашего графика Velocity и в рамках этих пределов будем как-то жить по средней.

Забывая оглядываться на то, что с изменением общей среды, меняются и пределы.
Ну ок, давайте ориентироваться на среднюю плавающую, и будем адаптировать Velocity под нее.

Еще одну проблему порождаем - а как считать тогда среднюю плавающую, это ж сколько спринтов надо для нормального расчета?

И это при том, что мы даже осознаем что шкала SP вообще не матчится ровненько на Время.
Т.е. мы умножаем одну ошибку на другую, и хотим при этом получать ровные срезы.

Вопрос - зачем такие сложности?
Scrum - же отлично сказано - одна цель на один спринт. Нафига нам вообще там SP?
По сути - старайся успеть за спринт сделать одну задачу. Мелочь, то же можно но не так важно