概述

现代复杂系统需要高效能团队，对于需要大量信息的知识密集型、问题解决型任务，一个有凝聚力的团队的表现要远远超出个人的集合；

依赖个体来理解和有效处理构建和演进现代软件所需要的信息量和信息的本质是不可持续的，团队活力远比谁在团队中更重要；

建设小而美的长期团队

团队规模：

• 本书中的团队定义：一个由 5-9 人组成的稳定小组，作为一个整体朝着共同的目标努力。我们不应该把工作指派给个人，而是指派给团队。
• 一个有效的团队最多由 7-9 人组成。

7-9 这一人数限制有着明确的理论基础：

1. Amazon 提出的 “两张披萨” 理论，即团队规模应该是两张披萨能够喂饱全体成员；
2. 这一人数限制是 Scrum 框架推荐的，它源于对群体认知和信任的进化限制；
3. 邓巴数字：15 是一个人可以信任的人数极限，其中只有 5 个人能够获得深入的了解和信任；

小规模团队带来信任。

工作流向长期团队：

• 团队需要时间磨合来实现高效，通常团队需要花 2 周到 3 个月甚至更长的时间来形成一个有凝聚力的集体；
• 提升团队存活周期的最佳办法就是提升团队稳定性。团队应该保持稳定，而非一成不变，仅在必要的时候进行偶尔的调整。

让团队对软件负责：

• 让一个团队负责系统或子系统；
• 需要明确的是：团队代码所有权划分并不是在划分地盘，团队对代码负责并维护，而不应该觉得代码是它们的而因此排斥其他人；

团队成员也需要具备团队优先的思维：

• 团队应该是交付的基础，而非个人；
• 即便通过引导，有的人依然不适合团队的工作，或者不愿意将团队的需求放在个人需求之上。这些人会影响团队工作，在极端场合下，甚至会摧毁团队；

在团队中拥抱多样性：

• 一点异质性会极大的帮助创建一个团队的团队；

奖励团队而非奖励个人。

良好设计的边界可以最小化认知负荷

约束团队职责以匹配团队认知负荷：

• 使用团队优先方法，团队的职责与团队所能处理的认知负荷是吻合的。

Sweller 定义了三种不同的认知负荷：

1. 固有认知负荷，与问题领域的基本任务相关；
2. 额外认知负荷，与任务处理的环境相关；
3. 相关认知负荷，与那些需要额外关注学习和高性能方面的任务相关；

一般来说，为了高效地交付和运维现代软件系统，组织应该：

1. 试图最小化固有认知负荷：通过招聘、培训等方式解决；
2. 消除额外认知负荷：自动化、成立工具平台部门等；
3. 为相关认知负荷预留足够的空间：”增值“思维的所在；

限制团队认知负荷也意味着限制了团队工作的子系统领域大小，所以将任务拆分就显得特别重要。

使用相关领域的复杂度来度量认知负荷：

• 试图通过一些简单的手段（比如代码行数等）来确认软件的认知负荷，可能会被误导；
• 我们可以通过团队职责领域的数量和相关组织内部的复杂度来进行评估；

我们将领域复杂度归类为”简单“、”复杂“、”非常复杂“，可以得到一些启发式结论：

1. 可以将每个领域分配给单一团队；
2. 一个 7-9 人的黄金规模团队应该可以应对 2-3 个简单领域；
3. 如果一个团队已经负责了非常复杂的领域，那么就不应该再给他们分配更多的领域，即便是一个非常简单的领域；
4. 避免单一团队负责两个复杂领域；

软件边界大小匹配团队认知负荷。为了增加团队可以负责的领域大小，可以通过降低”固有认知负荷“与”额外认知负荷“的方式，来优化团队工作生态，从而最大化团队认知容量。