随着敏捷得到众多企业的关注，负责财务底线的管理者发现很难用美元估计和衡量敏捷项目的价值。挣值管理  (EVM) 被广泛用于衡量公司层面的财务底线结果。但是对挣值管理是否可以应用于敏捷项目管理的争论在继续升温。

 软件纯粹主义者们谴责这一概念，他们声称挣值管理所需的前期规划对轻量级敏捷方法都“太重了”。另一方面，那些相信或已经实施敏捷挣值管理的人通常对该方法很满意，因为它提供了必要的衡量和报告要求。

 无论你是敏捷开发纯粹主义者或挣值管理的信徒，这里有三个实用技巧可以帮助你消除敏捷指标和你需要报告的的财务底线衡量之间的差距。

1. 在高管和“一线员工”之间找到共同语言。

 传统挣值管理和敏捷软件方法在计划、预算和项目交付的方法方面有鲜明的对比。挣值管理方法侧重于可预测的、预定的计划，结果在项目完成（计划的工作与预定的工作）时衡量。这些衡量通过五个基本指标进行跟踪：

计划的价值+预定的工作成本：我们计划花当多少钱？什么时间开始？

挣值+已执行工作的预算成本：实际完成工作的美元价值是多少？

实际成本+已执行工作的实际成本：我们为已完成工作花了多少钱？

完成预算：我们计划在整个项目周期中花多少钱？

完成估计：基于迄今为止完成的工作，我们估计完成成本是多少？

 相比之下，敏捷开发需要迭代方法。其重点是计划、预算和价值衡量，但有一个关键区别：对管理软件交付的范围变化的适应能力。

 使用挣值管理预测和衡量这些变化以提高项目价值是极其困难的，因为敏捷开发团队的业务分析人员通常使用另一种语言。在这种情况下，与财务底线相关的数据被嵌入到复杂的电子表格中，其中常常挤满了实际上做那些工作的人不会直接使用的财务缩略词和其它信息。但是在大楼的另一边，你会发现敏捷项目团队使用的是燃尽图，这是一种项目进度的视觉简化的表示法。

 提高项目价值（和最终财务底线）的第一步是让在一线和敞亮办公室中的人使用同样的语言。这可以通过应用轻量级挣值管理指标使用敏捷挣值管理实现，这些指标可以被项目团队和管理人员理解，从而能真正衡量项目的价值（进度、成本和性能）而不只是成本。

2.企业宣传片制作 衡量挣值管理的环境。使用计划的价值和预定义的“收入规则”量化计划工作的成果只留出很小的变化空间。因此，如何用指标来改善范围定义以及整体项目性能的分析？这个问题的关键是衡量挣值管理的环境。

 例如，如果重点放在已完成工作的成本和价值上，那么你必须包括与项目指标最密切相关的敏捷指标。这些可能包括：

报告的工作：为特定任务/项报告的工作数量

每功能成本：特定迭代每个功能的实际成本

每迭代预算：项目每个迭代的计划预算

每迭代成本：项目每个迭代的实际成本

累计预算：总计划预算

通过从敏捷挣值管理的角度处理每次迭代，你将准备提供管理所需的财务底线指标。

3．把敏捷指标转化为常用挣值管理术语。如果你花时间看一下挣值管理和敏捷指标以确定并把指标转化为常用的术语，财务底线报告将变得更容易。例如，可用在敏捷开发中的典型指标包括未结估计和结算估计。通过简单的方式，这些可以分别转化为挣值管理中的计划值 (PV) 和挣值 (EV)。但是，PV和EV指标不直接转化为敏捷指标。因为敏捷中的范围变化是预期的和频繁的，在整个项目中没有一成不变的PV。相反，将根据每个迭代的燃尽图处理敏捷指标。这显示了结算估计的想法与实际的安排表，是PV 与EV的最佳转化。

 请记住，敏捷方法会约束时间和成本，并且范围可以变化。因为这个原因，那些考虑财务底线的人将最感兴趣未结与已结的项（已计划什么和已完成什么），以满足趋势和更准确地计划的目的。在一天结束的时候，这一洞察力可以驱动可预测性，是每位经理和所有者的“圣杯”。此外，敏捷挣值管理报告将显示预算与成本指标来解决传统挣值管理指标的问题，如每功能成本、每迭代成本和每迭代预算。

 敏捷和挣值管理本质上是不同的衡量成功的方法。但是通过在项目层面追踪相关的指标，当必须满足其它约束时，敏捷经理可以灵活地衡量敏捷项目的挣值管理项的成功来调整其范围。

 在上面的例子中，成本超过了预算。因为敏捷挣值管理使时间和成本约束保持静态，可以很容易地调整范围以满足其它约束。例如，如果一个团队保持在预算之内，他们可以很容易地把功能或范围添加到项目中，使关心财务底线的股东和高管感到高兴。

