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>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Хорошесть метрики определяется его полезностью для целей проекта. Поэтому без цели довольно трудно ответить на этот вопрос.
Одна и та же метрика может принести пользу в одном проекте, и вред в другом.
1) Test coverage — необходим в критическом софте, но вреден в задачах прототипирования.
2) Cyclomatic complexity — будет вредна для legacy проекта в состоянии поддержки, так как отвлечет ресурсы на улучшение этой метрики. Также она будет вредна для модели разработки когда код пишется, например, математиком, а потом переписывается программистом.
3) Стори пойнты не работают в проектах с большой компонентой ресерча. Также они вредят в больших проектах с жесткими дедлайнами, так как команда за деревьями перестает видеть лес.
4) Количество строчек кода не работает в проектах, где большой разброс по сложности задач или команда состоит из специалистов очень разных компетенций. С другой стороны, если команда штампует типовые решения по образцу, то количество строчек кода может оказаться вполне себе полезной метрикой.
Список можно продолжать долго и метрик можно выдумать тоже много. Основная идея в том, что идти надо не от метрик, а от целей и задач. И думать о том, как метрики помогут с этим помочь и какую функцию они должны выполнять. Метрика может нужна, чтобы видеть прогресс, менять фокус команды, выявлять слабые места и так далее. Когда будут ответы на эти вопросы, то идеи метрик будут органично появляться сами. И очень может, что выработаете свои собственные.
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
Здравствуйте, r0nd, Вы писали:
R>Если назначенное код-ревью делает больше часа — либо тугой либо немотивирован. 1–2-1.
А зачем cr мерить в палках? Его надо делать крайне тщательно и добросовестно, если надо больше
часа, значит больше часа. Один из важнейших инструментов для повышения качества кода. Может
код полная лажа, что в нем приходится долго разбираться?
Здравствуйте, r0nd, Вы писали:
R>On Apr 23, 2024, 8:10 PM, alzt <59854@users.rsdn.org> wrote:
A>>2. Строк кода (в новом проекте и не очень)
R>100–150 строк кода в день для C++/Java соответствует синьору; если меньше — это мидл;
Наверное, я очень тупой тим лид — в день от силы 50 строк могу написать. Хотя зависит- может и 200 за час наизменяться переименованием . И ещё люто, яростно бью по рукам за копи-пасту в стиле
if()
a=b
else if
a=b
else if
a=b
else
a=b
Это реальный недавний пример пулреквеста от коллеги оверсииз.
A>>3. Количество закрытых тасков
Синьёрность зависит от сложности таски, которую можно поручить. Если тасков вагон и маленькая тележка в день — тогда это не сеньёр, а что-то в районе джуна.
Мне пофиг на количество изменённых строк- много строк не говорит о производительности программиста в части правильной имплементации фич, только говорит о количестве перелопаченных строк.
Здравствуйте, Буравчик, Вы писали:
Б>В общем случае не возомжно, т.к. нет прямой связи "работа программиста — прибыль"
Значит компания зарабатывает на чем-то другом. В общем случае это параметры модели, эволюционирование которой во времени может оценить последствия, разных воздействий.
В простейшем случае анализ рисков. Что потеряете в случае гибели ухода конкретного человека и какова вероятность такого события.
Здравствуйте, alzt, Вы писали:
A>Поделитесь какими-то формальными показателями работы программистов: A>1. Количеством коммитов A>2. Строк кода (в новом проекте и не очень) A>3. Количество закрытых тасков A>4. Количество WTF на код-ревью A>Любыми другими метриками, которые можно точно.
A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Эту тему хорошо раскрыл писатель-философ Редозубов. Люди стремятся все формализовать — смысл подменить определением, работу — метриками.
Уже все — это уходит в прошлое. GTP будет бить человека по всем метрикам.
Человек нужен в том что не поддается формализации, где требуется разобраться с чем-то уникальным. По этому метрики будут даже вредить.
Как быть, если некий человек метрик выдает мало — но без него проект тупо станет и заменить его практически не возможно за вменяемые деньги?
Здравствуйте, Codealot, Вы писали:
C>>>И кто сделал эти изменения, верно? MVK>>Верно. Вопрос с какой целью и что из этого следует? C>Из этого следует, что кто-то будет получать бонусы, а кто-то звиздюлей на основании этой метрики. А это значит, что ей будут манипулировать. И для участвующих неважно, насколько это контрпродуктивно.
- Доктор, когда я делаю вот так, у меня тут болит.
— А Вы так не делайте.
1. Не вводите метрики таким образом, что команда или отельные сотрудники могут быть заинтересованы в манипуляции ими. Классика — количество коммитов привязанное к бонусу.
2. Не любой метрикой можно манипулировать. Самый яркий пример — это, пожалуй, спорт.
3. Манипуляция метрикой тоже может быть целью. Классика — "Общество чистых тарелочек". В бизнесе — реструктуризация орг. структуры компании.
4. Еще есть интегральные метрики, когда выкручивая один компонент начинает проседать другой.
//Ваш КО
У меня прям полно всяких метрик в работе, но никто ими не манипулирует, так как смысла нет.
Поделитесь какими-то формальными показателями работы программистов:
1. Количеством коммитов
2. Строк кода (в новом проекте и не очень)
3. Количество закрытых тасков
4. Количество WTF на код-ревью
Любыми другими метриками, которые можно точно.
Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов. Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Кто хочет обсудить их бессмысленность — создайте соседний топик и там обсуждайте.
Здравствуйте, alzt, Вы писали:
A>Поделитесь какими-то формальными показателями работы программистов:
Вопрос простой, какие цели ты преследуешь собирая эти метрики и что будешь делать получив их? A>Любыми другими метриками, которые можно точно.
Я бы добавил количество задач на системный рефакторинг которые возникают в будущем и количество регресса. A>Какие показатели считаете хорошими, какие у вас есть/были, средние по команде и т.п.
Нет хороших и плохих, есть команда и есть её производительность и компетенции. A>Я понимаю, что часто это может быть бессмысленное сравнение в зависимости от гранулирования тасков или сложности багов.
Если таски небольшие, то их проще оценить и кластеризировать. Таска где надо просто написать 200 строк кода по сформированному дизайну и тесты к этому коду может пог времени занимать столько же сколько таска на разработку некоторого алгоритма или хитрой оптимизации на 40-60 строк кода. A>Ну и количество строк кода тоже не характеризует ни сложность задачи, ни производительность. Но всё равно интересно.
Смотря каких задач, можно делить их на классы и на базе этого примерно понимать какая задача сколько времени займёт.
Здравствуйте, Буравчик, Вы писали:
A>>Поделитесь какими-то формальными показателями работы программистов: A>>Любыми другими метриками, которые можно точно.
Б>Количество выполненных задач за месяц — в стори поинтах.
Я бы хотел не примеры таких метрик накидать, а именно конкретные значения: свои, коллег, крутых коллег, в среднем по офису и т.д.
Здравствуйте, Shmj, Вы писали:
S>Человек нужен в том что не поддается формализации, где требуется разобраться с чем-то уникальным. По этому метрики будут даже вредить.
S>Как быть, если некий человек метрик выдает мало — но без него проект тупо станет и заменить его практически не возможно за вменяемые деньги?
Расскажи, если знаешь примеры. Но вначале напиши сколько конкретно метрик он выдаёт. у меня другой опыт. Реально ключевые люди выдают нереальное количество показателей по всем адекватным метрикам.
Здравствуйте, alzt, Вы писали:
A>Расскажи, если знаешь примеры. Но вначале напиши сколько конкретно метрик он выдаёт. у меня другой опыт. Реально ключевые люди выдают нереальное количество показателей по всем адекватным метрикам.
Пример метрики и значения ключевых людей можно? Типа столько то строк кода и т.п..
A>2. Строк кода (в новом проекте и не очень) A>3. Количество закрытых тасков
Отношение одного к другому: task SPs/LOC. При выполнении прочих условий (код отформатирован корректно, покрытие тестами адекватное) этот параметр определяет продуктивность сейчас (числитель) и последующую поддержку (знаменатель).
On May 15, 2024, 12:58 AM, Артём <30761@users.rsdn.org> wrote: R>>100–150 строк кода в день для C++/Java соответствует синьору; если меньше — это мидл; Аё>Наверное, я очень тупой тим лид — в день от силы 50 строк могу написать.
Я думаю ответ здесь
⸻ ❧ “Goal setting is the secret to a compelling future.” — Tony Robbins
On May 16, 2024, 7:59 AM, Артём <30761@users.rsdn.org> wrote:
Аё>Мне пофиг на количество изменённых строк- много строк не говорит о производительности программиста в части правильной имплементации фич, только говорит о количестве перелопаченных строк.
Это не график измененных строк, разве я где-небудь говорил про измененные строки? Нет. Но, этот график полностью подтверждает твою фразу почему ты "в день от силы 50 строк можешь написать".
⸻ ❧ “If you can’t yet do great things, do small things in a great way.” ― Napoleon Hill
Здравствуйте, Codealot, Вы писали:
C>Какие и зачем?
Зависит от продукта и целей.
В качестве самого типового примера — это UX оптимизация и метрики для оценки качества UX.
_>Метрики надо снимать с продукта. А не с программиста, потому что люди приходят и уходят, а продукт остается.
Боюсь, что когда будешь делать ремонт в своей квартире, то оценивать будешь не только качество ремонта, а и скорость и эффективность рабочих.
Хотя они приходят и уходят, а квартира остается надолго.
Здравствуйте, kov_serg, Вы писали:
_>Значит компания зарабатывает на чем-то другом. В общем случае это параметры модели, эволюционирование которой во времени может оценить последствия, разных воздействий. _>В простейшем случае анализ рисков. Что потеряете в случае гибели ухода конкретного человека и какова вероятность такого события.
В реальности получается заливание кучи ресурсов на оценку и анализ рисков, который устаревает уже через месяц. Поэтому я не видел сам и не слышал, чтобы кто-то такие риски считал. Как правило, в маленьких компаниях и так все на виду, а в больших работают другие инструменты и анализ рисков делается на более высоком уровне.
Здравствуйте, Codealot, Вы писали:
C>Для оценки качества. C>То есть кто-то сделал более качественную работу, а кто-то менее качественную.
Нет, в общем случае это неверно. И в целом это контрпродуктивное рассуждение.
UX который работал вчера, может перестать работать сегодня.
И нужно постоянно мониторить, насколько эффективно UX решает задачи пользователя.
Здравствуйте, Codealot, Вы писали:
MVK>>Нет, в общем случае это неверно. И в целом это контрпродуктивное рассуждение. C>Это рассуждение, которое совершенно точно кто-то сделает.
Зависит от культуры разработки в команде.
Но да, встречается довольно часто.
MVK>>И нужно постоянно мониторить, насколько эффективно UX решает задачи пользователя. C>И кто сделал эти изменения, верно?
Верно. Вопрос с какой целью и что из этого следует?
Здравствуйте, MaximVK, Вы писали:
C>>И кто сделал эти изменения, верно? MVK>Верно. Вопрос с какой целью и что из этого следует?
Из этого следует, что кто-то будет получать бонусы, а кто-то звиздюлей на основании этой метрики. А это значит, что ей будут манипулировать. И для участвующих неважно, насколько это контрпродуктивно.
