我是一个由 4 名开发人员组成的小团队的 Scrum Master。我们正在做的项目有很多我们以前从未做过的任务，而且在冲刺计划会议上也不能轻易估计。对我来说，在这种不确定性的情况下进行 sprint 的最佳方式是什么？我发现用一个可能发布的产品完成一个冲刺非常困难。当有很多未知长度的任务时，我也发现很难计划冲刺。
问问题
7461 次
10 回答
16
我不确定 Scrum 中的术语是什么，但在用户故事术语中你会做一个“尖峰”，这基本上是对该主题的一个非常短的研究期，以便您的团队能够在尖峰结束。
例子：
故事：
分析师希望能够在饼图中查看财务数据。
您的团队不使用任何图表工具，因此您需要知道构建这样的东西需要多长时间。或者，也许相反，您可以投资第三方工具并将工具集与您的应用程序集成。
你会做一个尖峰来研究这些场地并提出对它们的估计，然后决定走哪条路线。
于 2009-11-13T16:46:11.600 回答
3
是世界上某个人以前做过的“任务”，还是对你的团队来说只是新手。我会假设后者。如果是这种情况，那么您会发现您的团队没有解决问题所需的经验。因此，您将在进行过程中不断发展这种体验。所有这一切都意味着您的故事的复杂性更高。在最初的几个 sprint 中，您可能会将一些故事评分为 13，然后它们会变成 8，因为这样您就拥有了所需的知识。
你不需要知道如何做故事来估计它们。由于您的经验差距，您只需要减少他们的数量。
我喜欢保留“Spikes”（是的，这是 scrum 中使用的术语）来尝试解决没有已知解决方案的业务领域问题。不为球队做训练。
于 2009-11-13T16:55:17.957 回答
2
如果您确实需要进行研究以获得良好的估计，您可以将研究本身作为一项任务进行，或者在冲刺计划之前将其搁置并（由某人）完成。
一般来说，我认为如果你不能得到一个好的估计，你应该做一个不好的估计（即疯狂的猜测）或者你应该对任务进行时间限制，所以你留出固定的时间来完成它冲刺。在那之后，您将获得一个完成的解决方案，或者您将对它有更好的理解，以便您可以估计它或将其分解为下一个 sprint（或以后的 sprint）的子任务。
于 2009-11-13T21:19:27.337 回答
2
您真的是指任务还是您在谈论产品待办事项 (PBI)？实际上，我很难相信一项任务是不可估量的。如果它们真的不是，它们很可能太大了（任务不应该超过 16 小时，这已经很庞大了）。
如果您谈论的是 PBI，那么您所描述的情况非常令人惊讶，理论上不应该发生。在最坏的情况下，只是给他们分配大量的故事点，这恰恰意味着他们有很多不确定性。但是，因为为 Sprint 做好准备的 PBI 不应该超过你速度的一半（否则你会给你的 sprint 带来太大的风险），解决这种情况的明显方法是将这些项目分成更小的块，这可能包括探索。但重要的部分是保持时间盒，甚至（或特别是）研发。请记住，使用 Scrum，一切都是有时间限制的。
换句话说，为了减少不确定性，把事情分解成更小的事情（无论是项目还是任务）！
于 2009-11-13T21:39:18.200 回答
0
如果这些任务看起来不可估计，我认为最好的方法是将这些任务分解为您可以估计的较小任务。它可能需要多次迭代，但您可能会在使用时想出一个伪设计。Joel 在他的一篇文章中提到了这一点。
于 2009-11-13T16:51:15.127 回答
0
将不可估计的任务拆分为一个任务以消除不确定性，以及“其余的”。通过概念验证测试或尖峰解决方案消除不确定性。要么安排这个 sprint 的尖峰，然后安排下一个 sprint 的其余工作，要么将 sprint 的开始推迟一周的尖峰。
于 2009-11-13T16:52:20.773 回答
0
我们通常没有足够的知识将故事分解为任务。在我们知道任务将是什么之前，我们有一段时间的发现。“尖峰”似乎很难管理。一方面，您可能无法对发现期进行时间限制。其次，如果不知道一个故事需要多长时间，我就无法有效地计划一个 sprint。
似乎另一种选择是在 Sprint 1 中完成任务，在 Sprint 2 中完成任务。不利的一面是，这个过程似乎迫使工作不自然地崩溃。为什么在这周发现然后等待一段时间再开始工作。
于 2009-11-13T17:03:26.210 回答
0
我们为此类任务使用“特遣队”或特定的积压工作。Scrum 工具 Agilo支持这种工作方式并计算这些问题，例如在 Burndown 中。通过这种方式，您可以很好地控制“不可计划”的项目。
于 2009-11-24T11:20:26.853 回答
0
您是否将精度与准确性混淆了？
敏捷估计背后的想法是提出一个足够好的数字，而不是一个精确的数字。这就是为什么使用故事点估计积压项目是最佳实践的原因；它强调努力/复杂性而不是持续时间。
您不需要知道在 sprint 中实施积压项目所需的每项任务需要多长时间。你需要知道的是，鉴于你之前在这个 sprint 中承诺的工作，你能承诺这个积压项目吗？因为我们知道我们无法确切知道每个积压项目需要多少时间，所以我们必须做出有根据的猜测。
更重要的是，在 Scrum 中失败意味着什么？不是让每个 sprint backlog 项目完成都失败了吗？不...如果您完成了五项中的四项，而第五项大部分已完成，您将获得四项已完成项目的功劳（就冲刺的速度而言），并且当您完成剩余的任务时在未来的冲刺中，您将获得该项目的全部积分。但是，如果你不使用 Scrum，你会做得更多吗？Scrum 中唯一的失败是未能从错误中吸取教训，不断重复做同样的功能失调的事情，同时期待不同的结果。
所以，在你的 sprint 计划会议上，不要花很多时间担心你无法知道的事情。让团队考虑工作，然后让他们报名参加他们在冲刺期间可以完成的工作量。如果他们承诺不足，您总是可以将某些内容拖到积压中，或者提前结束 sprint。如果他们过度使用，那么您可以按优先顺序完成积压的项目，并讨论为什么在 sprint 回顾中无法完成未完成的项目，以及如何防止在未来的 sprint 中出现未完成的项目。
顺便说一句，我知道这对你来说可能是一个糟糕的词选择，但是一个有效的 Scrum Master 不会运行 sprint。团队负责冲刺，Scrum Master 积极寻找会降低他们的生产力和影响他们履行承诺的能力的障碍。Scrum Master 不是经理，他们是裁判、教练和记分员的组合。他们是流程的守护者，他们帮助团队遵循流程，保护团队免受试图绕过流程的外部代理的影响，并通过确保更新 sprint 积压和 sprint 燃尽图来跟踪 sprint 期间的进度反映现实，每天。在您描述的情况下，团队不确定他们应该注册多少工作，Scrum Master 应该让团队决定作为尊重团队所有权的承诺的体现。无论决定是什么，都不会错。
于 2009-11-25T06:06:30.560 回答
0
尖峰应该有时间限制。它给团队施加了压力，要求他们限制范围并更好地了解研究将带来的成本效益；也就是说，为一项花费几美元的任务进行 3 天的研究是没有用的。
Latham 在目标设定理论方面的工作也支持这一点，他专门解决了这个问题。
于 2013-08-30T11:36:12.447 回答