工作软件交付

 在项目领导人可以从挣值管理报告转化为敏捷成功之前，他们需要确定衡量什么。挣值管理是关于衡量性能和预测输出的，但唯一应计算的性能是质量性能。因此，敏捷成功最重要的衡量是质量。

 一旦项目启动，敏捷就开始在软件开发的流程中嵌入持续的质量改进。甚至在团队开始着手工作之前，就从把测试人员包括为全部团队成员开始，引入质量实践。测试人员将帮助定义需求，并开发指导开发人员工作的验收标准。

 关于合作的敏捷承诺对开发质量实践是很重要的。跨职能团队提供了多个角度，使团队可以完全理解项目每个块的复杂性。这有助于团队准确地确定整体的每一块需要多少工作量，以及迭代中哪些部分可以交付。

 敏捷把质量改进嵌入流程的另一种方法，是通过持续集成：它随着新代码的编写不断测试和集成到系统中。团队的所有成员都应该参与测试，这是随着开发持续进行的。回归测试是每个迭代的关键部分，因为每次开发新功能时，它们必须与之前建立的所有功能无缝地集成。

 在测试自动进行时，持续集成是最成功的。虽然有效的自动化测试可能是昂贵和难以建立的，但是进行硬件和人们需要的前期投资来建立自动化可以得到巨大的收益。这样可以降低公司的质量保证 (QA) 费用，同时提高最终产品的整体质量。随着时间的推移，企业将只需要更少的专门测试人员，因为迭代中的错误可以及早发现并修复，而不是在项目第11小时再进行处理，因为这时返工滚动到下一个迭代存在巨大的风险。

用户眼中的质量

 不管使用什么指标，所有开发人员都会对质量软件的一些基本基准达成一致。例如，质量软件满足用户的需求。敏捷尤其擅长满足这种质量基准，因为它可以预计和适应产品需求随时间推移产生的变化。从用户的角度来看，当需求可以快速适应以满足他们不断变化的优先事项时，质量就提高了。

 质量的另一个基准是产品是否可以交付商业价值。在瀑布式环境中，ROI直到项目达到100%完成时才实现。在敏捷环境中，ROI可以在每次迭代结束（或几个迭代导致产品发布）时实现，因为迭代的输出可以交付给客户。收益不仅可以在项目的早期实现，而且在项目整个周期中产生的收入的数量也会增加。初期的收入有另一个好处：它允许使用实际的数字而不是预测的数字开发指标，这样可以帮助管理者实现他们的可预测性目标。

 用户的质量感知将在每次迭代之后被考虑。产品所有者在回顾中代表客户的利益，因此客户的直接反馈也可以得到考虑。回顾是一个内置的QA功能：团队会检查哪些方面工作良好，确定哪些方面需要改进，并分享前进和提高输出质量的建议。

 ·          完成=高质量

 当一个团队声明软件“完成”时，说明软件已经过测试、可以工作并可以交付给客户。在“完成”时，团队和产品所有者知道软件的每一块有多好。相比之下，在瀑布式环境中，测试和集成发生在过程之后，所以质量直到项目接近完成时才进行评估。

“完成”的概念是质量敏捷方法的核心元素。它需要一个从查看“完成比例”到查看事情是否完成或未完成的挣值管理方法的范式转变。完成度描述软件的入口、编码、测试和集成情况，其质量已经过检查。但是，完成度比例与质量没有关系，因为直到测试和集成执行之前，质量都是未知的。此外，瀑布式环境中完成度的比例可能会产生误导，因为它不占用返工将花费的时间。

 ·          高质量 = $$

 在流程中嵌入质量可以提高公司的财务底线。其收入预测更一致，因为质量可以在每个迭代中检查，问题可以在项目接近完成之前发现。利润将增加，因为返工形式的浪费减少了。生产更可预测，因为项目中软件交付的速度是相当一致的。财务风险减轻，因为ROI和进入市场的速度更快。企业的质量信誉使企业可以经营得更长久并获得利润。

 从敏捷的角度来看，良好的性能不能通过工作了多少小时、写了多少行代码或者已经花了多少钱来衡量；良好的性能是关于你的产品交付的价值。挣值管理想要衡量质量，但未能达到这一目标，因为挣值管理衡量性能的成本方面，对与生产管线一起发生的、与预算相关的一切进行评估。具有讽刺意味的是，对成本的关注通常需要以质量为代价。

 瀑布式项目经常落后于进度和超出预算，当他们进行项目时，总是通过捷径使项目回到正轨。因为瀑布式环境中的测试在发布之前进行，这通常是被削减的地方，这导致产品在制成成品时只经过不完整的测试。产品可能会按时并在预算内交付，但是如果质量保证不能作为流程的一部分，那么产品仍然是糟糕的。此外，实际成本仍然是未知的，因为发布后识别的错误仍将需要修复。

股东们想知道项目进度、估计的和实际的成本以及产品的质量。一些指标可以帮助管理者在敏捷和瀑布式环境中完成他们的工作，但这两种方法的关键区别是用于质量的指标。传统挣值管理使用成本和其它性能衡量作为衡量质量的代表，而敏捷拥有真正的质量指标：“完成度。”直到输出已经入口、编码、测试、集成和可交付后，产品才算“完成”。因此，完成等于高质量。

原文经许可，摘自Katia Sullivan发表在ProjectsAtWork上 的两篇文章：“敏捷+挣值”（2012年2月1日）和“衡量质量，而不是数量”（2012年3月7日）。ProjectsAtWork于2012年登记版权.。Geoffrey Bi译。

Katia Sullivan是VersionOne的产品与敏捷顾问。她在软件开发领域工作了超过12年时间，主要担任企业架构、需求管理和项目管理职务。

本中文版由世界经理人（www.ceconline.com）组织翻译并编辑。