agile - 故事中的任务应该有多细化？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




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

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

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

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

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

Answer 1

施瓦伯和比德尔说“大约四到十六个小时”。

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

下限是大多数任务的有用目标，以避免过度指定的脆弱性和成本。然而，有时团队可能会发现较短的任务对计划很有用，并且可以自由地包括这些任务。不应有强制下限。

例如，我们当前的一个故事包括一项向另一个团队发送内容的任务——该任务将花费 0 小时，但我们希望记住完成该任务。

燃尽图中的任务数量无关紧要。剩下的时间才是最重要的。正如 Schwaber 和 Beedle 指出的那样，团队应该可以在 sprint 期间随意更改任务。