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