一文搞懂Scrum Pattern︱敏捷软件开发（scrum敏捷开发是什么）

作为一个整体，团队应该包含交付产品所需的所有人才。

Scrum团队正在组织其开发工作，并正在选择团队成员，或正在评估如何使团队的技能获得成长。

01为什么需要跨职能团队

Scrum团队如果不能自主工作，就是因为它不具备完成复杂任务网络所需的所有技能。如果依赖团队外部人员的技能，团队就不能真正“拥有”手头的工作。这样团队对工作的完成时间就没那么有掌控力了，并且最终工作的质量也会受到影响。一致性（Consistency）和减少返工（Reduced Rework）这两项核心精益原则依赖于短的反馈回路。大多数复杂的开发工作都需要有来自不同领域（如人类工程学、工程卓越和质量保证等）的众多人才。很少有人能在一个团队中找到所有这些人才，更不用说在任何一个人身上找到所有这些技能。团队通常围绕着能力领域进行组织，正所谓物以类聚，人以群分。这有时被称为职能型组织（Functional Organization）。然而，跨越团队边界协调这些职能的成本很高，因为只有在那些共享当前工作背景的人之间才能存在有效沟通 — 这通常只有同一个团队的成员才能做到。

一个复杂的产品可能需要团队掌握许多技能才能“完成”（Scrum Pattern之一，将在单独的文章中介绍）各项功能。如果需要为每项所需的技能都分别增加一个人，那么团队就会变得过于庞大而无法有效工作。要解决这个问题，通常会有两种选择：你可能会倾向于不扩大团队的技能组合，而是引入外部依赖；你还可能会选择把工作交给团队，让他们去发展和学习所需的技能。但学习是需要时间的。

局部学习可以导致局部优化，也就是说专家会发展出优化他们工作的实践和流程。专业化（Specialization）、局部实践（Local Practices）和流程（Processes）都可以成为一个组织的效率来源，但也会在团队的边界处产生问题。为了解决这些问题，这个组织可以定义 "合同"，说明如何与对方合作（例如，服务请求）。这样的合同可以规定这个组织愿意做什么性质的工作，以及对请求的预期响应时间。任何需要该团队专业技能的人都必须使用这些合同与他们打交道。然而，这可能会减缓整个产品的开发，即使它提高了局部部门的效率。同时，可能需要在组织内设立额外的协调小组来管理这些边界合同、协商例外情况或确保所有各方了解所需的内容，并确保每个团队根据这些合同的义务，履行对其他团队以及对客户的义务。

新产品或现有产品的新版本，目的都是要为客户创造一个新世界。因为你无法事先知道这个新世界会是什么样子，所以你必须在产品开发过程中专注于学习和试验。团队必须从客户使用产品的经验中吸取教训，而不是单纯按预先安排的计划行事。而且，团队必须在整个产品开发过程中整合这些经验。每个人都认识到在流程的某一步骤或某一职能领域内作为个体工作所带来的局部流动、自主和控制的优势。然而，这样的工作结构使每个人（除了做最后一步的人）离最终用户更远，从而失去与最终用户进行互动才能获得的广泛洞察力。（从全局考虑问题）可能导致局部职能未必达到最优，但整个产品开发流程的优化程度会更高。

因此：每个Scrum团队应该包括交付“完成”的功能所需的所有人才。

在团队创建初期，关注技能的覆盖度是很好的，但更重要的是，团队成员要对愿景有共同的热情，并愿意学习新鲜事物。因为事情会随着时间的推移而变化，团队不可能从一开始就预见到所有的长期技能需求。

02如何培养跨职能团队

与其因为需要新的技能就去更换团队成员，不如在内部培养人才，并努力建立小而稳定的团队。随着时间的推移，对团队成员进行交叉培训，使他们的技能组合不断增长，以适应越来越多的能力领域（详见后续推出的Moderate Truck Number模式）。这将提高团队作为一个自主团队工作的能力。有了跨职能的团队，就更容易均匀分配工作（Scrum Pattern之一，将在单独的文章中介绍）。

