你如何确保你总是有一个可发布的构建？ [关闭]答案

【问题标题】：How do you make sure that you always have a releasable build? [closed]你如何确保你总是有一个可发布的构建？ [关闭]
【发布时间】：2023-04-07 01:18:01
【问题描述】：

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

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

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

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

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

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

【问题讨论】：

肯定用分支，通过的合并。
@rockinthesixstring 对每个用户故事进行分支是不切实际的，并且在规模适当的软件项目中可能效率低下。我们有 4 个 Scrum 团队的独立分支（更不用说每个故事了），由于分散的测试和几乎让我们发疯的冲突，这让我们放慢了速度。为主要或次要版本创建分支并定期合并回来时，分支工作得很好。
我投票决定将此问题作为题外话结束，因为project management is now off-topic on Stack Overflow。请在 SoftwareEngineering.SE 和 ProjectManagement.SE 上提出这些问题。（不幸的是，这个问题太老了，无法迁移。）

标签： build scrum release-management

【解决方案1】：

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

在我看来，您有 3 个问题中的一个（或全部）。

不完整的接受条件，您显然不了解 PO 期望您的故事完成并被他接受。您需要在 sprint 计划（或之前）方面做更多的工作，以了解每个故事的完成内容。
在 Sprint 期间没有足够的 PO 参与。演示应该不是他第一次看到完成的故事。这只是结束冲刺的最后仪式。 PO 应该在整个 sprint 中都接受故事。
过度使用；如果您正在编码到最后一分钟，那么您没有时间完全集成和测试。我不确定您的意思是“错误”，如损坏的未测试代码或无法正常工作的 PO-wanted-code。

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

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

【讨论】：

由于团队无法完美预测未来，所以总有一些用户故事不完整的可能。
@user128807 不完整故事的代码在整个工作过程中的每时每刻都应该是可发布的。

【解决方案2】：

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

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

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

希望这会有所帮助。

【讨论】：

【解决方案3】：

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

为什么 PO 拒绝报道？

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

你在做Sprint Retrospectives吗？

敏捷从业者谈论“检查和适应”或“计划-执行-检查-行动”。在 sprint 结束时，让团队和 Scrum Master 讨论哪些有效，哪些无效，以及您想要添加的内容。回顾有多种风格 - 重要的是您的回顾应该产生旨在改进您的流程的可操作项目。敏捷并不意味着保持流程不变——总是有改进的余地。

(* 有人建议，一旦 sprint 开始，就不应该改变正在处理的故事。对我来说，这太拘泥于过程。我认为团队没有任何意义如果 PO 合法地确定它不再提供商业价值，则完成一个故事。）

【讨论】：

【解决方案4】：

了解一种较新的分布式源代码控制类，例如 Mercurial。代码提交形成一个依赖链，可以更轻松地撤销特定功能，而不会中断其他并行工作。

Joel 的 HGInit 教程很好地解释了 Mercurial，并通过并行特征添加的示例进行了工作。

【讨论】：

【解决方案5】：

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

我认为您的问题有两个方面。一是版本控制加发布管理策略，二是如何处理“Undone”工作。

就版本控制部分而言，您的解决方案比您想象的要简单。使用 svn，每次提交都会为整个项目创建一个带有标签号的标签。您可以仅对特定的用户故事签入标签执行 svn revert。一篇最佳实践文章建议开发应该始终在主干上完成，并且您应该只分支发布。所以任何不可发布的代码都应该在主干上的标签号上使用 svn revert 来恢复，然后应该创建发布分支。创建分支后，您可以再次签入未发布的代码，并在下一个 Sprint 中继续处理它。在不干预主干的情况下继续处理分支本身的错误或发布问题。 Offcource 不要忘记定期将发布分支合并回主干。

关于未完成的工作，首先，您的组织认识到可交付和不可交付之间的区别是一件好事，因此这是一个很好的步骤。其次，你需要调查为什么工作没有完成，尝试在回顾中提出一些问题，这将有助于你的团队避免这种情况，使用检查和调整原则。

【讨论】：