本文主要是介绍研发效能工程实践-精益需求管理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
什么是精益管理
精益管理是源于精益生产，是美国麻省理工学院教授詹姆斯.P.沃麦克等专家通过"国际汽车计划(IMVP)对全世界17个国家90多个汽车制造厂的调查和对比分析，认为日本丰田汽车公司的生产方式是最适用于现代制造企业的一种生产组织管理方式
精益管理由最初的在生产系统的管理实践成功，已经逐步延伸到企业的各项管理业务，也由最初的具体业务管理方法，上升为战略管理理念。它能够通过提高顾客满意度、降低成本、提高质量、加快流程速度
沃麦克、琼斯和鲁斯(Womack,Jones&Roos,1996)在《精益思想》中指出，所谓精益思想就是根据用户需求定义企业生产价值，按照价值流组织全部生产活动，使要保留下来的、创造价值的各个活动流动起来，让用户的需求拉动产品生产。而不是把产品硬推给用户，暴露出价值流中所隐藏的muda,不断完善，达到尽善尽美
价值流是指原材料转化为成品赋予价值的过程，识别出价值流，我们测量需求的流动速度，以及如何改进价值流提升需求交付效率
在精益思想中，等待就是浪费。所以我们为了确保价值流的流动性，最大限度的降低等待。如果将大批量的生产改进为单件流，加速流动性
快速迭代，快速试错，以用户为导向改进产品，非常切合当下的互联网公司产品开发模式
精益思想还倡导的是不断改进完善价值流，提升价值流的速度。使用价值流分析法，将流程中的等待流程发掘出来优化
精益需求管理
传统的需求管理，需要花费大量的时间，对产品或项目进行大批量的需求分析，开发周期长，各个流程环节的时间长，某些阶段等待时间长
- 倡导小批量、条目化的方式管理需求，且需求的规模通常都比较小，价值流的流动性快，使得产品可以快速迭代、快速验证
- 精益需求倡导使用故事树的结构来管理需求，将需求按颗粒度抽象层级来管理需求
- 以价值流分析来提升改进研发流程
精益需求管理实现
前面提到过，精益需求倡导使用故事树的结构来管理需求，因此我们需要有一个颗粒度抽象的层级，在我们团队中常使用3层或4层结构来划分
- EPIC：通常指一个版本，这个一般由产品编写
- Feature：一个版本中的一项特性，比如我们经常看到一个软件更新后会列出一个列表说更新那些功能，这个也是最小可交付的需求颗粒度，比如说我们要做一个APP，其中要有一个登录功能，那么这个登录功能就可以是一个Feature，因为一旦这个Feature完成，意味着我们可以交付登录功能。Feature一般也是应该由产品编写
- Story：一个Feature往往是比较大的颗粒度，可能实现它的时间比较长，所以我们要把它拆解成小的故事来实现，也就是精益管理倡导的将大批量需求用小批量来管理，可以加快价值流的流动性。这个一般由开发人员拆解Feature编写。比如拿上边的登录功能为例，这里可能就由前端开发工作和后端开发功能，可以拆分称两个，Story也是我们在代码管理时关联的主要对象，也就是说你提交的代码应该关联到Story
- 实现登录API接口
- 实现登录页面以及接口交互
- Task(可以不需要)：我们把它称为任务，这个一般不是必要的，Task是比小故事更小
- EPIC -> Feature -> Story -> Task
标题应该是一个动宾结构来表示干一件啥事儿，比如：实现登录API接口，实现是一个动词，登录API接口就是宾语
单有标题是不够的，需求单不止给自己看，更是要给其他人看，尤其是测试人员，所以必须要描述清楚。描述更多是表达用户想要的最终实现出来的效果
测试人员要十分关注的东西，验收标准说明了在哪些场景下应该达到什么样的效果。它的大致结构如下
| 假定/假设 | 前置条件 | 动作 | 期望结果 |
|---|---|---|---|
为了方便我们后续做价值流分析，我们必须要监控某一些需求的需求
| 属性 | 取值 |
|---|---|
| 标题 | 动宾结构简要描述 |
| 状态 | 当前流转的状态节点，参照流程设计中的状态节点 |
| 迭代 | 需求所属的迭代，如果使用迭代开发模式 |
| 优先级 | 高、中、低 |
| 预计开始 | 预计开始开发时间 |
| 预计结束 | 预计结束开发时间 |
| 开发人员 | 开发责任人 |
| 需求颗粒度 | EPIC、Feature、Story、Task(非必须) |
| 需求类型 | 产品运营需求、技术需求、运营配置变更需求 |
| 确认启动时间 | 真实的启动时间，避免在统计需求交付周期时取需求创建时间不准确 |
| 测试人员 | 测试责任人 |
| 量化目标 | 可能对哪些业务指标产生影响，当前该指标的数据是什么情况。预估上线后，这些指标的变化 |
| 量化目标达成情况 | 远超预期、超过预期、符合预期、远低预期 |
这里给出了需求状态流转的大致建议，如果没有专职测试人员，比如很多中台项目是没有测试人员的。那么可以走开发中->待测试->测试中->待发布这一流程
在精益需求管理中强调的是小步快跑，快速验证，快速响应。如果我们一个功能版本太大的话，不便于我们精确的掌握开发进度，这时我们可以将大的版本拆分为小的里程牌，然后按迭代的方式来管理需求，这样我们可以已更小的批量来管理需求
每个人对需求拆解的理解都不一样，因此要团队达成共识就必须要做好团队成员的培训工作，让大家在思想上形成统一的标准，这样才能更好的开展后续的工作。否则，标准不统一，那么效能度量的数据口径就不一致，也就是说统计数据将没有意义，也无法衡量团队价值流的流动性，无法完善和改进流程
工欲善其事必先利其器，要想做好精益需求管理必须要有一款趁手的工具
- 自研：灵活、可以和其他devops平台集成，方便后续整个研发流程效能度量
- TAPD：基本的功能都有提供，部分功能要收费，有OpenAPI可以支持一定的集成
- JIRA：老牌的工具，挺贵的
- PingCode：支持私有部署、定制开发
这里也不说哪个好哪个不好，网上都可以很容易找到对比，找到一款适合自己就行
需求管理效能度量
精益需求管理中还倡导完善和改进流程，那么我们要如何才能完善和改进呢？当然我们要先准确度量
- 计算方式
需求开发周期 = S t o r y 增量测试结束时间 − S t o r y 开发开始时间 需求开发周期 = Story增量测试结束时间 - Story开发开始时间需求开发周期=Story增量测试结束时间−Story开发开始时间 - 统计周期：通常一个月
- 作用：衡量团队开发速度
- 计算公式
L e a d T i m e = F e a t u r e 已接受时间 − F e a t u r e 确认启动时间 LeadTime = Feature已接受时间 - Feature确认启动时间LeadTime=Feature已接受时间−Feature确认启动时间 - 统计周期：通常一个月
- 作用: 评估团队交付速度
- 计算公式
发布需求数 = S u m ( 统计周期内达到已交付状态的 S t o r y ) 发布需求数 = Sum(统计周期内达到已交付状态的Story)发布需求数=Sum(统计周期内达到已交付状态的Story) - 统计周期：通常一个月
- 作用：评估团队交付能力
- 计算公式
流负载 = S u m ( 团队未完成的需求 ) 流负载 = Sum(团队未完成的需求)流负载=Sum(团队未完成的需求) - 统计周期：全部
- 作用：衡量团队当前的需求饱和度
上述的指标都是一些结果指标，但是要改进流程必须要找到流程中卡点的地方。价值流分析就是用来寻找卡点流程的方法。在需求流程设计章节中有一副图，里边用不同的颜色标记了，其中浅绿色代表有效节点，蓝色代表等待节点，深绿色代表完成，根据这些不同节点，我们可以绘制出价值流分析图
统计值是平均值，这样我们可以一目了然看到等待节点如果耗时很长，就需要分析原因，然后通过改进流程来缩短这个值
价值流分析准确的前提是需求单的属性值和状态流转都是合规的。如果不合规，那么统计数据就会失去意义，甚至会做出错误决策，因此还需要统计需求的合规性，常见的需求合规性问题
- 停留开发中时间过短，开发没有按照实际情况及时流转状态
- 需求层级设计问题，比如story下又挂了Feature
- 属性值设置问题，比如确认时间设置问题、预计结束时间早于流转至开发中时间等
- 父子状态问题
- 父需求已完成，但是子需求还有未完成
- 子需求已全部流转至开发中，而父需求还没有流转至开发中
总结
上述是我对于精益需求管理的一些看法，希望可以给大家提供一些参考。不对的地方同时也欢迎指正，一起讨论。
这篇关于研发效能工程实践-精益需求管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
