Scrum敏捷软件项目管理
增值业务部/聂勇
一、前言
我部项目大多为短平快的中小型项目，这些项目的特点是客户要求工期时间
短，开发周期不长，需求变更频繁。采用传统的开发模式并不完全适应此类项目
的要求，我们有必要探索一种更适合应对快速需求的软件开发模式。
2003年以来，一批业界专家一起概括出了一些可以让软件开发团队具有快
速工作、响应变化能力的敏捷开发模式，主要有：SCRUM，Crystal,特征驱动软
件开发（FeatureDrivenDevelopment，简称FDD），自适应软件开发(Adaptive
SoftwareDevelopment，简称ASD)，以及最重要的极限编程(eXtremeProgramming,
简称XP)。本文主要介绍SCRUM敏捷开发模式。
二、Scrum简介
Scrum软件开发模型为近两年流行的敏捷开发模型。Scrum开发流程通常以
15到30天作为一个周期，由客户提供新产品的需求规格开始。每一个周期所要
实现的特性来自产品订单（productbacklog），产品订单是按照优先级排列的
要完成的工作的概要的需求。
Scrum的基本假设是：
开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程
中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum
将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备
的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑
战，确保每天、每个阶段都朝向目标有明确的推进。
1/8
Scrum开发流程通常以30天(或者更短的一段时间)为一个阶段，由客户提
供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规
格部分，开发团队必须尽力于30天后交付成果，团队每天用15分钟开会检查
每个成员的进度与计划，了解所遭遇的困难并设法排除。
三、Scrum术语
（一）角色
产品负责人：
负责维护产品订单的人，代表利益相关者的利益。
Scrum主管：
为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。
开发团队：
由负责自我管理开发产品的人组成的跨职能团队。
Scrum团队：
产品负责人，Scrum主管和开发团队。
（二）工件
冲刺燃尽图：
在冲刺长度上显示每天进展的图。
产品订单：
按照优先级排序的高层需求。
冲刺订单：
要在冲刺中完成的任务的清单。
（三）其他
冲刺：
2/8
一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所
承诺的一组订单项的开发。
四、Scrum较传统开发模型的优点
Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的
图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素
（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。
下图是Scrum模型和传统模型的对比：
3/8
五、实施Scrum的过程介绍
（一）将整个产品的backlog分解成SprintBacklog,这个SprintBacklog
是按照目前的人力物力条件可以完成的。
（二）召开sprintplanningmeeting，划分，确定这个Sprint内需要完
成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算
的，并不是按人天计算。
（三）进入sprint开发周期，在这个周期内，每天需要召开DailyScrum
meeting。
（四）整个sprint周期结束，召开Sprintreviewmeeting，将成果演示
给ProductOwner。
（五）团队成员最后召开Sprintretrospectivemeeting，总结问题和经
验。
（六）这样周而复始，按照同样的步骤进行下一次Sprint。
4/8
整个过程如下图所示：
六、Scrum会议介绍
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立
会议”。每日站立会议有一些具体的指导原则：
会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，
在脖子上挂橡胶鸡玩具）
欢迎所有人参加，但只有"猪"可以发言。
不论团队规模大小，会议被限制在15分钟。
所有出席者都应站立。（有助于保持会议简短）
会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
今天你完成了那些工作？
明天你打算做什么？
完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
5/8
一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要
反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在
4小时。
Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关
的规范（disciplines），这些有助于创造自我组织的团队。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的
需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同
样，Scrum采用了经验方法–承认问题无法完全理解或定义，而是关注于如何
使得开发团队快速推出和响应不断出现的需求的能力最大化。
七、Scrum相关文档
（一）产品订单
产品订单（productbacklog）是整个项目的概要文档。产品订单包括所有
所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放
的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮
助产品负责人衡量时间表和优先级（例如，如果"增加拼写检查"特性的估计需要
花3天或3个月，将影响产品负责人对该特性的渴望）.
（二）冲刺订单
冲刺订单（sprintbacklog）是大大细化了的文档，包含团队如何实现下一
个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小
时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的
任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
（三）燃尽图
燃尽图（burndownchart）是一个公开展示的图表，显示当前冲刺中未完
6/8
成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图
相混淆。
八、结语
Scrum是一个框架，其本身就是一种团队的管理。它提供了一套实践方法，
提出了把任务分成story、backlog、sprintbacklog等概念，每日跟踪完成进
度，回顾与明确今日的任务，使一个团队高效率的运作。一支出色团队靠的不是
技术，不是流程，而是有良好素质的团队成员。良好素质包括进取心、责任心、
良好的习惯、热情……在Scrum团队中，我们可以培养这种良好的习惯，良好素
质的团队成员。
目前我部暂无Scrum敏捷软件项目管理的实践经验，对于项目的生命周期管
理主要沿用传统模式，在一定程度上，对客户多变的需求还是有些力不从心。目
前国内已有多个公司的项目团队参与了Scrum敏捷软件模式的项目管理过程，并
取得了很好的效果。根据诸多的实践经验，Scrum敏捷软件项目管理在很大程度
在还是其可取之处，不但可以提高整个团队人员的素质，还有助于项目的管理，
而最主要的则是可以让我们以最优的状态为客户提供服务。
针对我部目前的情况，在Scrum的引入与实践过程中，不一定完全按照Scrum
里所涉及的方方面面，可以在Scrum框架的基础上，针对我部中小型项目，规范
化一套属于我部所适用的敏捷软件项目管理模式进行试点。相信这套试点规范的
制定与实施，会为项目管理带来有利的改变。
九、参考文献
TakeuchiandNonaka:TheNewNewProductDevelopmentGame(Harvard
BusinessReview,Jan-Feb1986)
PeterDeGrace,LeslieHuletStahl,Wickedproblems,righteous
7/8
solutions,1990,ISBN0-13-590126-X
JeffSutherland,AGILEDEVELOPMENT:LESSONSLEARNEDFROMTHEFIRST
SCRUM,2004
AgileProjectManagementwithScrum,KenSchwaber,MicrosoftPress,
January2004,163pp,ISBN0-7356-1993-X
8/8
|
|
