Здравствуйте, alzt, Вы писали:

A>Поделитесь какими-то формальными показателями работы программистов:
Вопрос простой, какие цели ты преследуешь собирая эти метрики и что будешь делать?
A>1. Количеством коммитов
После squash это не имеет смысла.
A>2. Строк кода (в новом проекте и не очень)
Вполне можно использовать для разных задач.
A>3. Количество закрытых тасков
Зависит от её оценки.
A>4. Количество WTF на код-ревью
Если человек не идиот, то он после первых WTF начинает учится.
A>Любыми другими метриками, которые можно точно.
Я бы добавил количество задач на системный рефакторинг и количество регресса.
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Нет хороших и плохих, есть команда и есть ей производительность и компетенции. Представь, что ты
A>Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов.
Если таски небольшие, то их проще оценить и кластеризировать. Таска где надо просто написать 200 строк кода по сформированному дизайну и тесты к этому коду может пог времени занимать столько же сколько таска на разработку некоторого алгоритма или хитрой оптимизации на 40-60 строк кода.
A>Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Смотря каких задач, можно делить их на классы и на базе этого примерно понимать какая задача сколько времени займёт.

Здравствуйте, alzt, Вы писали:

A>Поделитесь какими-то формальными показателями работы программистов:
Вопрос простой, какие цели ты преследуешь собирая эти метрики и что будешь делать получив их?
A>Любыми другими метриками, которые можно точно.
Я бы добавил количество задач на системный рефакторинг которые возникают в будущем и количество регресса.
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Нет хороших и плохих, есть команда и есть ей производительность и компетенции.
A>Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов.
Если таски небольшие, то их проще оценить и кластеризировать. Таска где надо просто написать 200 строк кода по сформированному дизайну и тесты к этому коду может пог времени занимать столько же сколько таска на разработку некоторого алгоритма или хитрой оптимизации на 40-60 строк кода.
A>Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Смотря каких задач, можно делить их на классы и на базе этого примерно понимать какая задача сколько времени займёт.