JIRA Agile(Greenhopper) 中的 sprint 容量是如何确定的？答案

【问题标题】：How is sprint capacity determined in JIRA Agile(Greenhopper)?JIRA Agile(Greenhopper) 中的 sprint 容量是如何确定的？
【发布时间】：2014-05-08 21:09:57
【问题描述】：

我是 JIRA Agile（前身为 Greenhopper）的新手，正在摸索它如何确定用于规划和燃尽估算的冲刺容量。据我所知，假设 sprint 容量（以小时为单位）等于您添加到 sprint 中的问题的总需求 - 即，如果您在 sprint 中添加 40 小时的问题，那么一旦 sprint 开始，冲刺时间为 40 小时。

对我来说，这混淆了容量和需求这两个术语，如果它是这样工作的话。此外，这意味着我必须先使用外部工具或流程来进行容量规划，然后确保在开始之前正确设置 sprint。

我想知道其他人如何使用 JIRA 解决容量规划问题，以及是否有可以指定每个 sprint 的 N 小时或故事点用于发布规划目的的方法。

【问题讨论】：

更新：JIRA Agile 计算基于速度的团队绩效，无论您使用故事点还是工作时间。但是，如果您使用时间估算，则可以从第 1 天开始对发布燃尽图进行可靠的工时估算。JIRA Agile 需要完成 3 个冲刺才能确定速度。因此，在速度确定之前它无法进行预测，这往往有利于 1 周的冲刺，这样您就可以更快地确定发布燃尽图。

标签： jira scrum jira-agile

【解决方案1】：

在 sprint 中解决容量规划时，任务/时间或故事/点几乎无关紧要。

使用故事点的好处纯粹是让您的开发团队更容易估计故事。当给定一些东西进行比较时，人们非常擅长估计相对大小。不太擅长根据过去的经验提供估计。在构建软件时，第二次以完全相同的方式做某事是很少见的。即使您确实看到涉及重复性任务，经验丰富的开发团队也会将其视为重构和概括可以快速轻松地重用的解决方案的机会，从而编写与第一次不同的解决方案。

第一步是确定用户故事包中最简单的任务之一，并将其称为 1 点故事。从那里你只需要回答这个问题，与你的“1”相比，做这个故事有多难。一旦您为几个故事完成了此操作，您将有一个更大的组进行比较，并且估计变得更容易。如果您遇到的故事距离您可以比较的任何故事都超过 2 个级别（例如，您估计的最大故事是 3 级，而您的开发团队说这是 13 级或更大），我建议您留下类似的故事这些直到你有更接近的比较。或者，您可以尝试将较大的故事分解为较小的故事，以便于估算。

作为项目经理，您需要做的就是抓住这些故事点并计划下一个 sprint。 “但我不知道冲刺多少分！”你说……如果这是一个新项目或一个新的开发团队正在评估这些故事，请选择一些不超过 2 或 3 个的小故事，将它们分出子任务并让团队估计每个子任务。将总小时数相加并除以总点数，即可得出“空气中的湿手指”估计您的团队每个故事点需要多少小时。在每个 sprint 之后进行相同的计算，以获得您的平均“速度”（每个故事点的平均小时数）。

我知道在纯敏捷方法中定义的这个术语是完全不同的（每个 sprint 的故事点），所以我使用术语速度。我理解外部客户总是问“这需要多少小时？”或“这要花多少钱？”。在 PM 级别将故事点转换为小时数只会让报告和与客户讨论变得更容易，而无需对他们进行敏捷方法教育。

几十年来，我一直在与敏捷软件开发团队合作（无论是作为开发人员还是作为 PM），这就是我设法让这一切顺利进行的方式。

希望这对游戏新手有所帮助。

【讨论】：

【解决方案2】：

@Shane，Sprint 容量由故事点决定比由小时更有用。通常，故事点数不会转换为小时数。这个想法是故事点更好地反映了团队的集体平均估计。

如果是第一个 sprint，每个 sprint 的故事点总是一个猜测。根据烧毁的故事点，您决定是否要增加/减少下一个 sprint 的故事点

在敏捷（Greenhopper）中，您添加到 Sprint 的故事点因此是 Sprint 的容量。故事点字段不同于“估计”字段

【讨论】：

Agile(Greenhopper) 可以配置为使用故事点数或小时数进行燃尽，我只给出了小时数作为示例。问题保持不变，它不是关于 Scrum 方法的理论问题，而是关于工具如何确定容量（如果有的话）的技术问题。您所描述的是使用历史速度来计划有多少故事点进入基于静态团队的下一个 sprint。但是，如果您添加或删除团队成员怎么办？或者由于其他项目的到来，他们只能在一个 sprint 中投入 N 小时而不是另一个？
另外，下面附上了关于使用时间与故事点进行 sprint 计划的好文章。另请注意，在敏捷（Greenhopper）中，默认功能仅允许您将故事点放在史诗和用户故事上，而不是错误、任务、功能或其他问题类型。 mountaingoatsoftware.com/blog/…
@Shane，我不同意博客中解释的想法。选择故事点的一个主要原因是它们比小时更能衡量平均复杂性。如果您使用小时进行估算，那么您的估算总是会因估算人员的熟悉程度而产生偏差。故事点有助于解决问题的复杂性，而不是花费的时间。
您始终可以跨类别覆盖故事点的默认实现，但是我认为任务上的故事点不是一个好主意。故事始终是产品负责人可以接受的最细粒度的可交付成果，因此不要将故事点放在任务上。
关于使用历史速度来规划 sprint，它在前 2-3 个 sprint 中对您不起作用，但在之后它工作得非常好。我们在失去资源和交换资源时使用了这个逻辑，它对我们很有效。唯一的挑战是新资源需要时间来适应团队的故事指向。不同的团队使用不同的方法来解决这个问题，最简单的方法是逐渐增加可归因于该成员的故事点。