如何做好研发精益需求管理

本文正文内容共计 3836 字，建议阅读时间：8 分钟。

阅读本文你将收获：

1、精益需求有哪些价值

2、精益需求的实现过程由哪几部分构成

3、京东的精益需求案例分析及注意误区

作者简介

赵卫，前京东首席敏捷 DevOps 布道师、首席 DevOps 研发效能架构师、敏捷创新教练，IBM 敏捷及 DevOps 卓越中心前主管，Ivar Jacobson 前资深敏捷咨询师，著作《京东敏捷实践指南》《DevOps 三十六计》，2013 年规模化敏捷框架认证咨询顾问 SPC，SAFe 官方贡献者从 2014-2021 年连续八年在敏捷中国/TID 演讲，2021 DevOpsDays 上海演讲，2020《项目管理评论》分享，2020 CSDI 中国软件研发管理行业技术峰会演讲

本文来源：赵卫老师的研发效能系列文章，本文全篇收录于 QECon 组委会发布的白皮书之《研发效能实践指南》

‍

01. 精益需求概述

‍

需求是产品开发的前提，是研发效能的起点，传统的需求需要花费大量的时间对整个产品或者整个项目进行大批量的需求分析。而精益的做法是小批量，甚至是单件流的方式，Scrum 框架的做法是围绕着产品待办列表 Product Backlog，以演进的方式，在待办列表里为未来 1-2 个迭代准备一小批就绪的需求。所以精益需求就是小批量的条目化的需求，并且每个条目的需求的规模或者说颗粒度都比较小。离散的较小颗粒度的条目化的需求，比较容易只见树木不见森林，让敏捷团队很快就会失去对整个产品的全量需求的全局观和产品演进的方向感，所以精益需求也有自己的需求架构，通常会由不同层级的树形结构来管理整个产品需求树。

‍

02. 精益需求的价值

‍

首先，需求不能百分百预测一定可以为用户带来巨大的价值，所以产品开发也可以说是假设驱动的开发，精益需求可以用较小的代价，优先实现重点关注的假设，上线之后，根据用户的反馈持续优化打磨产品，而无需花费巨大的代价和浪费开发出用户不使用的功能。

根据斯坦迪什集团（Standish Group）主席吉姆·约翰逊（Jim Johnson)，在撒丁岛举行的 XP 2002 会议上所做的主题演讲中提到：“产品中 64% 的功能是很少使用或从未使用过”，尽管他针对的是四个内部项目而不是商业产品，也比较有代表性的说明产品开发中存在着巨大的浪费，所以精益需求可以为我们节约很多不必要的成本。

图 1：软件功能的使用情况(2)

‍

其次，精益需求可以帮助我们进行最小化可行产品 MVP 的规划。大多数产品经理会错误的定义自己产品的 MVP，他们往往将想要实现的完美的完整的功能分成几个批次，简单命名为一期需求，二期需求等等，并且称之为 MVP 版本。实际上如果使用了带有层级的条目化需求，每个条目化需求的范围都比较小比较专注某个场景，那么多个需求条目组成的一小批需求才是真正的 MVP，可以为用户带来闭环的最小的、最核心的、闭环的可以使用的业务场景。

‍

‍最后，精益需求也比较好的帮助团队进行沟通，提高沟通效率以及理解需求的效率，例如在澄清需求的时候，以这种话术讲述，效果会更好：“这次会议要评审 10 个需求，分别是...，现在讲解第一个需求...大家有什么问题么？...没有问题的话，开始讲解第二个需求....。”

‍

03. 精益需求的实现

‍

●使用用户故事表达精益需求

‍

精益需求通常由产品负责人编写和维护，在开始编写产品需求文档 PRD 之前，通常使用用户故事的格式来编写，因为用户故事是条目化的需求，并不需要花费大量的时间像 PRD 那样进行详细的设计。用户故事是从用户的角度讲述并用他们的语言编写的一小段功能的简短描述，直接向最终用户提供功能。每个用户故事都是一个小的、独立的行为，可以逐步实施，并为用户或解决方案提供一些价值。它是用户与系统交互的一个垂直纵切的功能片段，可确保每次迭代都能带来新的价值。较大的用户故事被分成较小的故事，因此可以在一次迭代中完成。

图 2：面向用户的纵向切片

‍

用户故事为业务和技术人员提供了足够的信息来理解意图。细节推迟到故事准备好实施（迭代计划）之前。通过验收标准（Acceptance Criteria）和验收测试（Acceptance Test），故事变得更加有价值、具体，有助于确保做有价值的事，并且高质量正确的交付。用户故事专注用户价值，包括描述和验收标准，格式如下：

