您如何确保始终拥有可发布的版本？
我正处于一个遇到以下问题的Scrum团队：在Sprint结束时，团队将完成的用户故事呈现给产品负责人。 PO通常会接受几个用户故事但拒绝一两个用户故事。在这一点上，团队不再具有可释放的构建，因为构建包括可释放的故事和不可释放的故事，并没有简单的方法来撕掉不可释放的故事。此外，我们不想只删除与不可释放的故事相关联的代码，因为通常我们只需要添加一些错误修复。
我们该如何解决这个问题？我的猜测是有一些方法来分支构建，使得（a）每个用户故事都在自己的分支上，用户故事分支可以合并或（b）有一种方法来注释相关的代码与每个用户故事并创建仅具有工作用户故事的构建。但我不知道如何做（a）或（b）。我也很乐意有更简单的解决方案。
我想强调的是问题不在于构建被破坏了。构建没有被破坏 - 构建中只有一些用户故事无法发布。
我们目前正在使用svn，但如果能够解决问题，我们愿意切换到另一个源控制系统。
除了答案之外，我还对解决这个问题的任何书籍或参考文献感兴趣。
答案 0 :(得分：3)
我认为你想要退出不完整的代码是对真正问题的创可贴。真正需要解决的问题是你做错了什么让你在冲刺结束时遇到了不可接受的故事。
听起来像你有一个（或全部）3个问题。
不完整的接受条件，您显然不明白PO对您的故事的完成和接受程度。您需要在sprint计划中（或之前）做更多的工作，以了解每个故事的完成情况。
在冲刺期间没有足够的PO参与。演示不应该是他第一次看到故事完成。这只是关闭冲刺的最后仪式。 PO应该在整个sprint中接受所有故事。
过量使用;如果您在最后一刻编码，那么您没有时间完全集成和测试。我不确定你是否将“bug”视为未经测试的代码或者没有工作的PO代码。
每个功能的分支对于小型团队来说是一件昂贵的事情，在构建具有许多Scrum团队构建组件的大型系统时更为合适。这就像购买汽车保险，因为你经常崩溃;它不会让你更快到达它只是让你在此过程中支付更多。
尝试使用sprint或2：在PO批准当前版本之前不要开始另一个故事。
答案 1 :(得分：2)
正如您所说，解决这个问题的一种方法是从一开始就考虑拒绝。要求通过配置指令启用或禁用每个用户故事，以确保可以在没有被拒绝的故事的情况下进行可释放的构建。
如果你真的想要排除被拒绝的故事，配置指令是不够的，因为它可以由客户编辑。在这种情况下，您可以考虑编译常量。
这种方法需要一些额外的代码和测试，但可以省去分支和合并的麻烦。您也可以保留修订控制环境。
希望这有帮助。
答案 2 :(得分：2)
我同意@DancesWithBamboo - 你问的是症状，而不是真正的问题。问题是：
敏捷实践者谈论“检查和适应”或“计划 - 检查 - 行动”。在sprint结束时，让Team和Scrum Master讨论哪些有效，哪些没有，你想要添加什么。回顾展有各种风格 - 重要的是您的回顾会产生可操作的项目，旨在改善您的过程。敏捷并不意味着保持流程相同 - 总是有改进的余地。
（*有些人建议，一旦sprint开始，就不应该改变什么样的故事。对我来说，这过于严格地坚持过程。我认为团队没有任何意义如果PO已合法地确定它不再提供商业价值，则完成一个故事。）
答案 3 :(得分：1)
查看一个较新的分布式源代码控制类，如Mercurial。代码提交形成一个依赖链，使得在不中断其他并行工作的情况下更容易退出特定功能。
Joel的HGInit教程很好地解释了Mercurial，并且通过并行功能添加的示例工作。
答案 4 :(得分：1)
您如何确保始终拥有可发布的版本？
我认为你的问题有两个方面。一个是版本控制和发布管理策略，另一个是如何处理“Undone”工作。
就版本控制部分而言，您的解决方案比您想象的更简单。使用svn，每次提交都会为整个项目创建一个带标签号的标签。您可以仅对特定的用户素材签入标记执行svn还原。最佳实践文章建议开发应该始终在主干上完成，并且您应该只分支发布。因此，任何不可释放的代码都应该使用svn revert来恢复主干上的标签号，然后应该创建release分支。创建分支后，您可以再次检入未发布的代码，并在下一个Sprint上继续处理它。继续处理错误或在分支上释放问题而不干涉主干。 Offcource不会忘记定期将发布分支合并回主干。
关于未完成的工作，首先，你的组织认识到可运输和不可运输之间的区别是一件好事，所以这是一个很好的一步。其次，您需要调查为什么工作没有完成，尝试在回顾中提供一些问题，以帮助您的团队避免这种情况，使用检查和适应原则。