软件开发项目指标

从2007年开始，我就参与了一项工作，为软件开发项目的成败寻求无关方法论的度量，以便于向上级管理层汇报。这一努力是为了向更广泛的受众呈现我们遇到的挑战及应对的措施。下文描述了我在此次研究中的一些个人心得，它着重于绩效指标，而非进度指标，因为我个人相信后者那一套只关注当下，而对团队的未来成就影响寥寥。在我看来，进度指标只是一种帮助你的团队按时完成目标的方法，可是团队如果不反思其绩效，他们改善的机会就减少了。比如，如果一个项目经理总是拿出“进度计划对照表”之类的东西给人看，团队将忙于追回损失，而不会停下来思考问题出在哪里、如何改善——因为他们没那个闲功夫。我认为进度指标虽然有用，却并不完美，原因就在于此。

大家可能都记得这句名言：“若无法度量，则不可管理”。而如果一家公司无法管理软件项目，他们又该如何去了解怎样改善？何时获得了改善？引入流程的改变究竟增值几许？——比如他们软件实践和原则的转变——是不是有人提到“从瀑布模式转向敏捷”来着？软件项目的成功从来都是业内的目标，可是帮助我们衡量成功与否的指标却极为多样。建议采用的指标集取决于你所遵循的特定方法论，它们之间毫无共性可言。我们在惠普就面对这一挑战，因为我们有一组各式各样采用不同方法论的项目，所以上级管理层收到杂乱无章的指标，而这都取决于各部门自己想要汇报什么。

对有敏捷背景的读者，我们知道他们的项目尤为适合指标衡量，因为数据可以无缝收集，也不必让团队分心。但是，有些项目没有使用敏捷所信奉的原则和实践，建议使用的指标集可能就不适合它们。诸如速率、价值流累积和燃尽图可能对没有接受敏捷的团队来说毫无意义。那么，如果我们想衡量项目本身，而不是其采用的方法，又该如何呢？

软件开发流程的管理需要识别度量的能力，这些度量代表着内在因素的特性，用以控制项目并助其持续改善。我们在公司内外数次尝试和研究，结果纠结于一大批（约二十个）的拟议指标中。不过我们以一种很敏捷的方式与一组专家坐下来探讨，回顾每一个特定指标。我们首先淘汰所有与项目、文档、代码和交付物的大小相关的拟议指标，因为大公司要管理各种各样的项目，而我们确实扪心自问：我们真的要度量这个吗？答案是否定的，因为我们首先需要的是简单易行的指标集，它们不增加团队的负担，也更有助于确定团队成熟度与绩效。

最后我们决定简约至上，定义了普适整个IT业的三大核心指标如下：

人工投入，即产出可用产品或服务的任务的总时间量。计划的工时量称为“计划人工”，实际花费的工时量称为“实际人工”。人工投入可以用小时或天来度量，这取决于项目的规范。任务，是完结一个工作、问题或任务的一组行动的一部分。它在瀑布或敏捷项目中并无二致。但我们的确承认，采用不同方法论时对任务的管理有所不同，双方各有千秋。下图体现了这一指标是如何汇总至团队的。

图1：累积人工可视图 & 实际人工按工期分布

人工投入是一项可直接观测量，它通过分派给特定资源的任务量累计得到，也能够在特定任务、里程碑或工期上计算。“计划人工”在计划特定任务的工作量时采集，并在该任务被分析或设计时修正。'实际人工'在进行与特定任务相关的建造、测试和维护时采集。组织最初可能发现'估计值'和'实际值' 间有巨大的不同和差异，但随着团队日益变得“成熟”，数据会渐趋一致。我们的经验是，如果6个月后人工投入的图表并未显示更加一致的趋势，团队必须进行回顾，找到根本原因，并与团队内外因素联系起来。正如Poppendieck【5】建议的，定义约束条件将会是非常好的出发点。

生产效率，即每天可交付的"简单任务"的数量。可以在项目内的各个级别，如个人、工种、任务工期或项目上，对它进行计算。

“简单任务”的定义总是引致争论；我们最终将其定义为：某人力资源交付某物的过程，所需时间5小时左右（当然有些简单任务需时更长或更短，但是我们最后决定使用这一时长）。

基于我们对生产效率的定义：“可以在8小时工作日交付的简单任务数量”，其计算公式为：

生产效率 = (( 计划人工 / 5) / 实际人工 ) * 8

下图体现了这一指标是如何汇总至团队的。

图2：生产效率可视图

显然，这一指标有可商榷之处，我们下定义时也提出了大量有理有据的论点，但是正如每个良好的民主制度那样，我们需要最终统一于大多数人可接受的定义。而一旦有了这一指标，我们就发现了它在对比项目健康程度上的得力之处，不管是论周、论月还是论资源等等。

生产率指标产生在任务级别上，并可汇总至交付物、工期和项目级别。它明显依赖于做估计的技术和采集人工投入数据的工具。

图3：生产效率可视图

