Есть ли какой-нибудь элегантный способ проанализировать процесс инженера?

Существует множество мнений, что измерение коммитов неуместно.

Было ли проведено какое-либо исследование, которое пытается привлечь больше источников, чем коммитов, таких как:

• шаблоны просмотра
• IDE работа (предварительная фиксация)
• время простоя
• многозадачность

Я не могу придумать простой способ сделать эти меры, но мне интересно, было ли проведено какое-либо исследование.

Что касается меня, я считаю, что размышления о собственных «метриках» могут быть полезны независимо от (или в отсутствие) их использования для оценки производительности. То есть непредвзятый способ размышлять над своими привычками. Но это вопрос обсуждения, выходящий за рамки вопросов и ответов.

Не уверен, что вы сочтете это элегантным, но Уоттс Хамфри написал целую книгу под названием «Процесс персонального программного обеспечения», которая была посвящена измерению вашей собственной производительности. Он обрисовал в общих чертах метрики для входных данных, таких как время на рабочем месте и перерывы в работе, время, потраченное на работу над различными видами жизненного цикла программного обеспечения, количество дефектов на количество кода. Существует технический отчет, который дает краткую версию по адресу:

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

Если вы хотите посмотреть на что-то вроде качества кода разработчика, Chidamber & Kemerer предложили несколько метрик для объектно-ориентированного кода.

Метрики для объектно-ориентированного кода

• глубина наследования дерева,
• взвешенное количество методов,
• количество функций-членов,
• количество детей и
• связь между объектами.

Используя базу кода, они пытались соотнести эти показатели с плотностью дефектов и усилиями по обслуживанию, используя ковариантный анализ. Более поздние исследования провели аналогичный анализ сотен проектов Source Forge Java, чтобы определить их характеристики относительно CK Metrics и некоторые дополнительные метрики, предложенные позже.

Метрики, возникающие в контексте Обзоров кода

Дефекты можно классифицировать по многим критериям:

• серьезность: (большая, малая, косметическая, расследование / неизвестно),
• тип (логика, опечатка, орфография, нарушение стандартного кодирования и т. д.),
• сдерживание происхождения / фазы (требования, дизайн, код и т. д.).

Существуют также показатели подготовки и проверки (время на рецензента, время на строку кода) и плотность дефектов (на KLOC (тысяча строк кода), на минуту времени инспектора / рецензента).

Распределение этих значений по контрольным диаграммам может показать нам, находимся ли мы в пределах границ процесса (например, команда, которая проверяет 200 строк кода и не находит дефектов в группе, которая в среднем насчитывает двадцать пять дефектов на KLOC, может работать неправильно).

Другие показатели

Другие показатели, которые могут помочь, включают

• заработанная стоимость, чтобы помочь откалибровать оценку
• скорость для тех, кто использует Scrum или Kanban .
• Работа Парето , Юран , Demming , Ishikawa и др от качества и промышленной инженерии несколько портативных к разработке программного обеспечения с немного воображения.

Ограничения анализа

Существуют огромные ограничения на ценность метрик. Ошибки, исправленные на разработчика, могут означать почти все, и когда вы начнете наказывать или вознаграждать за это измерение, держу пари, что ошибки будут становиться все более многочисленными и детализированными, и набор трудных и легких исправленных ошибок также изменится, когда команда Черри выберет в мчаться, чтобы получить больше всего.

Существует также определенное отвлечение и, возможно, потеря фокуса и удовольствия, которые могут сопровождаться навязчивыми измерениями. Вы не можете стать намного более элегантным (и эмоционально обремененным), чем поэт озера, как Вордсворт, который сказал:

      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