团队成员现在有太多的机会去学习次级技能。比如他们可以在产品待办事项（PBI）上使用蜂拥模式，这样就可以增加学习的机会，优化流动，有助于功能快速达到“完成”的状态。次级技能的发展使团队更加灵活，因此如果有人不在，其他任何人都可以顶上来。这样团队总是可以取得进展，并且是自主的。

Scrum对如何处理能力缺失的问题没有提及，它相信这些都是常识可以搞定的 ：例如，向其他团队寻求帮助，或把大的工作外包出去，不过外包出去的工作结果就不好说了，有可能会让团队大吃一惊。如果团队偶尔需要这样的帮助，还是可以理解的。但如果团队发现他们经常要依赖外部的帮助，那么他们就应该把这看作是一种阻碍，并采取措施（如培训、重组或招聘）来补救这种情况。

例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于自己专业领域的产品，如制药或航空航天。我们很想在团队中为每个弱势能力指定一个负责人，也许可以咨询外部领域专家。然而，团队代表可能不知道他们有多少不知道的东西，甚至可能不知道该向领域专家提出什么问题；反过来，大多数领域专家把领域专业知识当做隐性知识（译者注：已经成为专家潜意识的一部分），所以他们可能也没有办法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会注意到他们觉得理所当然的事情，即隐性知识）。至关重要的是，团队成员要理解领域因素对实施的影响，并对业务和解决方案的空间都有全面的了解。在最近的一篇文章中，亚马逊的Jesse Watson指出，这两个因素"在一个头骨内"并存是至关重要的。[1] 最好是将专家带入团队，并通过交叉培训扩大知识面。但要记住保持小团队：向团队中增加专家可能会使团队合作减弱到几乎没有的地步。

这些团队自然会像 "特性团队（Feature Team）"（详见后续推出的康威定律模式）那样工作，因为大多数PBI都是以特性的形式存在的（Feature-Shaped）：产生收入的功能性产品增量中的可销售元素（marketable elements of revenue-generating functional product increment）。如果由跨职能团队来开发产品，那么交接动作自然会从价值流中消失：团队本身就可以开发任何特性，无需外部支持或干预。让多个团队参与进来，会造成反馈回路的延迟，增加返工的浪费（Muda），并在价值流的不同开发阶段之间产生不一致（Mura）。

《哈佛商业评论》（Harvard Business Review）发表了一项关于两家公司的研究，其中一家是按职能组织的，另一家是按产品组织的。研究表明，相比之下，跨职能团队交付特性的效果是最好的（见《组织选择：产品v.s.职能》[2] ）。

基于集合的设计（Set-Based Design，Scrum Pattern之一，将在单独的文章中介绍）是一种技术，它可以让开发人员参与到许多可能与业务相关的学科和领域中，即使这些学科和领域最终可能没有用在当前产品中。这种实践拓宽了团队和企业的专业知识基础，并且也让团队不会惊讶于需要掌握某些新学科。

随着团队整合新的经验，他们会对产品有新的想法。变化将会非常迅速（而且必须允许它迅速）。变化将是常态，而不是例外。这需要小规模的组织，因为在小规模的组织中，每个人都知道正在发生什么：这些组织能够拥抱变化、跨专业工作、定期交付价值，用一个词来形容就是：敏捷。

03一个游戏

组建几个小团队，在游戏中竞争制作和飞行纸飞机。每个团队成员一次只能做一个折叠动作，然后必须换到另一个飞机上。任何飞机都不得有超过15个折痕。它必须至少有15厘米长，8厘米宽。它必须有一个至少2厘米宽的钝头。要成为优质产品，测试员测试时，飞机必须水平飞行3米。测试员对每架飞机只能测试一次。

试试这个游戏，并应用Scrum Pattern（提示：蜂拥模式）来优化在一分钟长的Sprint中生产的优质飞机的数量。

你已经为Sprint做好了准备，现在你正在开Sprint计划会，进行迭代计划。

Sprint目标有多重要？

