基于Scrum方法的软件项目管理过程度量研究过程度量研究

通过分析软件项目管理中传统瀑布模型常用的挣值分析法的不足，引入敏捷开发的Scrum方法到项目实践中来解决问题，从而更好地实施软件项目管理，提高开发效率，达到项目进度和产品质量可控的目的。

软件项目管理 瀑布模型 敏捷开发 Scrum 挣值法

Research on Measurement of Software Project Management Process Based on Scrum Method

YAN Jing

（China Electronics Technology Group Corporation No.7 Research Institute， Guangzhou 510310， China）

By analyzing the shortage of earned value method commonly used in traditional waterfall model of software project management， the Scrum method of agile development is introduced into the project practice to solve the problems in order to better carry out the software project management and improve development efficiency， which achieves to control the project progress and product quality.

software project management waterfall model agile development Scrum earned value method

1 引言

软件项目管理能力的高低是软件项目最终能否成功的关键因素。目前软件行业所面临的最重要的软件开发问题莫过于如何用一种有效的方法来管理软件过程，确保软件开发的高效率和产品的高质量。随着软件开发复杂性的日益增大以及软件行业规范管理经验的逐渐积累，软件项目管理无论是在理论上还是在实践中都取得了很大的进展。CMMI（Capability Maturity Model Integration，软件能力成熟度模型集成）中的项目监控、项目策划、测量与分析这三个过程域，也对如何规范有效地开展项目管理有所指引。

本文对软件业界常用的瀑布模型和配套的挣值法的不足进行了分析，并引入敏捷开发中的最佳实践Scrum方法，通过全周期和阶段两层跟踪方式来实施软件项目管理。

2 Scrum方法简介

敏捷开发（Agile Development）是以提高软件开发效率和响应速率为目的，针对传统瀑布模型开发的弊端而研发的一种开发模式，是以人为核心的多次迭代循序渐进的开发方法。敏捷方法试图通过小型的、自我管理的团队使用短小的合作周期来鼓励迭代式软件开发方法。软件的质量贯穿敏捷软件开发的每一个阶段，并提出很多关键的规则来保证能在每一个迭代周期内及早地发现并及时消灭开发过程中出现的错误。敏捷开发将软件开发划分为多个迭代开发的过程和阶段，通过迭代式的增量开发，保证软件一直处于可使用的状态。

Scrum是敏捷开发的方法之一，也是目前软件业界的敏捷最佳实践之一。Scrum通过可视化、检验和适应来管理复杂、不可确认和变更。Scrum思想将工业过程控制中的概念应用到软件开发中来，认为软件开发过程不是确定性过程，而是将传统软件开发中的分析、设计和编码等子过程视为一个黑箱，充分发挥软件人员的创造力，使项目组工作在一种模糊状态增强适应力，以此来替代传统瀑布模型将经验性过程按确定性过程来处理所缺乏的适应力。

Scrum是一种工作管理的方法，它不仅仅限于软件开发，也可以用来管理硬件开发、系统工程等各种开发活动。Scrum开发模型图如图1所示。

（1）依据需求的优先级确定项目的需求列表，依据需求列表对工作量进行估算；

（2）假设每次的迭代周期为4周，确定单次迭代的工作目标，并对任务进行细化形成迭代任务列表，子任务的跟踪粒度小于2天；

（3）迭代中进行每日例会，每次会议控制在15分钟左右，并且每个成员要向团队汇报昨天完成了什么、今天要完成什么，同时遇到不能解决的问题也可以提出，汇报完成后更新迭代任务的燃尽图；

（4）当一个迭代的功能完成时，进行迭代演示也称为评审会议，会议中演示本次迭代所完成的软件产品。

3 项目管理过程度量

软件项目管理是为了使软件项目能够按照预定的成本、进度和质量顺利完成，而对人员（People）、产品（Product）、过程（Process）、项目（Project）进行分析和管理的活动。软件项目管理的目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，了解软件项目进展，以预定成本按期、按质的完成软件并交付用户使用。当项目绩效明显偏离计划时，能采取适当的纠正措施。

软件度量是对软件开发项目、过程及其产品进行数据定义、收集和分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。

软件项目管理的过程度量能够帮助项目经理等人员掌握软件过程的状态，提供软件项目管理受控所需的数据和信息。

4 瀑布模型的不足

软件开发中传统的瀑布模型是一种较为理想化线性的开发过程。其强调文档的作用，以文档为驱动，在整个开发过程中各阶段的划分完全固定，阶段之间产生大量的文档，一切以文档为依据，并要求每个阶段都要仔细验证。由于瀑布模型具有线性的特性，用户往往只有等到项目的末期才能见到开发成果，早期的错误可能要等到开发后期的测试阶段才能发现，这样既增加了开发的风险，也给项目带来了严重的后果。

具体到瀑布模型的项目管理方面，项目通过跟踪里程碑和阶段完成日期的方式来跟踪项目进度。通常使用挣值分析法的计算来显示和分析项目是否在按计划进行，但挣值的绩效指标可能带有误导性，并经常掩盖掉某些进度延误。在进度、范围和财政预算上，比起为传统瀑布项目提供的“挣值（EV）”和“进度绩效指标（SPI）”，Scrum能为项目利益相关方提供更为准确的预测。

