Scrum Patterns 之理解各种团队模式

在平时学习和交流敏捷相关的知识和经验的时候，经常会听到各种团队的称呼，例如：Self-Organizing Team(自组织团队)，Autonomous Team(自治团队)，Development Team(研发团队)，Scrum Team(Scrum 团队)，Cross-Functional Team(跨职能团队)，Stable Teams(稳定团队)，Collocated Team(同置团队)，Small Teams(小团队)。是不是种类繁多而且都听过？那他们说的是相似的定义吗？还是有一些区别？我们要如何理解他们呢？幸好 Jeff 老爷子的 Scrum Patterns 对这些定义都有详细的介绍。今天就分享一下我的学习心得。欢迎大家互相交流。

因为涉及到 8 个模式的说明篇幅会很长，所以先大概总结一下我个人的理解。想了解更细节的小伙伴可以阅读下面的详细模式介绍。从 High Level 的角度我喜欢把这 8 个模式分类 3 个不同视角：

• 团队行为方面的：自组织团队，自制团队，研发团队。

• 团队构成方面的：Scrum 团队，跨职能团队。

• 团队属性方面：同置的团队，小团队，稳定团队。

简单概述一下这 8 个团队模式的定义：

• Self-Organizing Team(自组织团队)是从组织层面来看，组织中的任何团队最好是自组织的，而不是命令控制型团队，这样才能更高效的工作。自组织团队并不只是说 Scrum 团队。而是组织中的各种团队。

• Autonomous Team(自治团队)是针对团队以及个人层面来说自治的重要性。团队自治需要的是每个成员的个人先自治。自治不代表封闭，团队需要对内做决定，对外积极接收信息，响应变化。

• Development Team(研发团队)着重聊了个人和团队的关系，为什么需要团队，团队需要什么样的构成，理想的团队大小等。这里的团队并不限制在 Scrum 范畴。对于一个好的研发团队来说，最好的目标是一个自治团队，更是一个自组织团队。

• Scrum Team(Scrum 团队)和上面几个团队说明侧重点不同，研发团队定义了如何能把事情做好。而产出是否更有价值不仅仅需要研发团队， 还需要有业务方的加入。同时团队保持持续改进也需要有教练的支持。Scrum 团队就是在 Scrum 的框架内，一个理想的团队是什么样的。所以最新版的《Scrum 指南》指出，Scrum 团队不仅能够决定自己如何工作，也能够决定做什么。它同时呼应了自组织团队，自治团队，研发团队。

• Cross-Functional Team(跨职能团队)团队如何应对不断增加的技能需求，持续满足变化。如何能够跨职能，团队自我造血和依赖外部团队会有哪些不同？这个模式都会将意义解释清楚。

• Stable Teams(稳定团队)这种模式有助于团队成长，并随着时间的推移分享其专业知识，以减少失去团队成员的风险。一个稳定的团队会建立一种集体认同感，这种认同感可以作为对产品和对团队归属感的共同自豪感的基础。

• Collocated Team(同置的团队)这个模式讲的是团队内沟通和距离的关系。强调就算有很多技术拉近人与人之间的沟通距离，也无法取代物理位置的优势。就像艾伦曲线显示的那样，能在同一个屋子强于同一层楼，好于同一栋楼，优于同一个城市，至少也要保证同一个时区内吧。

• Small Teams(小团队)这个模式说的是为什么一个小团队是优选，例如：7+-2 的规模。从团队稳定，沟通效率等多方面来说明。

下面是详细的模式介绍（内容略长，请收拾心情慢慢阅读:)）：

Self-Organizing Team(自组织团队)

原因为了减少复杂性和不可控性，组织会对结构和过程进行标准化。这些最佳实践可能是通过采用最佳实践或通过组织文化的历史发展出来的。但是现实世界唯一不变的就是变化。所以这些最佳实践也会随着时间的推移、技术的改进而带来周围环境的变化。从而最佳实践不再最佳。但是公司固化下来的制度和流程却让很多组织故步不前。其实可以看到参与具体工作的人是最了解当前工作上下文，并能够最有效的提出正确的改进方案的。但是如果他的领导是一个外行，或者并不是很熟悉这个工作，那么很可能这些改进方案不会被提出来或者被通过。现实生活中我们可以发现在一个层级制很强的企业中，一个部门的能力上限往往取决于他的直属领导而不是团队中成员的能力。另一方面，开发团队成员通常具有专门的技能;利用他们的差异来有效地工作是有益的。但是，如果每个人都只在自己的专长范围内工作，任务可能会延迟，而不是更平均地分配和完成。模式因为上面的原因，所以开发团队其实是工作领域最熟悉的人，他们是最知道该如何让工作做的更好的一群人，同时也是知道彼此如何合作的一群人。而这一切行为的背后总结就是“自组织”的含义。 一个自组织团队可以自我修复，它可以看到自己的错误并有能力修复它们。这是 Scrum 组织需要掌握的最重要的模式之一。团队因为获得了自由和相应的责任。他们会开始对如何构建产品有自己发言权，同时会对自己和产品更加自豪。注意：