Sprint的目标是为利益相关者交付价值。然而，简单地按照一个SBI（Sprint Backlog Item，Sprint待办事项；例如：任务）清单来做，不一定就能创造出最大的价值。如果团队按照单个任务或交付物来制定工作计划，就很容易在生产阶段（Production Episode，Scrum Pattern之一，将在单独的文章中介绍）选择单个待办事项，孤立地进行工作。如果这样的话，创新就被稀释了，因为创新是由对工作持有不同视角的个体进行互动而产生的。当工作孤立进行时，就像无形的办公隔间，可能会阻碍大家持续交流各种见解（这些见解不仅对一个开发人员，而且对许多开发人员甚至对整个团队来说都很重要）。没有充分的互动和沟通，团队合作就会受到影响。

团队可能需要部分重新规划正在进行的Sprint，以确保团队在Sprint结束时可以向利益相关者交付价值。随着时间的推移，团队会对工作有新的见解，可能会识别出新的工作，这时团队应该对计划做出相应调整。如果团队还是按照原来的计划行事，可能就无法创造出最大的价值。还有一种常见的情况是，在Sprint中途，团队感觉明显无法完成Sprint Backlog中的每个SBI，这通常是由于完成SBI所需的工作比预想的要多。此时团队仍然希望尽一切所能交付价值，这可能就需要通过重新规划来实现。重新规划Sprint的工作需要深思熟虑，并且需要时间。

另一种情况是，团队需要关于“如何实现一个PBI（Product Backlog Item，产品待办事项）”的重要技术知识，以便之后能够更有信心地开发它。比如开发人员（甚至是产品负责人）可能需要一个技术原型来验证一个建议的架构，或者了解一些技术的性能特点。这样的工作我们也把它做成一个PBI，不过这一类PBI的目标是帮助团队获取更多的知识，而不是完成一项功能。这样的技术原型是一种探索性的工作，耗时存在不确定性，因此它往往会处于Sprint成功的关键路径上，即它的完成与否关系到Sprint目标是否能够达成。（译者注：这样的PBI，我们称之为Spike，即探针。）

在某些情况下，最大的价值可能不是简单地实现一个PBI。例如，对团队来说，最大的价值是增加每个Sprint所能带来的经济收入，而团队只是用一个PBI来实现这个价值。另一方面，有时Sprint的大部分价值主要来自于很多PBI中的一个关键PBI。

因此：
Scrum团队为Sprint期间所要创造的价值书写了简短的声明（译者注：即Sprint目标），并对其做出承诺。这将成为Sprint中所有工作的重点。

整个Scrum团队共同创建Sprint目标。产品负责人自然会指导Sprint目标的创建，因为他或她对实现产品愿景的下一步以及如何能够创造出最大价值最有发言权。Scrum团队应该把Sprint目标当做总是能够触手可及的事物一样做出承诺。（译者注：最后这一句的原文是“The Scrum team should commit to the Sprint goal as something always within reach.”因为这一句关系到对Sprint目标的准确理解，因此标注原文以便对照参考。）

开发团队每个Sprint通过构建产品增量来实现Sprint目标。

Sprint目标怎么用？

Scrum团队可以依据Sprint目标来为Sprint选择PBI，但从某种意义上说，Sprint目标甚至比单个PBI的总和更重要。Sprint目标在PBI之间建立连贯性（译者注：而不是一堆散落的PBI），这有助于创造有价值的产品增量。一个初始化Product Backlog的好方法是就是将其表达为包含许多Sprint目标的列表，由产品负责人和开发团队一起随着时间的推移将其渐渐细化为PBIs。

自主团队的成员必须能够自我管理，以完成他们的目标，而由开发人员进行排序的工作计划（Developer-Ordered Work Plan，Scrum Pattern之一，将在单独的文章中介绍）指出，开发团队必须能够自由地以他们认为合适的方式安排他们生产阶段的工作。Sprint目标是产品负责人用于影响开发团队潜在工作顺序的唯一机制（通过Sprint目标所传达的重要性来推断紧迫性）– 当然，只有在得到开发人员同意后才可以。

