基于Scrum框架的软件项目管理

陈良才 胡章元 夏 波

江苏省邮电规划设计院有限责任公司，江苏 南京 210019

引言

传统开发模型不能适应快速变化的客户需求，而且客户在前期无法看到产品，只有到后期UAT测试或系统上线时才能看到。如果产品与用户的预期相差甚远，再提出更改已经太晚，提出需求变更的时间越晚，成本会成倍增加，而敏捷方法刚好可以解决这个痛点。价值驱动和拥抱变化是敏捷的本质。在最流行的Scrum敏捷框架中，每一个Sprint都产生可交付的产品增量，客户可以见到产品，及时校正自己的需求。Scrum这种短迭代持续高效交付产品增量的开发方法，受到越来越多的企业，特别是互联网企业的青睐。

Scrum框架是目前全球最流行与最有效的敏捷项目管理理念与方法。本文就 Scrum框架内容和实践方法，以及实践中需要注意的问题进行了简单阐述。

1 Scrum框架介绍

1.1 Scrum历史

Scrum的雏形是由日本的Takeuchi和Nonaka两位教授在1986年提出来的，并且用于制造业新产品的研发过程中。1993年，Jeff Sutherland读到了这两位教授新的产品开发方法Rugby（橄榄球）的文章。他受到启发，结合自己多年的经验，与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（橄榄球术语，争球的意思），并且首次将这种方法应用于软件开发。1995年，在奥斯汀举办的面向对象技术 OOPSLA高峰会议上，Sutherland和Schwaber第一次向世人介绍了Scrum。

2001年2月，17位敏捷先行者起草《敏捷宣言》，成立敏捷联盟。那时 Scrum只是众多敏捷方法的其中一个。经过这些年的发展，现在Scrum成为最流行、最有效的敏捷框架，几乎成为敏捷的代名词。

1.2 Scrum框架介绍

Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成。一个短的迭代周期称为一个Sprint或一个冲刺，每个Sprint的建议长度是2～4周（互联网产品研发可以使用1周的Sprint）。在Scrum中，使用产品Backlog来管理产品的需求。产品 Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事 User Story。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

Scrum框架包括3个角色、3个工件、5个活动、5个价值，如图1所示。

图1 Scrum框架图

1.3 敏捷方法在国内外的应用现状

根据Scrum联盟最新发布的《2016年Scrum状态报告》，Scrum联盟调查了来自76个国家的2000多名受访者，涉及15种不同行业人士。其中89%的受访者表示正在使用Scrum框架进行项目开发，而在2015年的调查中，这一比例只有82%。经过一年的发展，Scrum受到了更多项目管理者和开发者的青睐。另外，43%的受访者使用Kanban方法，23%的受访者使用传统的瀑布模型与敏捷混合方式。应用 Scrum的项目总体成功率由2015年的62%提高到68%。

在我国，新兴的互联网公司和外资跨国企业应用Scrum或其它敏捷框架方法较为广泛，而传统软件企业使用瀑布、RUP等传统方式较多。随着更多企业认识到了传统开发方法的弊病，新的敏捷方法可以解决这些痛点后，将会有越来越多的国内企业把目光投向敏捷方法，投向Scrum。

2 Scrum在软件项目中的实践

Scrum框架包括5个价值观、3个角色、3个工件、5个活动。框架本身非常简单，但往往能把简单的事做好。一直做好，就非常不容易。正如亚洲首位ACSM认证讲师Vernon 所言：“Scrum is simple，but it's not easy。”

2.1 认同敏捷宣言的价值观

在敏捷宣言中有 4句话道出了敏捷方法的价值取向：个体与互动重于流程和工具，工作的软件重于详尽的文档，客户合作重于合同谈判，响应变化重于遵循计划。这就是敏捷与传统瀑布模型的价值观的不同之处。在传统的瀑布模型中，都是计划驱动和文档驱动，每个阶段以文档或代码通过评审为结束，前面的阶段无法看到可用的软件，而从头至尾的周期比较长。当看到软件时，可能若干个月以前的需求已经变化了，或者软件与当初的需求出现偏差。这时返工的成本非常高，给项目带来不确定的风险非常大。

在传统的瀑布模型中，最害怕需求变更，越到项目后期，需求变更难度越大，变更成本也会成倍增加。在敏捷方法中，最强调的就是要拥抱变化、适应变化、将变化的成本和风险降到最低。

2.2 认同Scrum价值观

作为 Scrum框架的实践者，我们首先需要理解和认同Scrum所追求的5个价值，即承诺、专注、开放、尊重、勇气。这些价值观是 Scrum框架的基石。就好比建造高楼大厦的地基，虽然不属于建筑的组成部分，但它对保证建筑物的坚固耐久具有非常重要的作用。不理解或者不认同这些价值观，后续的各项活动也就不会深入理解其中的目的或者价值，会做得越来越形式化，变得有形而无神。