• 自组织不代表随意，他是需要成熟度和纪律来支撑的。同时，并不是所有人都喜欢自组织。

• 移除一个明确的监督角色的潜在风险是，团队中的另一个人可能会填补这个角色，要避免这种情况的发生。

简单描述自组织团队的定义可以说：按照自治团队运行的研发团队就是自组织团队。自制团队和研发团队的定义请继续看下面的解释。

Autonomous Team(自治团队)

原因一个新的团队开始 Scrum 的工作方式，或者一个现有的团队开始采用 Scrum 工作。在任何一种情况下，团队都必须先明确如何一起工作。 此时企业的一些流程或者规定，可能并不适用于所有的情况。不同的团队有不同的人员和其独特行为。而且，一个具有特定职责和完成任务所必需的专业知识的团队知道如何最好地着手去做。干系人在 Scrum 项目的成功中拥有既得利益。因此，想要对开发工作有一些控制是很自然的。因为这样会让他们感到更安全。然而，开发团队之外的干系人很可能不知道开发工作的细节，所以他们想要的策略和流程可能不适合团队的需要，可能会起到反作用。最后，企业本身可能会有一些已存在的“最佳实践”来指导团队工作，然而，一个团队的最佳实践未必适合另一个团队。

模式一般来说 Scrum 团队的决策不受外部控制，虽然它是一个关注外部的开放系统，但团队根据其对价值的追求制定自己的方向，而没有受到不当的外部影响。自治包括建立自己的文化，包括任何行为规范和奖励系统。它还包括团队如何开展工作。但是这并不意味着开发团队有权简单地做它想做的任何事情。

注意在自治团队中，一个可能的危险信号是团队可能对自己的弱点视而不见。因此，让 ScrumMaster 与自治团队一起工作，给他们提供反馈，传递团队外部的反馈，并让他们对来自其他来源的反馈保持开放的态度。

总之，当人们拥有自主权时，他们通常会更加积极主动。当成功时，这就建立了一个良性循环。所以在高效的组织中，自治团队这是一个重要的成功因素。同时可以延伸到成员本身的个人自治。

Development Team(研发团队)

原因许多伟大的努力不能仅靠个人的努力就取得卓越；生产中最大的力量来自团队合作。伟大的个人可以创造伟大的产品，但从一个人开始会让以后的发展变得困难。在大约 6 个月的时间里，每个新人的加入都会使团队中其他成员的效率降低 25% (James Coplien 的经验法则)。 另一方面，在一个过于庞大的群体中很难形成一致的方向，所谓的人多误事。由少数人组成的开发团队最终可以达成共识，但通常只有经过长时间的相互商议才能做到这一点。在一个反应灵敏的行业这样的延误是不能容忍的。

模式这里推荐的研发团队规模是由大约 5 个配置的个人组成的，他们致力于为一个共同的目标而相互协作。团队是自治的：自我选择、自我组织和自我管理。给每个人一个集体的身份来实现产品负责人的愿景。产品负责人可以告诉他们：“这是你的产品——做吧。” 这样每个人都建立了一个与产品愿景相联系的新身份，同时尊重彼此的身份。它不是关于扩大个人潜力来提高生产力到某个生产水平，而是要改变发展的范式，形成集体思维，形成一个比个人总和更能实现目标的整体。Scrum 避免了团队内部或跨团队的任何依赖导致无法自治，每个交付品的所有工作都在一个开发团队中进行。这意味着，没有单独的测试团队，也没有单独的团队来将开发与维护方面联系起来。

总之，一个研发团队应该同心协力，专注于共同的目标，并围绕着单个的开发增量聚集在一起，而不是单独地“在自己的岗位上投入时间”。

Scrum Team(Scrum 团队)

原因许多伟大的愿景是单人努力所无法实现的，为了实现这样的愿景，你需要创造复杂的产品，并将其推向市场。另外如果没有专业化知识，只有一些好的想法，仍然无法交付一个好的产品。另外一点，业务人员和开发的工作节奏是不同的，有各自专注于自己最擅长的工作。好的一面是，在开发准备交付产品的同时，这给了业务人员从事其他工作的自由。但是糟糕的是，如果业务将产品交付的责任转移到一个独立的开发组织，就会发生交接。而交接的结果可能目标从一个业务产品转变成了一个截止日期。由于业务和开发是分离的，所以截止日期可能是任意的，交付的内容也可能无法满足预期了。最后，与整个产品的关注点分离会让工作变得没有意义，并剥夺人们对愿景的主人翁感，或者让他们无法认同产品的目的。当拥有不同专业知识和观点的人在开发过程中一起工作时，学习甚至会更加有效。专注于产品开发活动的人往往没有多少时间去思考如何改进。

