Scrum开发管理方法的由来、团队建设与实施过程

起死回生的“哨兵”

2001年9月11日，随着世贸双塔轰然倒塌的巨响，美国联邦调查局遭受了前所未有的指责和质疑。美国人民很想知道，这个地球上最强大的情报机构为什么事先一点预警也没有？联调局的分析员们带着愧疚的心情重新分析整理过往的资料，发现恐怖分子的行踪其实都有迹可循，倒霉的事情在于联调局的工作方式还是30年前式的。他们将情报打印在纸上然后从楼上传到楼下由某个负责人签字之后再传回楼上，最后分发给相关部门。显然，恐怖分子不会给联调局这个时间去发现他们的阴谋。

痛定思痛，联调局决定投入巨资建设一套信息化的分析处理系统，力争在最短时间内发现风险并发出预警。考虑到这套系统的保密性要求，他们将其交给了传统军工巨头洛克希德·马丁公司。这项工程被命名为“哨兵”计划，预算4.5亿美元。经过了五年的开发之后，钱花得差不多了，但进度只有一半。更可怕的是洛·马公司宣称完成开发工作还需要6至8年，并且再投入3.5亿美元。其实大家心里都清楚，这已经是一个烂尾工程了。

杰夫·约翰逊是联调局“哨兵”项目的技术负责人，他很清楚项目失败的原因，就在于洛·马公司使用的仍然是传统瀑布式开发方式。这种方式对于需求的变化几乎没有招架之力，只能是将前期工作推倒重来，所以造成如今的困局。约翰逊为此向联调局提出可以采用一种敏捷方法论，只需要用项目里还剩下的2000万美元，保留五分之一的开发人员，在12个月内就能完成这个项目。

负责经费预算的检察长一度认为约翰逊因为焦虑过度而病急乱投医。但面对现实同样束手无策的检察长只好死马当活马医，让约翰逊按照他自己的想法姑且一试。约翰逊使用敏捷方法论中的Scrum开发管理方式，首先确定最重要的需求，然后立即开发实现功能原型。有了最小可用的功能，就让联调局的工作人员使用并提出意见。之后调整功能，扩展需求进入下一轮迭代中。这样的一个过程在Scrum称之为冲刺周期，在不断的冲刺之下这套系统逐渐完善起来。

终于在两年之后“哨兵”系统正式运行起来，尽管这比约翰逊承诺的时间要长，但还是让联调局大大松了一口气。这个神奇的Scrum是什么？它来自于橄榄球运动的一个术语，即球员们环抱围成一圈，然后将球控制脚下向着目标区移动。引申在软件开发管理上则是强调团队合作的重要性，同时让各个成员发挥出自己的力量，整个团队具有强大的信心与持续的激情。

Scrum理念的创造者是杰夫·萨瑟兰博士，这位老兄的人生经历堪称彪悍。早年他从军服役，在越南战场上干的就是最危险的技术活：驾驶侦察机深入敌军后方。当时美军飞机被击落的概率是50%，但他却成功完成了100次敌后侦察任务。可知这位老兄是一个非常善于思考并且处事冷静利落的人。

当然，美军飞机的战损率高也有自身训练的问题，后来军方发起了Top Gun训练计划，一举扭转了飞机战损率。这一最初来自越南战场的训练经验后来在陆军中也得到了推广应用，并且在第一次海湾战争中大获成功，成为了一场影响世界的军事训练革命。此为后话，不再赘述。

萨瑟兰博士在退役后又经历了学术生涯与商业活动生涯。他正是在企业里管理软件开发的过程中，发现了传统瀑布式方法的诸多缺陷，进而思考并提出了Scrum方法并进行了实践。

Scrum的理念和方法其实很简单：一个团队最好在七人以下；一个产品负责人，一个项目管理员；一张包含待办、在办、已完成的事项清单；由冲刺构成的开发周期与每日立会。

这一理念提出后，立即引发了业界的广泛思考和探索。杰夫·约翰逊显然也是Scrum理论的拥趸，不过可以看出来他也并非是盲目的信徒。他非常了解“哨兵”项目的症结所在，所以能够对症下药，应用Scrum方法创造了这一看起来似乎是不可能的奇迹。