“承诺”是PO和开发团队相互给予对方的，在过程中通过紧密“合作”来促进承诺的达成。团队基于团队的平均速率“诚实”地向 PO承诺下一个 Sprint目标，PO在过程中充分“信任”团队可以交付高质量产品增量，并且承诺不会干扰团队。

Scrum团队是乐观积极、配合默契的自组织团队，团队不需要领导，彼此互相尊重、互相协作，为达成自己的承诺全身心投入。Scrum团队是开放的团队，各种资源计划信息都是共享的、透明的，确保每个人接受到的信息是一致的，而不是残缺的，这样有利于团队对项目的统一理解。

2.3 三个角色在项目中的应用

Scrum中三个角色分别是 PO（产品负责人）、SM（Scrum Master）、开发团队。首先需要明确的是SM并不是领导，SM是通过自己的个人影响力来领导团队，在团队中承担培训、引导、辅导、启发、协调等作用，最多算“服务式领导”。SM要避免通过权力来命令或者控制，否则违反了Scrum基本价值观。实际情况下，很多SM是由原来瀑布模型中的项目经理转型而来的，很容易出现命令式的指挥团队。这点在转型过程中难以避免，需要不断深入理解Scrum价值才能做好这个角色。

SM在项目中负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫清障碍；保证开发团队不受外力的干扰和阻扰；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和 Sprint评审会议。

PO这个角色，类似于产品经理，一般由精通业务和市场的人员担任。PO需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级，并且有权决定接受或否决各个Sprint的工作成果。

而开发团队是由一群跨职能、自组织，认同敏捷价值观和 Scrum价值观的人员组成的。人数尽量控制在5～9人，遵循“两个披萨”原则，即团队的人数不应多到让两个披萨不够吃。人数越多，沟通成本越高，效率越低。对于人数众多的大中型项目，可以采取多个Scrum团队分工协作的方式。

2.4 三个工件的作用

三个工件分别是产品列表Product Backlog、冲刺列表Sprint Backlog、潜在可交付的产品增量。

产品列表是由PO管理、不断演进的一个动态需求列表，其中每一个条目就是一个用户故事User Story，包括功能性需求、非功能性需求、技术改进点、待解决的问题等，并且每个条目要符合DEEP原则，即详略得当的、涌现的、估算过的、排序过的。

冲刺列表是从产品列表中选择数量适当的、最有价值、优先级最高的User Story组成的。原则上，在一个冲刺期间不允许改变范围内的目标，但是，有时候无法完全遵从这个原则。通常，我们在各个团队中采取的做法是：PO首先阐明变更的必要性，一切基于价值评估来说话，团队认可价值后再与团队协商是否采用“需求置换”，或者团队接受这个冲刺加班完成。无论是什么结果，PO都不能威胁团队必须要做。

在早期的Scrum框架中，燃尽图是工件之一；但是当图形燃到0点时，并不意味着可以交付出有价值的产品，所以“潜在可交付的产品增量”替代其成为Scrum工件。“潜在可交付”并不意味着构建出的东西必须实际交付。交付是PO的业务决策，基于发布计划来确定。

那么，燃尽图是不是就不再重要，可以不再关注呢？答案是否定的。个人认为，燃尽图在冲刺过程中是需要团队成员共同关注的。无论是手绘还是通过工具来展示，都是冲刺过程中可视化进度的表达方式，能帮助团队判断冲刺目标是否可达成的风险概率。

2.5 五个活动在项目中的应用

五个活动是指产品列表梳理会议、冲刺计划会议、每日站会、冲刺评审会议、冲刺回顾会议。

产品列表梳理会议是 Scrum中非常重要的，而且很容易被忽略的一个会议。说它重要，是因为 Scrum开始之前就需要有准备就绪的输入。这个输入就来自于产品列表梳理会议的结果，即初始的产品列表。只有产品列表准备好了，才可以进入迭代。另外，梳理会议是由PO发起或负责，可以召集开发团队参与，也可以只有相关的开发团队成员或相关的利益干系人参与。在此会议中和会议外，可以对产品列表进行更新维护，维护好的产品列表应是符合DEEP原则的。

冲刺计划会议是每个冲刺第一天，团队要在计划会议中确定本冲刺中需要完成的产品列表的哪些内容，并且讨论如何实现这些内容。开发团队可以就实现的细节问题，向PO提问。根据明细的信息，估算完成这些工作所需的工作量。最后团队基于这些估计，承诺实现全部或部分内容。此会议时长一般为Sprint周数*2小时。

