《敏捷软件开发 : Scrum实战指南》—1.2 Scrum

Scrum

Scrum看上去很简单、基础，但是很多人不能明白的是，要做好Scrum，还必须从根本上改变原来开发软件的方式，而这并不容易做到。你会挣扎，你会遇到障碍。我们故事中的团队以其所经历的艰难历程发现了这一点。如果你拿起这本书，你可能也已经意识到了这个问题。为了理解为什么这么简单的事情做起来居然可以这么困难，让我们深入探究一下Scrum。

什么是Scrum？

《危险边缘》(Jeopardy)[1]是我最喜欢的电视游戏节目之一。我一直希望有一个类似的关于软件开发的版本，其中有这样一些类别：方法和框架、导致软件故障的常见原因、著名的软件架构师以及聪明人的愚蠢引用。我可以想出一大堆符合这些类别的问题，比如，“他说：‘对笨蛋要友好。因为你最后有可能要为他们中的一位打工。’”我设想在“方法与框架”这个类别里面，可以有这样一个问题：“以一个美式橄榄球的术语命名一个项目管理框架，这个项目管理框架可以每2～4周交付可工作的软件。”可能会被接受的一个常见答案，以提问的形式，就是“什么是Scrum？”

那么究竟什么是Scrum？Scrum不是一个方法或者一套工程实践。它其实是一个轻量级的框架，设计初衷是管理软件和产品开发。施瓦伯和苏瑟兰(Ken Schwaber和Jeff Sutherland)[Schwaber01]是这样描述的：

Scrum(名词)：一个框架，在这个框架中，人们可以解决复杂的适应性问题，同时以高效生产力和创造性方式交付价值最大化的产品。

Scrum有以下三大属性：

l   轻量的

l   简单易懂的

l   非常难以掌握的

Scrum是一个流程框架，从20世纪90年代早期用来管理复杂产品的开发。Scrum不是产品制造流程或者技术；相反，它是一个框架，在这个框架里面，可以使用各种流程与技术。Scrum把产品管理和开发实践的相对效率清楚地展现出来，以便加以改进。

Scrum依赖于固定节奏的迭代周期，称为Sprint。每个Sprint以计划会议开始，以对潜在可交付产品的演示而结束。Scrum的特征是团队内外反馈快，高度透明。它的短周期和协同的本质使其相当适用于快速变化或者有紧急需求的项目。

Scrum建立在5个核心价值之上，它有3个不同的角色、3个工件以及3或4个会议。关于Scrum机制的更多细节，可以参见附录“Scrum框架”。

实施Scrum

尽管Scrum看上去可能很容易实施，但是它实际上很有挑战性。为什么？因为它的实施需要更多行动，而不仅仅是设置好正确的机制后按一下按钮即可顺利运转。正确实施Scrum需要团队愿意做出以下改变：

l  理解Scrum的价值观

l  往往要经历巨大的思维方式的转变

l  准备面对变化并适应变化

l  处理新暴露出来或新冒出来的问题

l  引入敏捷工程实践

Scrum的基本价值观

任何有使用价值的框架都是建立在一些原则与价值之上的。每一个原始的敏捷实践(XP、Scrum、DSDM、Crystal、FDD以及看板和精益)，都有一套核心价值。这些价值给我们指明方向；在我们困惑的时候进行澄清；最重要的是，帮助我们理解我们为什么要这样做。就像你从前面开篇故事中读到的那样，这个团队试图使用Scrum，但是他们不理解为什么要这么做。他们不理解Scrum框架的基本价值观：专注、尊重、承诺、勇气与开放[Schwaber02]。

专注。专注意味着全神贯注，将注意力集中到某件事情上。在Scrum中，为了交付潜在可发布的功能增量，团队必须专注于为此所需要完成的所有事情上。专注意味着在一段时间内只做一个项目。这也意味着有专门的“团队时间”，在此期间，整个团队屏蔽任何电子邮件、即时通信、手机以及会议干扰。专注就是团队在所有Sprint的整个周期里面使团队集中精力做手头要交付的任务。

尊重。我们都知道尊重是靠赢得的，而不是给予的。这一点在Scrum中特别正确。尊重团队同事或者缺乏这种尊重，可以成就项目或者导致项目的失败。高效率Scrum团队成员之间彼此信任，足以做到坦诚面对自己碰到的障碍。当某个团队成员承诺了一项任务，他们相信这个团队成员会自始至终完成这项任务。一个真正的Scrum团队，是没有你我之分的。在本章开篇的故事里面，测试人员与开发人员明显有争执而且相互之间缺乏足够的尊重。幸运的是，他们相互之间还没有完全失去尊重，他们最终团结在一起便是证明。

