写在前面
今天 Liga 只做三件事情:讲清研发任务层级、梳理需求拆分逻辑、介绍子任务 0/1 判断标准。
在研究不同团队工作习惯的过程中,我们发现了一个很有趣的共性:需求拆分总是伴随着开发阶段进行。
一般情况下,当需求抵达研发团队,会先进入需求池(Product Backlog)等待处理,直到项目 PO 和研发团队完成理解、评估、规划和分工等一系列工作后,才会正式进入开发阶段。
很多团队会在迭代开始后,才开始需求的细化拆分。 这就导致那些看起来不复杂,但其实工作量很大的需求被拆分成几十个甚至上百个子任务,有的甚至需要嵌套 N 层子任务才能触底落到每个开发者身上。此外,这些子任务颗粒度混杂:有的任务可能几个小时就能完成,有的则需要几天、一周甚至更长的开发时间。这势必会带来进度管理上的混乱。
与之不同的另一种处理办法:前置需求拆分环节,在开发阶段专注价值创造和交付,更有条理地管理项目进度。敏捷团队应该在迭代计划阶段(Sprint Planning)将需求拆分到尽可能小的粒度,再推进后续的工作。
正如前面所说,体量更小的需求,有助于更好地规划和统筹团队资源,避免研发过程中的反复讨论和精力浪费。另外,前置需求拆分也会让工作量估算、价值排序、进度规划等工作更加轻松高效。
也因此,敏捷开发一直倡导以“用户故事”替代“需求”来描述将被开发的产品功能。体量更小的“用户故事”有几个显著的敏捷竞争优势:
小而精确的需求更容易在短期内交付。基于完善的优先级排序,敏捷团队可以始终专注于开发更具价值的需求。
更小的需求粒度意味着,敏捷团队需要通过与客户频繁交互来明确需求的真正内涵,将大而模糊的“功能点”拆小、拆细至具体的“场景解决方案”,以满足客户的预期。
小颗粒度的工作更符合“快速交付-快速验证-快速调整-再次交付”的精益循环模式,能帮助团队在滚动开发和定期回顾的过程中,不断磨合工作方式、增进合作,进而实现持续成长,逐步完成目标。
但是,“小需求”的尽头是什么?拆分的结果有好坏标准吗?要回答这两个问题,首先要了解需求的层级有哪些。
在许多的敏捷实践中,根据颗粒度(即任务清晰程度)和优先级顺序的不同,需求通常被分为3个层级,分别是史诗、用户故事和子任务。
史诗(Epic),也称史诗故事,是基于产品长期战略被提出的、颗粒度最大的研发需求,具有跨迭代特性。它通常表示一个可独立使用的产品功能模块或者功能合集,能够被拆分成若干个用户故事并在多个迭代周期中完成。
用户故事,也称故事(在 LigaAI 中以 Issue 表示),是任务需求最清晰的、颗粒度最小的需求,一般要求在一个迭代周期内完成。当需求落到故事层级,敏捷团队就可以通过完成它实现价值交付,因此故事有时也被称为需求的最小可交付单位。
如果说故事是最小可交付单位,那么子任务就是最小可执行单位,在 LigaAI 中以子任务或 Subtask 表示。它是用户故事的完成路径,是组成故事的具体工作事项;只有将若干个子任务全部完成,才能最终交付完整的用户故事。
为了满足研发团队对故事管理的不同需求,LigaAI 使用「父故事」即「父 Issue 」概念定义用户故事间的父子级关系,实现 2 级故事层级管理。
Liga 提示:需求粒度和层级判断不是绝对的。由于业务模式和工作习惯上存在差异,不同研发团队对同一需求的层级判定也可能截然不同。
从需求层级的树状图中不难看出,小粒度需求的终点是用户故事,而子任务是完成故事时,精确到“人/天”单位的实现路径。
极限编程的倡导者 Bill Wake 指出,一个好的用户故事应该遵循 INVEST 原则。
01 Independent 独立
用户故事应该尽可能是独立的、功能耦合性低的,即用户故事可以按照任何顺序完成。用户故事之间相互独立使得计划制定、优先级排序、工作量估算、效果跟踪等工作更加轻松。
02 Negotiable 可协商
故事的内容可协商,意味着开发人员可以通过与客户或者产品经理的沟通敲定研发细节,而不是遵照用户故事的文字内容展开工作。
03 Valuable 有价值
用户故事的价值性要求是指,当用户故事成功交付,那么使用者就会在产品中获得一些好处或者使用提升。
04 Estimable 可估算
开发团队通过估算用户故事的重要性和工作量,以确定故事的优先顺序。当你发现无法估算一个故事的完成成本,要么你缺乏足够支撑估算的信息,要么故事需要被进一步地分解。
05 Small 足够小
用户故事要尽可能小。在实践中,如果发现一个用户故事里包含了太多的工作,请继续将它拆解直至契合团队工作节奏为止。
06 Testable 可测试
可测试的用户故事要求,除了“WHO-WHAT-WHY”的规范语言外,故事还应该提供清晰明确的验收标准,以确认它是可完成的。
确认需求拆分的终点和判断标准后,就可以回答:如何将需求尽可能地拆小?
01 用户故事能在一个迭代内完成
在项目里,如果遇到一个史诗级需求,敏捷团队应该结合团队研发能力,在一定的拆分标准下,将需求拆分成若干个能够在一个迭代内完成的故事。
需求的拆分标准有很多,比如用户角色、用户操作、数据来源、工作流程、业务逻辑等等。简单举个例子:
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 免除子任务详情描述,通过完成勾选操作实现对子任务的 0/1 判断,因为经过细化拆解的子任务完全可以通过命名传递任务核心,比如用户故事【增加数据的环形统计展示】的子任务【UI | 添加新的环形图模板】。
同时,Liga 建议对用户故事分配负责人,以便于及时掌握和跟进任务完成情况,而子任务分配具体执行人。如果负责人也有具体的工作内容,可以添加子任务并指定管理者为任务执行者。
阅读更多「LigaAI」的趣味分享与敏捷实践… 请关注 LigaAI@CSDN,持续接收更多干货分享~ 进一步了解我们的产品,请访问 LigaAI -新一代智能研发协作平台。