只是想知道其他人如何管理与完成用户故事不直接相关的任务，例如服务器配置和应用程序部署(在 Web 应用程序环境中)。以前，我已将这些事件包含在产品待办事项的任务分解中，但这些工作往往会在与满足用户需求直接相关的其他任务中丢失。
其他人是否为此类工作创建专门的产品待办事项列表？或者以“需要潜在可交付”为幌子将其纳入现有要求？或者您甚至没有将其纳入 Sprint 计划中？对那里的不同方法感兴趣。谢谢!
最佳答案
为了让一个故事被视为“完成”，它需要是可交付的，这不仅包括测试，还包括部署和配置。
如果您已经建立了基础设施，那么这应该包含在您对故事的估计中。
如果您没有基础设施，那么构建脚本和部署系统的构建本身就是一个故事:除了这里的“客户”是开发人员或基础设施人员，而不是开发人员。所以:
作为一名开发人员，我需要部署 XYZ 应用程序并验证它是否通过了功能测试，以便我们可以将其他故事视为完整。
在这种情况下，这是一个完全可以接受的故事。
一旦您掌握了其中一些故事，您就会知道它们通常需要多长时间。对后续故事的估计就容易得多。
关于deployment - 在 Scrum 中管理部署和配置任务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2025129/