InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

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

作者 Vikas Hazrati 译者 金明 发布于 2009年4月17日

领域
过程 & 实践
主题
团队工作 ,
敏捷
标签
伸缩性敏捷 ,
生产力

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

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?

译者 金明 是ThoughtWorks咨询师,SCJP,系统分析师。关注敏捷方法学,特别是敏捷实施和项目管理的实践。

沟通成本真的很高 发表人 yun lou 发表于
队伍,顾名思义 发表人 Guo Xiaogang 发表于
Re: 队伍,顾名思义 发表人 吕 新科 发表于
  1. 返回顶部

    沟通成本真的很高

    发表人 yun lou

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

  2. 返回顶部

    队伍,顾名思义

    发表人 Guo Xiaogang

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

  3. 返回顶部

    Re: 队伍,顾名思义

    发表人 吕 新科

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

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

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

深度内容

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

解析JDK 7的动态类型语言支持

随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。

Java Remoting远程服务(下)

随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。