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

阅读本文你将收获: 1、精益需求有哪些价值 2、精益需求的实现过程由哪几部分构成 3、京东的精益需求案例分析及注意误区;

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

本文正文内容共计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研发效能分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在思码逸网站留下联系方式,我们将在24小时内回复。或拨打电话400-863-7426:

与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消