在敏捷冲刺分支中处理未完成项目的最佳方法是什么？

Question

如果您以敏捷的方式工作并为每个冲刺工作分支，并且还有一个政策，只有完成和测试的项目可以回到主干，您如何最好地处理未完成的项目？

该分支机构是否应保持活跃并重新命名为新的sprint分支并继续处理这些问题？如果这些问题不应成为即将到来的冲刺的一部分怎么办？

更新：

在Alex Pereira和其他人的回答之后，我觉得我错过了我的问题，或者说是误解了我自己的想法。我不是指每个sprint一个分支。而是每个版本/功能集一个分支。由于该分支可以继续存在，因此最初的问题实际上是不存在的。

将它与功能分支相结合，未完成项目的问题变得更容易处理。

我想要注意的是，尽管朝向主干（或任何其他预定分支）开发然后沿途标记发布是一种可行的方式，我以前使用过，我想要一个可以从1到100的系统扩展的系统开发人员需要进行最少的更改。因此，需要有一个分支被认为是稳定的分支，其中有不同的团队可以同时处理特征而不会相互干扰。

在我制定这样的

之前，我必须为所有这些提供便利

Answer 1

不确定您的设置是否最合适。我在一家我们也做Agile的商店，我们不按照Sprint进行分支，而是按照Release发布分支。我认为没有必要让Sprint分支机构，如果你愿意，实际上可以通过Release分支，如果你希望每个Sprint都应用标签。我也不同意他们建议让开发人员创建自己的分支的其他评论，你在那里要求一团糟。

在你的情况下，由于你已经在使用该设置，我会说你将“挂起”转移到下一个Sprint分支，并将当前的Sprint分支合并回Trunk。如果开发人员已经开始处理当前的Sprint分支，那么要么手动移动代码，要么进行无基础合并（如果源控件允许）到下一个Sprint分支。

更新4/17/2012 12:43 PM：

我们在这方面的工作中有很多讨论。基本上，我们有三个敏捷团队致力于三个独特的产品，两个.NET和一个VB6（遗留）。

我们希望为我们所有团队的工作找到一种标准方式，这就是我们想出的 - 也许它可以帮到你：

文件夹/分支结构：

• 开发（分支主 - 将包含用于未来开发的发布分支 - 由Main中的更改更新 - 在发布时间和代码通过初始验收测试时仅合并到Main中< / em>的）
  • 第1版
  • 第2版
• Main （这是主干 - 包含相对稳定的候选发布代码 - 最终构建版本）
• 发布（在QA批准的版本中分支主 - 从未通过更改更新为主 - 仅由Service Pack更新以解决关键缺陷或紧急增强，然后更改合并进入主）
  • 第1版
    • Service Pack 1
    • Service Pack 2
  • 第2版

Answer 2

就个人而言，如果未完成的工作不会延续到下一个冲刺阶段，我会抛弃未完成的工作。