Не уверен, что вы сочтете это элегантным, но Уоттс Хамфри написал целую книгу под названием «Процесс персонального программного обеспечения», которая была посвящена измерению вашей собственной производительности. Он обрисовал в общих чертах метрики для входных данных, таких как время на рабочем месте и перерывы в работе, время, потраченное на работу над различными видами жизненного цикла программного обеспечения, количество дефектов на количество кода. Существует технический отчет, который дает краткую версию по адресу:
http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm
Если вы хотите посмотреть на что-то вроде качества кода разработчика, Chidamber & Kemerer предложили несколько метрик для объектно-ориентированного кода.
Метрики для объектно-ориентированного кода
- глубина наследования дерева,
- взвешенное количество методов,
- количество функций-членов,
- количество детей и
- связь между объектами.
Используя базу кода, они пытались соотнести эти показатели с плотностью дефектов и усилиями по обслуживанию, используя ковариантный анализ. Более поздние исследования провели аналогичный анализ сотен проектов Source Forge Java, чтобы определить их характеристики относительно CK Metrics и некоторые дополнительные метрики, предложенные позже.
Метрики, возникающие в контексте Обзоров кода
Дефекты можно классифицировать по многим критериям:
- серьезность: (большая, малая, косметическая, расследование / неизвестно),
- тип (логика, опечатка, орфография, нарушение стандартного кодирования и т. д.),
- сдерживание происхождения / фазы (требования, дизайн, код и т. д.).
Существуют также показатели подготовки и проверки (время на рецензента, время на строку кода) и плотность дефектов (на KLOC (тысяча строк кода), на минуту времени инспектора / рецензента).
Распределение этих значений по контрольным диаграммам может показать нам, находимся ли мы в пределах границ процесса (например, команда, которая проверяет 200 строк кода и не находит дефектов в группе, которая в среднем насчитывает двадцать пять дефектов на KLOC, может работать неправильно).
Другие показатели
Другие показатели, которые могут помочь, включают
Ограничения анализа
Существуют огромные ограничения на ценность метрик. Ошибки, исправленные на разработчика, могут означать почти все, и когда вы начнете наказывать или вознаграждать за это измерение, держу пари, что ошибки будут становиться все более многочисленными и детализированными, и набор трудных и легких исправленных ошибок также изменится, когда команда Черри выберет в мчаться, чтобы получить больше всего.
Существует также определенное отвлечение и, возможно, потеря фокуса и удовольствия, которые могут сопровождаться навязчивыми измерениями. Вы не можете стать намного более элегантным (и эмоционально обремененным), чем поэт озера, как Вордсворт, который сказал:
Sweet is the lore which Nature brings;
Our meddling intellect
Mis-shapes the beauteous forms of things:--
We murder to dissect.
Хотя программное обеспечение не совсем Природа, дайте мне немного свободы, потому что я думал, что никогда не смогу использовать что-либо из школьного урока английской литературы.
Agile можно считать реакцией на централизованный, большой процесс. Иногда такой способ работы может потребовать столько аналитических усилий, что способность достигать потока при создании программного обеспечения практически исчезает.
Я хочу добавить альтернативный ответ, который укажет от стандартной практики разработки программного обеспечения на другую область с целью использования базовых инструментов, которые мы можем адаптировать по мере необходимости. Специалисты по обеспечению качества, как и разработчики программного обеспечения, занимаются производством, выходом, обнаружением и предотвращением дефектов.
http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality
Мне нравится контрольная диаграмма.
http://en.wikipedia.org/wiki/Control_chart
Выполните задание, наметьте метрику, сделайте другое, наметьте ее метрику и так далее. Например, сюжет фиксирует за день. Диаграмма будет разбрасывать данные, которые варьируются от некоторого минимума до некоторого максимума. Возможно, позже вы сможете охарактеризовать результаты, чтобы определить, что когда значение низкое, что-то препятствует прогрессу, а когда оно слишком высокое, работа начинается быстро, но неаккуратно. Как вы поощряете работников ускоряться или замедляться, остается за вами.
Личные показатели могут быть чем-то, что вы можете соотнести для себя, начиная с вопроса типа «Я чувствую себя наиболее продуктивно, когда я ...»
Старый взгляд на то, что мы измеряем, заключается в том, что то, что делается, может привести вас к атаке на основе того, что вы считаете ограничивающим фактором
или несколько факторов в порядке приоритета на основе диаграммы Парето.
http://en.wikipedia.org/wiki/Pareto_chart
источник