例如，一个项目周期为12个月，某阶段的计划工作量为1 000人时，项目在跟踪频率为双周时对项目的SPI进行度量。当实际工作量为800人时，SPI=800/1 000=0.8，意味着SPI小于1即延迟于原计划20%；当实际工作量为1 200人时，SPI=1.2，意味着项目比原计划超前20%。在对项目的跟踪分析数据进行分析时会发现，这样的延迟或超前对项目进度本身的影响并没有太多的实际意义，只要不影响阶段的周期进度就是可行的。假设还是这个项目，前期的系统分析和软件需求分析占用了全周期工作量的20%，但因为瀑布的线性特性，这个阶段项目的输出仅仅是大量的研制任务书、软件需求、讨论记录、会议纪要等，并没有可使用的软件产品的雏形。上述的项目管理跟踪方式往往掩盖了项目的实际问题，有可能造成项目在临近结束时才暴露出开发过程中产生的问题。即使从挣值分析的数据来看，项目能够按照预定的计划稳步开展，并不能确保最终能够生成预期的软件产品。如果此时出现了颠覆性的重大设计问题，但从挣值分析数据来看并不一定能够发现，对项目的影响也许只能通过调整计划等决策来进行挽救。

综上所述，挣值分析这样的项目管理方法虽然有着光鲜的外表，但对软件产品开发过程度量的实质意义不大，不能较好地通过对软件项目管理过程度量达到对项目进度和软件产品质量监控的目的，促进项目的最终成功交付。

5 引入Scrum方法来解决问题

Scrum方法能更快、更高效地交付可工作的软件产品，并提供更准确的进度、预算和范围的预测。使用Scrum方法将范例12个月项目分成12次迭代，即每次迭代周期是1个月。在第3个迭代完成时，完成了3个可交付软件产品，而不是瀑布模型的一堆文档和记录表。Scrum方法也写文档，但只写有必要且尽量少的文档和记录。Scrum注重的是人与人之间面对面的交流，强调以人为核心，例如每日例会中当场记录项目成员的工作量数据，就可以替代挣值分析法中的个人工作日志、工作周报等。

Scrum相较于传统的挣值分析法，度量数据的数量和种类有了大幅度的减少，约占挣值分析法度量数据的50%，同时也大大降低了数据统计分析的难度。主要的度量数据包括：任务计划工作量（人时）、任务实际工作量（人时）、迭代次数、迭代周期（工作日）、计划总工作量（人时）、计划剩余工作量（人时）、实际剩余工作量（人时）和工作量偏差（%）。

采用Scrum方法，项目仍然需要按照传统的方式划分软件里程碑，从而把控项目阶段的全周期进度，防止由于迭代次数过多或是迭代内容的更改以至于对项目的整体进度造成影响。项目采用全周期进度和每次迭代阶段任务两层跟踪的方法，同步对全周期进度和阶段进度进行管理。

范例项目周期12个月，每个月1次共12次迭代，每次迭代的任务计划总工作量为620人时，项目全周期计划总工作量为7 440人时。

表1和图2是项目全周期项目管理过程度量的数据及跟踪图，其中的度量数据有偏差百分比、计划剩余工作量和实际剩余工作量。计划剩余工作量是由计划总工作量开始递减的等差数列，偏差百分比=（计划剩余工作量-实际剩余工作量）/任务计划总工作量* 100%。数据及跟踪图使用Excel工具来定制，跟踪图可以通过数据自动刷新生成。这里的跟踪图使用了Scrum常用的燃尽图的表达形式。

表2和图3是项目一次迭代阶段的项目管理过程度量的数据及跟踪图。数据的类型和计算方式与全周期的记录表类似，只是偏差百分比的分母基数替换为这次迭代阶段的计划总工作量。从跟踪图的数据分布情况来看，当实际剩余工作量小于计划剩余工作量时，进度提前；当实际剩余工作量大于计划剩余工作量时，进度延期。为了增强与CMMI标准的适应性，增加偏差百分比这个度量项，偏差可根据项目计划中制定的阈值范围采取措施进行纠偏。每次迭代的跟踪保证了度量数据与软件产品实现间的直观性，全周期跟踪图中尤其是对里程碑节点的重点把控，从而实现了对全周期的各个阶段的监控。

6 结束语

基于敏捷思想的Scrum方法，能够改善传统瀑布模型和挣值分析法的项目管理方法数据分析的误导，针对项目进度和产品质量无法准确预测、项目重大问题容易在项目后期才暴露等问题，通过迭代、增量式的开发，加强项目各种角色间的沟通，提高开发效率，简化项目的文档和过程记录。通过对迭代目标和迭代进度的把控，每次迭代生成可提交用户的软件产品，从而把控全周期进度，迭代增量式完成软件产品的开发。当然，Scrum在项目实践中可能还存在不足，需要软件从业人员不断深入地探索和研究。

参考文献：

[1] Schwaber K. Scrum敏捷项目管理[M]. 李国彪，译. 北京： 清华大学出版社， 2007.

[2] Mike Cohn. Scrum敏捷软件开发[M]. 廖靖斌，吕梁岳，陈争云，等译. 北京： 清华大学出版社， 2010.

[3] Robert C Martin. 敏捷软件开发（原则、模式与实践）[M]. 邓辉，译. 北京： 清华大学出版社， 2003.

[4] Ken Schwaber， Jeff Sutherland. 30天软件开发：告别瀑布拥抱敏捷[M]. 王军，李麟德，译. 北京： 人民邮电出版社， 2014.

[5] Andrew Pham， Phuong-Van Pham. Scrum实战：敏捷软件项目管理与开发[M]. 崔康，译. 北京： 清华大学出版社， 2013.