在Sprint计划会期间，Scrum团队确定他们希望在Sprint结束时实现的目标；简而言之，这就是Sprint目标存在的意义。开发团队使用Sprint Backlog来定义如何完成这个Sprint目标的细节。如果开发团队认为他们不能完成Sprint目标，就应该和产品负责人一起对Sprint目标再次斟酌。Sprint计划会的一个关键产出就是，开发团队应该能够解释如何完成Sprint目标，以及如何知道自己已经实现了这个目标。解释的能力来自于对未来工作的透彻理解，这就提高了团队在Sprint中实现Sprint目标的概率。

开发团队对Sprint目标做出承诺。这个Sprint目标可以帮助开发团队众志成城，并有助于建立利益相关者对团队的信任。

Sprint目标对团队应该是可见的；例如，把它放在Scrum 板或其他信息雷达上。

为支持Sprint目标的实现，在Sprint期间，开发团队要确保Sprint Backlog一直反映最新的工作状况。Sprint Backlog的进展（比如在Sprint 燃尽图上显示的）就像Sprint期间足球场上的进展一样：虽然每一码的进展都会使球更接近终点，但价值是在球门上（译者注：球门和目标的英文是相同的，都是“Goal”，一语双关！）。有时也有可能在没有完成所有SBI的情况下完成Sprint目标（以某种方式）。这有助于团队处理突发事件，并使开发人员在每日Scrum会中灵活地改变他们的工作计划（译者注：在目标不变的前提下）。举个例子：突发的阻碍会威胁到开发团队交付完整的Sprint Backlog。在这种情况下，团队会自动采用Sprint目标作为 "B计划"，而不需要花费很长的时间重新规划。卡耐基梅隆大学[1]的一项研究报告指出，提前为中断做准备的团队比没有提前准备的团队要好14%。为中断做准备的团队比不做准备的团队完成一个不间断的任务间隔要快43%。这是一种为计划外的事情做准备的心态：当它们发生时，团队可以转到一个新的配置来处理它们，不需要外部辅导。

理论上，在每个Sprint只完成一小部分PBI的情况下，一次又一次地实现Sprint目标也是可能的。不过，这应该是不常见的，因为Sprint Backlog应该与Sprint目标一致；如果不是，就说明价值流存在严重问题。

速率（Velocity）能够帮助团队了解他们是否在正确地做事（我们假设正确地做事速率就会提升）。Sprint目标帮助团队确保他们在做正确的事情。它是关于理解团队正在做的事情的 "Why"，以便在事情发生变化时能够保持专注。

Sprint目标还有其他功效？

杰夫.萨瑟兰（Jeff Sutherland）补充说，除了让团队保持专注外，Sprint目标还会促进蜂拥模式（Swarming，Scrum Pattern之一，将在单独的文章中介绍）的使用。我们能不能让大家一起做一件事？他说道：

2007年在硅谷，Palm正在开发一个网络操作系统，后来被惠普公司收购。前几个Sprint，团队做得很好，但在几个Sprint之后，他们似乎遇到了困难。PBIs没有完成。开发人员的积极性很低，而且很早就回家了。他们请我来，我请产品负责人和Scrum Master花了一个小时来采访团队成员，了解他们为什么没有积极性。我们发现，原因是他们不理解做的这些低层级的PBI要解决什么问题。

我们花了一个下午的时间来清理Product Backlog，清晰地展示出了高层级故事和分解出来的较低层级故事之间的联系。当开发人员了解到Sprint的目标是将网络操作系统的性能提高10%时，他们就有动力去完成低层级的故事，速度也恢复了正常。

理解为什么要实现PBI，对开发人员来说至关重要，特别是对专家级的开发人员来说，如果他们找不到自己工作的理由，就会宁愿去冲浪。

Sprint目标通常与产品价值有关。团队也可以用过程目标来定义Sprint目标 — 例如，通过结对编程来完成所有的编程，或者准时参加每日Scrum会。反复推动Sprint目标的实现，可以激励团队达到更高的参与度；反过来，幸福指数可以成为定义或建议Sprint目标的一个有效工具。

Sprint目标的作者是谁？

2001年，Ken Schwaber和Mike Beedle第一次提出了Sprint目标的概念（[2]，第48页）。