承诺。承诺是对交付的保证、誓言与义务。团队不能轻许诺言，他们必须根据大量信息来做出承诺。在每个Sprint计划会议上，团队对组织以及成员相互之间做出承诺。在Sprint计划会议结束的时候，团队的每一个成员必须对团队承诺在Sprint中需要实现的目标达成共识。

勇气。勇气是克服恐惧和面对困难的能力。克服恐惧是团队和组织帮助团队成员鼓起勇气最好的方法之一。团队可以做到开诚布公以建立共识，组织能够证明它会客观听取坏消息，这都有助于团队成员勇于表达自己的想法。记住，如果团队缺乏勇气做自己认为正确的事情，就极有可能做不好事情。

开放。开放使我们能够善于接受新的想法。在Sprint回顾会议中，团队的开放是最明显的。愿意接受新的想法、观念与思考方式可以帮助我们成为学习型组织和高效率团队。

Scrum 需要转变思维方式

爱因斯坦说过：“我们不能用产生问题时使用的思维方式来解决这个问题。”成功应用Scrum(或者就此而言，任何敏捷方法)，最大的障碍就是不具备转变思维方式的能力，或者说不具备使用新的思考方式来解决问题的能力。因此至少在最初的3～6个月以内，Scrum和所有的敏捷实践都需要某种程度的开放心态。在我做的第一个Scrum项目中，我几乎花了一年的时间才真正理解什么是Scrum。[2]

在那一年中，我意识到Scrum是一个强大的但同时也是一个危险的工具。你看过情景喜剧《家居装饰》(Home Improvement)[3]吗？剧中的主角“居家男人”Tim Taylor在使用崭新发亮的新工具时，常常因为没有采取安全性防卫措施而惹上麻烦，比如没有按照原来的设计用途来使用，或者咬掉了他不该去掉的东西。Scrum也是一样。如果没有按照它的指令来使用，特别是在最初的时候，Scrum可以使你的项目很快变得很糟糕。很多团队浅尝辄止，自以为懂得更多了，认为他们的实际情况有所不同，他们已经把事情解决了。

听我一句忠告：在决定定制Scrum之前，一定要先理解Scrum。按照它本来的意图，不做修改直接拿来就用。花一些时间尽你所能好好学习它。在你的大脑中留下一些空间，让这种知识生根发芽，就像泡茶一样。对于从事软件开发的读者来说，大脑中留出一些内存地址空间给这种知识。不要，我重复一次，不要在这个时候尝试把Scrum和你熟悉的其他一些工具组合使用，现在还不是时候。只有掌握了一种工具之后，你才能够学会把它和其他工具成功结合在一起使用。最重要的是，你要有能力与纪律给Scrum一个公平的机会，特别是Scrum本来就有挑战与困难。你会惊讶地发现，几乎不需要修改Scrum，最终也能实现思维形式的巨大改变。你也许会认为这有悖于敏捷宣言的第一条价值：“个体与交互高于流程与工具。”相反，正是个体与交互才使你能够学习使用Scrum(或者其他任何敏捷实践)，坚持这一点有助于你判断什么才是最有效的。

Scrum采用的是最短路径，而不是预设路径

项目中最长的路径被称为“关键路径”或者“限速路径”。我们依据关键路径制定并执行计划，从A点到B点。沿着关键路径执行项目，问题开始出现：比如在制定计划的时候，项目干系人并不知道他们究竟需要什么；或者有新的细节可能在开发过程中显露出来，在产品的生命周期中业务目标发生了变化；项目响应内部与外部的因素，比如竞争对手的产品发布以及其他各种在开发过程中经常出现的问题。几乎每个项目都可能发生这些状况，并不局限于软件项目。

使用传统的项目计划方法，即使出现这些问题，我们也仍然被迫从A点执行到B点，在此过程中牺牲质量、功能以及客户满意度。一旦终于到达B点，我们才开始检查积累的问题并开始制定到达C点的计划。C点是我们发现需要到达但仅仅因为计划不容许而未到达的地方(参见图1-1)。

图1-1  传统的计划方法

在 Scrum 中，我们承认前面提到的各种问题都可能发生，它们是无法改变的现实。不同于制定一个完美的计划来全面应对各种问题，我们接受这些问题会发生的事实，并建立一个机制使得我们可以处理项目过程中出现的问题，以便我们可以直接到达C点，而不必经过B点。

