在敏捷sprint分支中处理未完成项目的最佳方法是什么？ [关闭]

Question

如果您以敏捷的方式工作，并且每个冲刺都有一个分支，并且还具有只能将已完成和经过测试的项目放回后备箱的策略，那么您如何最好地处理未完成的项目？

该分支是否应该保留下来并重命名为新的sprint分支，并在那里继续解决这些问题？ 如果这些问题不应该成为即将到来的冲刺的一部分，该怎么办？

更新 ：

在获得亚历克斯·佩雷拉（Alex Pereira）等人的回答后，我感到我对问题的措辞错了，或者是误解了自己的想法。 我的意思不是每个冲刺一个分支。 而是每个发行版/功能集一个分支。 并且由于该分支可以继续存在，因此最初的问题实际上不存在。

将其与功能分支结合使用，未完成项目的问题将变得更加易于处理。

我确实要注意，尽管朝着主干（或任何其他预定的分支）进行开发，然后沿此方式标记发布是我以前使用的可行方法，但我希望系统可以将开发人员的数量从1扩展到100需要更改。 因此，必须有一个分支被认为是稳定的分支，已经完成了工作，并且可能有多个并行分支供不同团队同时处理要素而不互相干扰。

在制定这样的想法之前，我必须为所有这些提供便利的想法

Answer 1

不确定此处的设置是否最佳。 我在一家同时也进行敏捷开发的商店中，我们不按Sprint进行分支，而是按Release进行分支。 我认为没有必要建立Sprint分支，实际上，如果您希望每个Sprint都按Release分支并应用Labels。 我也不同意其他建议，在这些建议中，他们建议让开发人员创建自己的分支。

但是，就您而言，由于您已经在使用该设置，因此我想说您将“挂断”转移到下一个Sprint分支，并将当前的Sprint分支合并回Trunk。 如果开发人员已经开始在当前的Sprint分支上工作，则可以手动移动代码或对下一个Sprint分支进行无基础的合并（如果源控件允许）。

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

在这方面，我们在此进行了很多讨论。 基本上，我们有三个敏捷团队致力于三种独特的产品，两个.NET和一个VB6（旧版）。

我们想找出所有团队合作的标准方式，这就是我们想出的-也许它可以为您提供帮助：

文件夹/分支结构：

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

Answer 2

就个人而言，如果未完成的工作不继续进行到下一个冲刺，我将丢弃未完成的工作。