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

Question

只是想知道其他人是如何管理与实现用户故事没有直接关系的任务的，比如服务器配置和应用程序部署(在web应用程序环境中)。以前，我已经将这些活动包含在产品待办事项的任务分解中，但在与满足用户需求直接相关的其他任务中，这些工作往往会丢失。

其他人会为这类工作创建专门的产品积压吗？或者以“需要潜在的可发货”为借口将其纳入现有的需求中？或者您甚至不将其包括在Sprint计划中？对不同的方法感兴趣。谢谢!

Answer 1

我们有一个单独的任务列表，用于服务器管理等任务，并围绕此计划我们的交付日期。例如，根据经验，我知道我每天将花费大约2个小时来处理管理任务，所以当我告诉我的项目经理需要4个小时时，他会自动在交付日期上增加~2个小时，并让CEO知道这将需要6个小时(或1个工作日)。

或者，一些“管理”任务是完成可交付项目的先决条件。例如，如果一个项目包括重写我们网站中较慢的部分以提高效率，并且部分问题是我们的服务器没有设置为使用我们需要的memcached，那么设置和配置memcached就成为重写代码的先决条件项目。之所以没有将它们合并在一起，是因为当我们正确地设置了缓存之后，站点的密集型部分可能会运行得足够好，以至于我们需要预先插入另一个与销售相关的重要项目。这让它保持了灵活性。

我认为这是相关的：http://joelonsoftware.com/articles/SetYourPriorities.html -特别是在接近尾声的时候，他概述了他的优先功能的方法。

这篇关于基于证据的日程安排的文章似乎也是相关的：http://joelonsoftware.com/items/2007/10/26.html

Answer 2

我不明白问题中“迷失”的意思。这是你必须要做的工作。那么，它怎么会丢失呢？

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

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

创建新的infrastructure.

• Using现有infrastructure.

的

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

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

有些东西(比如我们的新防火墙)给一些版本带来了真正的复杂性。

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

你说的“努力容易迷失”是什么意思？“迷失”是什么意思？你知道你必须这么做。你干得不错。失去了什么？

编辑。尽管有这么多评论，认为这段时间是“迷失”、“不可见”、“影响”或“一切照常”以外的任何事情的想法都没有任何意义。

这只是你做的事情。这是版本的一部分。这只是工作，就像开发一样，你只需要做。

“一天的迁移是一段很长的时间”，但如果这是需要的，那么这就是需要的。你可以简单地允许它。这只是你在每次发布时都要做的一个任务。

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

Answer 3

任何人都可以添加到产品积压中，包括开发人员，但这是产品所有者决定是否发生工作的一部分。

因此，如果你有一个新的生产环境要构建，把它添加到产品待办事项中，在Scrum计划会议上，你可以向你的产品所有者解释它的相对重要性，他们可能会决定现在或以后再做。(这同样适用于部署和/或配置应用程序)

如果你有一个可以提高应用程序速度的重构任务，将它添加到产品积压中，产品所有者可以再次决定相对重要性，以及是现在完成还是以后完成。

如果你有一个重构任务，为了使开发能够顺利地继续下去，那么我猜产品积压中有一些东西是这个重构可以利用的，对该积压项的估计应该反映出这一点。