本文是团队管理系列的第五篇，也是“松结对编程”系列的第九篇。（团队管理栏目目录，松结对编程栏目目录）

抱歉在这次MPD上不知道中间的20分钟茶歇也在3小时内，所以最后有10分钟左右的内容没有讲，这里补充一下。

大型团队的切分

如果团队大到一定程度，比如40人，那么怎样切分团队最好呢？答案是纵向切分，就是按产品而非按职能切分，也就是事业部化，而非开发-测试-支持这样划分。

原因大致如此：

1. 纵向切分的团队之间不会有直接竞争、对抗关系，避免了各种对抗和办公室斗争。

2. 纵向切分的团队内部目标清晰，都是为了事业部的盈利，责任分工、利益分配更容易。

当然这会带来一些其它问题，比如：资源共用，新产品线和产品的孵化问题。但整体上讲，解决这些问题，比解决横向分工固有的问题要简单一些。

比如下面的图中，红色的1-3-9团队开发一个产品，绿色、蓝色的也开发一个产品，就是纵向切分。

如果红色是开发组，绿色是测试组，蓝色是产品组，就变成横向切分了，扯皮现象很严重。

纵向切分的各部门领导想晋升，方法是提升自己部门的营业额，而横向切分的各部门领导则倾向于证明自己的工作更重要，出发点不同，结果完全不同。

松结对编程看似只解决了最末级微型团队的问题，但实际上，配合1-3-9团队，可以达到将团队规模除以4的效果，这是一般管理方法很难达到的。

大型团队敏捷行为

1～5人规模适合XP（松结对编程+师徒制度）

尽管Scrum“适合5～9人”的团队，但实际上如果办公环境足够开放，在5个人的尺度上（甚至有时候在多达9个人的尺度上），都应该实行接近XP的随时沟通的状态，也就是尽量不在3～5人的小规模团队中做每日立会实践（参考http://blog.csdn.net/cheny_com/article/details/6933835），而是把这些人放置在一个开放环境中，由一个末级的1-3团队进行管理，所有人随时进行沟通（下图中的绿框中）。

5～15人适合Scrum

但在9人以上，直至多达40人（这个数字只是图例中的数字，曾有人报告在500人的团队中实施Scrum，但具体情况不详）的情况中，则是Scrum的天下。

下图中的细红线所圈定的是一个13人的团队，在跨末级团队的级别上就要进行Scrum每日立会，因为13个人很难完成点对点的沟通。

不过召开这样的立会并不需要所有人发言，因为最末级的徒弟多数情况下只关心自己小组几个人的工作，而且他们也很难向外界描述自己做的事情对别有人什么用。

这时候，不如只让师傅发言，师傅并非只说自己的工作，也不是替徒弟发言，而是一个整体小组的形式描述自己小组的工作（昨天做了什么，今天做什么，有何困难），适当的时候可以多预言两三天。徒弟不说话而是倾听自己小组的整体工作，对于开拓眼光和形成大局观很有帮助。

15人以上适合Scrum of Scrums（SoS）

“15”不是一个固定的数字，也不是一个统计数字，不同的团队、产品、领导，会有不同的界限。

Scrum Of Scrums传统认为是几个Scrum Master在几个小组分别召开完每日立会后聚在开的一个特殊的每日立会，但实际实践的时候很难。

原因包括：经常不是一个团队配备一个Scrum Master；Scrum Master负责的东西只涉及秩序，而对于团队的进度、质量、成本、需求这些实质内容无法通过SoS进行汇总，这在跟进项目上有巨大的漏洞。

因此，应该首先召集1-3-9-27团队的各级项目经理（这是Scrum中不存在的一个角色）逐级汇总每日立会，解决团队的技术、进度等关键问题。

Scrum Master们也可以召开SOS会议，但是目的可以说是为了汇总团队开发的管理问题，以及推广Scrum的协调、总结、积累问题。