[1] Bob Sullivan and Hugh Thompson. Gray Matter. “Brain, Interrupted.” In New York Times, 5 May 2013, page SR12, http://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html (accessed 2 November 2017).[2] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 48.

我们假定Scrum团队已经相聚在一起，准备开始或已经开始了Sprint。这时，开发人员已经创建了一个Sprint Backlog，并正在努力实现Sprint目标。然而，用德国陆军元帅赫尔穆特.冯.毛奇的话说，“除了与主要敌对势力的第一次接触之外，没有任何行动计划是确定无疑的。”简而言之就是，在Sprint计划会中制定的计划几乎立刻就过时了。

问题

团队在Sprint中取得进展，是通过完成Sprint Backlog中的条目达成的，但是因为工作很复杂，所以任务的特征、大小和数量经常会发生变化——甚至有时每分钟都在变化。

例如，替代解决方案、需要但未知的知识、隐藏的任务、误解的需求、需要进一步细化的需求、开发人员之间的依赖关系，或者以阻塞形式出现的问题可能会在团队的日常工作中不断浮现出来。问题是如何有效地处理这些问题。

有9乘以10的157次方种方法可以给100项任务排序，但其中只有少数几种方法可以使团队“处于工作轻松、速率显著提高的区域”。由于工作性质的变化，团队需要每天至少对工作进行一次新的排序，以超越平庸。

除了工作之外，团队成员缺勤（如病假）可能会迫使团队重新考虑其工作计划。

另一方面，过多的重新规划和重新估算会浪费时间，让开发人员窒息。但太少的重新规划和重新估算会导致阻塞，导致计划延误或过时，不能体现实际情况。

个人可以很快做出决策，但在团队环境中，个人不可能孤立地做出决策。你需要与每个可能受决策影响的人接触。与相关方取得一致需要时间。

个人可能需要把问题提给整个团队。但可能很难找到这样做的机会。特别是，在团队解决问题之前，这些问题仍然是阻碍。

解决方案

因此：

每天有一个简短的活动来重新规划Sprint，以优化1. 达到冲刺目标的机会，2. 完成所有Sprint Backlog条目的机会。严格遵守时间盒，以确保专注于当日计划，避免剥夺开发人员的宝贵时间。专注于接下来一天的工作，但同时也要对Sprint的剩余工作心中有数。

将会议时间限制在15分钟以内。团队按照自己的时间盒管理自己，如果需要，Scrum Master将强制执行流程的这一方面。许多团队在会议期间站立以强调会议的短暂性。团队可以在之后继续处理每日Scrum会中的未尽事宜，但每天此会议如果花15分钟以上来做重新规划，就说明需要持续改善（Kaizen）或突破性改善（Kaikaku）。

每个开发人员都必须参加，这一点至关重要。在开发人员因疾病或冲突而缺席的罕见情况下，找其他人顶替参加可能没有意义，因为最晚他会在下一次每日Scrum会上获得最新信息。

为了制定计划，你必须知道自己在哪里，以及有哪些问题在阻碍你。你需要知道全局。一种受欢迎技巧是让每个开发人员回答以下三个问题：

昨天我做了什么帮助团队实现Sprint目标？

今天我将如何帮助团队实现Sprint目标？

我是否看到任何阻碍我或团队实现Sprint目标的阻碍？

请注意，当开发人员提出阻碍时，大家可能很自然会想要去深入研究这些阻碍并探索可能的解决方案。但这次会议是为了重新规划和决策，而不是为了解决问题。相反，一些开发人员可能会同意在白天聚在一起制定解决方案，这样就不会浪费其他人的时间。他们将在第二天的每日Scrum会上报告他们所做的事情。

当然，这些阻碍往往会需要对计划做出改变。因此，团队对当天的计划做出调整，以疏通阻碍。这是这次会议的重点之一。

这是开发人员的会议。在开发人员的邀请下，开发人员以外的人员可以参加每日Scrum会。开发人员可能会认为Scrum有一种透明的精神。但另一方面，局外人的存在可能会影响会议。在任何情况下，只有开发人员才需要高度参与此会议。本段叙述适用于产品负责人以及任何其他非开发人员。

