Классические модели оценки Storypoints, Functionpoints не работают!

А что если я вам скажу, что Storypoints, Functionpoints имеют мало общего со сложностью задач? И мысль тут не моя, а [ребят из Stanford - Егора Денисова-Бланш и его коллег](https://ar5iv.labs.arxiv.org/html/2409.15152#:~:text=Manual code reviews are an,86 for)[.](https://ar5iv.labs.arxiv.org/html/2409.15152#:~:text=Manual code reviews are an,86 for)

Но как так получилось? Они разработали модель, натренировали ее на 100+ тыс.репозиториях и 10 экспертах в разработке, а затем проверили и убедились, что лучшая метрика - это сколько инженерного усилия и сложности было в фактических коммитах!

Обычно, вот эта задача оценки сложности хм…сложная! Но статья ребят раскрывает то, как это посчитать.

Фактически, метрика комплексная и состоит из следующих: 1. Сколько времени (в часах) в этом коммите “закодировано” 2. Насколько трудной была задача, судя по коду и контексту 3. Какие объективные признаки сложности есть внутри изменений (кохезия, сложность, coupling, архитектурные изменения, объём и тип модификаций)

И как менеджер вы скажите мне: «Да нафига мне оценки сложности уже после написания когда?»

И тут я сижу «сижу на двух стульях» вместе с вами и ребятами, кто готовил статью: 1. Как менеджер, я хочу знать оценку до старта. Но оценка до старта - это гипотеза. Фактически, это шум! 2. Но как эксперт я понимаю, что люди отваритетельно оценивают задачи и планируют.

Авторы прямо пишут, что их результаты «подсвечивают ограничения традиционных forward‑looking методов» и что backward‑оценка по коду даёт более точную меру усилия.

Как можно это применить на практике: 1. Код ревью важная задача в нашей индустрии и модель из статьи может позволить вам распределять более сложные задачи на ревью на более «экспертных ребят». 2. Такая модель может позволить объяснить стоимость реализации отдельных фич и задержку сроков. 3. Если научиться надёжно оценивать усилие и сложность по коду, можно затем искать связи между «постфактум» метриками и ранними артефактами (типы требований, области системы и т.п.). То есть модель даёт основу для более качественной калибровки планирования (сравнивать фактический effort по коду с изначальными оценками), но не описывает модель, которая сразу из описания задачи выдаёт оценку сложности/усилия.

А разве умение учиться на основе прошлого не ключевой навык менеджера?

«Storypoints - это гипотеза. Код - это факт. Без измерения факта гипотеза никогда не станет лучше.»

А вы верите в умение людей оценивать сроки?

🔥 - да, люди умеют оценивать сроки с достаточной точностью 🦄 - ох о чем вы, сроки мы особо оценивать не умеем 😎 - оцениваю сроки с точностью до минуты