本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。
精益软件开发
2003 年《精益软件开发》书籍的问世，标志着精益理念和实践正式引入软件开发领域，与敏捷软件开发平齐（2001 敏捷宣言），成为新的软件开发方法。敏捷软件开发继承和吸收了众多的精益思想和理念，精益软件开发对敏捷软件开发产生了重大的影响。
精益软件开发将精益生产在制造业的实践映射到软件工程业，并通过类比的方式将精益生产中的七种浪费与映射到软件开发中的七种浪费。
精益软件开发七大原则
1 消除浪费
田生产系统的策划人之一新乡重夫（Shigeo Shingo），他首创制造业的七种浪费类型，而波彭迪克夫妇则将它转换成软件业的七大浪费类型。
精益生产 | 精益软件开发 |
|---|---|
多余加工 | 额外步骤（Extra Processes） |
库存 | 半成品、部分完成的工作（Partially Done Work） |
等待 | 等待（Waiting） |
搬运 | 任务调换（Task Switching） |
生产过剩 | 多余功能（Extra Features） |
运输 | 移动（Motion） |
不良品的返工 | 缺陷（Defects） |
- 额外步骤（Extra Processes）
对需求的过多细化以及不必要的文档工作，额外的步骤（过度处理）不仅仅存在于需求中，还存在于代码中。不少程序员会在代码中去做很多“预防性”工作，譬如预见可能发生的变化或者可能出现的情况，为了为这些变数留有余地，结果通常是在代码中写一些额外的代码。这种做法一方面增加了不必要的复杂性，另外一方面如果“可能的”情况永远没有发生，这些代码就成了负债。设计模式的出现可能会让这种问题缓解很多，然而我们还是要处处留意在开发过程中是否进行了过度的处理。
- 半成品、部分完成的工作（Partially Done Work）
部分完成的工作时软件开发过程中第二大的浪费。在 Lean Thinking 这本书里面，Mary Poppendieck 把制造业的七大浪费之一“存货”对应于软件开发中的需求列表，她这种判断所处的环境是软件需求被写得非常细致，细致到可以直接用于编程的程度，同时这些细化了的需求又不会立马被拿去实现，相反它们会在需求列表中等待相当长的一段时间。当然，毫无疑问这是软件开发中的“存货”之一，然而我认为这并不是全部存货。另外还有一些常见的现象是大部分“已编码完成”的功能不得不等待很长一段时间才会被测试，而被测试了的功能会等待相当长一段时间才拿去被客户验收，这些通通都是软件开发过程中的存货。
- 等待（Waiting）
等待也包括让客户等待。无论是客户的等待，还是开发团队内部的互相等待，都是没有价值的事情。等待也会推迟问题的暴露和解决时间，所以减少等待就是减少浪费。
- 任务调换（Task Switching）
软件开发中上下文切换或寻找信息也是一种常见的浪费。在软件开发过程中，经常要找客户确认或者澄清需求，要向开发者传达设计思路和技术要点，要找团队成员了解项目进展情况，要彼此反应遇到的问题以及解决办法等等，总而言之就是干系人之间彼此需要大量的沟通，所有这些沟通都是信息传递的过程，所以及时准确地传达信息是非常重要的。与此同时，开发团队经常面临的境地是很难找到客户进行需求沟通和确认，或者不得不花费很多时间和精力去寻找各种需要的信息，也经常遇到由误解造成的尴尬和浪费。团队用在寻找信息上面的时间，并不直接创造软件的价值，所以是一种浪费，应当努力去减少。
- 多余功能（Extra Features）
额外的功能特性是软件开发过程中最大的浪费。根据 Standish Group 的调查报告，传统的软件开发过程制造了大量人们不需要的功能特性（7% always used，13% often used，16% sometimes used，19% rarely used，45% never used）。每个功能的实现，都要经历软件开发的整个生命周期：需求分析、设计、编码、测试、发布和维护，这需要耗费大量的人力、物力和财力，如果最终人们将不会用到这些功能，那么所有的投入都变成了浪费。而这还没有考虑过多的功能特性带来的系统复杂度所增加的开销。
- 移动（Motion）
信息在移动的过程中，经手的人越多，需要交接的地方越多，花费的代价就越高。所以减少信息的移动步骤就是减少浪费。
- 缺陷（Defects）
缺陷并不创造价值，缺陷是影响价值交付的一大障碍。软件中的缺陷是一种浪费，如果能采取适当的措施减少 Bug 的出现，就能够减少缺陷修复的时间，将更多时间投入到客户价值创造上。
2 增强学习
面对开发团队以及最终的产品大小的额外挑战，可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示，并听取他们的反馈来完成。
3 尽量延迟决策
因为软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。
4 尽快发布
在一个技术发展非常迅速的时代，尽早的发布产品有助于更快的获得用户的反馈来改善当前产品的质量，从而更快的完成下一次迭代。如果每一次快速的发布都能满足用户的需求，那么这个产品就可以视为成功的。每一次迭代的时间越短，团队内部的学习和交流就会变得更好。拥有了速度，决策会被延迟。拥有了速度，就可以更好的满足客户当前而非昨天的需求。
5 下放权力
传统的团队里都是由团队的领导者来决定和分配每个人所要完成的任务。但是精益开发主张将这种权利下放到团队的每个人手里，从而使开发人员有权利来阐述自己观点并提出建议。
6 嵌入质量
质量的管理在精益软件开发中尤其重要。在这里，质量的保证一开始便被贯穿在开发过程中的每一个阶段，而不只是在测试阶段来发现质量问题。
7 全局优化
全局优化使得每个部门之间的联系更紧密。相对于努力降低每个部门内的成本，消除部门之间的隔阂和浪费会产生更显著的效果。在 DevOps 成为一大趋势的今天，开发部门，质量管理部门和运行维护部门之间的协同变得越来越重要了。
精益产品开发
2017 年《精益产品开发》书籍的问世，从产品角度引入精益思想和精益理念，结合产品开发特点和流程，将精益生产的理念与产品实践进行提炼、适配和优化。
丰田精益生产屋
精益产品开发屋
一个目标
顺畅和高质量地交付有用的价值。
- 顺畅
只价值交付过程要顺畅，用最短的实践完成用户价值的交付，而非断断续续，问题连连。
- 高质量
高质量指符合要求，避免不必要的错误。它与为了探索而进行的必要试错不冲突。
- 有用的价值
价值的交付应该符合市场和用户的需求，并能产生业务的影响，促进组织绩效。
两个支柱
1. 探索和发现有用的价值
探索的目标是发现真正有用的价值，通过探索和发现进行不断的调整，找到可行的商业模式和有意义的产品功能，并持续优化他们。
2. 聚焦和提升价值流动效率
从用户的视角，审视用户价值经历各个流程步骤直至交付的过程，整个过程的时间越短，等待的时间越少，则流动效率越高。聚焦流动效率，就是要从外部绩效出发，协调内部资源最快的交付用户价值。
三个管理实践
1. 精益创业和创新
“精益创业”提倡先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，并灵活调整方向。
执行过程（外环）：遵循构建、度量、学习的循环：
1. 从概念出发构建最小产品；
2. 对产品进行度量获得数据；
3. 验证概念或发现新概念；
4. 进入下一个循环。
计划过程（内环）：与执行过程的循环方向相反：
1. 规划要验证什么概念；
2. 规划需要怎样的数据来验证这一概念；
3. 规划需要构建怎样的最小产品得到数据；
4. 实施后，进入下一循环。
2. 精益需求分析和管理
解决的问题是如何有效的拆分、规划和沟通需求，确保团队能够一致的理解需求，变因分析和沟通不当而带来的缺陷，并为后面价值小批量的持续流动创造条件。
精益价值管理闭环：
1. 价值定义识别价值要素
2. 建立需求价值权重模型
3. 产品功能价值排序
4. MVP 定义
5. 价值验证反馈
3. 精益看板
建立看板
- 可视化价值流动
1. 可视化用户价值。产品的目标是交付用户价值，看板的可视化也应该从用户的视角来组织；
2. 可视化用户价值端到端的流动过程。所谓端到端，是指价值提出到价值交付的整个过程；
3. 可视化问题和瓶颈。问题是指那些阻碍用户价值流动的因素，如需求不明确、技术障碍、外部依赖等。
- 显示化流程规则
显示化流程规则是指明确价值流转和团队协作的规则并达成共识。显示化的流程规则是团队协作的依据，更是团队改进的基线。
- 控制在制品数量
1. 控制在制品数量加速了用户价值的流动，对产品开发的敏捷性至关重要；
2. 控制在制品数量帮助团队暴露瓶颈和问题；
3. 控制在制品事实上形成一个拉动机制，下游顺畅时才能从上游拉取新的工作，最终拉动整个价值流动的用户价值交付。
运作看板
- 管理价值流动
1. 管理价值流动的输入：就绪队列填充活动。就绪队列是看板系统输入和价值流动的源头。
2. 管理价值流动的中间过程：看板站会。
3. 管理价值流动的输出：发布评审。
- 建立反馈持续改进
反馈
1. 流动是否顺畅的反馈，如阻碍问题分类、影响和原因分析等；
2. 质量问题的反馈，如开发环节或测试环节遗漏缺陷的正交分析和分类。
改进
1. 团队协作流程
2. 产品的设计及内部质量
3. 团队的结构及人员能力
4. 环境及工具的改进
精益产品开发价值与影响
传统的产品开发把内部资源作为中心，在实践上强调任务的分解与分配，以及计划的制定、执行、跟踪和控制。假设通过局部效率的改进，可以提升整体效益。敏捷开发开始聚焦从内部资源，转向用户价值，强调迭代价值交付，由多功能的小团队直接面向价值和交付用户价值，并通过迭代反馈，不断调整。
精益产品开发则完成了范式转化。它明确了把用户价值作为核心，围绕用户价值的流动，协调和优化端到端和整个组织的交付过程。从传统到敏捷和精益，完成了从内部资源为核心，到用户价值为核心的范式转化。