（1） 用户故事标题：

动宾词组。

（2） 用户故事描述：

作为（用户角色），我希望/想要（系统提供的功能），以便/所以（这样我就能/实现什么业务价值或目标）。

（3）验收标准：

假设/假定(Given)上下文、前置条件，

当（When）执行某些事件、行动或操作，

那么（Then）获得可观察到的结果。

●用户故事具有 3C 特征

‍

1、卡片（Card）——用索引卡/卡片/便签条记录用户故事，代表用户需求，而不是需求的详细记录。卡片上同时可记录工作量估算、优先级和验收标准。2、对话（Conversion）——敏捷团队通过面对面交流获得用户故事的细节。好的创意来源于交流，文档代替不了交流，也不能完整准确记录所有需求。PRD 需要用户故事做索引，同时作为用户故事的补充细节文档，例如界面原型设计等。3 确认（Confirmation）——用验收标准、验收测试用例来确认和记录用户故事开发完整度和正确性。

‍

●用户故事的 INVEST 原则

‍

1、独立的（Independent）——用户故事应该尽可能独立于另一个。故事之间的依赖关系使规划、优先级排序和估算变得更加困难。每个用户故事代表对用户有意义的一个回合的交互。通常，可以通过将故事组合成一个或通过拆分故事来减少依赖性。有的时候多个用户故事组成的业务闭环的业务流程，才对用户和企业真正有价值，例如，京东购物 App 的黄金流程，需要根据业务流程的先后，排定顺序。

‍

2、可讨论的（Negotiable）——用户故事是可以协商，因为耗费巨大精力详细描述的需求也避免不了误解和需求变更。所有故事的“卡片”只是故事的简短描述，占位符，它不包括细节。细节在“对话”阶段制定。带有太多细节的“卡片”实际上限制了与客户的对话。

‍

3、有价值的（Valuable）——每个故事都必须对客户（用户或购买者）有价值。这种价值有可能是有形的，例如提现、支付等；或者是无形的，例如搜索商品、查看商品详情页等。只要对用户产生积极作用，触发、推动或者激励用户进一步的旅程，都是有价值的，值得投入人力实现。

‍

4、可估计的（Estimable）——开发人员需要能够估算用户故事的规模，以便对故事进行优先级排序和规划。使开发人员无法估计故事的问题是：缺乏领域知识（在这种情况下，需要更多的对话）；或者如果故事太大（在这种情况下，故事需要分解成更小的故事）；或者需求模糊只有大概的概念（在这种情况下，需要进一步细化）；或者技术实现由很大的不确定性（在这种情况下，可以分解成一个技术故事 Spike 探针来进行研究和实验）等等。

‍

5、小的（Small）——好的故事应该很小，规模适合在一个迭代中完成。这里的规模代表开发和测试达到潜在可上线的程度。

‍

6、可测试的（Testable）——故事必须是可测试的，成功通过测试可以证明开发人员正确的实现了故事，如果不能被测试，就不知道何时被完成。同时也不能在迭代评审会议中演示完成效果。

●精益需求的层级表达

‍

精益需求使用故事树来划分不同层级的需求。

‍

图 3：故事树示例(3)业界里通常使用三个层级来管理条目化的需求，如下图所示，一个维度是按颗粒度来区分父子关系。

图 4：需求与任务层级结构(4)

‍

一个维度是按需求条目的目标抽象程度来区分，例如故事地图将目标抽象程度分为三个目标层级：

1、用户活动（User Activity）——最抽象、最粗粒度、最高层的用户目标，像空中的“风筝”一样称之为摘要级任务（Summary-level task）。例如：“管理邮件”。

2、用户任务（User Task）——较具体、较详细、中层的用户目标，像“海平面”一样称之为功能级任务（Functional-level task）。例如：“管理邮件”按照增删改查维度拆分的“读取邮件、删除邮件、查找邮件、撰写邮件”等。

3、子任务（Sub-tasks）——最小颗粒度、最具体、最底层的细节、替代、变化和异常等用户目标，像“海平面”任务下的“小鱼”任务一样，称之为子任务。

‍

例如“读取邮件”拆分的：打开基本文本邮件，打开富文本邮件，打开 HTML 邮件，打开附件等。如上三种目标抽象的比喻，实际上来源于 Alistair Cockburn 的《编写有效用例》，而用例是传统的需求工程的一个方法。在进入敏捷时代之后，用例的发明人之一雅各布森博士又发布了《用例 2.0》将用例进一步切分成更小的用例切片，实际上这种用例切片等同于用户故事，所以需求可以使用两级层级来表达，父级就是用例，子节点就是用户故事。