我们是这样做的：在每日、每周、每月与各种层级的人(团队、管理层和客户)设置检查点，保证我们沿着正确的方向构建正确的功能以实现愿景。不同于指望一个大而全、面面俱到的需求收集阶段，我们随着时间的进展逐步收集需求，并根据在开发过程中不断展现出来的新信息对需求进行调整与细化。正因为我们可以这样做，才使项目可以适应业务需要与外部市场条件，因此也给我们提供了走向成功的最短路径(参见图1-2)。

图1-2  Scrum的计划方法

成功需要付出代价。在“完美计划”模型中，我们有这样一个(常常是错误的)认识，就是我们可以知道项目完成的确切日期。这种认识是很难戒掉的。然而在现实中，我们都知道要么进度延期，要么为了满足进度而削减功能(无论它们是否是最重要的功能)，或者为了在预定日期完成指定功能集而牺牲质量。最终，所有这些牺牲都会给业务带来时间、质量以及金钱的代价。

使用Scrum，我们不会同时承诺在某一个特定的日期交付确定的功能集。我们可以变动完成日期或者需要完成的功能集。在一些项目中，我们承诺在一个预定的日期交付大致数量的功能。我们这样做可以事先锁定成本(客户每个Sprint的开支是多少)与进度(什么时候项目结束，项目需要多少个Sprint)。然后估计在这些限制条件下可以完成多少功能。由于Scrum项目总是首先做最高优先级的工作，所以在项目结束时还没有完成的任何功能通常是价值不高且很可能对项目的总体成功并不太重要。

对于完成功能优先于预定日期完成的一些项目，我们可以锁定功能集，但是容许完成日期(因此也导致成本)的波动。我们承诺在一个大致的日期或者日期范围之间交付确定数量的功能集。当变化发生的时候(增加新的功能，或者对已有功能的需求有了更好的理解)，客户明白在按照既定时间交付功能或者延长进度以适应期望功能之间，必须做出一个选择。

这与传统方法有极大的不同。在传统方法中，功能是事先确定的，然后要求团队估计交付这些功能需要的时间与成本的限制。在要求团队对这些功能进行承诺的时候，时间与成本的限制条件往往还被压缩。图1-3总结了这两种方法的差异。这也是思维方式的巨大转变，即为什么相信本章讨论的价值，信守这些价值为什么相当重要。

图1-3  与计划方法相比较

Scrum发现问题

Scrum可以暴露长期以来被掩盖或者忘记的问题或者有些人还没有意识到的问题。它也会暴露新的问题。这些问题不局限于开发与团队合作。比如，我所看见的最常见的问题之一就是“我们应该如何为我们的人确定报酬？”或者“运行这套验收测试集需要多久时间？”在传统的开发模式中，开发人员会基于他是否按时完成自己的代码并达到一定的质量标准而得到回报。这些东西如何映射到一个不对个体进行职能领域度量的跨职能的团队中？Scrum挑战类似的这些组织规范，迫使管理层做出艰难的选择：解决这些问题或者忽视这些问题。然而，Scrum的好处是，一旦这些行为与模式表现出来，就不太容易被人忽视了。

Scrum的最佳搭档

Scrum是一个项目管理框架。因此，它讲的是如何管理项目，但是它不包括特定的、可以使你每两到四周就提交潜在可交付软件的工程实践。因此，你需要Scrum的“白马王子”——极限编程(XP)。尽管Scrum与XP有很大的共性(比如XP有计划游戏；Scrum有计划会议)，但XP还包括一些不同的实践对Scrum进行了完美的补充，比如持续集成、测试先行以及结对编程。

尽管单靠Scrum也对团队有所帮助，但把Scrum与XP结合在一起会产生显著的效果。这并不是说在Scrum有一个坚固的根基之前就应该立即尝试XP的实践，但谨慎为妙，不要一次性引入太多变化。一旦你的团队对Scrum的角色、工件以及会议有丰富的经验，他们就可以准备集成XP的实践。注意，用敏捷项目管理的同时使用传统的瀑布式工程实践是一个不稳定的组合，会导致(比试图解决的问题)更多的问题。取决于团队对变化的忍受程度，引入XP可能需要一天、一周或者一个月。然而一旦引入XP，真正的魔法就开始了。更多关于XP的工程实践，请参见第9章。

