build - 您如何确保始终拥有可发布的构建？

Question

关闭。这个问题需要更多 focused .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，使其只关注一个问题 editing this post .

关闭 5 年前。

Improve this question

如何确保始终拥有可发布的构建？

我所在的 Scrum 团队遇到了以下问题:在 Sprint 结束时，团队将完成的用户故事展示给产品负责人。 PO 通常会接受几个用户故事，但会拒绝一两个。此时，团队不再有可发布的构建，因为构建由可发布的故事和不可发布的故事组成，并且没有简单的方法可以删除不可发布的故事。此外，我们不想仅仅删除与无法发布的故事相关的代码，因为通常我们只需要添加一些错误修复。

我们应该如何解决这个问题？我的猜测是，有一些方法可以以这样的方式对构建进行分支:(a)每个用户故事都在自己的分支上，并且可以合并用户故事分支，或者(b)有一种注释相关代码的方法每个用户故事并创建一个只有工作用户故事的构建。但我不知道该怎么做(a)或(b)。我也对有更简单的解决方案的可能性持开放态度。

我想强调，问题不在于构建被破坏。构建没有损坏——构建中只有一些用户故事无法发布。

我们目前正在使用 svn，但如果这能解决问题，我们愿意切换到另一个源代码控制系统。

除了答案之外，我还对解决这个问题的任何书籍或引用资料感兴趣。

Answer 1

我认为您希望退出不完整的代码是解决真正问题的创可贴。要解决的真正问题是您做错了什么，导致您在 sprint 结束时出现 Not Acceptable 故事。

在我看来，您遇到了 3 个问题中的一个(或全部)。

1. 接受条件不完整，您显然不了解 PO 期望您的故事完成并被他接受。您需要在 sprint 计划(或之前)方面做更多工作，以了解每个故事的完成内容。

2. 在 Sprint 期间没有足够的 PO 参与。演示应该不是他第一次看到完成的故事。这只是结束冲刺的最后仪式。 PO 应该在整个 sprint 中都接受故事。

3. 过度使用；如果您正在编码到最后一分钟，那么您没有时间完全集成和测试。我不确定您的意思是“错误”，如损坏的未测试代码或无法正常工作的 PO-wanted-code。

每个功能的分支对于小型团队来说是一件昂贵的事情，并且在构建大型系统时更合适，其中许多 Scrum 团队都在构建组件。这就像购买汽车保险，因为你经常撞车；它不会让您更快到达那里，只会让您在此过程中支付更多费用。

在 sprint 或 2 中试试这个:在 PO 批准当前的故事之前不要开始另一个故事。