图 5：用例 2.0 按场景/流拆分成故事(5)

图 6：用例拆分为用户故事和任务示例在规模化敏捷框架 SAFe 中，需求可以是三层结构或者是四层结构(6)：

1、三层结构是：Epic（史诗）-> Feature（特性) -> Story（故事）

2、四层结构是：Epic（史诗）-> Capability（能力）-> Feature（特性) -> Story（故事）

在产品部落敏捷研发章程 ADAPT（Agile Development Agenda for Product Tribe）中，需求是两层结构(7)：

1、需求：提供完整业务价值，能够细化到一次发布完整上线的程度。

2、系统功能：需求被拆分到不同系统，每个系统功能必须对应到一个系统，建议每个系统功能不超过 10 人天开发工作量。

图 7：产品部落敏捷研发章程的二层需求结构（需求+系统需求）精益需求的层次结构无论分成 2 级，3 级还是 4 级，都具备如下特点：

1、面向用户的场景、用户与系统的交互

2、按颗粒度或者目标抽象层次划分

3、叶子节点的故事/需求条目，通常可以在一个 2 周迭代内开发测试完成

4、通常使用 2-3 级，Use case/Feature -> Story, 需求->系统任务，业务需求->产品需求，或者 Epic -> Feature -> Story

5、口语表达简单可以称呼为大故事，中故事，小故事

‍

04. 案例研究：京东的精益需求

‍

原始的产品需求条目：

‍1)   需求描述【离职流程】在 PS（人力资源管理系统 Oracle PeopleSoft）中抓取是否有福利房的信息，自动推送给行政和人力资源业务伙伴 BP，并提醒员工启动退房流程。行政节点增加【福利房】一项，若员工有有效福利房，则为必填。

‍2)   细节详情自动推送就是邮件发送；提示员工退房的文案随后提供；行政福利房必填字段是：已退房、未退房。优化之后的需求条目：

‍3)   用户故事标题作为办理离职的员工，我希望将福利房交还给公司，以便在很短的时间之内（例如：10 分钟之内）办完离职手续

‍4)   用户故事描述【离职流程】在 PS 中抓取是否有福利房的信息，自动推送给行政和 BP，并提醒员工启动退房流程。行政节点增加【福利房】一项，若员工有有效福利房，则为必填。自动推送就是邮件发送；提示员工退房的文案随后提供。行政福利房必填字段是：已退房、未退房。

‍5)   验收标准

‍（1）假定员工有福利房，当启动离职流程后，那么员工自动收到邮件。

（2）假定员工没有福利房，当启动离职流程后，那么员工不会收到邮件。

（3）假定员工有福利房，当员工收到邮件，那么员工看到邮件里的文案，简单明了没有异议。

（4）假定行政节点行政福利房字段内容不选择，当启动离职流程后，那么期望的系统现象是…

（5）假定选择已退房，当启动离职流程后，期望的系统现象是…

（6）假定选择未退房，当启动离职流程后，期望的系统现象是… 这个用户故事和验收标准的示例表达了重点：验收标准强调的是作为用户，作为测试，有哪些场景、路径、测试要点，经过这些“总结”性的要点，开发人员和测试人员就可以更好的理解这个需求，同时在写代码的时候可以有针对性地去写 if…else…。

05. 精益需求的误区

‍

●需求条目的颗粒度比较大○可以使用用户故事拆分技巧

●先写需求文档，再产出条目化的需求○先产出需求条目，再按优先顺序逐个细化

●一次讲解一大批需求○按迭代小批量，讲解需求

●按照软件架构的模块，或者业务的模块编写需求，没有按用户视角编写需求条目○可以使用用例技术○可以使用设计思维的人物角色技术

●用户故事缺少验收标准○可以使用简单的场景描述○可以使用 Given-When-Then 格式

●需求条目没有优先级，或者优先级都是高○按照先后顺序排列，决定开发测试顺序

●缺乏需求的全局业务流程○复杂需求，仍然需要使用业务流程图表达○串联多个需求条目

●缺乏状态机○复杂需求，仍然需要使用状态机表达状态

●缺乏文档○仍然需要文档，轻量化描述需求，编写更有价值的信息○可以存档、沟通、传承

——结束——

如果您想了解更多关于研发效能的内容，可查看思码逸网站获取；

思码逸 Merico 研发效能分析平台，致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点，提升研发效率与软件工程质量；

欢迎在评论区交流探讨！