Scrum Patterns: 小团队 (译)

关注

发布于: 2021 年 04 月 13 日

Bruce 有话说

为什么敏捷团队需要是小团队，当然大型敏捷团队是由众多敏捷小团队组合起来的，这里暂且不提，这属于规模化敏捷的范畴。单单讲敏捷团队的大小，为什么需要小而不是大？为什么大型团队却反倒效率不高？1+1<2？协作效率是复杂产品开发好坏的重要因素之一，大团队的主要浪费在哪里？什么是科勒效应？今天这篇文章将带给我们深入的见解，让我们能了解这背后的原因。

正文

每个周一早上，我们那位有 5000 名员工的公司 CEO 都会发一封电子邮件，开头写着“你好，团队”。可我们都知道我们不是一个团队。

复杂的产品开发是一项协作活动，需要人们一起工作来构建它。当人们带着一个共同的目标一起工作时，优化工作的最佳方式就是大家作为一个团队一起工作。

随着干系人对需求的逐步清晰，产品愿景逐步涌现，同时追求它的能量聚集起来。

✥ ✥ ✥

当有大量工作要做时，你很容易将全世界抛在脑后。但是复杂的工作需要高度的知识共享和协作，例如产品设计和开发。

让多人从事困难的工作有明显的好处。有了许多眼睛和声音，团队可以避免单独工作时可能出现的偏见。每个人都可以从探索复杂的新领域的过程中获得第一手经验。这会让一大群人一起工作。这样的团队往往会吸引专家，这会让团队得到成长。

截止日期可能会促使你分配尽可能多的人来同时完成工作。但是，除非将工作分解为独立的部分，否则节省的时间将被通信和协调开销所消耗。

当团队在组织中的地位与团队规模成正比时，大型团队可能会成为组织政治的一部分。

多人在一个大团队里一起工作意味着几乎没有内部小团队分工。人们很容易认为，拥有大型团队可以减少拥有众多小团队所带来的麻烦。但其实没有所谓的大团队优势。大型组织自组织成可以完成任务的小(子)团队。你可能会认为拥有一个大团队很容易，但最终你还是会拥有一堆较小的团队。那么，为什么不从一群人自然进化到一种工作良好的结构呢？

不幸的是，一大群人一起工作在相互依赖的任务上会导致意想不到的问题。

在一起工作的人越多，沟通的开销就越大。良好的沟通对于有效的团队合作至关重要。但是，这种开销会对通信质量产生不利影响。随着群体的增长，群体内部传递的信息也相应减少，但随着人数的增加，需要传递的信息也相应增加。在极端情况下，沟通和协调开销几乎消耗了团队的所有资源，几乎没有时间做有成效的工作。这就像在计算机中被称为“thrashing”的问题，大量的能量被消耗，但实际上没有完成任何事情。或者，组织可以指定沟通交换所，例如管理角色、决策论坛和委员会，这些都是组织结构的形式。不过这些额外的通信链路会造成通信瓶颈，损害通信保真度或两者兼而有之。

随着人数的增加，每个人的相对贡献都会减少。这可能会产生不可忽视的动机效应，因为随着团队规模的增加，搭便车和社交偷懒会增加(个人在团队中的贡献比他们自己的贡献少)。结果可能是大的团队产生的结果少于小团队，或者大的团队产出的质量低于小团队。

当有很多人一起工作时，更需要协调这些人。这种协调工作称为过程损失。正如斯坦纳（Steiner）在 1972 年所描述的，团队的实际生产率是潜在生产率减去过程损失（[2]）。随着团队规模的扩大，过程损失也随之增加，随着团队规模的增加，有效地限制了生产力的增长。在这种情况下，团队会增加越来越多的角色来支持协调工作，而这些角色并没有增加价值，反而降低了团队的生产力（一个团队中这样的角色数量就是 Wally (Wally 是斯科特·亚当在《呆伯特》中扮演的角色)

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

尽管有合理的推定力量会导致拥有更大的团队，但这些大批人员仍面临重大问题。

因此:

使用小型团队来进行一系列的工作，而不是努力争取错误的并行性。

