我们最近一直在实施 Scrum，我们经常想知道的一件事是故事中任务的粒度。
我们公司内部的一些人表示，理想情况下，这些任务应该是非常细粒度的，也就是说，有助于传递故事的每个小部分都应该代表一个任务。他们认为这可以跟踪我们在当前 sprint 中的表现。
这导致大量任务详细说明了许多技术方面和需要完成的小动作，例如为组件 X 创建一个 DAO 以持久保存在数据库中。我也一直在阅读 Ken Schwaber 和 Mike Beedle 的书，使用 Scrum 进行敏捷软件开发，并且我理解任务确实应该具有这种粒度；在其中一章中，他们指出任务应该需要 4 到 16 个小时才能完成。
但我注意到，对于如此小的任务，我们往往会过度指定事情，当我们的解决方案与我们之前在计划会议中确定的不同时，我们需要创建许多新任务或替换旧任务。团队成员也不必跟踪他们在 sprint 中所做的每一件事并创建新任务，因为这意味着我们必须在燃尽图中增加我们的总任务，但不一定要添加一个汇总价值的任务。
那么，理想情况下，每个故事中的任务应该有多细？
施瓦伯和比德尔说“大约四到十六个小时”。
上限很有用。它迫使团队进行计划，并帮助提供每日进度可见性。
对于大多数任务来说，下限是一个有用的目标，以避免过度指定的脆弱性和成本。但是，有时团队可能会发现较短的任务对计划很有用，并且可以自由地包括这些任务。不应该有强制性的下限。
例如，我们当前的一个故事包括向另一个团队发送一些东西的任务——这个任务需要 0 小时，但我们希望记住完成。
燃尽图中的任务数量无关紧要。重要的是剩下的时间。正如 Schwaber 和 Beedle 所指出的，团队应该在 sprint 期间随意更改任务。
在我的最后一项任务中，我们每项任务有 4 到 32 个小时。我们发现，当我们将任务估计超过约 32 小时时，这是因为我们不了解在估计期间要做什么以及如何完成任务。
结果是这些任务的实际执行时间比较小的任务变化大得多。我们也经常“卡”在这些任务上，或者选择了错误的路径，或者误解了需求。
后来我们了解到，当估计的任务有那么长时，这是一个尝试进一步分解它的信号。如果这不可能，我们拒绝了该任务并将其送回进一步调查。
编辑
每周至少完成几次任务也给人一种很好的感觉。
当事情没有按计划进行时，它也会提供相当快的反馈。如果有人在两天内没有完成一项 8 小时的任务，我们会讨论这个人是否卡在某个部分上，是否其他人有一些想法如何取得进展，或者估计是否从一开始就是错误的。
这样想：在更宏观的层面上，短迭代通过快速创造少量价值并允许计划随着业务需求的变化而改变来提高敏捷性。在更微观的层面上，任务也是如此。就像您不想在一次迭代上花费 3 个月一样，您也不想在一项任务上花费一周时间。
每日站立会议可以让您知道您的任务规模太大。如果团队成员经常回答“你昨天做了什么？” 和“你今天要做什么？” 与他们前一天给出的相同答案，您的任务可能还不够小。
例如，如果团队成员连续一天以上定期回答：“我今天在 BigComplexFeatureObject 上工作，明天将在它上工作”，这表明您的任务可能太大了。希望大多数时间团队成员报告已完成一项任务并即将开始另一项任务。
正如其他人所说的 4-16 小时的短任务也可以为 PO 和团队提供有关项目进度的良好反馈。它们还可以防止团队成员走上“兔子之路”，并在业务需求发生变化时可能不需要的工作上花费大量精力。
拥有许多较小任务的好处是它可能为 PO 提供空间来更好地确定任务的优先级并优化交付的价值。如果它们是他们自己的小任务，你会惊讶地发现有多少大任务的“重要”部分可以被推迟或消除。
一般来说，一个好的标准是任务是你在某一天所做的事情。这是理想的，这意味着它很少见。但它确实很适合您给出的 4-16 小时估计（有些需要半天，有些需要两天等）。诚然，我认为我从来没有在一项任务上花一整天不间断的时间。至少，你必须为 Scrum 会议休息一下。（在以前的工作中，一天的编码被认为是 6 小时，以考虑开销。）
我可以理解管理层想要计划每一个细节的诱惑。这样他们就可以对它的各个方面进行微观管理。但在实践中，这是行不通的。他们也可能认为他们可以使用任务描述以某种方式生成有关软件的详细文档，本质上将其作为实际任务本身跳过。再次，在现实中不起作用。
敏捷开发确实需要小的工作项目，但太过分会完全违背目的。它最终会成为一个预先计划过多的问题，并且在任何时候发生任何变化时都必须进行大量额外的重新计划。那时它不再是敏捷的，它只是一系列较小的瀑布。
我不认为这个问题有一个适合所有情况的通用答案。我认为您应该尝试您的同事提出的建议，在第一个或两个 sprint 之后，您评估并查看该过程是否需要调整以适应每个人的需求和愿望。
对我来说，这个 4 小时的数字听起来很不错。我喜欢用可见的结果来思考。我们确实没有每行代码的任务，或者屏幕上的标签，或者每个重构的实用程序方法吗？但是当我们得到其他人可以使用的东西时，比如其他人使用的公共类，或者屏幕上允许一些有用操作的一组字段，那么这对我来说听起来像是一项可跟踪的任务。
对我来说，关键问题是“我们知道我们已经完成了吗？” 使用单独的辅助函数，重构和更改的机会很大，但是当我对我的同事说“在这里，使用这个”时，它要么有效，要么无效。可以评估任务的完整性。