工作分解

大多数人关注或听说过有关故事的INVEST和有关任务原则的SMART。 在这篇简短的文章中,我将分享一些将故事分解为任务时要遵循的规则。 我们团队的一项关键活动是将工作分解为较小的可行的任务。 我们会在一周的开始(或冲刺),优化期间以及需要时的任何时候进行此操作。 有时,开发人员会问我有关如何降低活动成本,子任务的外观以及其粒度的细节。 我发现WBS指南中的某些原则是可以接受的(由于可变性,100%规则除外),尤其是。 保持分解结果为导向而不是行动为导向 ,例如“用户创建REST端点”与“创建数据库模式” +“创建CRUD方法”(这也是垂直切片与水平切片的示例)。 您的大多数任务都是有时间限制的,可能会使用诸如消耗/耗尽等工具来跟踪进度。 我通常建议使用1–2–4量表进行基于时间的快速估算 :该任务可以在一个小时内,不到半天或半天内完成。 半天是一个很好的检查点,可以告诉您是否应该为任务分配更多时间,或者需要更多的眼睛和双手来加快任务的进行。 尽我们所能, 某些任务就不能成为SMART ,尤其是在可预测性较低(例如峰值)的情况下。 但是对于一个相当稳定的团队(在研发和引进新技术上投入很少的精力),SMART是适用的,希望我也能提出建议。 如果您喜欢反馈(应该!),请对您的任务进行分类(因为控制图最初是为对过程输出进行抽样而设计的),并监视平均值的变化趋势,并使用SPCC…