一个 Scrum 团队大约有 5 个人左右。他们需要适当的专业知识和协作能力，这可以形成一个跨职能团队。

在小团队中工作的人对团队和团队目标有更强的依恋感，在团队中有更好的沟通，有更多的机会被倾听，通常也更有生产力。小团队有助于克服消极的团队效应，如社交偷懒和过程损失，同时促进更积极的效应，如科勒效应(激励自己不要成为团队中表现最差的成员)。

✥ ✥ ✥

在跨职能的小型团队中，确定谁需要在团队中创建产品增量可能是具有挑战性的。尝试使用团队自选，而不是用其额外角色(例如经理)，来解决此问题。当团队规模开始增长时，就有机会深入地探索增长试图要解决的组织问题。例如，过于复杂的体系结构可能导致一个团队需要依赖于许多专家的共同努力，才能完成产品增量。解决这些问题是一个很好的方向是想办法在保持团队规模较小的同时仍能够交付产品增量。产品和过程都可以从这种整洁中受益。

大量的研究表明，在多个维度上，小团队比大团队更有效，并且人们更喜欢小团队而不是更大的组织。 1958 年，Slater 的研究参与者更倾向于由五个人组成的团队，而不是更大的团队（[2]，第 86 页）。团队成员发现，较大的团队协调性较低，更难以分享想法，并且在利用团队成员的时间方面效率不高。较小团队的成员（2 至 4 个成员）也更喜欢以 5 人为一组，这表明人们偏爱小型团队。 1992 年 Kameda 等人进行的研究表明，随着团队规模的扩大，绩效会提高，然后在超过特定数量时才降低绩效。实验使用了两个，四个，六个和十二个人的团队规模。结论是，一个四人团队中成员的表现最高（[3]）。在有关软件开发的最新研究中，发现拥有 9 个或更多人员的团队的生产力低于拥有少于 9 个成员的团队的生产力[4]。其他研究表明，三个人的临界人数是必要的，也是足以比最好的单个人表现更好。所以，尽管“小”很漂亮，但“3”可能是有效团队规模的下限（[5]）。

尝试为您的团队找到最佳规模：我们在这里不会为您提供最佳人数。大多数初创公司始于一两个人，然后在他们得到官方资金时逐渐扩大。请记住，优秀的团队是由工作的小型团队成长而来的。然后小心谨慎地添加新的团队成员。从长远来看，整个团队的交叉培训和扩展专业知识总是比被动弥补团队缺少的专业知识要好。将人员从一个过大的团队中裁掉以达到合适的团队规模，这可能会使人们感到苦恼。最好是寻找自然的机会将人员从团队中移出，例如人员流失，晋升或团队成员主动寻求在另一个团队中寻求职业机会。

较大的团队（统计上）比较小的团队经历的流失更多，因此，团队越大，其成员随时间推移稳定的可能性就越小。因此，小型团队更有利于团队的稳定。

如果团队开始变得太大，请考虑有丝分裂

[1] Christopher Alexander et al. “Small Meeting Rooms.” In A Pattern Language. Oxford University Press, 1977, pattern 151, p. 713.

[2] Ivan Dale Steiner. Group Process and Productivity. New York: Academic Press, 1972, p. 86.

[3] Tatsuya Kameda, Mark F. Stasson, James H. Davis, Craig D. Parks and Suzi K. Zimmerman. “Social Dilemmas, Subgroups, and Motivation Loss in Task-Oriented Groups: In Search of an ‘Optimal’ Team Size in Division of Work.” In Social Psychology Quarterly 55(1), Mar. 1992, pp. 47-56.

[4] Daniel Rodríguez, Miguel-Ángel Sicilia, Elena García Barriocanal, and Rachel Harrison. “Empirical findings on team size and productivity in software development.” In Journal of Systems and Software 85(3), March 2012, pp. 562-570.

[5] Patrick R. Laughlin, Erin C. Hatch, Jonathan S. Silver, and Lee Boh. “Groups Perform Better Than the Best Individuals on Letters-to-Numbers Problems: Effects of Group Size.” In Journal of Personality and Social Psychology 90(4), 2006, pp. 644-651.

Picture credits: The Scrum Patterns Group (Lachlan Heasman).