如何做大你的软件研发团队？

实践证明5-9人的团队工作效率最高。理想的情况下软件研发公司的团队都由这种小规模的团队组成。在研发大型软件的时候，软件公司需要许多这种小团队，但是如果这些小团队总是需要各种沟通和协调才能推进工作，公司的整体研发产出不可能得到同比例地提高。

因此如何组织这些团队，在研发大型软件时同样保持高效是每个快速成长的软件研发公司必须解决的问题。评判团队的组织形式的标准是考察这种组织形式是否可以保证价值能顺畅地流动到客户手中。本文结合《团队拓扑》一书提出的 4 种团队形式，以及上述评判标准，试图回答这个问题。

为什么说小团队工作效率更高？

在 QSM (Quantitative Software Management) 公司的一项研究中发现大规模增加一个团队的人手只会增加浪费而不会带来想象中的交付能力的提高。该公司考察了 1994 年以来的 4000 个软件开发项目，以代码行数为标准。虽然我不认为使用代码行数标准是最客观的交付能力的标准，但是它确实能反映一些问题。

上图显示了一个 32 人团队的代码达到 10 万行需要 178 人月 (PM)，而一个 4 个人的小团队达到 10 万行代码只需要 24.5 人月。上图中绿圈表示项目使用的是 20 人以上的团队，红圈表示的是项目使用的是 5 人以下的团队。大型团队的成本要显著高于小型团队，但是产出比并不显著。

如上图所示在交付时间上大型团队使用了 8.92 个月达到 10 万行代码，小型团队用了 9.12 个月。大型团队只比小型团队快了 1 周。大型团队在开发速度上也没有显著的优势。

在上图中表示的是代码行数和 Bug 数之间的关系，可以看出人数在 20 人以上的团队在10万行时平均有 170 个 Bug，而 5 人以下小团队只有 33 个 Bug。小团队的质量控制的更好。

我只选取了 3 张图说明 20 人以上的大型团队和 5 人以下的小型团队相比在开发上并没有效率上的显著优势，而质量还不及小型团队。更详细的报告可以查看本文末的链接。

软件研发中应该团队优先还是个人优先？

那么是不是把团队继续分解至个人，然后让团队个人按照项目要求随时组队开发更高效呢？答案是否定的。让公司依赖于个人是非常危险的，这样会形成单点依赖风险。从价值流的角度来说，可能会形成阻塞，比如在执行某项任务时如果只依赖于某个个人，那么其他人只有在等待这个人腾出手来以后工作才能继续，价值流才能重新开始流动。这种等待就是一种浪费。

美国退役将军 Stanley McChrystal 在其畅销书《赋能：打造应对不确定性的敏捷团队》(Team of Teams) 中指出，表现最突出的团队“之所以能够取得非凡的成就，不仅仅是因为团队成员的个人素质，还在于这些成员凝聚成了一个整体”。

众所周知一个稳定的团队比一个临时由多个顶尖高手凑成的团队更有战斗力。如果让球迷猜各国球星组成的临时球队和一个进入世界杯半决赛的国家队对阵谁的胜算更高，球迷会毫不犹豫的选择后者。同样的在战场上那些久经沙场的队伍比临时拼凑的团队更能保证战斗的胜利。

DevOps的创始人在《DevOps实践指南》一书中指出保持团队稳定，让团队持续改进的重要性：“在一般的项目团队中，每次软件发布以后开发人员就被打散并重新分配了，他们没有机会得到自己工作的反馈；我们则保持团队的完整性，这样团队可以进行迭代和改进，用团队各成员所学到的经验来更好地实现目标。”

因此，组织要成功应该依赖于团队而不是个人，而建设稳定的团队是成功的基础。

全功能小团队才能保证价值顺畅流动

虽然说5人以下的小型团队比20人以上的大型团队在软件研发中的效率更高，但是并不是把团队拆小，然后一起开发大型软件，研发效率就会等于所有小型团队之和。

如果团队是按照职能拆分的，那么由于每次反馈都只能反馈到上级团队，就会造成在反馈链条上的多次等待。比如某软件系统在线上出现事故，职能团队划分为架构、开发、测试、交付、运维，运维发现事故上报给交付团队，交付团队在排除了配置故障后再交给测试团队，测试团队复现后交给开发团队，开发团队发现解决这个问题需要架构设计参与再把问题反馈给架构设计团队。

