Понятно что в завимости от опыта/типа разработчика задача будет выполнена с разной скоростью и качеством. Но основная линейка это велосити субьекта и динамика.

А как ты велосити считаешь?

Этот параметр даже в скраме считают по команде, а не человеку (хотя даже для команды оно не работает)

> Вообще покрути команду в разных срезах, посмотри, как можно получить эффект от конкретного сотрудника.
Это то понятно, что нужно оперировать лучшими качествами, сглаживать углы, и всё такое
> Если никак, найм будет эффективнее и окупиться с учетом онбординга и мотивационных факторов - то прощайся.
У нас когда происходит найм, и если человек прошёл ИС, то менеджмент максимально тормозит расставание: 1-1, PDP, HR/менеджмент саппорт или смена команды

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

Ну и обосновывай, почему расставание эффективно.
Деньгами, конечно.
Собственно, кроме демотивации остальной команды - других поводов обычно и нет (существенных).
Очень редко разработчик, который прошел ИС - не окупает своей зарплаты.

кол-во новых задач * сторипоинты            кол-во повторяющихся задач * сторипоинты
———————————————————-    +      —————————————————————————
             процент участия                                                         процент участия


новые задачи - все, где нет участия, или процент участия меньше 20%

ну и у нас есть ещё процесс саппорта, регламент и требования, там мы замеряем кол-во решенных тикетов, сложность, повторяемость, время ответа, время решения, кол-во привлеченных ресурсов для решения задачи

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

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

Эээ, сторипойнты - не аддитивная функция же, это только мера сложности задачи (да и то сильно зависит от того, как определяется оценка задачи в пойнтах). Ее нельзя использовать для velocity, тем более velocity человека.
Оценка процента участия - тоже очень странный параметр, как его считать-то. У какого-нибудь эксперта по СБ процент участия может быть 0.1%, а при этом без него ничего не заработает.
Ну и так далее - все эти линейки ничего не показывают, увы.

Ну, это проблемы процессов (впрочем, спринты - это вообще признак проблем в процессах)

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

ну мы когда пристреливаемся новой командой, при самой первой истории, даём вводные: представьте, что идеальный программист, который знает всё о системе может сжечь за день 3 сторипоинта. сторипоинт в нашей системе координат состоит из: 1) сложности 2) обьема 3) рисков

Вспоминая тех людей, которые у меня спасали проект - по этим линейкам они все были бы лоуперформерами )

Но это бессмысленный параметр. Задачу, которую Вася напишет за день, Катя будет писать неделю. Но и наоборот.

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

Изначально даются легкие задачи-истории для оценки командой, дальше команда нарабатывает экспертизу, погружается в домен и задачи, которые были на 3-м месяце - 8/13 sp становятся 3-5sp. Ну и тут ещё важно соблюдать предсказуемость команды и ретро спринта(с менеджментом, не с командой)

Ну, вот в результате ты и говоришь не столько о sp, сколько о майках.
Но майки - очевидно не аддитивны.

Да, совершенно верно, но со временем команда начинает осознавать эту абстракцию в рамках команды

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