关于挣值管理(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 信息,下面的链接列出了一些资源,能让你先学习再做出决定。
评论