如果团队同时在实现多个故事该怎么办？

    如果团队每次实现一个故事，将代码发布到主干中并不算什么大不了的事情。只要这个故事相关的代码在工作分支上完成实现并通过测试，我们把所有的相关内容从工作分支上复制到主干上就可以了。搞定！

    先等一下。如果团队中同时开发多个故事呢？如果“开户”故事完成了，而“存款”还在进行中呢？

    如果我们在这个点上向主干进行同步，就会将尚未完成的“存款”故事同步进去，这时它还不能发布呢！而且违反了主干的版本控制方针！

    当然，我们可以等到“存款”故事完成。

    （等待……）

    好了，现在“存款”故事完成了！太棒了！等一下……现在有人开始开发“取款”用户故事了！没错！同样的问题又发生了！

    如果 “存款”故事的一个测试失败了，就很难知道是因为“存款”故事相关代码造成的，还是由于检入同一分支中并且部分完成的“取款”故事相关代码的原因。

    等待无法起到任何帮助作用。这样实际上是在滚雪球，期望在未来某个假设的时间点上所有的故事都可以完成（如果这样的情况真的能够发生的话），而且可以进行一次大规模的发布。

    上述是一个非常普遍的问题。我们该怎么做呢？

    下面是一些应对之策：

• 不要做过多的并行开发。要力图将团队的注意力每次都只放在一个故事之上。
• 如果在“开户”完成之前就有人准备开始“存款”相关的工作，要等到“开户”彻底完成之后再检入“存款”相关代码。或者可以将“存款”相关的代码检入到一个临时的分支之中，如果你喜欢操作多个分支的话。
• 如果在“开户”完成之前就有人准备开始“存款”相关的工作，可以让他先从一些相对安全和不可见的UI元素等部分开始，这些东西的变化不会影响到整个分支的可发布性。比如，“存款”需要开发一些新的代码以及对一些旧有代码的修改，可以先实现新的代码（新的方法、新的类、新的测试等等），而不是先去修改已有代码。如果“存款”需要新的GUI元素，那就让它们先不可见。等到“开户”故事完成而且发布到主干上之后，我们就可以开始实现“存款”的剩余代码了。

    下面是一个合适的规则集：

• 任何针对优先级最高的故事开发的人都是“国王”。
• 团队其他的任何人都是“仆人”。
• 要是你想成为“国王”，就试着找路子帮助完成最高优先级故事的相关工作吧。
• “国王”任何时候需要帮助，“仆人”就必须马上提供相应的服务。
• “仆人”不能打扰“国王”的工作。
• “仆人”不能向工作分支中检入不可发布的代码。“国王”可以检入任何他想要检入的东西（当然，只要他不违反分支方针即可）。
• 目前优先级最高的故事一“完成”，任何开始下一个最高优先级的团队成员就成为了“国王”。

    你甚至还能为团队争取到一些王冠饰品呢。:o)

    总体来说，很多团队都会过高评价同时实现多个用户故事的效果。这样做从开发速度上说感觉好像不错，但却只是一个幻象；因为它将有风险和消耗实践的编码工作推到了最后——包括合并、集成与测试等工作。

    这就是Scrum团队应该保持小规模的原因（少于9个人）——这样他们就可以紧密协作而且将注意力集中于自己的工作成果之上。如果任何人都在独立开发自己负责的用户故事，那大概就不会有多少协作的情形发生了。当然可以有人为将来做计划，为下一个故事做准备并做一些实现工作。但是在任何时候，团队的主要工作努力都要放在优先级最高的故事上。

    多个团队就是不同的情况了。如果很想并行实现多个故事，那就不妨创建多个团队。我们不久后就会看到如何具体操作。首先我想讨论下关于回归测试，以及分叉代码的相关话题。