关于挣值管理（EVM）的价值以及如何将其整合到敏捷方法引发了激烈的争论，因为更多大型项目应用了敏捷方法，这些大型项目也需要采用挣值管理。观点各有不同，但有些人相信不仅敏捷项目可以应用挣值管理，有敏捷的 EVM 优于没有敏捷的 EVM。
Glen Alleman 解释了 EVM 的基础：“挣值用实际完成的百分比和计划完成的百分比的比值衡量进度。”国防军需大学（DAU）金卡提供了 EVM 如何可视化的表现当前变化作为未来调整依据的例子（注意使用的传统 EVM 术语）。
- 成本差异（cost variance）显示了实际工作的预算成本（BCWP），新术语经常被称为挣值（Earned Value，EV）和实际工作的实际成本（ACWP）的差值。这个例子中，项目当前超支。
- 进度差异（schedule variance）显示了计划工作预算成本（BCWS）和 BCWP 之间的差值，以美元为单位近似表示项目进度。这个例子中项目当前进度落后。
2011 年 5 月 Dr. Dobb’s 的网站上发布了一篇题目为敏捷和 EVM 策略的文章，在文中 Scott Ambler 认为可以将 EVM 应用于敏捷项目中，但他质疑了它在 IT 开发项目中的价值，无论是否为敏捷项目。
EVM 的根本问题是挣值没有什么作用，并且一切在管理上的作用通常被证实为天真、虚构的计划和在项目早期承诺的过高估算。虽然 EVM 是一种有意思的项目管理理论，而且我也毫不怀疑在某些非 IT 领域它能发挥作用，但对于 IT 开发项目来说它在实践中已被证实为一种糟糕的项目管理策略。
虽然 EVM 实际上能适用于敏捷项目，在我的看来是有问题的实践，无论项目形式。试图治理 IT 项目组的组织应该监控准确和即时的信息。这显然不是 EVM 能做到的。
其他人提供了不同的视角。 Glen Alleman 针对 Scott 的表述写了一篇帖子，并互发了 email，Glen 解释了 EV 和敏捷是一种共生的关系。
EV 和敏捷是一种共生关系。EV 可以通过对出资方有意义的单位——美元——来预计估算完成情况。敏捷能相对容易的适应需求变化，因为客户和开发团队（单一团队）间建立的关系。现在就试图增加 1000 个需求，复杂的架构（为载人飞行指导的 ERP 系统），多个出资人，不在一地的客户（我们在菲尼克斯而客户在休斯顿，我们每月见一次面）和许多其它的“复杂性”，这种情况下敏捷依然能够在软件开发层面提供价值，同时当花其他人钱的时候 EV 成为几种“治理”过程之一。成为资金管理人或项目干系人。
Derek Huether ，直到最近一直是美国联邦政府的一个项目管理办公室（PMO）的顾问，进一步指出敏捷方法如何改进 EVM，“如果供应商不得不在短迭代的结束时向客户交付价值，更不可能尝试对成本绩效指数（CPI）或进度绩效指数（SPI）进行某种处理。”
项目集转型中心的 Norm Brown 博士表述了敏捷方法如何使 EVM 更健壮，“当敏捷技术应用于项目集时 EVM 变得高效。”
对于那些合同强制要求使用 EVM 的人来说，这是实践问题，而非哲学上的辩论。幸运的是网络上有免费的、高质量的 EVM 信息，下面的链接列出了一些资源，能让你先学习再做出决定。
评论