问你如何确保你总是有一个可发布的构建？

EN

我认为你想退出不完整代码的愿望是解决真正问题的创可贴。真正要解决的问题是，你做错了什么，让你以不可接受的故事结束了冲刺。

在我看来，你有3个问题中的一个(或全部)。

1. 不完整的接受条件，你显然不理解PO希望你的故事被他完成和接受。您需要在sprint计划(或之前)中做更多的工作，以了解为每个故事所做的工作。
2. 在sprint期间没有足够多地涉及PO。演示不应该是他第一次看到故事完成。这只是一个结束冲刺的最后仪式。PO应该已经在整个sprint.
3. Overcommitment；中接受了所有的故事，如果你编码到最后一分钟，那么你就没有时间完全集成和测试。我不确定您的意思是“错误”，就像在未测试的代码或didn't-work-like-PO-wanted-code.

中那样。

每个特性的分支对于小团队来说是一件昂贵的事情，当构建大型系统时更合适，因为有许多scrum团队构建组件部分。这就像买汽车保险一样，因为你经常撞车；它不会让你更快地到达那里，它只会让你在路上支付更多。

尝试这个冲刺或2:在PO批准当前的故事之前，不要开始另一个故事。

正如你所建议的，解决这个问题的一种方法是从一开始就考虑拒绝。要求每个用户故事都可以通过配置指令启用或禁用，这保证了没有被拒绝的故事的可发布构建。

如果你真的想排除被拒绝的故事，那么配置指令是不够的，因为它可以被客户端编辑。在这种情况下，您可以考虑编译常量。

这种方法需要一些额外的代码和测试，但省去了分支和合并的麻烦。您还可以保持修订控制环境不变。

希望这能有所帮助。

我同意@DancesWith竹子--你问的是症状，而不是真正的问题。问题是：

为什么PO拒绝这些报道？

• 这些故事是不是不完整？如果是这样，那么他们就不应该致力于发布，团队需要被提醒，不应该有“部分完成”的故事-完成是/否。
• 这些故事没有达到PO的预期吗？然后，你需要花更多的时间在pre-sprint会议上，在团队承诺之前，变得非常清楚故事的含义。也可以考虑使用自动化的验收测试，比如FitNesse。如果PO帮助编写验收标准，那么当故事完成时，他/她将知道预期会发生什么。另请参阅"Card, Conversation, Confirmation".
• Did在冲刺过程中业务需求的变化？那么也许你应该缩短你的冲刺时间，这样PO就可以让团队放弃不再需要的故事。*

你在做Sprint Retrospectives吗？

敏捷实践者谈论“检查和适应”或“计划-做-检查-行动”。在冲刺结束时，让团队和Scrum Master讨论什么是有效的，什么是无效的，什么是你想要添加的。回顾有不同的风格--重要的是，回顾应该产生可操作的项目，旨在改进您的流程。敏捷并不意味着保持流程不变--总是有改进的空间。

(*有些人建议，一旦sprint开始，就不应该改变故事的内容。对我来说，这太死板地坚持流程了。如果PO已经合法地确定它不再提供业务价值，我认为完成一个故事的团队没有任何意义。)