Scrum方法不仅适用于软件开发过程，在其他行业甚至是我们的家庭生活中都可以应用它。当然，一个理念再简单再好，也需要先得到认同然后再去进行实践。很难想象团队中的成员连基本的认知都无法达成一致，却要去基于这个方法做事情，肯定是无功而返了。

标题目标与团队建设

目标

scrum正如其名称来由所揭示的，橄榄球运动员们紧紧围成一圈，把球控制在圈内，然后向着目标前进。最终能否得分取决于所有队员之间的全力配合。在使用scrum方法进行开发活动管理也是一样，开发团队成立的第一天，所有成员首要的事务就是要知道团队的目标所在。

如果目标不清晰，那就像在赛场上队员们思路不统一一样。这个认为要稳守反击，那个觉得要大举压上，造成的结果是兵力分散，空门大开，轻易被对手抓住机会得分。诚然，球队中会有实力超群的球星，他的能力可以一个顶俩或者顶仨，但不可能一个打十个。球星如果把目标定为自己多得分，想凭一己之力终结比赛，这多半难以成功。但球星的目标如果是和队友们一起赢得最后的胜利，球队的战斗力就爆发出来了。

软件开发团队也是如此，每个人的实力不见得都在一个水平线上。但开发者们如果只把目标定为完成好自己的任务，那么这个团队中的成员仍然处于一种各自为战的状态，最终结果的质量必然是在团队成员的平均水准之下。所以，每个人都应该把最终交付的产品质量作为目标，力求产品做到稳定、高效、可用。

团队建设

关于团队的构成，它首先应该是多功能的。也就是说开发一个软件产品所需的专业技术人员都应该包括在内。自从人类进入机器大生产时代以来，工业流水线式的生产方式就是主流，因为它快速并且易于管理。这一思维应用在软件开发上则收效甚微，因为开发工作是知识密集型，并且软件产品的特点是需求变化快速。很难做到前期目标不调整，后面可以持续各个环节的工作，一旦返工则成本巨大。

因此以流水线模式将开发人员分成“服务端组”、“客户端组”、“美工组”、“测试组”并非是最好的办法。这种组织方式会造成的另一个严重问题是各个组只对本组的工作负责，最常见的一种情况是产品在线上运行出了问题，每个组都试图证明“在我的环境里运行是正常的”，然后建议“你们要不再查查别的原因”。这显然不是在解决问题，而是利用组织之间的鸿沟来摆脱问题。

其实出现上述情况之后，最后总是要由CTO或技术总监这样更自更高层的领导者下令，抽调各组人员临时组成一个团队来分析问题并解决掉。各位可以回想一下，在职业生涯中是不是面对过上面所说的场景。所以，一个多功能的团队内所有信息都是均等流通的，出现问题能够快速排查并处理。

多功能团队的另一层含义是每名成员除了自己擅长的技术之外，还应该学习其他成员所擅长的技能。这一点对于应对人员风险来说至关重要。团队中的成员总会遇到各种问题而有可能暂时缺席或者离开，那么在短时间内为了不影响工作进展，最好的顶替者当然是团队内部的成员。因为就算临时去找来高手，其要熟悉业务就需要一个过程，不可能快速上手并融入团队中。

对于团队成员数量，最好是在八人以下。这个依据来源于一个人际交往的理论，就是说一个人在日常活动中可以保持联络而不影响工作效率的人数是七人。联系人超出了七人，那意味着个人生产力会大幅下降。其实也不难理解，因为大部分时间都用在频繁的沟通交流上了，而且还要记住这些交流会产生的待办事项，显然本职工作就难以做好了。

可能会有疑问说，一个大公司里好几百号人，要应用scrum那应该怎么办？办法就是把大团队拆分，然后按照scrum的结构进行组织。对于有任务关连的团队，可以由各个团队的管理员们再出来单独组成一个scrum团队，这样可以根据任务需要灵活构建上层管理团队。而每一个基层团队又都可以保持自主性与凝聚力。

scrum团队中的管理员角色从功能上更像是为项目服务的管家，他负责召集人员制定目标、召开每日立会，协调资源，在冲刺活动结束后召开总结会议。一个迭代周期完成之后，管理员要联系客户并向其展示工作成果，根据客户的反馈对功能进行修正，并确立下一个周期的工作内容。