Scrum Master可以随时参加会议，特别是在组织中Scrum的早期，主要是为了确保大家遵守时间盒以及流程的其他方面。但是在这些会议上，很多开发人员往往会将Scrum Master视为经理。为了避免此情况带来的负面作用，Scrum Master最好不要参加这个会，或者在出席会议时扮演一个隐身Scrum Master的角色。

每日Scrum会导致Sprint Backlog以及相关的信息雷达做出更新。然而，理解每日Scrum会是一个重新规划的会议而不是状态会议是至关重要的。信息雷达上的信息是会议的副产品，而不是会议的目的。

进一步说明

每日Scrum会的精神是对现实的检验：我们会实现Sprint目标吗？每日Scrum会的结果是基于现实的新的每日计划，该会议还有助于培养更易于合作的团队，该团队对他们一起做的事情有更好的共同愿景和理解。团队能够更好地适应其工作中遇到的各种阻碍。

每日Scrum会这一仪式有助于团队成员产生团队认同感。它将他们聚集在一起，重新关注他们的共同目标和共同身份。它增强了团队士气。在某种程度上，它是早期发布的模式的每日版本，早期发布的模式建议团队成员在深入研究工作任务之前，首先协调桌面上的广泛问题：在远程工作之前进行面对面交流。

每日Scrum会还有其他好处：

减少浪费的时间，因为团队每天都能看到阻碍；

帮助寻找协调的机会，因为每个人都知道其他人在做什么；

强化对Sprint目标的共同愿景；

通过确保每天至少一次整体互动，促进团队团结；

促进知识共享和识别知识差距；

增强整体紧迫感；

通过可验证的每日状态，鼓励开发者之间的信任和诚实；以及，

通过共享的仪式以及鼓励大家积极参与，来加强团队的文化。

历史

“站立会议”一词有着悠久的传统，据报道在英国维多利亚女王出席的活动中使用：在女王面前必须站着。Scrum实践源于Coplien对Borland Quattro Pro for Windows（QPW）项目的分析（[1]），该项目在快速产生价值和质量方面有着卓越的记录。Bob Warfield当时正在运作该项目，并提供了以下反思：

这是我们生产力的一个关键部分，今天它是敏捷/Scrum的基石，在这里它被称为“Standing”会议或“Stand Up”会议。显然，有些人按照字面意思理解，开始在没有椅子的情况下开会。那很好，我想我会在会议上保留椅子，但我会让会议足够短，没有椅子应该不是问题。我曾经告诉人们要让他们准时出席会议，椅子的数目会比与会者少两个，但那只是我的蹩脚笑话，我不记得我曾经真的那样做过。

第一个Scrum团队根据QPW计划于1994年2月实施了每日会议。Scrum团队得出结论，在Borland召开的每日会议有助于实现非凡的绩效。Scrum团队在其第二个月度Sprint期间实施了每日会议。1994年3月，团队在Sprint中投入的工作量与上个月相同，并且在第一周就完成了。从那时起，有效的每日会议大大提高了整体Scrum团队的速度。

敲黑板

最后需要指出的是：外行经常将“做Scrum”等同于每日Scrum会。虽然在Scrum板旁边开的每日Scrum会是Scrum组织中最引人注目的事件之一，但是Scrum远不止这些，我们不能说用一套工具就是Scrum了。打个比方，在公园里踢足球看起来很像踢足球，但它不是足球。在这个模式的讲解中，引用了许多代表Scrum框架关键组件的其他模式，但这些模式也只是一个起点。

这种模式是先前发布的站立会议的演进。

[1] 詹姆斯·科普连和乔恩·埃里克森。“检查软件开发过程”，《Dobbs博士软件工具杂志》19（11），1994年10月，第88-97页。

[2] 鲍勃·沃菲尔德。“20年前我是如何帮助启动敏捷/Scrum运动的。”Smoothspan博客，2014年10月2日，https://smoothspan.com/2014/10/02/how-i-helped-start-the-agilescrum-movement-20-years-ago/ （2019年2月14日查阅）。（文章来源：徐东伟敏捷教练）