故事中的任务应该多么精细？

Question

我们最近一直在实施Scrum，其中一件我们常常想知道的是故事中任务的粒度。

我们公司内部的一些人表示，理想情况下，这些任务应该非常精细，也就是说，有助于提供故事的每一个小部分都应该代表一项任务。他们认为这可以跟踪我们在当前sprint中的表现。

这会导致大量任务详细说明需要完成的许多技术方面和小动作，例如为组件X创建DAO以在数据库中保留。 我也一直在阅读Ken Schwaber和Mike Beedle的书，使用Scrum进行敏捷软件开发，并且我已经理解任务应该具有这种粒度;在其中一章中，他们指出任务需要4到16个小时才能完成。

我注意到的是，在这么小的任务中，我们经常倾向于过度指定事物，当我们的解决方案与我们之前在计划会议中建立的不同时，我们需要创建许多新任务或替换旧任务。团队成员也不必跟踪每一个 他们在sprint中做的事情和创建新任务，因为这意味着我们必须在我们的燃尽图中增加我们的总任务，但不一定要添加聚合价值的任务。

那么，理想情况下，每个故事中的任务应该是多么精细？

Answer 1

Schwaber和Beedle说“大致四到十六个小时。”

上限很有用。它迫使团队进行计划，并帮助提供每日进度的可见性。

下限是大多数任务的有用目标，以避免过度指定的脆弱性和成本。但是，有时候团队可能会发现在规划中有用的较短任务，并且可以自由地包含这些任务。应该没有强制下限。

例如，我们当前的一个故事包括向另一个团队发送内容的任务 - 一个需要0小时但我们想要记住完成的任务。

您的燃尽图中的任务数量无关紧要。这是重要的剩余时间。 Schwaber和Beedle指出，团队应该随时改变冲刺期间的任务。

Answer 2

在我上一次任务中，我们每项任务的时间为4到32小时。我们发现，当我们估计任务超过~32小时时，这是因为我们在估算期间不了解什么以及如何完成任务。

效果是这些任务的实际执行时间变化远远小于小任务。我们经常也“陷入”这些任务或选择错误的路径或误解了要求。

后来我们了解到，当估计的任务持续很长时间时，这是一个试图将其分解的信号。如果那是不可能的，我们拒绝了这项任务并将其送回进行进一步调查。

修改
它还给人一种很好的感觉，每周至少完成几次任务 当某些事情没有按计划进行时，它也会提供相当快速的反馈。如果有人在两天内没有完成一项8小时的任务，我们会讨论这个人是否被困在某个方面，如果其他人有一些想法如何进展，或者估计从一开始就是错误的。

Answer 3

任务可能需要半天到一天，有时可能需要两天。

以这种方式思考：在更宏观的层面上，短迭代通过快速创建少量价值并允许计划随着业务需求的变化而变化来提高敏捷性。在更微观的层面上，任务也是如此。就像你不想在一次迭代中花费3个月一样，你不想在一个任务上花费一个星期。

每日站立会议可以为您提供任务规模太大的线索。如果团队成员经常回答“你昨天做了什么？”和“你今天会做什么？”与前一天给出的答案相同，你的任务可能不够小。

一个例子是，如果一个团队成员经常回答：“我今天在BigComplexFeatureObject上工作，并且明天将继续工作”，连续工作超过一天，这就是你的任务可能太大的线索。希望团队成员在大部分时间内完成一项任务并即将开始另一项任务。

简短的任务，正如其他人所说的那样，4-16小时，也为PO和团队提供了有关项目进展的良好反馈。并且他们阻止团队成员走下“兔子小道”并花费大量精力在商业欲望发生变化时可能不需要的工作上。

拥有许多较小任务的一个好处是，它可以为PO提供空间，以便更好地确定任务的优先级并优化交付价值。如果大任务的许多“重要”部分是他们自己的小任务，那么你会感到惊讶。

Answer 4

一般来说，一个好的尺度是任务是你在某一天所做的事情。这是理想的，这意味着它很少见。但它确实适合你给出的4-16小时估计（有些需要半天，有些需要两天，等等）。当然，我认为我没有在一个任务上度过一整天不间断的一天。至少，你必须打破scrum会议。 （在以前的工作中，编码的一天被认为是6小时来计算开销。）

我可以理解管理层希望计划每一个细节的细节。这样他们就可以微观管理它的每个方面。但在实践中，这是行不通的。他们也可能认为他们可以使用任务描述以某种方式生成有关软件的详细文档，基本上将其作为实际任务本身跳过。再次，在现实中不起作用。

敏捷开发确实需要小工作项目，但是把它放得太远就完全失去了目的。它最终成为一个过多的前期规划问题，并且在任何时候发生任何变化时都必须进行大量的额外重新规划。那时它不再灵活，它只是一系列较小的瀑布。

Answer 5

我不认为这个问题的普遍答案适用于所有情况。我认为您应该尝试一下您的同事提出的建议，并在第一个或两个冲刺后进行评估，看看该过程是否需要调整以满足每个人的需求和愿望。

Answer 6

这个4小时的数字对我来说听起来不错。我喜欢从可见的结果来考虑。我们的每行代码，屏幕上的标签，或者每个重构的实用程序方法都没有任务吗？但是当我们得到别人可以使用的东西时，比如其他人使用的公共类，或者屏幕上的一组字段允许一些有用的动作，那么这对我来说听起来像是一个可跟踪的任务。

对我来说，关键问题是“我们知道我们已经完成了吗？”有了个人助手功能，很有可能进行重构和改变，但是当我对我的同事说“在这里，使用它”它既可以使用也可以不运行。可以评估任务的完整性。