一切在于交付

许多传统的瀑布型项目依赖一套称为“挣值”(Earned Value)和“进度执行指数”(SPI)的计算来显示他们的项目是否在按计划进行。这些指标可能带有误导性,并经常掩盖掉某些进度耽延。论及进度、范围和财政预算,比起传统“挣值”和“进度执行指数”为瀑布项目提供的,Scrum为项目利益相关者提供了更加准确的预测。

 

传统的指标起源于哪里?

 

1967年,国防部(DOD)引进了一套(共35个)成本/进度控制系统标准(C/SCSC)。实施这些标准,在管理控制系统上给那些跟国防部做生意的公司带来了复杂的修改。这套“体系”和许多副产品现在被各种非军工企业普遍接受(“既然军队需要它,那肯定是合理的”)。它已变得如此主流,以至于它的逻辑被构建到微软项目管理软件和其他日程安排软件中。

 

在《把挣值(C/SCSC)放入你的管理控制系统》一文中,Quentin W. Fleming为C/SCSC系统定义了它工作所需的五个指标(BCWS, BCWP, ACWP, SV, and CV)。其中,只有前两个与本文的讨论相关:

 

1. “计划”或“所计划工作的预算开支”(BCWS)——可称为计划工作量,与预算、计划都是同义词。

 

2. “挣值”或“已完成工作的预算开支”(BCWP)——可称为已完成工作量,与“挣值”同义。

 

在特定的时间内,用已完成工作量(BCWP)除以计划工作量(BCWS),结果作为判断实际工作对计划执行好坏的凭据:即进度执行指数(SPI)。要确定一个瀑布型项目是否“步入正轨”,可在既定的时间间隔内有规律地测量SPI(通常是每月),并使用公式:SPI =(BCWP/BCWS)。任何时候SPI小于1,进度即被认为出现困难。例如,计划了5000小时的工作时间(BCWS),只完成了4500小时(BCWP),SPI就是0.9(4500 / 5000 = 0.9)。则项目落后于计划10%。另一方面,如果计划了4500小时而完成了5000小时,SPI就是1.1(5,000 / 4,500 = 1.1),这意味着项目比计划超前了10%。

 

这些指标有什么误导性呢?

 

这些指标的问题在于:首先传统的瀑布型项目在交付任何软件之前,必须完成很多任务。考虑一个10个月的项目,定义阶段占据了全部工作量的30%。定义阶段结束时,30%的预算已经花费掉,30%的项目也完成了,但仍没有可工作的软件。事实上,直到软件可交付为止,该项目将继续消耗可观的费用。如果项目总预算为600万美元,制定详细的规范说明需要30%的时间,你就已经为一大堆说明书、会议记录、审批表、备忘录等花了180万美元(600万美元的30%)(见图1)。

 

 

 

图1.  10个月(60000小时)的瀑布型项目已完成30%

 

这些指标的另一个问题是,SPI和挣值计算因为掩盖了实际问题,往往造成直到将近项目结束时,开发周期中产生的问题才暴露出来。这两种计算表明,随着时间的推移可接受的进展正在取得,但是无法确保该软件最终能够工作。如果重大的设计问题发现得太晚,典型的响应包括了计划外的重设计、重编码和重测试(通常会牺牲掉原计划的质量评价时间)。项目经理还要努力解释为什么项目在后期会有风险,特别在刚提交了可接受的每月 SPI和挣值(EV)报告的情况下。如果问题确实发生了,项目经理通常会尝试重新设定项目的结束日期,以便再次报告可接受的SPI和EV指标。这将再一次导致一切在纸上都看起来很好,却没有真实的用处。然而,有一个更好的方法。

 

Scrum如何避免这些问题?

 

Scrum能够更快地交付可工作软件,并提供更准确的进度、预算和范围的预测。在Scrum框架下,我们将这十个月的项目分成十个迭代,即每个迭代是一个30天的sprint(见图2)。在第三个sprint(进展到项目的30%)结束时,我们将完成三个迭代,并花费180万美元。与同一时间、花费相同的瀑布型项目相比,我们将已经产生三个可交付产品,而不是一堆说明书和审批表。这点不同非常显著。

 

 

 

 

图2.  10个月(60000小时)Scrum项目完成了30%

 

图3在同一个虚拟项目中比较了两种方法(Scrum和瀑布型)。请注意当两者估计相同数量的完成时间时,只有Scrum项目每30天能交付可工作的软件。只有Scrum项目通过所交付的工作、而不是一种可能产生误导的计算来检测进度。最后,只有在Scrum项目中,随着每个迭代产生的软件交付,价值在不断累积,而不是通过所计划工作已经完成了多少来测量价值,且不考虑实际上是否有任何软件可以交付。

 

 

图3. 瀑布型“进度执行指数”和“挣值”计算对比Scrum检测方法(使用同样的10个月的(60000小时)项目)

 

我们能得出什么结论?

SPI是衡量一个项目进度的劣质晴雨表。“挣值”计算建立了错误的观念——即项目早期到中期阶段(当没有任何软件产生时)的实际“价值”正在被创造。Scrum以30天(时间箱)为交付周期的简单检查和调适机制比起传统的DOD指标,直观上提供了更加可靠的情况。

 

关于作者:

John Hill

Agile Program Manager JDA Software Group, Inc.
Certified: CSM, CSP
Location: Calabasas, California

此文由scrum中文网整理,转载请注明