任务拆分中的「敏捷刺客」，你中招了吗？

写在前面

今天 Liga 只做三件事情：讲清研发任务层级、梳理需求拆分逻辑、介绍子任务 0/1 判断标准。

在研究不同团队工作习惯的过程中，我们发现了一个很有趣的共性：需求拆分总是伴随着开发阶段进行。

一般情况下，当需求抵达研发团队，会先进入需求池（Product Backlog）等待处理，直到项目 PO 和研发团队完成理解、评估、规划和分工等一系列工作后，才会正式进入开发阶段。

很多团队会在迭代开始后，才开始需求的细化拆分。这就导致那些看起来不复杂，但其实工作量很大的需求被拆分成几十个甚至上百个子任务，有的甚至需要嵌套 N 层子任务才能触底落到每个开发者身上。此外，这些子任务颗粒度混杂：有的任务可能几个小时就能完成，有的则需要几天、一周甚至更长的开发时间。这势必会带来进度管理上的混乱。

与之不同的另一种处理办法：前置需求拆分环节，在开发阶段专注价值创造和交付，更有条理地管理项目进度。敏捷团队应该在迭代计划阶段（Sprint Planning）将需求拆分到尽可能小的粒度，再推进后续的工作。

一、 需求应该尽可能地拆小

正如前面所说，体量更小的需求，有助于更好地规划和统筹团队资源，避免研发过程中的反复讨论和精力浪费。另外，前置需求拆分也会让工作量估算、价值排序、进度规划等工作更加轻松高效。

也因此，敏捷开发一直倡导以“用户故事”替代“需求”来描述将被开发的产品功能。体量更小的“用户故事”有几个显著的敏捷竞争优势：

• 保持专注：永远做最有价值的事情

小而精确的需求更容易在短期内交付。基于完善的优先级排序，敏捷团队可以始终专注于开发更具价值的需求。

• 交互共创：交付满足客户期待的产品

更小的需求粒度意味着，敏捷团队需要通过与客户频繁交互来明确需求的真正内涵，将大而模糊的“功能点”拆小、拆细至具体的“场景解决方案”，以满足客户的预期。

• 精益成长：不断地快速调整与成长

小颗粒度的工作更符合“快速交付-快速验证-快速调整-再次交付”的精益循环模式，能帮助团队在滚动开发和定期回顾的过程中，不断磨合工作方式、增进合作，进而实现持续成长，逐步完成目标。

但是，“小需求”的尽头是什么？拆分的结果有好坏标准吗？要回答这两个问题，首先要了解需求的层级有哪些。

二、 研发需求的三个层级

在许多的敏捷实践中，根据颗粒度（即任务清晰程度）和优先级顺序的不同，需求通常被分为 3 个层级，分别是史诗、用户故事和子任务。

• 史诗层级

史诗（Epic），也称史诗故事，是基于产品长期战略被提出的、颗粒度最大的研发需求，具有跨迭代特性。它通常表示一个可独立使用的产品功能模块或者功能合集，能够被拆分成若干个用户故事并在多个迭代周期中完成。

• 用户故事层级

用户故事，也称故事（在 LigaAI 中以 Issue 表示），是任务需求最清晰的、颗粒度最小的需求，一般要求在一个迭代周期内完成。当需求落到故事层级，敏捷团队就可以通过完成它实现价值交付，因此故事有时也被称为需求的最小可交付单位。

• 子任务层级

如果说故事是最小可交付单位，那么子任务就是最小可执行单位，在 LigaAI 中以子任务或 Subtask 表示。它是用户故事的完成路径，是组成故事的具体工作事项；只有将若干个子任务全部完成，才能最终交付完整的用户故事。

为了满足研发团队对故事管理的不同需求，LigaAI 使用「父故事」即「父 Issue 」概念定义用户故事间的父子级关系，实现 2 级故事层级管理。

Liga 提示：需求粒度和层级判断不是绝对的。由于业务模式和工作习惯上存在差异，不同研发团队对同一需求的层级判定也可能截然不同。

从需求层级的树状图中不难看出，小粒度需求的终点是用户故事，而子任务是完成故事时，精确到“人/天”单位的实现路径。

三、 好的故事遵循 INVEST 原则

极限编程的倡导者 Bill Wake 指出，一个好的用户故事应该遵循 INVEST 原则。

01 Independent 独立

用户故事应该尽可能是独立的、功能耦合性低的，即用户故事可以按照任何顺序完成。用户故事之间相互独立使得计划制定、优先级排序、工作量估算、效果跟踪等工作更加轻松。

