【IT168 技术文章】
从2007年开始，我就参与了一项工作，为软件开发项目的成败寻求无关方法论的度量，以便于向上级管理层汇报。这一努力是为了向更广泛的受众呈现我们遇到的挑战及应对的措施。下文描述了我在此次研究中的一些个人心得，它着重于绩效指标，而非进度指标，因为我个人相信后者那一套只关注当下，而对团队的未来成就影响寥寥。在我看来，进度指标只是一种帮助你的团队按时完成目标的方法，可是团队如果不反思其绩效，他们改善的机会就减少了。比如，如果一个项目经理总是拿出“进度计划对照表”之类的东西给人看，团队将忙于追回损失，而不会停下来思考问题出在哪里、如何改善——因为他们没那个闲功夫。我认为进度指标虽然有用，却并不完美，原因就在于此。
大家可能都记得这句名言：“若无法度量，则不可管理”。而如果一家公司无法管理软件项目，他们又该如何去了解怎样改善？何时获得了改善？引入流程的改变究竟增值几许？——比如他们软件实践和原则的转变——是不是有人提到“从瀑布模式转向敏捷”来着？软件项目的成功从来都是业内的目标，可是帮助我们衡量成功与否的指标却极为多样。建议采用的指标集取决于你所遵循的特定方法论，它们之间毫无共性可言。我们在惠普就面对这一挑战，因为我们有一组各式各样采用不同方法论的项目，所以上级管理层收到杂乱无章的指标，而这都取决于各部门自己想要汇报什么。
对有敏捷背景的读者，我们知道他们的项目尤为适合指标衡量，因为数据可以无缝收集，也不必让团队分心。但是，有些项目没有使用敏捷所信奉的原则和实践，建议使用的指标集可能就不适合它们。诸如速率、价值流累积和燃尽图可能对没有接受敏捷的团队来说毫无意义。那么，如果我们想衡量项目本身，而不是其采用的方法，又该如何呢？
软件开发流程的管理需要识别度量的能力，这些度量代表着内在因素的特性，用以控制项目并助其持续改善。我们在公司内外数次尝试和研究，结果纠结于一大批（约二十个）的拟议指标中。不过我们以一种很敏捷的方式与一组专家坐下来探讨，回顾每一个特定指标。我们首先淘汰所有与项目、文档、代码和交付物的大小相关的拟议指标，因为大公司要管理各种各样的项目，而我们确实扪心自问：我们真的要度量这个吗？答案是否定的，因为我们首先需要的是简单易行的指标集，它们不增加团队的负担，也更有助于确定团队成熟度与绩效。
最后我们决定简约至上，定义了普适整个IT业的三大核心指标如下：
人工投入，即产出可用产品或服务的任务的总时间量。计划的工时量称为“计划人工”，实际花费的工时量称为“实际人工”。人工投入可以用小时或天来度量，这取决于项目的规范。任务，是完结一个工作、问题或任务的一组行动的一部分。它在瀑布或敏捷项目中并无二致。但我们的确承认，采用不同方法论时对任务的管理有所不同，双方各有千秋。下图体现了这一指标是如何汇总至团队的。
图1：累积人工可视图 & 实际人工按工期分布
人工投入是一项可直接观测量，它通过分派给特定资源的任务量累计得到，也能够在特定任务、里程碑或工期上计算。“计划人工”在计划特定任务的工作量时采集，并在该任务被分析或设计时修正。'实际人工'在进行与特定任务相关的建造、测试和维护时采集。组织最初可能发现'估计值'和'实际值' 间有巨大的不同和差异，但随着团队日益变得“成熟”，数据会渐趋一致。我们的经验是，如果6个月后人工投入的图表并未显示更加一致的趋势，团队必须进行回顾，找到根本原因，并与团队内外因素联系起来。正如Poppendieck【5】建议的，定义约束条件将会是非常好的出发点。
生产效率，即每天可交付的"简单任务"的数量。可以在项目内的各个级别，如个人、工种、任务工期或项目上，对它进行计算。
“简单任务”的定义总是引致争论；我们最终将其定义为：某人力资源交付某物的过程，所需时间5小时左右（当然有些简单任务需时更长或更短，但是我们最后决定使用这一时长）。
基于我们对生产效率的定义：“可以在8小时工作日交付的简单任务数量”，其计算公式为：
生产效率 = (( 计划人工 / 5) / 实际人工 ) * 8
下图体现了这一指标是如何汇总至团队的。
图2：生产效率可视图
显然，这一指标有可商榷之处，我们下定义时也提出了大量有理有据的论点，但是正如每个良好的民主制度那样，我们需要最终统一于大多数人可接受的定义。而一旦有了这一指标，我们就发现了它在对比项目健康程度上的得力之处，不管是论周、论月还是论资源等等。
生产率指标产生在任务级别上，并可汇总至交付物、工期和项目级别。它明显依赖于做估计的技术和采集人工投入数据的工具。
图3：生产效率可视图
上图显示了两个类似项目发布的生产率累积，它们由相同团队完成，成员相同，指标相同。一开始这个团队使用其所熟悉的瀑布型方法论（所有分析工作在前，所有编码工作居中，所有测试工作断后）工作6个月，然后采用敏捷方法在另6个月中完成另一发布。在两个项目中应用的生产效率公式，显示了敏捷专家们常说的典型趋势，即工作从一个项目阶段（如编码）成批地向另一阶段（如测试）移动，就无法让项目团队以可持续的步调交付高质量产品，因而降低了他们在前述公式定义下的生产效率（原因可能是从某一任务向下一任务的轮番转换——进行多任务处理的耗费）。相较于上一项目发布，同一团队在使用了敏捷原则与实践后，如迭代式开发、聚焦某一特定功能、试错开发（首先开发高风险需求）等，他们的生产效率得到了提高。
使用共同指标，我们就能够衡量敏捷项目所具备的交付上的可预测程度，以及项目成熟后估计的准确程度。
