如何将不可估量的任务变成scrum sprint？

Question

我是一个由4名开发人员组成的小团队的scrum master。我们正在开展的项目有很多我们以前从未做过的任务，在sprint计划会议上无法轻易估算。在这种不确定性下进行冲刺的最佳方式是什么？我发现用潜在的可释放产品完成冲刺非常困难。我还发现，当有很多未知长度的任务时，很难计划冲刺。

Answer 1

我不确定Scrum中的术语是什么，但是在用户故事术语中你会做一个“尖峰”，这对于该主题来说基本上是一段非常短的研究时间，这样你的团队就可以估算出在秒杀结束时的任务。

示例：

  

故事：

     

分析师希望能够进行审核   饼图中的财务数据。

您的团队不使用任何图表工具，因此您需要知道构建此类内容需要多长时间。或者，也许您可​​以投资第三方工具并将工具集与您的应用程序集成。

你会对这些场地进行研究，然后对它们进行估计，然后决定采取哪种方式。

Answer 2

世界上某人以前做过的“任务”事件，还是他们刚刚对你的团队不熟悉的事情。我会假设后者。如果是这种情况，那么您发现的是您没有必要的团队经验来解决问题。因此，随着您的发展，您将获得这种体验。所有这些意味着你的故事的复杂性更高。在前几个冲刺中，你可以将一些故事评为13，然后再将它们变为8s，因为你拥有所需的知识。

你不需要知道如何做故事来估计它们。由于你的经验差距，你只需要减少它们。

我想保留“Spikes”（是的，这是scrum中使用的术语），试图解决没有已知解决方案的业务领域问题。不适合团队进行培训。

Answer 3

如果你真的需要做研究以获得一个好的估计，你可以将研究本身作为一项任务，或者将它放在一边，并在sprint计划之前完成（由某人）完成。

一般来说，我认为如果你不能得到一个好的估计，你应该做一个糟糕的估计（即疯狂的猜测），或者你应该计时任务，所以你留出一定的时间在冲刺中。在那之后，您将获得一个完整的解决方案，或者您将更好地了解它，以便您可以估计它或将其分解为下一个sprint（或后来的sprint）的子任务。

Answer 4

您真的是指任务还是在谈论产品待办事项（PBI）？实际上，我发现很难相信任务是不可估量的。如果他们真的不是，他们很可能太大（任务不应超过16小时，这已经是巨大的）。

如果你在谈论PBI，你所描述的情况是非常令人惊讶的，理论上应该不会发生。在最糟糕的情况下，只需为它们分配大量的故事点，这恰恰意味着它们存在很多不确定性。但是，因为为Sprint做好准备的PBI不应超过你速度的一半（或者你的冲刺会带来太大的风险），解决这种情况的明显方法是将这些项目分成更小的块，这可能是包括探索。但重要的是保持时间，即使（或特别是）R＆amp; D。请记住，使用Scrum，所有内容都是时间盒。

换句话说，为了减少不确定性，将事情分解为更小的事物（无论是项目还是任务）！

Answer 5

如果任务看起来不可估量，我认为最好的方法是将这些任务分解为您可以估算的较小任务。它可能需要多次迭代，但是当你在它时，你可能会想出一个伪设计。乔尔在他的一个articles中提到了这一点。

Answer 6

将不可估量的任务分成任务以消除不确定性和“其余”。通过概念验证测试或尖峰解决方案消除不确定性。要么计划这个冲刺的尖峰和下一个冲刺的其余工作，要么延迟冲刺的开始一周的尖峰。

Answer 7

我们经常不知道将故事分解为任务。在我们知道任务将会是什么之前，我们有一段时间的发现。 “尖峰”似乎很难管理。例如，您可能无法将发现期限定时。其次，在不知道故事需要多长时间的情况下，我无法有效地计划冲刺。

似乎另一种选择是Sprint 1中的尖峰和Sprint 2中的任务。缺点是这个过程似乎迫使工作不自然地崩溃。为什么要在本周发现，然后等待一段时间再开始工作。

Answer 8

我们使用“特遣队”或特定的积压来完成此类任务。 Scrum Tool Agilo支持这种工作方式并计算这些问题，例如在Burndown。通过这种方式，您可以很好地控制“不可规划”的项目。

Answer 9

您是否在准确性方面令人困惑？

敏捷评估背后的想法是提出一个足够好的数字，而不是一个确切的数字。这就是为什么使用故事点进行积压项目估算是最佳做法;它强调努力/复杂性而不是持续时间。

您无需知道在sprint中实施积压项目所需的每项任务需要多长时间。您需要知道的是，鉴于您之前在此sprint中承诺的工作，您是否可以承诺此积压项目？因为我们知道我们无法准确知道每个积压项目需要花多少时间，所以我们必须做出有根据的猜测。

更重要的是，Scrum失败意味着什么？是不是每个sprint积压项都没有完成失败？不......如果您完成了五个项目中的四个并且第五个项目大部分已完成，那么您将获得四个已完成项目的信用（就sprint的速度而言），以及当您完成其余任务时在未来冲刺中的第五项，您将获得该项目的全部功劳。但是，如果你不使用Scrum，你还会做得更多吗？ Scrum唯一的失败就是没有从你的错误中吸取教训，不断反复做同样功能失调的事情，同时期待不同的结果。

因此，在您的sprint计划会议中，不要花费大量时间来担心您无法知道的事情。让团队考虑工作，然后让他们报名参加他们在冲刺期间可以完成的工作量。如果他们拒绝承诺，您可以随时将某些内容拖入待办事项，或者尽早结束冲刺。如果他们过度使用，那么你可以按优先顺序完成积压项目，并讨论为什么在sprint回顾中无法完成未完成的项目，以及如何防止在未来冲刺中有未完成的项目。

顺便说一句，我知道这对你来说可能是一个糟糕的选择，但是一个有效的Scrum Master并没有运行sprint。团队进行冲刺，Scrum Master积极寻找降低生产力和干扰他们履行承诺能力的障碍。 Scrum Masters不是经理，他们是裁判，教练和记分员的组合。他们是流程的守护者，他们帮助团队遵循流程，他们保护团队免受外部代理人的攻击，他们通过确保sprint积压更新和sprint burndown chart来跟踪sprint期间的进度每天都反映现实。在您所描述的情况下，团队不确定他们应该注册多少工作，Scrum Master应该让团队决定尊重团队对承诺的所有权。无论决定是什么，都不会错。

Answer 10

尖峰应该是时间盒装的。它给团队施加压力，限制范围，更好地了解研究所带来的成本效益;也就是说，对一项耗资几美元的任务进行3天的研究是没用的。

Latham在目标设定理论方面的工作也支持这一点，他专门解决了这个问题。