由于每次反馈都需要等待上级团队的响应，所以按职能拆分团队会造成问题修复周期非常长，要解决一个问题至少数以周计。如下图所示，按职能划分团队从运维来的一个问题最大可能需要4次沟通才能完成问题的传递。这还不包括在解决问题时的各种跨团队协调的沟通工作。结果就是价值流通中形成了多个阻塞点，造成价值流动不顺畅。

使用全功能小团队可以减少沟通层级提高价值流动效率。在上面的运维问题的反馈中，运维把问题直接反馈给全功能小团队，如下图所示。团队自己就可以在诸如日常交流或者站会等场合就能解决收到的问题了。

全功能小团队应该跟价值流对齐，简单地说就是跟业务线或者产品对齐，目的是尽快地把价值增量或者说产品的新功能交付到客户的手中。

使用“团队拓扑”保障规模化团队的价值顺畅流动

全功能的小团队减少了问题反馈的层级，但是导致价值流阻塞的还可能有其他因素，比如在研发某个组件的时候需要团队学习高深的数学、计算或者其他专业知识才能开始开发该组件，或者由于团队对某项知识的储备不足导致团队需要花时间在某项特定的任务上，那么我们的价值流对齐团队就可能会延迟交付客户需要的功能。价值流对齐团队可能需要一些共用的组件，如果每个团队都维护自己的共用的组件也会导致价值流动减慢，而且会增加组织的成本。

针对上面的问题《团队拓扑》一书提出了下面 4 种团队类型：

价值流对齐团队 (Stream Aligned Team)
赋能团队 (Enabling Team)
复杂子系统团队 (Complex Subsystem Team)
平台团队

如前一节提到的，价值流对齐团队拥有一块完整的业务领域，负责端到端地建设和运行 (You built it. You run it.). 价值流对齐团队不交付成果给其他团队，而是直面客户。

赋能团队帮助价值流对齐团队克服障碍，也检查缺失的能力。赋能团队可能会派 1-2 名成员进入价值流对齐团队 1 到 2 个月和他们密切协作建立缺失的能力，然后退出，目的是让价值流对齐团队消除价值流流动障碍或者提升流动效率。需要注意的是，赋能团队的使用是通过提升价值流对齐团队的能力来提高其自主性，所以需要聚焦于解决价值流对齐团队遇到的问题，而不是推广其解决方案。

复杂子系统团队建立那些需要特殊专业知识的组件，例如 AI，数学或者其他专业技能。这样价值流对齐团队在价值流动过程中就不会因为要花时间掌握专业知识为建设复杂子系统而降低了流动效率，减慢了交付速度。

平台团队是一组其他团队类型，它们提供引人注目的内部产品，以加速价值流对齐团队的交付。

一个组织中的大多数团队应该是价值流对齐团队，比如有6-8个价值对齐团队，一个赋能团队，一个复杂子系统团队，一个平台团队。

下面是《团队拓扑》推荐的 3 种团队之间的沟通方式:

协作（Collaboration）
两个团队为了 API, 实践，技术等一起工作一段时间
服务（X-as-a-service）
一个团队提供服务，而另一个团队消费这个服务
促进（Facilitation）
一个团队帮助或者辅导另一个团队

上图是 4 种团队在价值流流动过程中的一个快照。在上图中，红色表示复杂子组件团队，蓝色表示赋能团队，青色表示平台团队，黄色表示价值流对齐团队。上图中有 3 个价值流对齐团队，复杂子组件团队以“服务”的形式为 2 个价值流对齐团队提供服务，赋能团队使用“促进”的合作形式帮助价值流对齐团队掌握新技术，而平台团队正在和某个价值流对齐团队以“协作”的形式合作。

结论

本文简要介绍了在团队优先的前提下，使用全功能小团队，在保持小型团队灵活高效的同时，如何基于“团队拓扑”合作建设大型软件。由于篇幅的限制，本文没有介绍如何划分价值流对齐团队的边界，以建立“高内聚，低耦合”或者说如何实现团队内部高频沟通在团队间低频沟通。本文也没有回答为什么说“认知容量”限制了高效团队和高效组织的的最大人数，以及诸如如何管理平台团队等问题。我将在将来的文章中讨论这些内容。

参考链接

Haste Makes Waste When You Over-Staff to Achieve Schedule Compression
Team Topologies Key Concepts
DevOps 实践指南