主干不必是主线
这个模式需要一条主线才能进行下去，不过不必是主干（虽然在大多数情况下，使用主干是很自然的选择）。

团队不一定必须有自己的分支
当然可以有多个团队共享同一分支，甚至直接在主线上展开工作。只要保证遵循分支的方针即可。

通常，团队希望有自己的分支，以避免未完成的故事在多个团队之间造成干扰。

不必每次都创建一个全新的发布分支
可以使用同样的发布分支，而不是在每个sprint结束后都创建新分支。那个分支可以称为“新生产系统”或其他类似的名字。如果在生产系统中总是保持只有一个版本，这当然是很好的模型。

不必在每个sprint结束后都进行发布
可以在每个故事完成后进行发布。或者每三个sprint完成后发布一次。确定你自己的步伐。

不必针对每个故事都运行回归测试
如果在你的环境中，回归测试或集成确实很难实际操作，那么可以在sprint接近尾声时进行。这样可以针对一批故事进行测试和集成的工作。你自己要承担相关风险。如果回归测试和集成属于“完成”的定义，这可能意味着你在sprint末尾时可能会遇到问题，导致没有任何故事完成的风险。

FAQ
持续集成（CI）在这个模式中如何使用？
CI服务器应该针对哪个分支运行？这要根据具体情况，不过下面的叙述是一个好的起点。

假定主干的方针是“完成而且可发布”，而每个工作分支的方针是“通过单元测试”：

对每个工作分支来说，CI服务器自动并持续地检查构建和运行所有单元测试的状况。
如果有任何失败，给出一个红色警告。让机器冒烟……
对每个工作分支来说，CI服务器自动并有规律地（如果不能持续地）运行集成测试和回归测试。
如果有任何失败，给出一个分离的警告。因为这不是当前分支的方针。
当有人考虑从工作分支向主干发布代码时，要触发该手工测试，以检查故事是否“完成”。
对主干来说，CI服务器自动并持续地运行集成测试和回归测试。
如果有任何失败，给出一个红色警告。让机器冒烟、触发警笛、USB火箭发射器，再把国民防卫队叫来。
该版本控制模型使用哪种工具合适？
不确定。我知道Perforce是可以的，我想subversion应该也没有问题，但是对于CVS我不敢打包票。欢迎任何新的建议。

不过要记得一个重要的事情??切换工具的成本要比不能有效协作产生的成本低得多！所以搞清楚你想怎么做，然后找到合适的工具来支持。

与用户故事无关的检入怎么处理？
不是所有的代码变更都必须与某个用户故事相关的，在例子中，我只是为了描述的清晰才这样做。无论检入何种类型的代码（或文档之类），同样的模型也是可用的。

合并代码很麻烦，所以我想做得越少越好！
恭喜，你得了合并恐惧症??对于合并代码的非理性恐惧！合并让你觉得麻烦，是因为做的太少了。合并得越多，痛苦越少。:o)