记得刚工作那会，研发部门刚组建不久就 2 人，我和我领导的工作方式他做一个业务板块，我做一个业务板块。那个时候还没有前后端分离概念，我们都是从前到后，一套撸到底。前端页面、后台代码，再到数据库表的设计，外加手工的测试，一个人包办了。

后来，随着业务部门的需求不断增加，团队人数也开始慢慢的增加，人数从开始的 2 个，到4个、7个再到10多个人。人数的增加，研发的模式并没有进行调整，单人负责一个业务板块的方式出现了问题。

比如，流程审批是我构建编写的，当出了问题第一时间肯定是找我，然后解决处理问题。当有一天请假了不在公司，审批出了问题，不能及时的解决，只能通过电话、微信远程沟通的方式教同事解决方案。

或许，有人说可以远程沟通解决也可以，并不是什么大问题。实则不然，假如那个人离职了，接手那人工作的可能要花费很多时间去理解业务，理解代码。另外，比较严重的是信息不透明，各自写自己的业务板块，当出现问题，另外同事不能给予帮助，工作进展无人知晓，只能去问本人，或者去问题领导（假如，那人没有汇报、领导没有关注跟踪，那就…）。这样算不上一个团队，只能算一个个小个体。

所以，在软件开发领域，团队规模和团队的研发方法是多么重要，一个团队的规模维持在多少人最为合适？今天我们来聊聊，学习一下。

团队维持在多少人最为合适？

在软件开发领域，多大的团队规模才是最佳，从而使生产率最大化？有数据显示，如果你的团队规模超过 9 人，那么运作速度其实会放缓。更有数据表示，更多的资源会导致团队运作得更慢。所以，团队规模人数是非常值得关注。

那一个团队的规模应多少人合适？数据显示，一个团队一般是由 7 个人组成，可以多两人，也可以少两人，人数控制在 5 到 9 人之间最为合适。

弗雷德 · 布鲁克斯的著作《人月神话》提出了 “布鲁克斯定律”。简单地说，布鲁克斯定律认为：“为一个延误的 IT 项目增加人员，将导致更严重的延误。” 这就是为什么某些项目启动的时候会进行招人，一旦启动后项目组就不在加人。

劳伦斯 · 普特南是软件开发领域的一位传奇人物，他一生都致力于研究工作时间与效率的问题。他做了一项研究，一个团队究竟维持在多大规模才算合适。他从数百家公司里选取了 491 个中型项目。这些项目都需要设计出新产品或新功能，而不是对固有产品或功能进行修修补补。他根据团队规模对这些项目进行了分类，很快发现，一旦团队规模超过了 8 人，那么项目耗费的时间往往就会非常多。要完成同样的工作量，3～7 人的团队所需时间只有 9～20 人的团队所需时间的 25% 左右。这种情况在数以百计的项目中反复出现。

他的研究成果表明，如果一个项目的参与者超过 20 人，那么与参与者只有 5 个或少于 5 个时相比，需要付出的努力会更多，而且不是多出一星半点。和小团队相比，大团队得花费 5 倍以上的时间才能完成任务。

那造成这样的问题原因是什么呢？

鱼，经常被说记忆只有 7 秒，鱼表示很冤，我的记忆明明可高达几个月。那人呢？国外有一项研究表明，如果你能把短期记忆中的内容与长期记忆中的内容联系起来的话，那么很有可能会记住更多，但人类思维中负责集中精力的那部分，也就是有意识的那个部分，往往一次只能记住大概 4 样东西。所以，我们的大脑一次记住的内容是有限的。

那我们回到 “布鲁克斯定律” ，为什么项目中增加人数反而会降低进度，其中有两个原因。

第一，要培养一个新成员，使其跟上其他成员的速度，需要耗费一定的时间。

第二，**团队成员增加，沟通渠道就会大幅增加，我们的大脑可能根本无法应付这么多的沟通渠道。
**
我们简单的来计算一下，沟通渠道的公式如下：

沟通渠道 = n（n - 1）/ 2 ；n 表示团队人数；

假如，你的团队有 5 个人，那么你们的沟通渠道就有 10 条；如果 6 个人，沟通渠道就有 15 条；......；如果有 9 个人，沟通渠道就有 36 条；沟通渠道如此之多，超过了我们大脑的承受能力，我们根本无法得知别人做什么，而当我试图寻找答案时，工作进度就会放缓。

因此，在多功能 Scrum 团队中，每个成员都必须知道其他人在做什么。每个正在做什么，正面临着哪些挑战，取得了哪些进步，等等，都必须透明，让别人知道。

团队人数过多的话，会影响彼此的沟通效率，可能产生太多相互矛盾的意见，容易导致团队分裂成小团体，每个小团体各行其是，以至于多功能多团队不复存在了，之前只需要几分钟就开完的会，现在可能需要几个小时的时间。

关注团队规模，让你的团队保持小而精。