模式所以，Scrum 团队是一种模式，他希望组建一个具备所有必要能力的团队：能够制作和交付产品的人(研发团队)，指导产品方向的产品负责人，以及促进学习的 ScrumMaster。这里呼应了前一个模式——研发团队。但强调了只有研发团队是无法做出卓越产品的，如果要打造一个卓越的学习型团队，还需要结合业务方以及团队教练持续。

Cross-Functional Team(跨职能团队)

原因如果一个 Scrum 团队不能自主工作，也就是说他们不具备完成复杂任务所需的所有技能，而需要依赖于团队外部人员的技能，团队无法拥有完成任务的掌控权。这种情况减少了团队对完成时间的响应，并可能影响最终结果的产出质量。很难在一个团队的成员身上发现所有所需天赋，更不用说在某个特定的个体身上了。所以组织中的团队经常围绕能力区域组织结构：物以类聚，人以群分。所以这种组织被称为职能性组织。然而，跨团队边界协调这些功能是昂贵的，因为有效的沟通发生在共享当前工作上下文的人之间——通常是团队成员，而非不同团队之间。专业化、本地实践和过程都可以是组织中效率的来源，但也可能是组织边界产生的源泉。

模式所以，这个模式说明的就是：每个 Scrum 团队都应该包括交付完成功能所需的所有人才。而且要认识到在最初创建团队时，关注技能集覆盖范围是好的，但更重要的是，给予团队学习的时间。因为事情会随着时间而改变，团队不太可能从一开始就能预见到所有的长期技能需求。当新技能需求出现时，不要替换团队成员，而是在内部培养员工(团队成员现在有学习第二技能的学习机会)，随着时间的推移，交叉培训团队成员，使他们的技能集增长，以适应越来越多的能力领域。这种团队才更可能自治，平均分配工作也会变得更容易。

Stable Teams(稳定团队)

原因干系人最喜欢能够及时满足他们期望的团队，因此团队会希望自己的预测更加准确，这样就能更好的实现对干系人的承诺。在传统项目管理中，一直都有将人与人力资源混淆的倾向。它导致了“资源管理”，将需求与每个团队的能力(或者，每个团队成员的能力)结合起来，以完成交付。这也常常导致在项目开始时，人员从一个团队转移到另一个团队，或者在交付过程中，从一个危机转移到另一个危机，这导致了一个不稳定的环境，同时增加了成本:

• 管理部门跟踪人们在做什么。

• 效率降低，因为团队需要整合一个新成员，新成员需要了解团队及其产品，

• 接触布鲁克斯法则(“向一个已经延迟的软件项目增加人力会使它更加延迟”)

基于这些因素,团队一直希望能够处理不变的需求，以便应对我们不断变化的资源能够在可预测的时间内交付。不过锁定我们产品的需求会阻碍我们学习，并且忽略可以创造最大价值的产品变化，所以这不是一个好的解决方案。

模式保持团队稳定，避免在团队之间调动人员。稳定的团队倾向于了解他们自己的能力，这使得业务具有一些可预测性成为可能。尽可能将团队成员奉献给一个团队。稳定团队的成员互相了解。团队成员体验彼此的工作风格，并了解他们可以一起做多少工作。一个稳定的团队在满足相互期望的熟悉和一致性中成长，并开始发展成为一个可信任的社区。如果只在一起工作很短一段时间的人可能不会投入太多精力来改善他们的工作流程或彼此之间的社交互动，因为几个月(或更少)后，他们就会和其他人一起工作。而另一方面，如果人们知道他们会在同一个同事身边待更长的时间，他们就更有可能投入精力去创造一个愉快的团队环境，改善他们的工作流程。组织层面如果可以用灵活的工作分配取代了将人员从一个团队转移到另一个团对的“灵活性”。那么团队更容易根据他们当前的能力来承担工作，这反过来导致了更准确的预测。从而降低了成本。

Collocated Team(同置的团队)