实施方法与工作过程

冲刺

一个遵循Scrum理念的团队建立起来之后，就要进入工作状态中了。但这不是一上来先打了鸡血一样，过一阵子又疲软无力。要想保持高效的产出，节奏很重要。在scrum中，一个冲刺的过程一般来说不超过一周时间。持续四到五个周期的冲刺之后，就可以得到基本可用的产品了，这也是流传甚广的30天开发可用软件说法的由来。

对于冲刺的目标来说，并不是说在每个周期完成一个功能模块，所有模块开发完后组装在一起完事。每一次冲刺的目标都应该是交付一个可用的软件产品。当然，最初的产品仅是一个粗糙的原型，但也足够给客户提供直观的体验。在此时客户发现问题并提出新的需求，在下一个冲刺中就可以全力解决问题并开发客户所需的功能了。

在冲刺开始之前，要举行一场计划会议。这个会议的议题是讨论要进行的工作，并将讨论内容归纳成用户故事。需要注意的是计划会议只讨论当前一个冲刺之内能完成的任务，目标过于宏大没有意义。作为一种敏捷方法论，Scrum强调的是快速接近用户真实意图，打造符合预期的可用软件。

当一个冲刺结束之后，则要召开一场总结会。这个会议则是讨论当前已经完成的工作，同时要回顾出现了哪些问题以及解决的办法。这是为了避免在后面的工作中再犯相同的错误，这往往是提高效率的关键。最后则是向所有成员展示已经取得的成果，鼓舞团队士气，为下一个冲刺做好准备。

经过数轮的冲刺实现产品的迭代，这必然是趋近于客户的目标的。这远比团队关起门来开发几个月，拿出来的产品跟客户的预期差距甚大要好得多。同时，固定时间的冲刺活动也有利于团队成员保持工作节奏，能够合理地安排自己的任务。

要点：

举行冲刺计划会议；
全力以赴投入工作；
召开冲刺总结会；
多轮迭代。

事项清单

Scrum团队的任务管理是有别于传统的软件开发管理的。在传统管理方式中，是由项目经理与架构师或者资深程序员讨论出一个任务列表。然后项目经理在甘特图中标明各个任务的起止时间，再把开发人员填充进去，万事大吉。这种图表是完美的，如果不出意外，结果也应该是完美的。

可是问题就在于软件开发活动就是个意外频出的过程，一张绘制完美的图表到后期总是被各种变更扭曲、打乱，结果变得丑陋不堪。在Scrum的实施过程中，采用的是事项清单来管理任务。

在说明任务管理方法前，还是要提一下Scrum理念所强调的仪式感。Scrum方法认为一个团队中的所有成员最好是将自己的电脑从格子间的工位搬出来，有条件的话大家在一个单独的房间里共同办公。例如找一间空闲的会议室，大家把电脑都放在会议桌上，彼此围成一圈。然后拿出可粘贴式便签纸，准备下一步工作。

管理员这时会站起来，在会议室的白板上用碳素笔画出三个分隔的区域，并且从左至右在各自区域写上：待办事项、在办事项、完成事项。接下来讨论第一个冲刺要完成哪些任务，在Scrum中，这被称之为用户故事（下节详细讨论用户故事）。大家达到一致之后，管理员把用户故事分别写在便签条上并贴在“待办事项”区。再接着就是进行任务分配了。

重点之处在于，任务并不是由管理员自上而下地分配给某人，而是由团队成员自告奋勇领取任务。领取者会庄严地将便签条从“待办事项”区移至“在办事项”区。这样团队所有成员也就明确承诺了自己的任务，并且在一个冲刺周期完成之后，再由领取任务者将自己的便签条从“在办事项”区移至“完成事项”区。相信当众主动承诺所带来的驱动力是远胜于被人在后面给推着走的了。

当然，如果一个团队在组建伊始，可能会出现对工作承诺过于悲观或过于乐观的问题。但经过一到两个冲刺之后，团队成员彼此熟悉并且配合默契了，就会更加合理地领取任务并完成好。当冲刺的次数越多，团队的效率就会越高，这是Scrum方法所带来的一个巨大的益处。