每日站会的主要目的是推进项目进度，明确项目目标，并促使团队齐心协力朝共同目标迈进。SM要确保这个会议每天准时开始，采用站立方式，并且在15分钟内结束。每个成员都需要回答3个问题：自上次站会以来，完成了哪些工作？至下次站会之前，将完成哪些工作？工作中碰到哪些问题或障碍？在这个站会上，不要求解决提出来的问题。这些问题需要会后单独沟通或组织会议沟通解决。会议应在每天同一时间同一地点准时开始和结束。这种一贯性可帮助团队确立一个模式。此外，团队还可以在开会的地方布置一个看板，把任务计划、燃尽图等贴在看板上，并且随时更新。

冲刺评审会议是在冲刺结束前给PO演示并接受评价的会议，并根据反馈结果，提出新的产品列表。这个会议主要是检验冲刺的成果，检查是否完成冲刺计划的目标。在可能的情况下，邀请用户参与测试流程，并得到用户对产品的认可。此会议时长一般为Sprint周数*1小时。

冲刺回顾会议的目的是促进Scrum团队在后续的冲刺中做得更好。在每次冲刺结束后，对前一个冲刺中的人、关系、过程和工具进行检视，找出做得好的方面和需要改进的方面，并一同制定改进Scrum团队工作方式的计划。此会议时长一般为Sprint周数*1小时[1]。

3 Scrum实践中应避免的问题

3.1 SM角色定位不清或不设置

SM敏捷教练不是项目领导，但很多从传统开发模式转型过来的团队，一般由项目经理担任这一角色，经常会用领导者和决策者的姿态与开发团队交流，经常会把这个角色的职责弄得混乱不堪。设立这个角色的初衷是，他作为一个教练或引导者，设立在项目和客户之间的角色，不参与团队的实际工作；反而，他会协助产品负责人，辅导团队，确保项目团队遵循Scrum流程。SM只负责Scrum流程能够正确、持续的实施，发挥出它的最大效用。

另外，SM角色，在国内很多的公司是无法得到认同的，因为他既不开发也不测试，对产品没有直接贡献，因此很多国内公司不设置这个角色，或者这个角色存在的时间很短。这样就会落入自组织陷阱。

经常有人认为，自组织团队不需要任何管理。这个观点是有问题的。新团队需要由敏捷教练进行适当的管理，非命令式的引导项目团队建成自组织团队。对于更加成熟的团队来说，敏捷教练主要关注于确保团队能够持续保持自组织。

3.2 缺少架构设计

忽视架构设计是 Scrum在中国难于落地的一个原因。在Sprint开始前，会有一个产品列表梳理会议。这个会议是目标承诺会，与架构设计无关。在每个Sprint开始的计划会议上，有两个主题——澄清需求和设计。但时间太短，往往无法承载架构设计。在一些大量应用现成框架的产品开发过程中，或在一个产品的维护阶段，还可能成功。但是，对于大型复杂产品开发而言，不进行架构设计，结果基本上是灾难性的。

目前，我国的现实情况基本上是详细设计的多，架构设计太少，而Scrum更助长了这种轻视设计的风气。当然，强调架构设计并不一定意味要写很厚的架构设计文档，或者进行复杂的UML建模，如何进行架构设计，做到什么程度，应由团队自己决定。现在很多敏捷专家都建议在实践敏捷方法中，增加架构设计会议。

3.3 不可持续的工作方式

Scrum 团队必须对在一次 Sprint 中可以完成哪些任务、谁可以在正常的一个Sprint内完成这些任务做出决定。敏捷最重要的目的，是通过持续不断地交付有价值的产品增量使客户满意。有些人总是试图在Sprint中塞进更多的任务，这些任务超出了Scrum团队在额定时间内所能完成的工作量。这就会导致团队疲于应付，可能会挤占其他活动的时间，而造成自组织的下降。另外，过多的加班会打乱团队的节奏，容易造成效率低下、质量下降、人员的耗尽以及职员的跳槽等。不能持续稳定地交付有价值的产品增量，这已经背离了敏捷的价值观。

4 结语

Scrum框架非常简单，但要把简单的事持续做好，并不容易，需要整个组织认清 Scrum能给组织带来什么价值，也需要组织、领导以及团队都能认同 Scrum价值观，避免出现“照猫画虎”。

我们在实际应用 Scrum框架进行软件开发时，应该认同敏捷宣言中的价值观，认同 Scrum的价值观，在项目开发中实践Scrum，并且不断探索更好的开发方式，这样软件开发才能够真正地敏捷起来。

[1]巩菁菁.基于 Scrum的敏捷框架在软件企业中的应用研究[D].大连：大连海事大学，2011.