5

是否有人将 Scrum 和 Sprint 用于基础设施。

我正在为永远不会完成的 Sprint 的概念而苦苦挣扎，即网络增强项目。

还有关于如何将项目时间建立到产品待办列表的任何建议，以便我可以理智地检查资源在 sprint 中是否被过度使用。

4

4 回答 4

4

我建议您可以从刷新对 Scrum 整个概念的记忆开始（http://en.wikipedia.org/wiki/Scrum可能是一个不错的起点）。

例如，我不认为应该有“永无止境的冲刺”之类的东西。如果您有一些非常长和/或经常性的任务，只需将其分解为更具体的任务。网络增强非常通用 - 将其分解为：

  • 研究新网络设备的高峰期
  • 检查电缆布局的尖峰
  • 绘制设备物理位置和接线图的任务

估计这些并将它们放入您的待办事项列表中。

等等

然后计划短期（1-2）周的冲刺或迭代。为他们每个人分配一个特定的目标。将您的一些任务从积压工作添加到迭代中。完成它。

查看结果，调整过程，重复。

于 2008-10-21T15:34:57.013 回答
1

Scrum 是一种项目管理方法，它并不是专门针对软件开发的；因此可用于网络增强项目。

你说你正在为“永远不会结束的冲刺”而苦苦挣扎，那不是 Scrum。Sprint 是有时间限制的，它们按时完成。

现在，如果团队在 sprint 中过度承诺，​​或者某些任务被低估，并且有未“完成”的积压项目，它们将从 sprint 的结果中删除，并可能在下一个 sprint 中继续。

您可以做几件事来防止过度使用：

  • 积压项目应少；小物品比大物品更容易估计。实际上，它们应该具有INVEST 特性。编辑：积压项目的大小应使团队平均可以在一个 Sprint 中完成 5 到 10 个。
  • 在第一个 sprint 之后，您现在可以在 sprint 中投入多少团队（提供可比较的资源）
  • 不要在 sprint 上 100% 分配人员，根据经验从 80% 开始
  • 定义“完成”是什么意思
  • 根据你学到的东西重新估计你的积压项目

如果网络增强项目永远无法完成，我认为这是因为发现了新的需求。将它们添加到您的待办事项中，对它们进行优先排序，对它们进行估计，它们最终将被安排在一个 sprint 中。

于 2008-10-23T11:38:09.380 回答
1

你可以看看看板。您仍然有积压，但不是时间盒，而是在整个流程流程中施加 WIP 限制。我仍然建议在适当的情况下使用带有站立会议和定期回顾和演示的 Scrum 沟通计划。计划会议有点不同，因为您实际上并没有投入任何工作，但您仍然可以使用故事和故事点（WIP 限制可以在故事点上）。如果你每两周开会一次，我会确保你有 2.5 或 3 周的工作排队（虽然看板的一个优点是你可以随时将下一件大事添加到队列的顶部，而不必等到下一个短跑）。

此外，我喜欢这样一个事实，即您可以让泳道代表他们的各种客户，因为基础设施通常在处理最终用户支持票证并支持除了他们自己的日常工作之外的多个项目。

在瀑布中，您将一次构建和发布所有内容。在 Scrum 中，您会在短时间的冲刺中定期构建和发布。使用看板，您只需保持水流。

Google Infra-gile 了解更多信息。

于 2014-06-23T16:53:54.623 回答
0

永不结束的 Sprint 不是 Sprint……它是一种职业。JK。如果主要目标无法实现和/或不断变化，请确保您已明确定义子目标。估计每项任务的工时，如果这些工时超过半天左右（非常宽松的规则），则将其分解为子任务。跟踪时间（不必精确——可以在站立会议上或通过您的项目管理系统或票务系统记录）并与任务进行比较。您会发现一些功能和完成时间相似的任务。将它们用作下一个 sprint 的原型，并不断增强它，直到你越来越符合要求。
一旦你对此有了很好的处理，重新审视你的积压工作，分配估计的时间并开始为你的 sprint 定义可靠的目标（由离散的、明确定义的子任务组成）、延伸目标和遥远的目标。坚实的目标应该在您的团队可以达到的范围内（不超过您可以完成的估计目标的 60%，通常更少），延伸目标应该从那个点到您估计可以完成的目标（以 100% 的估计效率）并且遥不可及你应该在你的雷达上设定目标，以防你在冲刺时运气很好。每天，在站立时回顾和绘制你的燃尽图，并重新评估你的 sprint 目标。如果你的估计有很大的变化，请注意原因，如果它们是系统的，重新审视你的任务和估计的时间并重新调整，这样你的下一个估计会更好。起初这是一项艰巨的工作，需要大量的纪律，但几个月后的回报是巨大的。只要坚持严格的现实。祝你好运！

于 2008-10-21T15:38:47.053 回答