Deployment 在Scrum中管理部署和配置任务

只是想知道其他人是如何管理与实现用户情景（如服务器配置和应用程序部署（在web应用程序环境中））无关的任务的。之前，我将这些活动包括在产品待办事项的任务分解中，但这些工作往往会在与满足用户需求直接相关的其他任务中丢失

其他人是否为此类工作创建专门的产品积压？或者打着“需要潜在可交付”的幌子将其纳入现有需求？或者你甚至不把它包括在冲刺计划中？对不同的方法感兴趣。谢谢

我不理解问题中的“迷失”。这是你必须做的工作。那么它怎么会丢失呢

敏捷背后的“理论”是你有一个成熟的基础设施

有两个截然不同的基础设施问题

• 创建新的基础设施

• 使用现有的基础设施

在创建新的基础设施时，我们将探索构建到最初的几个sprint中。你不能安排这个。你无法预测其中的各种路径、路障、陷阱、陷阱和陷阱。它需要学习。不要试图预测铺设新基础设施所需的时间。事情会出差错的。如果没有，那么基础设施就不是真正的“新”——它是一个克隆或拷贝

使用现有的基础设施——服务器配置和部署——在每个版本中都会发生，所以我们会尽可能频繁地使用它们

有些东西（比如我们的新防火墙）给一些发布带来了真正的复杂性

但一般来说，配置和部署——就像成熟的基础设施一样——是基础性的。他们已经是你过程的一部分了。你已经在做了。他们怎么会“迷路”

你说的“努力容易迷失”是什么意思？“丢失”是什么意思？你知道你必须这么做。你做到了。丢了什么

---

编辑。尽管有这么多评论，但认为这一次“消失”或“看不见”或“影响”或任何非正常的想法都没有任何意义

这只是你做的事情。这是发布的一部分。你所做的只是工作，就像开发一样

“一天的迁移是一段很长的时间”，但如果这是需要的，那么这就是需要的。你只是允许它。这只是您在每个版本中都要完成的任务

---

如果时间表是神圣的——迁移的日子是一个“问题”——你必须问谁有“问题”，他们有什么“问题”？这是项目经理的问题吗？如果是这样的话，那么时间表已经胜过了交付的功能集，项目经理需要重新思考他们对现实的看法。用户的功能集是真实的。时间表只是一个很好的想法，但并不总是奏效。

我们有一个单独的任务列表，用于服务器管理等任务，并围绕这一点计划我们的可交付日期。例如，根据经验，我知道我每天要花大约2个小时做管理任务，因此当我告诉我的项目经理某件事情需要4个小时时，他会自动在可交付日期上增加约2个小时，并让CEO知道需要6个小时（或1个工作日）

或者，一些“管理”任务是完成可交付项目的先决条件。例如，如果一个项目包括重新编写我们网站的慢部分以提高效率，而部分问题是我们的服务器没有设置为使用我们需要的memcached，那么设置和配置memcached就成为重新编写代码的先决条件项目。之所以没有合并在一起，是因为当我们正确设置缓存时，站点的密集部分可能会运行得很好，因此我们需要事先插入另一个重要的销售相关项目。这使它保持敏捷

我认为这是相关的：-特别是在最后，他概述了他对特性进行优先级排序的方法

---

这篇关于循证计划的文章似乎也很相关：

我们使用两种方法。用户故事生命周期中包括部署应用程序等内容。故事在部署时完成

---

如果我们有一些与特定故事无关的独立任务（例如，新测试环境的配置，但更改架构也属于这一类），我们只需将它们添加为另一个“故事”。我知道这实际上不是用户的故事，但我们也在做类似的工作。必须有人来做这项工作，其他人来验证它是否工作正常等等。

任何人都可以添加到产品待办事项列表中，包括开发人员，但这项工作是否发生，由产品所有者决定

因此，如果您要构建一个新的生产环境，请将其添加到产品待办事项列表中，在Scrum规划会议上，您可以向您的产品所有者解释相对重要性，他们可能会决定现在或以后完成。（这同样适用于部署和/或配置应用程序）

如果您有一项重构任务可以提高应用程序速度，请将其添加到产品待办事项列表中，产品所有者可以再次决定其相对重要性以及是现在完成还是以后完成

---

如果你有一项重构任务，为了使开发能够顺利进行，你确实必须完成它，那么我猜在产品待办事项列表中有一些东西是这个重构可以借助的，而待办事项列表项的估计应该反映出这一点。

为了让一个故事被视为“完成”，它需要是可交付的，这不仅包括测试，还包括部署和配置

如果您已经建立了基础设施，那么这应该包括在您对故事的估计中

如果您没有基础设施，那么构建脚本和部署系统的构建本身就是一个故事：这里的“客户”是一个开发人员