精益（Lean）思想来自制造业，21 世纪初由Tom 和Mary Poppendieck 引入软件开发领域，精益的很多思想也被认为是对软件行业有参考价值。与Scrum所提供的的过程管理框架不同，精益更多体现为一种思维方式，精益的思维方式也常被称为精益思维（Lean Thinking）。
1. 精益思想
精益是敏捷开发的一个重要部分。当把精益制造的一些思想应用到软件开发中时，我们从敏捷开发的其他组成部分中借鉴了一些东西。和敏捷开发一样，精益思想也包含一些价值观，这些价值观中的一部分入尽快交付、增强学习等与敏捷思想完全一致，但也有有一些思想代表着精益的特有思维，最具代表性的就是消除浪费，即找出那些不能直接帮助你创造出有价值软件的工作，把它们从项目当中去掉。关于软件研发过程中的浪费现象可以总结为：
- 部分完成的工作：部分完成但没有最终落地的工作
- 未应用特性：开发完成但没有被客户应用的特性
- 额外过程：开发过程中不需要的流程和中间产物
- 再次学习：人员、环节变动导致反复重新学习
- 信息移交：隐性知识信息的传递总是伴随信息丢失
- 任务切换：多任务工作会导致效率下降
- 资源依赖：因任务或资源相互依赖而导致工作停滞
- 系统缺陷：解决缺陷活动本身就是浪费
对这些浪费现象的分析思想来自于丰田制造系统（TPS），并在软件行业中得到映射，精益软件开发过程的倡导者们虽然为我们总结了这些浪费现象，但对如何识别这些浪费进而消除和压缩这些浪费都没有提供很明确的实践方法。我们需要在日常研发过程中观察这些浪费现象进而找到消除和压缩实际研发过程浪费的工作方法。
2. 精益中的管道管理
在《敏捷软件开发工具》一书中推荐了一种简单的方法来帮助你找出浪费，这种方法就叫作价值流图（Value Stream Map）。跟其他精益技巧一样，价值流示意图源于制造业，但是它同样适用于软件团队，如图8-14所示的就是一个典型的价值流图。
要想得到类似上图中的价值流图也比较简单，首先从团队已经开发并交付了的一个产品功能开始，回想这个功能单元从设想到交付经历了哪些步骤。在纸上为每一个步骤画一个方框，用箭头把各个方框连起来。接下来，估计一下完成第一步需要多少时间以及第一步完成后要等多长时间才能开始第二步。对每个步骤进行相同的估计，并且在方框的下方划线来表示工作和等待的时间。
价值流示意图清晰地显示了该流程中涉及多少等待的时间，从团队开始改项目到最终交付，一共花了XX天。在这XX 天中，有XX天花在了等待而不是工作上。这些等待时间可能是多种原因导致的：需求文档可能需要很长时间才能送交所有的评审者；或者工时估计会议必须延后，因为大家已经有其他安排了等等。价值流示意图展示了对该特性的各种延迟所造成的累加效果，看到这种整体的影响，可以帮助你进一步探究哪些延迟是浪费，哪些是必要的。
结合管道理论，实际上图中的每一个都可以看做是一个管道，所以价值流图就是各个管道的负载流转图。如果下一个管道处于等待上一个管道的结果，那么这个管道就处于空置状态，而如果某一个管道上的开发任务与其他管道上的开发任务比例严重不匹配，也就会导致因为管道之间数据流转不平衡导致浪费。我们可以经常看到开发过程中出现如下的不良现象：
- 让每个人确认某规格文档要花很长时间，而与此同时开发人员则坐在那干等着项目开工。甫一开工，他们就已经落后进度了。
- 开发到一半，开发团队意识到软件设计或架构的一个重要部分需要更改，但是这会导致非常严重的问题，因为有很多其他部分依赖它。
- 质量控制团队要等到每一个特性都开发完毕才开始测试软件。质量控制团队发现了一个严重的bug 或者一个严重的性能问题，而开发团队不得不进行抢修。
- 分析和设计花费的时间过长，导致进入编码阶段时，每个人都需要加班加点地赶工期。
- 即使是对软件规格、文档或者计划的最小修改都需要经过一个冗长的修改控制流程。大家为了绕过该流程，于是甚至把大型的、颠覆式的修改都放到bug 跟踪系统里面。
基于价值流图和管道理论，我们可以使用拉动式（Pull）系统帮助团队消除以上问题。所谓拉动式系统，指的是通过使用队列或缓冲区来消除约束的一种运作项目的方法或流程。它也源自日本的汽车制造业，但对于开发软件也非常有用，原因并不意外，跟它对制造业有用的原因相同。与其让用户、经理或者项目负责人把任务、特性、请求“推送”给开发团队，不如让他们把这些请求送入一个队列，由开发团队自己从该队列中拉取。当工作发生堆积并在项目中途导致分配不均衡时，他们可以创建一个缓冲区来解决。开发团队在整个项目中可能会用到好几个不同的队列和缓冲区。事实表明，这是一种减少等待时间、消除浪费的有效方法，同时也是帮助用户、经理、产品所有者和软件团队决定开发什么样软件的有效方法。
下面我们举一个拉动式系统如何解决一个熟悉问题的例子：软件团队需要等待所有的特性都写入一个大型规格文档，而后者还必须要经过一个冗长的审核流程。或许该流程为的是征求每个人的意见；也许它不过是那些不敢真正承诺的老板或利益干系人的一种保护自己的手段；或者它干脆就是公司一直以来习惯的做事方法，从来没人想到它其实是一种浪费。如果我们用一个拉动式系统来替换它，会是个什么样子呢？
建立一个拉动式系统的第一步是把工作分解成小型的、可供拉取的块。也就是说，不要编写一个大型的规格文档，而要把系统分解为最小可交付特性，比如一个个独立的用户故事，可能还有针对每个故事的少量文档。这些故事可以单独地进行审批。一般来讲，当一个规格文档审查流程长时间停滞不前时，原因通常是大家对某些特性有不同看法。对每个可交付特性进行单独的审批应该至少能够让一部分特性快速得到批准。只要有一个可交付特性通过了批准，开发团队就可以开始进入开发阶段。
拉动式系统可以很好地消除工作的不均衡并防止团队的超负荷工作。上述关于拉动式系统的思想和做法体现的正是8.1.2节中介绍的管道负载分析方法，可以认为精益思想也是管理理论的一种具体表现形式。
3. 识别浪费的其他方法
除了价值流图，还有其他一些方法可以用于识别开发过程中的浪费：
（1）项目输入过滤
研发过程通常面向产品，而企业级应用或半互联网半企业级应用的产品最终通过项目进行实施和落地，这样项目线就成为研发过程的一个重要输入，而项目经理们站在项目线和客户的立场上提出来的需求和计划往往会和产品线、研发线有一定出入。如果本不应该进入研发环节的输入最终进入了研发环节就势必会导致浪费。如何通过规划和分析去把控来自项目上的输入，让项目线需求能够尽量和产品线一致是降低研发成本、消除浪费的一个重要方面，所以项目输入也是我们寻找浪费的一个来源。
（2）会议聚焦
我们不得不经常召开这种或那种会议，那开会是一种浪费吗？很多时候是的。会造成浪费的会议通常会有一些共性，典型的有：
- 输入输出不明确
- 缺少主持人或主持人不善于引导
- 会议不是结果导向、无法形成有效决策
- 会议议程空泛而不能收敛
- 会议虽然能达成一致，但没有具体工作安排和责任人制度
- 即使有工作安排但缺乏跟踪和监控机制
- 会议相关的资料没有充分准备，也没有提前交付到参会人员
具有上述特点的会议很大程度上不会有实质性的成果，开完一次之后还需要开第二次，如果把握不好浪费的不但是时间还是团队的气氛，需要进行分析和识别，看看我们每天的会议中是否具有以上问题。
（3）数据传递有效性对比
目前主流的研发管理方法论中普遍认为沟通和协作是研发成功的关键性因素，而沟通和协作的背后体现的实际上就是数据传递过程的有效性。如果有两个研发团队，其中一个团队中数据从团队中的一个人传递到另一个人的过程无论在时间上或空间上都比另一个团队有效，那两个团队的战斗力无疑是不一样的。数据传递在沟通模式、媒介、工具等各个方面都可能存在效率不高甚至不合理的地方，浪费也就在这些地方不断的滋长，从而消耗着研发团队的战斗力。
（4）管理活动梳理
有人说团队如果足够自组织（Self-Organization），那我们就不需要管理。这句话虽然听起来有一定道理，但未必太过虚无缥缈。但从管理工作本身入手分析其在工作流程、文档管理、任务分配等各个方面上是否存在冗余或者不合理的管理活动确实不失为一种识别浪费的实践。管理是需要成本的，管理做的好、做的精细更加需要成本，但管理过程本身也可能像代码一样需要随着研发过程和团队的演变不断进行重构，重构的前提也就是需要我们对管理活动进行分析和梳理，找出其中的浪费之处并进行消除或压缩。
（5）流程执行力
无论是好的管理模式和理念，还是适合团队的研发模型，要想取得令人满意的效果，归根揭底还是需要执行力。执行力来自很多方面，如合理的团队组织架构、优秀的人才、高效的工具、良好的团队气氛等，这些通常都不是技术所能起决定作用的领域，却实实在在影响着团队的执行力。流程本身可能是合适的，但因为执行的人不行、或因为工具使用不当导致效率降低，这通常都是属于无法避免但是需要进行压缩的浪费形式。
通过识别，团队中的浪费现象已经摊在大家面前。其中有很大一部分的浪费属于存粹浪费，这些浪费需要通过一定的思路和工作模式进行消除；而对有些浪费通常是必要的，也是不可避免的，对这些浪费而言，我们的思路是尽量进行压缩。关于如何消除存粹的浪费以及如何如何压缩必要的浪费我们会另起一篇文章详细讨论。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
