硝烟中的 Scrum 和 XP（五）

                                              我们怎样管理多个 Scrum 团队

这里的核心问题是:

• 要创建多少个团队

• 如何把人员分配到各个团队中

创建多少个团队

宁可团队数量少，人数多，也比弄上一大堆总在互相 干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产 生互相干扰!

最佳的团队尺寸—5 到 9 个人被公认为是“最佳的”团队构 成人数。

是否同步多个 Sprint?

同步进行的 sprint 有如下优点:

• 可以利用 sprint 之间的时间来重新组织团队!如果各个 sprint 重叠的话，要想重新组织团队，就必须打断至少一个 团队的 sprint 进程。
• 所有团队都可以在一个 sprint 中向同一个目标努力，他们 可以有更好的协作。
• 更小的管理压力，即更少的sprint计划会议、sprint演示和 发布。

我们怎样在团队中分配人手

有多个团队开发同一个产品时，一般有两种分配人手的策略。

• 让一个指定的人来做分配，例如我前面提到的“团队领导”，

或产品负责人，或职能经理(如果他的参与度比较高，就

可以做出正确的决定)。

• 让团队自己决定。

我们这三种全都用过。三种?是的，策略 1，策略 2，还有二者的 组合。我们发现二者组合以后的效果最好。

是否使用特定的团队?

方式 1:特定于组件的团队：方式之一是创建针对特定组件展开工作的团队，例如“client 团队”、 “server 团队”和“DB 团队”。

方式 2:跨组件的团队

是否在 sprint 之间重新组织团队?

如果你确实想要重新组织团队，请先考虑一下后果。这是个 长期变化还是短期变化?如果是短期变化，最好考虑跳过这一步。 如果是长期变化，那就干吧。

兼职团队成员

一般来讲，宁愿要三个全职工作的成员，也不愿意要 8 个只能做 兼职的。

我们怎样进行 Scrum-of-scrums

Scrum-of-scrums 实际上是一个常规会议，是为了让所有的 Scrum master 聚到一起交流。

交错的每日例会

求团队避免在同一时刻进行每日例会。

这种做法超级有效，原因有二: 1、像产品负责人和我这样的人可以在一个早上参加所有的例 会。想清楚了解到当前的 sprint 进展状况，有什么严重的 风险，这是最好的方式。

2、团队成员可以参加其他团队的例会。这种情况不常发生， 不过有时两个团队会在相似的环境下工作，所以会有几个 人参加彼此的例会来保持同步。

它的缺点是减少了团队的自由度——他们无法选择他们自己喜欢 的时间开例会。不过这一直没成为我们的问题。

救火团队

救火团队(实际上我们管他们叫“支持团队”)有两项工作。

1) 救火。

2) 保护Scrum团队远离各种干扰，包括挡开那些不知从何而来的、 增加临时特性的要求。

是否拆分产品 backlog?

策略 1:一个产品负责人，一个 backlog（比较合理）

这种模型的优点是:你可以让团队根据产品负责人当前的优先级来 自行管理。产品负责人关注他所需要的东西，团队决定怎么分割工作。

策略 2:一个产品负责人，多个 backlog

它的劣势在于，产品负责人要把故事分配给团队，而这项工作交给 团队自己处理会更好。

策略 3:多个产品负责人，每人一个产品 backlog 它跟第二个策略有点像，每个团队都有一个产品 backlog，但每个团队也都有一个产品负责人!

代码分支（Git）

• 主线(或者主干)的状态要严格保持一致:最起码所有的 东西都要能够进行编译，所有的单元测试都可以通过。每 时每刻都能创建一个可以工作的发布版本。
• 给每个版本打上标记(tag)
• 只在必需的时候创建分支。
• 将分支主要用于分离不同的生命周期。
• 经常同步

多团队回顾

在 sprint 计划会议上(因为我们在同一个产品中使用的是同步的 sprint，所以所有团队均会参加)，第一件事情就是让每个团队中 找出一个发言人，站起来总结他们回顾中得出的关键点。每个团队 都有 5 分钟的时间。然后我们会进行大约 10 到 20 分钟的开放讨论。 之后稍作休整，开始真正的 sprint 计划。