如果两个团队正在开发的代码互相冲突,后一个检入的团队必须负责解决冲突问题。这是一个好的副作用,因为它可以鼓励团队尽早检入代码。:o)
下面是一个完整Sprint的示例图:
两个团队进行了一次6天的sprint。团队A准备实现“预订”和“取消”。团部B准备实现“发票”和“黑名单”。让我们看看发生了什么。
Sprint完成了!除“黑名单”之外,所有的故事都完成了。但是没关系,我们还是可以发布的!因为我们是以增量的方式完成合并与集成的工作。如果我们等到sprint结束再做,任何分叉的代码就会在错误的时刻发现——此时我们能够用来修复问题的时间最少。
发布分支
假定我们完成了sprint 1并发布了系统的1.0.0版本。现在,我们在进行sprint 2之中的工作时,有人报告说之前发布的版本中发现一个严重的缺陷!不!我们该怎么办?
最简单的方式是:在主干上修复该问题,并发布1.1.0版本。这就是说在sprint 2中任何新实现的故事都会包括在新发布版本中。理论上来说,这样做没有问题;因为主干是“完成”分支,而“完成”的定义就是“可发布的”。所以主干上的内容无论何时都是我们要发布的东西。
不过还是会有一些原因让我们不想马上发布新故事。例如:
- 发现了严重的缺陷,实质上意味着主干在发布时就已经有问题了。也就是说sprint 2的故事都是在一个有问题的基础上构建的。在必须处理新的故事之前,我们会想要修复这个基础。
- 也许利益相关者不希望在sprint当中发布新的功能。
- 从主干中发布包含新功能和全部已有功能的新版本,也许需要一段时间才能完成;所以我们需要一个“hotfix”机制来更快地修复问题。