Классические модели оценки Storypoints, Functionpoints не работают!
А что если я вам скажу, что Storypoints, Functionpoints имеют мало общего со сложностью задач?
И мысль тут не моя, а ребят из Stanford - Егора Денисова-Бланш и его коллег.
Но как так получилось?
Они разработали модель, натренировали ее на 100+ тыс.репозиториях и 10 экспертах в разработке, а затем проверили и убедились, что лучшая метрика - это сколько инженерного усилия и сложности было в фактических коммитах!
Обычно, вот эта задача оценки сложности хм…сложная!
Но статья ребят раскрывает то, как это посчитать.
Фактически, метрика комплексная и состоит из следующих:
1.
Сколько времени (в часах) в этом коммите “закодировано”
2.
Насколько трудной была задача, судя по коду и контексту
3.
Какие объективные признаки сложности есть внутри изменений (кохезия, сложность, coupling, архитектурные изменения, объём и тип модификаций)
И как менеджер вы скажите мне:
И тут я сижу «сижу на двух стульях» вместе с вами и ребятами, кто готовил статью:
1.
Как менеджер, я хочу знать оценку до старта.
Но оценка до старта - это гипотеза. Фактически, это шум!
2.
Но как эксперт я понимаю, что люди отваритетельно оценивают задачи и планируют.
Авторы прямо пишут, что их результаты «подсвечивают ограничения традиционных forward‑looking методов» и что backward‑оценка по коду даёт более точную меру усилия.
Как можно это применить на практике:
1.
Код ревью важная задача в нашей индустрии и модель из статьи может позволить вам распределять более сложные задачи на ревью на более «экспертных ребят».
2.
Такая модель может позволить объяснить стоимость реализации отдельных фич и задержку сроков.
3.
Если научиться надёжно оценивать усилие и сложность по коду, можно затем искать связи между «постфактум» метриками и ранними артефактами (типы требований, области системы и т.п.). То есть модель даёт основу для более качественной калибровки планирования (сравнивать фактический effort по коду с изначальными оценками), но не описывает модель, которая сразу из описания задачи выдаёт оценку сложности/усилия.
А разве умение учиться на основе прошлого не ключевой навык менеджера?
А вы верите в умение людей оценивать сроки?
🔥 - да, люди умеют оценивать сроки с достаточной точностью
🦄 - ох о чем вы, сроки мы особо оценивать не умеем
😎 - оцениваю сроки с точностью до минуты
А что если я вам скажу, что Storypoints, Functionpoints имеют мало общего со сложностью задач?
И мысль тут не моя, а ребят из Stanford - Егора Денисова-Бланш и его коллег.
Но как так получилось?
Они разработали модель, натренировали ее на 100+ тыс.репозиториях и 10 экспертах в разработке, а затем проверили и убедились, что лучшая метрика - это сколько инженерного усилия и сложности было в фактических коммитах!
Обычно, вот эта задача оценки сложности хм…сложная!
Но статья ребят раскрывает то, как это посчитать.
Фактически, метрика комплексная и состоит из следующих:
1.
Сколько времени (в часах) в этом коммите “закодировано”
2.
Насколько трудной была задача, судя по коду и контексту
3.
Какие объективные признаки сложности есть внутри изменений (кохезия, сложность, coupling, архитектурные изменения, объём и тип модификаций)
И как менеджер вы скажите мне:
«Да нафига мне оценки сложности уже после написания когда?»
И тут я сижу «сижу на двух стульях» вместе с вами и ребятами, кто готовил статью:
1.
Как менеджер, я хочу знать оценку до старта.
Но оценка до старта - это гипотеза. Фактически, это шум!
2.
Но как эксперт я понимаю, что люди отваритетельно оценивают задачи и планируют.
Авторы прямо пишут, что их результаты «подсвечивают ограничения традиционных forward‑looking методов» и что backward‑оценка по коду даёт более точную меру усилия.
Как можно это применить на практике:
1.
Код ревью важная задача в нашей индустрии и модель из статьи может позволить вам распределять более сложные задачи на ревью на более «экспертных ребят».
2.
Такая модель может позволить объяснить стоимость реализации отдельных фич и задержку сроков.
3.
Если научиться надёжно оценивать усилие и сложность по коду, можно затем искать связи между «постфактум» метриками и ранними артефактами (типы требований, области системы и т.п.). То есть модель даёт основу для более качественной калибровки планирования (сравнивать фактический effort по коду с изначальными оценками), но не описывает модель, которая сразу из описания задачи выдаёт оценку сложности/усилия.
А разве умение учиться на основе прошлого не ключевой навык менеджера?
«Storypoints - это гипотеза.
Код - это факт.
Без измерения факта гипотеза никогда не станет лучше.»
А вы верите в умение людей оценивать сроки?
🔥 - да, люди умеют оценивать сроки с достаточной точностью
🦄 - ох о чем вы, сроки мы особо оценивать не умеем
😎 - оцениваю сроки с точностью до минуты