事项清单也有助于团队成员对项目整体进展的把握，因为只要有一个任务还留在“在办事项”区内，那么这一次冲刺也是失败的。势必大家都会为了共同的目标而群策群力，而不是说别人的任务跟我没关系，等他自己解决就行了。

要点：

在封闭空间内集体办公；
准备好写有待办、在办、完成事项的白板和便签纸；
将用户故事写在便签纸上，并张贴出来；
团队成员主动领取任务；
移动便签纸，直到任务全部完成。

用户故事

在Scrum中，软件功能的需求被称之为用户故事。之所以要用这样的名称，是为了借助于“故事”一词所传达出的隐喻。我们知道一个故事的基本要素里包括人物、情节发展与结局。对应于软件需求来说，一个需求应该从用户角度出发，然后他会如何操作以达成目标，以及这个需求是否可测试。

在讨论用户故事的时候应该要和最终使用者进行充分地沟通，因为只有使用者才明白他们想要的是什么。但遗憾的是使用者本人在没有直观的感受前，他只能以模糊的话语来描述他想象中的事物。

所以在确定一个用户故事时，它的规模不能太大，最好是一个可在短期内实现的功能。一般在Scrum实践中，一个用户故事的开发周期就是在一个冲刺之内。

同时，一个用户故事必须是独立可测试的，不能说对它进行测试还要依赖于另外一个用户故事。强调它的独立性一是为了减少系统功能的耦合，二则是可以根据用户对功能的要求紧急程度进行组合。

在初期讨论用户故事时，可能会罗列出很多事项来，但不可能都同时进行。因此要按照功能的重要程度给其标记上权重值，这样就可以将最核心的功能挑选出来优先开发。在一个冲刺完成后，用户立即就能对已经完成的功能有直观体验，进一步明确下一步的工作。

除了功能重要程度，每个用户故事还应该标记实现复杂度。这个数值是为了估算团队的完成能力，有了这个数值就可以合理分配一个冲刺之内的工作量。不至于说上周任务难度低，工作特别轻松，这周任务都很复杂，结果搞得大家都压力重重。

要点：

一个用户故事必须是独立可测试的；
一个用户故事最好在一个冲刺内完成；
标记重要程度值；
标记复杂度值。

立会

立会的意思就和字面上一样，站着开会。这也是一个Scrum所要求的仪式，站着开会显然会促使人长话短说，同时还有益健康。当然，Scrum理念的发起者是希望这样一个形式能让人时刻记住立会的目标：快速总结工作成果，并提出问题。

在一个冲刺周期内，立会是要求每天都要召开的，通常由管理员发起。开会时间也最好是一天中的固定时刻，例如早晨十点，不用特别通知，每个人到了点就自动聚在一起开会。

管理员会提出三个拷问灵魂的问题：

“昨天完成了什么工作？”

“今天要做什么工作？”

“遇到了什么问题？”

每个人都要回答，而且每个问题的回答时间不能超过30秒，意味着两三分钟内就要把三个问题全部答完。这不是在搞某种行为艺术，而是效率的需要。如果在短时间内不能说清这些事项，那就意味着任务的分解是不合理的，有隐含的复杂情况没有被发现，而这对项目来说就是风险。

一个需要注意的情况，就是立会不要开成工作汇报会，大家只是例行公事般说完自己的事就各自安好了。立会的主要功能有两点：一是让大家的信息保持对等；二是尽早解决问题。

有研究发现，一个团队的默契合作程度和一个叫做信息饱和度的指标相关。这个指标的含义就是团队成员之间分享信息的比例，信息饱和度越高则团队的产出效率越高。而每日立会则是一个极好的大家共同交换信息的机会，通过这种方式将信息饱和度保持在一个高水准。

我们翻开任何一本讲述软件工程的书籍，都会告诉我们一个软件bug如果在前期被忽略，到后期来修复时会产生更加巨大的代价。立会上的第三个提问就解决了延迟解决问题所带来的损失。

当然，在立会上仅需要提出问题就好，散会后再召集相关人员详细讨论解决办法。切忌在立会上就热烈讨论半天，而耽误了整个项目的进展。这时管理员就要保持清醒的头脑，控制会议的进程。

要点：

三个问题；
三分钟之内说完；
聚焦于出现的问题。