写在前面
今天 Liga 只做三件事情：讲清研发任务层级、梳理需求拆分逻辑、介绍子任务 0/1 判断标准。
在研究不同团队工作习惯的过程中，我们发现了一个很有趣的共性：需求拆分总是伴随着开发阶段进行。
一般情况下，当需求抵达研发团队，会先进入需求池（Product Backlog）等待处理，直到项目 PO 和研发团队完成理解、评估、规划和分工等一系列工作后，才会正式进入开发阶段。
很多团队会在迭代开始后，才开始需求的细化拆分。这就导致那些看起来不复杂，但其实工作量很大的需求被拆分成几十个甚至上百个子任务，有的甚至需要嵌套 N 层子任务才能触底落到每个开发者身上。此外，这些子任务颗粒度混杂：有的任务可能几个小时就能完成，有的则需要几天、一周甚至更长的开发时间。这势必会带来进度管理上的混乱。
与之不同的另一种处理办法：前置需求拆分环节，在开发阶段专注价值创造和交付，更有条理地管理项目进度。敏捷团队应该在迭代计划阶段（Sprint Planning）将需求拆分到尽可能小的粒度，再推进后续的工作。
一、 需求应该尽可能地拆小
正如前面所说，体量更小的需求，有助于更好地规划和统筹团队资源，避免研发过程中的反复讨论和精力浪费。另外，前置需求拆分也会让工作量估算、价值排序、进度规划等工作更加轻松高效。
也因此，敏捷开发一直倡导以“用户故事”替代“需求”来描述将被开发的产品功能。体量更小的“用户故事”有几个显著的敏捷竞争优势：
- 保持专注：永远做最有价值的事情