在我工作过的项目中，我认为项目必须有以下XP实践。

l   可持续的步伐：每周工作40小时，持续达到85%的输出。详情参见第23章。

l   代码的集体所有：整个团队都工作在整个代码集上，没有一个单独的所有者。详情参见第21章。

l   结对编程：结对编程是两个程序员一起开发同一块代码的艺术。他们采用一种最好的方法来解决问题，详情参见第19章。

l   测试驱动开发：也称为测试第一。这意味着写代码之前先写测试；典型的模式是用红色表示测试失败，用绿色表示通过测试；然后重构以优化代码。始终坚持要求工作达到绿色，不能有例外。详情参见第19章。

l   持续集成：CI(持续集成)使得我们对于代码集的行为与表现有一个连续的图像。每天至少提交一次代码。就像在测试驱动开发中要求测试总是绿色的一样，努力争取每天回家的时候持续集成也是绿色的。

l   编码标准：常常被忽视。没有编码标准的话，团队的每个成员都会使用他或她自己的个人风格，这会对代码集体所有造成巨大的破坏。制定、发布编码标准并把它挂在墙上，提醒每个人注意。

l   重构：这是在不改变代码意图的情况下更改代码的艺术，从而产生更简单、更一致的代码。不断的重构将使团队保持警觉和新鲜。

l   潜在可交付：这个词常常让团队感到头痛。在我的朋友Chris Sterling写的一篇博客中，他认为潜在可交付是一个被遗忘的Scrum组件[Sterling]。为了真正达到可交付的状态，团队不仅需要改变项目管理流程，而且需要改变软开发方法。否则，在我们故事中出现的所有问题(比如质量较差、没有时间测试和不能交付等)都存在，而且会拖垮我们的项目。集成XP的实践是我发现的能够带来真正、持久变化的最好的方法。

什么时候适合用Scrum？

我们已经可以看出，实施Scrum比看上去的复杂得多。那么你还想试一试吗？这得看情况。

我有几个在建筑行业工作的朋友。在小型的家装项目中，我常常请他们帮助我，然后请他们吃套餐，他们都很乐意帮助我。每次他们来，我都注意到他们腰带上的很多工具。我问Joachim，他是否带着一套标准的工具或者根据他的团队每次要做的事情而定制腰带上的工具。他告诉我他总是带着他的基本工具(一个卷尺、铅笔以及护目镜)，其他的所有工具就取决于要做的工作。做框架的工作时，他会在腰带上装上做框架所需要的工具。做木工或者泥工的时候，他就用一套不同的工具。与此同时，那些没有带在腰带上的工具就放在不远处的卡车里面。这与Scrum有什么关系呢？

我把Scrum看作是一个人腰带上的一个工具。就像任何一个优秀的承包商一样，一个人只有在合适的时候才使用Scrum，而不是不分时间地点和场景一直都用。就像我们不会用螺丝刀来固定钉子一样，我们也不应该在一个不需要Scrum的项目中使用Scrum。那么什么时候应该使用Scrum呢？

在史泰西(Ralph Stacey)[1]的《战略管理与组织动力学》(Strategic Management and Organizational Dynamics)(第2版)[Stacey]中，软件项目通常可以归为四个不同的领域：简单、复杂、繁杂与混乱无序(参见图1-4)。简单的项目主要是由各种已知组成：类似的项目已经完成了N次，所以每个人都知道需要做什么，对应用的技术也有很好的理解。简单的项目很容易理解与实施。

图1-4  需求、技术以及项目类型的关系

然而随着我们走出简单的领域，事情就开始变得有点模糊了。我们的需求、我们的技术或者两者兼有，可能不再像我们所希望的那样稳定。也许人们对最终的产品功能没有那么确定；也许使用了新的技术或者应用还没有尝试过的技术。在复杂与繁杂的领域里面，我们遇到了很明显的变化。这样的项目很难预测与实施。当我们从繁杂移到混乱无序的领域，就真的开始一无所知了。如果公司或项目处于这种状态，就应该集中精力解决导致他们处于如此境地的各种问题，而不是建造一个新的系统。

所有这一切的意思就是，除非在简单的领域里面，否则在项目中你就会遇到各种变化：需求的改变、技术的改变或者两者兼有。我也在简单的项目中使用过Scrum与XP，往往却发现这简直就是杀鸡用牛刀。然而，一旦离开共识与确定性，就需要使用Scrum与XP，因为这有助于你适应无法避免的业务需求变化。