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

Question

测量提交的有大量的情绪存在是不适当的。

是否做过任何研究，试图提取比提交更多的资源--例如：

• 浏览模式
• IDE工作(预承诺)
• 闲置时间
• 多任务处理

我想不出一个简单的方法来做这些措施，但我不知道是否做了任何研究。

就个人而言，我确实认为，无论在性能评估中使用(或不使用)这些指标，对自己的“度量”进行反映都是很有价值的。也就是说，一种不偏不倚的方式来反思你的习惯。但这是一个超越Q&A的讨论问题。

Answer 1

不确定你是否认为它优雅，但瓦茨·汉弗莱写了一整本书，名为“个人软件过程”( Personal Software Process )，它都是关于衡量你自己的生产力的。他概述了输入的指标，比如办公桌上的时间与中断、用于各种软件生命周期活动的时间、代码数量的缺陷。有一份技术报告提供了以下简短的版本：

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

如果您想查看类似于开发人员代码的质量，Chidamber & Kemerer提出了几个面向对象代码的度量标准。

面向对象代码

度量

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

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

代码评审上下文中产生的

度量

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

• 严重程度：(主要，次要，美容，调查/未知)，
• 类型(逻辑、错误、拼写、编码标准违反等)，
• 起源/阶段包容(要求、设计、代码等)。

还有准备和检查速率(每个审阅者的时间，每一行代码的时间)和缺陷密度(每KLOC (千行代码)，每分钟的检查/审阅时间)。

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

其他度量标准

其他可以帮助包括的指标

• 挣值帮助校准估计
• 速度适用于使用Scrum或看板的用户。
• 帕雷托、朱兰、德明、石川和其他来自质量和工业工程的工作在一定程度上可以移植到软件开发中，只需一点想象力。

分析

的局限性

度量的价值有很大的限制。每个开发人员修复的bug可能意味着几乎任何东西，当您开始惩罚或奖励该度量时，我敢打赌bug将变得更多、更细，而且当团队在争夺最多bug时，很难修复的bug组合也会发生变化。

也有一定的分心和潜在的注意力和乐趣的损失，这可能伴随着侵入性的测量。你不能比像华兹华斯这样的湖畔诗人更优雅(情感负担)，他说：

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

虽然软件并不完全是自然，但给我一些自由，因为我认为我永远不能使用高中英语文学课上的任何东西。

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

Answer 2

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

http://en.wikipedia.org/wiki/Seven_基础知识_工具_的_质量

我喜欢控制图。

http://en.wikipedia.org/wiki/Control_图表

做一个活动，绘制一个度量，做另一个，绘制它的度量，等等。例如，情节每天提交。该图表将分散从某些最小值到某些最大值的数据。也许稍后您可以对结果进行描述，以确定当值较低时，某件事情会阻碍进展，而当它太高时，就会以一种快速但草率的方式开始工作。如何鼓励员工提速或减速是由你自己决定的。

个人指标可能是你可以从一个问题开始联系起来的，比如“当我.我觉得最有效率”

• 在开始编写代码之前编写完整的用例。
• 在代码之前编写单元测试。
• 经常与涉众进行检查，以确保需求不会改变，并在完成的工作中创建大量的返工，以实现过时的计划。
• 尽可能多地修改代码。
• 将定义良好的更改委托给团队成员，他们最擅长我要求他们更改的部分。
  • 给我的团队一个完整的概述，但有了优先级，我们可以在当前的冲刺中完成。
  • 从我将要更改的目录、文件、类、方法、等式、变量、文档等层次列表开始我的重构传递。
  • 研究一个高层次的问题，找出现有的技术解决方案，估计出更好的解决方案所需的范围和关键改进。

老生常谈，我们衡量的是做了什么，可能会导致你解决问题的基础上，你确定的限制因素。

或基于Pareto图按优先级顺序排列的多个因素。

http://en.wikipedia.org/wiki/Pareto_图表