5

我们开始了一个将使用 Scrum/XP 管理的项目。为了评估目的，我们预先编写了整个产品 backlog。我们确保所有故事都以客户为中心，并通过以下方式对其进行评估

  • 故事商业价值：莫斯科技术 - 必须、应该、可以、不会/不会实现这个
  • 故事工作量/复杂度（= 故事点数）：1、2、3、5、8、13、21、100 - 与故事复杂度/工作量有关，而不是理想的持续时间

100 个故事点可能有一些带有会/不会有的故事，因为它们实际上是更大的复杂故事，如果需要，稍后会分解。

计算的故事重要性基于不重叠莫斯科故事的价值和努力。

但是，如果没有 100 点故事，我们的故事到目前为止（也被分解）的复杂度在 2 到 8 之间，我们认为这是避免微观管理的合适故事大小。但有些故事变得相互关联或相互依赖。如果先完成，我们的故事可能会花费更多，如果在他们之前完成其他故事，则可能会花费更少。

问题
是否可以在开发过程中稍后调整故事点，就像我们可以对故事任务做的那样，我们可以重新评估它们、添加新的、删除现有的，或者故事不是这种情况？因为改变它们的复杂性，也会改变基于计划速度的结束日期估计。在这种情况下，最佳做法是什么？

4

4 回答 4

5

你绝对可以再次估计你的故事，你应该。仅当团队在 Sprint 开始前的 Sprint 计划会议上对这些点做出承诺时，这些点才会被锁定。

我使用的一种做法是，在进行单独的 Sprint 计划时，您应该再次评估每个故事。团队会随着时间的推移而学习，并将在估计和识别依赖关系方面变得更加准确。请记住，进入 Sprint 的内容取决于团队，产品负责人定义了整个积压工作。如果项目有时间限制，请不要尝试使估算符合结束日期，如果这样做，您就是在为失败做准备。

请记住，使用 Velocity，您首先要猜测您可以完成什么。通常要到第 3 或第 4 个 Sprint 时，您才能确定团队可以管理的现实速度。是的，这确实意味着您可能假设团队可以在每个 Sprint 中交付 20 分，但实际上只能获得 15 分。是的，这意味着交货时间结束或故事低于切割线。

至于依赖故事，您应该与您的产品所有者合作。如果团队与他们交谈，您通常可以重新安排故事。大多数人都接受有人告诉他们“如果我们现在做 A，它将花费整个 Sprint，但如果我们稍后再做 A，它将花费 15% 的 Sprint”，这使得它非常有说服力。

一个有用的尝试是在 Sprint 中安排故事。在计划会议期间，一旦所有故事都经过验证和讨论，团队就会拿出一个日历并讨论他们何时想要完成任务。通过将目标日期放在日历上，有助于识别故事之间的重叠和依赖关系。这可以识别本质上是连续的并且可能导致 Sprint 失败的事物。

希望这些信息对您有所帮助。

于 2009-08-06T10:23:13.460 回答
2

从你的解释来看，你已经做得很好了。当然，总会有依赖的故事。有些甚至可能没有直接可见的客户价值；即建立架构和一些框架的初步努力）。但是如果你把它们排除在外，你会产生很多技术债务。如果可以的话，我建议您尝试使方程式完整并以某种方式显示任务之间的关系。

例如： - 如果在任务 2 之后完成任务 3，则为 8 分，但如果独立完成，则为 12 分。

这样，产品负责人会感受到忽略依赖的痛苦，但仍然可以选择先做最有价值的故事。如果产品负责人确定所有故事都在下一个 sprint 中完成，那么您可以引导以最有效的顺序实施它们。例如，通过阻止尚未满足依赖关系的项目（即，您只能在故事“启用网络的版本”完成后才能使用“更改网站上的徽标”功能。）

祝你好运！

于 2009-08-06T09:45:50.103 回答
0

我只能描述我的经历。

当我们计划第一次冲刺时，我们决定我们可以完成 18 分。所以我们拍了几个故事，总估计是15分。正如我上面提到的，我们在 scrum 中迈出了第一步，这就是为什么我们决定 3 个未使用的点和 0.6 的外形尺寸保证了我们的成功。

但我们对每个故事的估计只是近似的。我们也有一些依赖的故事。而且我们没有制定每个故事的实施计划，因为我们认为敏捷方法论是不必要的。

结果，我们的第一个 sprint 仅以 8 个完整点失败。

在我们的第二个 sprint 之前，我决定我们应该从旧的、简单的级联和迭代方法中汲取一些东西（我是一个 scrum 大师）。因此，在我们下一个春季计划做出正确估计时，我们计划了每个故事（每个故事大约 20 分钟），使用简单的图表、所有依赖项、实施细节等。计划很困难，需要召开 2 次会议。

但是第二个冲刺要好得多，我们几乎完成了所有工作（实际上我们已经完成了所有工作，但有一些错误）。我认为我们将在第 3 次 sprint 中采用更少的外形尺寸并且它会成功。

于 2009-08-06T08:33:23.917 回答
0

有一些模式可以帮助您以保持 INVEST 的方式拆分用户故事，这意味着您将尝试保存依赖关系、大小、可测试性和价值。您可以在这里阅读更多相关信息：http ://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/理查德正在积极应用和改进它们，他并不孤单；-)

请注意，拆分和保持依赖关系（就像在甘特图中创建关键路径）将胜过团队的创造力和就这些故事进行谈判的能力，并且还可能隐藏“无价值-主张”。

HTH
安得瑞特

于 2011-01-20T10:28:30.207 回答