原因复杂的协作开发，如知识工作，需要高质量的沟通才能有效。很难预测成功所必需的这种交流的时间、频率和持续时间。我们试图通过预订会议空间来弥补。但是似乎所有建筑中的会议空间的数量都没有经过设计，导致在一起的时间增加了开销。其结果是使人们不努力去见面，从而减少了人际交往。人们经常求助于低保真度的通讯方式——即时通讯、电子邮件、电话、传真等。沟通不仅仅依赖于发送和接收消息:接收者还必须理解消息。一个丰富的沟通渠道支持人际沟通的细微差别，包括语言和非语言属性。当消息对发送者和接收者来说都是“新鲜的”时，必须有快速的反馈来确认理解。非语言交流对于”表达情感，沟通人际关系，支持语言交流”很重要。1977 年的艾伦曲线显示，当人们相距 10 米时，他们每周至少交流一次的概率小于 10%。艾伦说，尽管最近通信技术有了发展，但这方面并没有改善。例如办公室不再只是一个物理场所；我们可以在任何地方参加会议，在文件上进行协作而不需要见对方。这些似乎缩短距离的技术感觉会打破艾伦曲线，沟通不再与距离相关。但事实并非如此。艾伦曲线仍然成立。事实上，共用一间实体办公室的工程师与在其他地方工作的工程师保持联系的可能性要高出 20%。当他们需要密切合作时，同一地点的同事发送电子邮件的频率是不同地点的同事的 4 倍，这使得项目完成时间快了 32%。

模式把团队成员安排在一起，最好是在同一个房间里，甚至在可以交谈的距离内。Alistair Cockburn 建议整个团队坐在一辆校车的长度内。允许人们在一起工作时轻松地进行特别的对话。人们定期、快速地分享信息。员工们还可以随意地谈论工作以外的话题，从而增强团队凝聚力。对于喜欢拥有大型团队或认为必须拥有大型团队的组织来说，在同一个位置这个要求可能是非常困难的。让员工迁移地点可能会缺乏空间或有很大的迁移成本。对于组织来说，这将是一个重要的决定。参考小团队模式、跨职能团队模式和康威定律。沟通是一个社交过程，当技术限制了沟通的自然性时，沟通就会变得不那么有效。这往往证实了电话会议和视频会议在有效沟通方面的不足。很容易溜号、不关注、或者参与度很低。同置团队除了能够促成高效的沟通外，还可以给团队带来更多的自豪感和自尊，因为更有团队的意识，更有归属感。

Small Teams(小团队)

原因有时候当团队在组织中的地位与团队规模成正比时，大型团队可能会成为组织政治的一部分。在一起工作的人越多，沟通的开销就越大。 良好的沟通对于有效的团队合作至关重要。 但是，随着群体的增长，群体内部传递的信息也相应减少，但随着人数的增加，需要传递的信息也相应增加。在极端情况下，沟通和协调开销几乎消耗了团队的所有资源，几乎没有时间做有成效的工作。另外随着人数的增加，每个人的相对贡献都会减少。这可能会产生不可忽视的动机效应，因为随着团队规模的增加，搭便车和社交偷懒会增加(个人在团队中的贡献比他们自己的贡献少)。结果可能是大的团队产生的结果少于小团队，或者大的团队产出的质量低于小团队。因此，当有很多人一起工作时，更需要协调这些人。在这种情况下，团队会增加越来越多的角色来支持协调工作，而这些角色并没有增加价值，反而降低了团队的生产力（一个团队中这样的角色数量就是 Wally (Wally 是斯科特·亚当在《呆伯特》中扮演的角色)。

克里斯托弗·亚历山大(Christopher Alexander)引用了一项研究，该研究表明，沟通效率随着群体规模的增加而下降。在他的模式中，“小会议室”，他指出，在会议中，“一个 12 个人的小组，会有一个人从来不说话。“在 24 人的小组中，有 6 人从不说话”。

模式在小团队中工作的人对团队和团队目标有更强的依恋感，在团队中有更好的沟通，有更多的机会被倾听，通常也更有生产力。小团队有助于克服消极的团队效应，如社交偷懒和过程损失，同时促进更积极的效应，如科勒效应(激励自己不要成为团队中表现最差的成员)。 较大的团队（统计上）比较小的团队经历的流失更多，因此，团队越大，其成员随时间推移稳定的可能性就越小。 因此，小型团队更有利于团队的稳定。所以如果团队开始变得太大，请考虑有丝分裂吧。

总结

团队模式的定义虽然多，但是其本质都是在描述如何构建一个健康的团队，从不同的视角可以更全面让你清楚一个理想团队的全貌。希望这些总结对你如何构建自己的理想团队有帮助。

践行敏捷实践，让工作变得更美好。欢迎关注我的公众号，交流落地经验。

原文引用

• Self-Organizing Team**
  

• Autonomous Team**
  

• Development Team**
  

• Scrum Team**
  

• Cross-Functional Team**
  

• Stable Teams**
  

• Collocated Team**
  

• Small Teams**
  

【欢迎关注我的博客】