InfoQ

新闻

5人是最佳的团队规模吗?

作者 Vikas Hazrati 译者 金明 发布于 2009年4月17日 下午8时9分

社区
Agile
主题
团队工作
标签
生产力,
伸缩性敏捷

多大的团队规模才是最佳,从而使生产率最大化?关于这点已经有很多的讨论和争论。虽然大多数敏捷实践者赞同团队规模越小,团队的实用性更强、生产率也越高,但定义最佳的团队规模大小,依然是一个挑战。

Jeff Sutherland 分享了一些有利于小规模团队的统计:7人团队开发每个功能点的成本是$566美元,而14人团队则高达$2970美元。在对InfoQ新闻“

关于团队规模增长和生产率”的回复里面,Mishkin Berteig同样写到

假象一下你被任命为由100名开发人员组成的软件开发团队的头,现在需要开发一个非常重要的项目。下面哪种结构更可取:

a)把所有的100个人都安排上项目(提供良好的项目管理、领导力等),或者...

b)找出团队里面想加入项目的最强的7个人(换句话说,这7个最强的人对该项目真正感兴趣),让他们上这个项目。解雇其他所有人,把省下的钱用来给这7个人配置他们想要的最好的工具和环境,剩下的钱用来提高这些人的满意度和愉悦度。

就个人而言,尽管方案b过于严酷,我依然会选择它,而不会选择方案a。

Jurgen Apello 建议最佳的团队规模应该是5个人。在很多对沟通和团队结构的研究里面,5是常见的团队规模大小

  • Scrum 推荐的团队规模是7 +/-2,因此团队规模在5到9之间
  • 根据Congnitive Edge的研究,人类大脑虽然会随着社会同步演化,但个体所能维护的社会关系数量存在一个自然极限,这项研究结果也被称为5,15,150规则。短期记住的人数的自然极限是5,深度信任的人数的自然极限是15,而人大脑里能记住的人数的极限是150。
  • 另一项研究与帕金森定律相关,它指出除了8人团队,任何规模小于20的团队都能运作良好。而团队超过20人就会自然而然地分成更小的子团队,团队再也无法形成一致性了。而在8人团队里,人们发现做出的决定总是难以取得大多数人的支持。

在对帕金森定律的回复中,PMHut提出了另一项5人团队的论据支持,他指出

团队成员越多,沟通方式就越多,而且该数量是呈指数上涨的。比如团队有3个成员,你可能会有4种沟通方式,但一旦成员数为4,就会有9种。我猜想对应的方程式是(m-1)2

在我看来,4到5人的小团队是最理想的。

因此,上面的事实和研究表明,从Scrum推荐的团队规模、帕金森定律、短期记忆的自然极限到有利的沟通方式,5人的团队规模满足了所有的条件

然而,虽然种种迹象表明5人团队是最佳的规模大小,Jurgen 也警告与其照搬推荐的团队规模,不如由团队先尝试自组织,然后动态达到最佳的团队规模。根据他的观点,

当你需要组建一只庞大的项目团队,不要照搬任何书里面写的“更佳”的团队规模。尝试团队自组织,由团队成员(在真实的环境下)得出最佳的团队规模。他们愿意把7人团队分割成两个,一个3人,一个4人?当然,为什么不?他们想把两个团队合并成一个15人团队?没问题,让他们看是否有效。

查看英文原文Is Five the Optimal Team Size?

沟通成本真的很高 发表人 lou yun 发表于 2009年4月20日 下午8时58分
队伍,顾名思义 发表人 Xiaogang Guo 发表于 2009年4月20日 下午10时5分
Re: 队伍,顾名思义 发表人 Shinco Lu 发表于 2009年4月29日 下午8时26分
  1. 返回顶部

    沟通成本真的很高

    2009年4月20日 下午8时58分 发表人 lou yun

    5~7人的团队可以使用任何管理模式,敏捷也好,RUP也好,基本都能运转起来。
    而且我同意一个观点:大团队会“自然分解”为多个5~7人规模的小团队!

  2. 返回顶部

    队伍,顾名思义

    2009年4月20日 下午10时5分 发表人 Xiaogang Guo

    以后都不用“团队”了,改成“队伍”。

  3. 返回顶部

    Re: 队伍,顾名思义

    2009年4月29日 下午8时26分 发表人 Shinco Lu

    有意思,能说说“团队”和“队伍”的区别么?

    以前只是听说过,团队(Team)和组(Group)两个概念的区别

    以后都不用“团队”了,改成“队伍”。

深度内容

模块化Java:声明式模块化

本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。

Ian Robinson和Jim Webber谈论基于Web的整合

本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。

项目管理修炼之道(精选版)

项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。

那是鸟,还是飞机?不,那是超人!

在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。

访谈和书摘:Eben Hewitt的新书《Java SOA Cookbook》

Java SOA Cookbook

Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。

Mark Richard的《Java消息服务》第二版

Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。

模块化Java:动态模块化

本文是“模块化Java”系列文章的第三篇,讨论动态模块化,内容涉及如何解析bundle类、bundle如何变化、以及bundle之间如何通信。

让测试也敏捷起来

对于测试组织来说,敏捷方法带来的快速迭代却让测试本身变得困难起来:缺乏“足够详细的文档”,缺乏“仔细设计用例的时间”等等。在本演讲中,段念将与大家探讨如何在敏捷过程中进行测试。