Fab*_*nji 15 agile scrum task granularity
我们最近一直在实施Scrum,其中一件我们常常想知道的是故事中任务的粒度.
我们公司内部的一些人表示,理想情况下,这些任务应该非常精细,也就是说,有助于提供故事的每一个小部分都应该代表一项任务.他们认为这可以跟踪我们在当前sprint中的表现.
这导致了大量任务,详细说明了许多技术方面和需要完成的小动作,例如为组件X创建DAO以在数据库中保留.我也一直在阅读Ken Schwaber和Mike Beedle的书,使用Scrum进行敏捷软件开发,并且我已经理解任务应该具有这种粒度; 在其中一章中,他们指出任务需要4到16个小时才能完成.
我注意到的是,由于这些小任务我们经常倾向于过度指定事物,当我们的解决方案与我们之前在计划会议中建立的不同时,我们需要创建许多新任务或替换旧任务.团队成员也不必在sprint中跟踪他们正在做的每件事并创建新任务,因为这意味着我们必须在我们的燃尽图中增加我们的总任务,但不一定要添加聚合价值的任务.
那么,理想情况下,每个故事中的任务应该是多么精细？
Schwaber和Beedle说" 大约四到十六个小时".
上限很有用.它迫使团队进行计划,并帮助提供每日进度的可见性.
下限是大多数任务的有用目标,以避免过度指定的脆弱性和成本.但是,有时候团队可能会发现在规划中有用的较短任务,并且可以自由地包含这些任务.应该没有强制下限.
例如,我们当前的一个故事包括向另一个团队发送内容的任务 - 一个需要0小时但我们想要记住完成的任务.
您的燃尽图中的任务数量无关紧要.这是重要的剩余时间.Schwaber和Beedle指出,团队应该随时改变冲刺期间的任务.