有什么优雅的方法可以分析工程师的过程吗？

存在很多观点认为衡量提交是不合适的。

有没有做过任何尝试吸引更多资源而不是提交的研究，例如：

• 浏览模式
• IDE工作（预提交）
• 空闲时间
• 多任务

我想不出一种简便的方法来执行这些措施，但是我想知道是否已经进行了任何研究。

就个人而言，我确实认为，反思自己的“指标”可能是有价值的，无论（或不使用）这些指标进行绩效评估。IE浏览器会以一种无偏见的方式来反映您的习惯。但这是问答之外的讨论问题。

不知道您是否会认为它很优雅，但是Watts Humphrey撰写了一本名为《个人软件过程》的整本书，内容全都是关于衡量自己的生产力的。他概述了输入的度量标准，例如，您在办公桌前的时间与中断，在各种软件生命周期活动上花费的时间，每单位代码量的缺陷。有一份技术报告提供了简短的版本，网址为：

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

如果您想看开发人员代码的质量，Chidamber＆Kemerer提出了一些面向对象代码的指标。

面向对象代码的度量

• 继承树的深度，
• 加权方法数
• 成员函数的数量
• 儿童人数，以及
• 对象之间的耦合。

他们使用代码库尝试使用协变量分析将这些指标与缺陷密度和维护工作相关联。后来的研究对数百个Source Forge Java项目进行了类似的分析，以确定它们相对于CK度量标准以及稍后提出的一些其他度量标准的特征。

代码审查中产生的指标

缺陷可以按许多标准分类：

• 严重程度：（主要，次要，美容，调查/未知），
• 类型（逻辑，错字，拼写，违反标准的编码等），
• 原始/阶段遏制（需求，设计，代码等）。

还有准备和检查率（每个检查者的时间，每行代码的时间）和缺陷密度（每KLOC（千行代码），检查员/检查者时间的每分钟）。

根据控制图绘制这些值可以向我们显示我们是否在流程的范围之内（例如，一个检查200行代码的团队发现在每个KLOC平均有25个缺陷的组中没有缺陷，可能会出现故障）。

其他指标

其他可能有助于衡量的指标

• 赚取的价值以帮助校准估算
• 使用Scrum或看板的速度。
• 工作帕累托，朱兰，Demming，石川，和其他人的质量和工业工程与想象力的一点点有点移植到软件开发。

分析的局限性

指标的价值受到极大限制。每个开发人员修复的错误几乎可以指任何东西，当您开始衡量或奖励这种衡量标准时，我敢打赌，错误会变得越来越多，而且越来越细，并且难以修复的错误的组合也会随着团队中樱桃的选择而改变。争取拥有最多的东西。

侵入式测量也会带来一定的干扰，并可能导致注意力和娱乐性丧失。你不能比华兹华斯这样的湖诗人说得优雅得多（在情感上负担很多），

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

尽管软件并非自然，但请给我一些自由，因为我认为我永远也不会使用中学英语文学课上的任何东西。

敏捷可能被认为是对集中的大型过程的反应。有时，这种工作方式可能需要大量的分析工作，以至于在创建软件时达到流程的能力几乎消失了。

我想添加一个替代答案，该答案从标准软件工程实践转向另一个领域，目的是窃取我们可以根据需要进行调整的基本工具。就像软件开发人员一样，质量保证人员也关注生产，良率以及缺陷检测和预防。

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

我喜欢控制图。

http://en.wikipedia.org/wiki/Control_chart

执行一项活动，绘制一个度量，执行另一个，绘制其度量，依此类推。例如，每天的图提交。图表将分散从最小到最大的数据。也许以后您可以对结果进行特征化处理，以确定当该值较低时，某些事情会阻碍进度，而当该值太大时，便会以快速但草率的方式开始工作。您如何鼓励员工加快或减慢速度。

您可以将个人指标与自己相关联，例如“当我...时，我觉得自己最有生产力”。

• 在开始编码之前，编写一个完整的用例。
• 在我的代码之前编写我的单元测试。
• 经常与利益相关者进行核对，以确保需求不会改变，并针对过时的计划进行大规模的返工。
• 更改尽可能多的代码。
• 将定义明确的变更委派给最熟练处理我要求他们更改的部分的团队成员。
  • 给我的团队一个完整的概述，但是有了优先考虑，我们可以在当前的冲刺中完成。
  • 从我将要更改的目录，文件，类，方法，方程式，变量，文档等的分层列表开始我的重构过程。
  • 研究一个高级问题，以找到现有技术的解决方案，估算出做出更好解决方案所需的范围和关键改进。

老手看到我们衡量的是完成的事情，可能会导致您基于确定为限制因素的问题来解决问题

或基于帕累托图按优先顺序排列的多个因素。

http://en.wikipedia.org/wiki/Pareto_chart