Поделитесь какими-то формальными показателями работы программистов:
1. Количеством коммитов
2. Строк кода (в новом проекте и не очень)
3. Количество закрытых тасков
4. Количество WTF на код-ревью
Любыми другими метриками, которые можно точно.
Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов. Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Кто хочет обсудить их бессмысленность — создайте соседний топик и там обсуждайте.
On Apr 23, 2024, 8:10 PM, alzt <59854@users.rsdn.org> wrote:
A>2. Строк кода (в новом проекте и не очень)
100–150 строк кода в день для C++/Java соответствует синьору; если меньше — это мидл;
A>3. Количество закрытых тасков
Синьор закрывает 2 на 5sp, либо 1 на 8sp в 2W-спринт, либо до 5 мелких поддержки 2–3 линии за 2W-спринт
A>4. Количество WTF на код-ревью
Если назначенное код-ревью делает больше часа — либо тугой либо немотивирован. 1–2-1.
A>Любыми другими метриками, которые можно точно.
Да их там куча. Если вопрос не про R&D, а про support, то обычно смотрят на показатель скорости компетентного ответа тира, количество «переоткрытий» задач (когда открывается якобы закрытый баг — считается самым худшим показателем), и время жизни проблемы.
Хорошим показателем есть полностью независимая от мнения разработчиков система аудита качества, такая как SonarQube. Если метрика Coverage показывает меньше 10% — это явно указывает на проблемы у автора Pull Request.
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Если вопрос Assessment/Evaluation то я прибегал к Skills Matrix (Required skills, Engineering skills, Highly specialized skills), из всех остальных методов она лучше всего себя показала.
Грубо говоря выписываете проекты свои (актуальные, не мертвые), технологии на проектах и обязательные скилы) и по инженерам составляете.
Если более глобально (например, в качестве стандарта по всей компании), то посмотрите в сторону Programmer Competency Matrix1, 2 (как пример);
В обоих случаях принимают бальную систему. Просто тема обширная, бессмысленно описывать этот объем в одном сообщении.
Теперь возвращаясь к вопросу о показателях. Тут надо быть осторожным. Скажу спорную вещь, у разных синьоров могут быть низкие компетенции в отдельных вещах. Например, в команде есть синьор с сильными компетенциями в SQL, есть второй скиловой синьор в специфической области (например ETL). Требовать одинаковые оценки для обоих синьоров, мотивируя это тупым бальным подходом (особенно если он спущен сверху). Потому основная цель, команда должна стремится быть совершенной, если форма совершенства заключается в том, что один из синьоров знает одну область и не знает другую. Это реальность, не будет никогда (конечно будет но не сейчас и не при вас) такого, что все будут знать все. Это очень сложно достичь.
PS. Да, уточню, что озвученные мною показатели, понятно, индивидуальны, тут нет предмета спора, они мною давно, и по "быстрому" можно ими воспользоваться. Но они могут быть другими для других людей, надеюсь, на понимание.
⸻ ❧ “More is lost by indecision than wrong decision.” — Marcus Tullius Cicero
Здравствуйте, alzt, Вы писали:
A>Поделитесь какими-то формальными показателями работы программистов:
Вопрос простой, какие цели ты преследуешь собирая эти метрики и что будешь делать получив их? A>Любыми другими метриками, которые можно точно.
Я бы добавил количество задач на системный рефакторинг которые возникают в будущем и количество регресса. A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Нет хороших и плохих, есть команда и есть её производительность и компетенции. A>Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов.
Если таски небольшие, то их проще оценить и кластеризировать. Таска где надо просто написать 200 строк кода по сформированному дизайну и тесты к этому коду может пог времени занимать столько же сколько таска на разработку некоторого алгоритма или хитрой оптимизации на 40-60 строк кода. A>Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Смотря каких задач, можно делить их на классы и на базе этого примерно понимать какая задача сколько времени займёт.
Здравствуйте, r0nd, Вы писали:
R>Если назначенное код-ревью делает больше часа — либо тугой либо немотивирован. 1–2-1.
А зачем cr мерить в палках? Его надо делать крайне тщательно и добросовестно, если надо больше
часа, значит больше часа. Один из важнейших инструментов для повышения качества кода. Может
код полная лажа, что в нем приходится долго разбираться?
On Apr 24, 2024, 5:22 PM, Sharov <79401@users.rsdn.org> wrote:
S>А зачем cr мерить в палках? Его надо делать крайне тщательно и добросовестно, если надо больше S>часа, значит больше часа. Один из важнейших инструментов для повышения качества кода. Может
Тщательно и добросовестно — слишком пафосно звучит в 2024 для меня. Например, "добросовестно" я слышал столько раз, что это слово для меня потеряло уже всякий смысл.
S>код полная лажа, что в нем приходится долго разбираться?
Рецензент должен уметь общаться с членами команды разработки, и если он не догадался позвонить автору кода и попросить ему помочь, либо объяснить код. То это вариант задуматься руководителю.
⸻ ❧ “To know how much there is to know is the beginning of learning to live.” — Dorothy West
Здравствуйте, Буравчик, Вы писали:
A>>Поделитесь какими-то формальными показателями работы программистов: A>>Любыми другими метриками, которые можно точно.
Б>Количество выполненных задач за месяц — в стори поинтах.
Я бы хотел не примеры таких метрик накидать, а именно конкретные значения: свои, коллег, крутых коллег, в среднем по офису и т.д.
Здравствуйте, Буравчик, Вы писали:
Б>В общем случае не возомжно, т.к. нет прямой связи "работа программиста — прибыль"
Значит компания зарабатывает на чем-то другом. В общем случае это параметры модели, эволюционирование которой во времени может оценить последствия, разных воздействий.
В простейшем случае анализ рисков. Что потеряете в случае гибели ухода конкретного человека и какова вероятность такого события.
Здравствуйте, alzt, Вы писали:
A>Поделитесь какими-то формальными показателями работы программистов: A>1. Количеством коммитов A>2. Строк кода (в новом проекте и не очень) A>3. Количество закрытых тасков A>4. Количество WTF на код-ревью A>Любыми другими метриками, которые можно точно.
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Эту тему хорошо раскрыл писатель-философ Редозубов. Люди стремятся все формализовать — смысл подменить определением, работу — метриками.
Уже все — это уходит в прошлое. GTP будет бить человека по всем метрикам.
Человек нужен в том что не поддается формализации, где требуется разобраться с чем-то уникальным. По этому метрики будут даже вредить.
Как быть, если некий человек метрик выдает мало — но без него проект тупо станет и заменить его практически не возможно за вменяемые деньги?
Здравствуйте, Shmj, Вы писали:
S>Человек нужен в том что не поддается формализации, где требуется разобраться с чем-то уникальным. По этому метрики будут даже вредить.
S>Как быть, если некий человек метрик выдает мало — но без него проект тупо станет и заменить его практически не возможно за вменяемые деньги?
Расскажи, если знаешь примеры. Но вначале напиши сколько конкретно метрик он выдаёт. у меня другой опыт. Реально ключевые люди выдают нереальное количество показателей по всем адекватным метрикам.
Здравствуйте, alzt, Вы писали:
A>Расскажи, если знаешь примеры. Но вначале напиши сколько конкретно метрик он выдаёт. у меня другой опыт. Реально ключевые люди выдают нереальное количество показателей по всем адекватным метрикам.
Пример метрики и значения ключевых людей можно? Типа столько то строк кода и т.п..
A>2. Строк кода (в новом проекте и не очень) A>3. Количество закрытых тасков
Отношение одного к другому: task SPs/LOC. При выполнении прочих условий (код отформатирован корректно, покрытие тестами адекватное) этот параметр определяет продуктивность сейчас (числитель) и последующую поддержку (знаменатель).