上图显示了两个类似项目发布的生产率累积，它们由相同团队完成，成员相同，指标相同。一开始这个团队使用其所熟悉的瀑布型方法论（所有分析工作在前，所有编码工作居中，所有测试工作断后）工作6个月，然后采用敏捷方法在另6个月中完成另一发布。在两个项目中应用的生产效率公式，显示了敏捷专家们常说的典型趋势，即工作从一个项目阶段（如编码）成批地向另一阶段（如测试）移动，就无法让项目团队以可持续的步调交付高质量产品，因而降低了他们在前述公式定义下的生产效率（原因可能是从某一任务向下一任务的轮番转换——进行多任务处理的耗费）。相较于上一项目发布，同一团队在使用了敏捷原则与实践后，如迭代式开发、聚焦某一特定功能、试错开发（首先开发高风险需求）等，他们的生产效率得到了提高。

使用共同指标，我们就能够衡量敏捷项目所具备的交付上的可预测程度，以及项目成熟后估计的准确程度。

质量，即项目生命期内交付中的高、中、低级缺陷的数量。它有助于识别最终用户交付物的优良程度。每个团队都需要针对其特定项目来定义高中低级别的含义。应当在整个项目周期内报告质量情况：缺陷发现得越晚，对项目的影响越大。 下图体现了这一指标是如何汇总至团队的。

图4：质量可视图

采集缺陷信息后，我们也追踪另一衍生指标，“缺陷移除”。其目标在于，相对于流程前期，评估流程后期所发现问题（显然代价更高）的百分比。我们在此比较敏捷和瀑布类项目时也发现了一些有趣的行为模式。

图5：缺陷移除可视图

上图显示，敏捷项目在软件生命周期里具有相对可持续的缺陷率，而瀑布型项目在后期表现出一个波峰。该信息采集自同一团队的两次产品发布（需求集相当），而开发模式互不相同。

这一指标集被持续采集、分析和汇报。我们可以将他们包含在一个“项目仪表盘”内，从而建立一个全局视图，可以与利益相关方共享和解读成果。

如下表所示，指标间有明显的关联关系

指标 1	指标 2	积极趋势	消极趋势
生产效率	交付缺陷密度	高生产率伴随高缺陷密度，是项目中所计划的QA人工投入不足的标志。虽然高生产率是可取的，但是在总体效益上必须平衡生产率和质量。因此，具备高质量的最优生产率才是最合宜的。	高生产率伴随低缺陷密度，是好的行为模式，而团队可以在监控缺陷密度的同时，力求生产率的进一步提高。 高缺陷密度伴随低生产率，表明需要对测试进行调优、修改或自动化，来尽早查出问题。
生产效率	缺陷移除效率	高生产率伴随高缺陷移除效率，标志着生产效率与质量之间的很好平衡。团队可以在监控缺陷移除效率的同时，力求生产率的进一步提高。	高生产率伴随低缺陷移除效率，表明在项目中所计划的QA人工投入不足。 高缺陷移除效率伴随低生产率，表明在整个周期中需要对质量多加重视。

我们在巴西研发部门的一位项目经理Guilherme Souto，编纂了如下速效提示，帮助我们在采纳指标的过程中保持诚实和理性：

• 指标需要与组织或项目目标相联系，才能体现我们是否达成了承诺。
• 指标需要与日常工作流程（尽可能地）整合，以避免单为采集数据而花费时间。
• 所选择的指标需要被核实是否覆盖各个领域，这些领域将决定项目结束时是否成功。
• 指标就像单词，在成组造句时才真正表达含义。所以尽量避免过度分析单一指标的数据是很有必要的。当这一指标集引入后，我们总是看到团队过度关注生产效率，但是将指标孤立出来的观念，让我们无法在分析时考虑到其他变量，比如项目的困难和挑战程度或是团队（缘于其成熟度、遵循的流程或其他因素）所产出的质量高低。最终我们总不想重复过去的错误，以前我们只孤立地观察进度计划对照表之类的进度指标，导致我们牺牲了质量或者资源。
• 如果一个指标无法被用来建立或定义行动计划，采用它就毫无用处。
• 绩效之类的指标需要目标值。一旦要采取改正措施，团队必须明了预期的高低阈值区间。

这些指标只提供了部分历史情况，而它们在决策中的适用性，取决于对触发团队趋势特定改变的事件链的了解。这一举措和所定义的指标，对您的特定团队不一定是最佳的，但这是我们至今采取的，对我们来说也管用。希望对某些读者能有帮助，当然我也可能错得离谱。

参考文献

下面这些是本文所涉主题的很好出发点。

【1】. H T. Goranson，敏捷虚拟企业：案例、指标、工具。 Quorum Books. 2003.
【2】. Tom DeMarco，控制软件项目：管理、度量和估计。Prentice Hall. 1986
【3】. Dr. Cem Kaner，软件工程指标：它们衡量什么，而我们又如何了解？第十届国际软件指标研讨会. 2004
【4】. R¨¹diger Lincke, Jonas Lundberg, Welf L?we，软件指标工具之对比。软件测试与分析国际研讨会. 2008
【5】. Poppendieck and Poppendieck，实施精益软件开发：从概念到实利。Addison Wesley Professional, 2003.