02 Negotiable 可协商

故事的内容可协商，意味着开发人员可以通过与客户或者产品经理的沟通敲定研发细节，而不是遵照用户故事的文字内容展开工作。

03 Valuable 有价值

用户故事的价值性要求是指，当用户故事成功交付，那么使用者就会在产品中获得一些好处或者使用提升。

04 Estimable 可估算

开发团队通过估算用户故事的重要性和工作量，以确定故事的优先顺序。当你发现无法估算一个故事的完成成本，要么你缺乏足够支撑估算的信息，要么故事需要被进一步地分解。

05 Small 足够小

用户故事要尽可能小。在实践中，如果发现一个用户故事里包含了太多的工作，请继续将它拆解直至契合团队工作节奏为止。

06 Testable 可测试

可测试的用户故事要求，除了“WHO-WHAT-WHY”的规范语言外，故事还应该提供清晰明确的验收标准，以确认它是可完成的。

确认需求拆分的终点和判断标准后，就可以回答：如何将需求尽可能地拆小？

四、 需求拆分要落在故事和子任务上

01 用户故事能在一个迭代内完成

在项目里，如果遇到一个史诗级需求，敏捷团队应该结合团队研发能力，在一定的拆分标准下，将需求拆分成若干个能够在一个迭代内完成的故事。

需求的拆分标准有很多，比如用户角色、用户操作、数据来源、工作流程、业务逻辑等等。简单举个例子：

在下一篇文章中，Liga 将会详细介绍需求拆分的方法与实例，请持续关注 LigaAI 。

02 子任务进度可以完成 0/1 判断

Liga 建议，子任务的粒度应该设置为 0.5~1 人/天，且其完成应该符合 0/1 判断标准。子任务完成的 0/1 判断标准是指，子任务只存在「未完成」和「已完成」两种状态，而不是若干个形如「已完成 20%」的状态。

思考：为什么子任务要符合 0/1 判断？

用户故事拆解成符合 0/1 判断的子任务，在敏捷管理、信息透明和自驱培养等方面具有更大的赋能优势。

• 更高效地管理团队和目标

相比没有明确判断标准、容易注有水分的百分比式进度判断，子任务的 0/1 判断能让管理者更加直观地掌握用户故事和迭代目标的完成情况，及时发现滞后的进度并提供支持，赋能敏捷管理。

• 更容易实现跨职能的能力互补

敏捷团队通常是由 3-10 位成员组成的跨职能团队。子任务的 0/1 判断赋予团队极高的信息透明度。所有成员都能看到子任务的完成情况，对迭代进度了如指掌；当团队需要帮助时，能力富余的成员能够主动承担责任，通过坑位互补推进团队目标的完成，加速团队自组织化的形成。

• 更有依据地完成反思与成长

当子任务能被轻松、明确地量化，成员就能借以数据参考判断工作节奏和速率，并在每次迭代结束后，基于数据信息贡献可优化建议。

五、 LigaAI 如何完成需求拆分与管理？

LigaAI 支持史诗级需求的集中管理，团队管理者与成员可在同一面板完成史诗任务的快速创建与跟踪，轻松获取史诗任务的进行状态、需求进度、项目时间等等重要信息。

在 LigaAI 提供的产品需求池中，敏捷团队可以根据需求的具体类型创建新的工作，标记任务优先级并指定需求负责人。无论故事的任务详情清晰与否，团队都可以先行创建需求记录，再统一进行规划管理。

为了更好地管理需求“由大拆小”的过程，LigaAI 支持构建不同故事间的父子级关系，解决团队对大需求全面拆解的层级需要。

在子任务管理方面，LigaAI 免除子任务详情描述，通过完成勾选操作实现对子任务的 0/1 判断，因为经过细化拆解的子任务完全可以通过命名传递任务核心，比如用户故事【增加数据的环形统计展示】的子任务【UI | 添加新的环形图模板】。

同时，Liga 建议对用户故事分配负责人，以便于及时掌握和跟进任务完成情况，而子任务分配具体执行人。如果负责人也有具体的工作内容，可以添加子任务并指定管理者为任务执行者。

六、 Liga 总结

1. 前置需求拆分工作。研发团队应该在迭代计划阶段完成需求拆分工作，让开发专注价值创造，快速实现交付；

2. 将需求拆分到用户故事。敏捷团队应该将需求向下拆分成若干个可以在一个迭代周期内完成的，符合 INVEST 原则的用户故事；

3. 子任务应尽可能小且分工明确。子任务应该满足 0/1 判断，其工作量建议设置为 0.5~1 人/天。