共计 3362 个字符，预计需要花费 9 分钟才能阅读完成。
写在后面
明天 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 用户故事能在一个迭代内实现
在我的项目里，如果遇到一个史诗级需要，麻利团队应该联合团队研发能力，在肯定的拆分规范下，将需要拆分成若干个可能在一个迭代内实现的故事。
需要的拆分规范有很多，比方用户角色、用户操作、数据起源、工作流程、业务逻辑等等。简略举个例子：
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 总结
- 前置需要拆分工作。研发团队应该在迭代打算阶段实现需要拆分工作，让开发专一价值发明，疾速实现交付；
- 将需要拆分到用户故事。麻利团队应该将需要向下拆分成若干个能够在一个迭代周期内实现的，合乎 INVEST 准则的用户故事；
- 子工作应尽可能小且分工明确。子工作应该满足 0/1 判断，其工作量倡议设置为 0.5~1 人 / 天。
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。
