精益之识别和消除研发过程中浪费的思路和模式
本文基于精益思想和精益软件开发，针对研发过程中的“浪费现象”进行深入分析。浪费分成存粹的浪费和必要的浪费，当中存粹的浪费须要消除，而必要的浪费能够进行压缩。结合日常研发过程，本文对怎样识别这些浪费、假设消除存粹的浪费以及怎样压缩必要的浪费进行剖析，并提供思路和模式。
一．理论基础
精益思想来自制造业，引入软件行业只是10年，眼下非常多理念还是停留在理论阶段，非常难在实际研发过程中进行直接应用和推广。精益的非常多思想个人觉得是对软件行业有參考价值的，比如本文的主题“消除浪费”。关于软件研发过程中的浪费现象能够总结为：
- 部分完毕的工作：部分完毕但没有终于落地的工作
- 未应用特性：开发完毕但没有被客户应用的特性
- 额外过程：开发过程中不须要的流程和中间产物
- 再次学习：人员、环节变动导致重复又一次学习
- 信息移交：隐性知识信息的传递总是伴随信息丢失
- 任务切换：多任务工作会导致效率下降
- 资源依赖：因任务或资源相互依赖而导致工作停滞
- 系统缺陷：解决缺陷活动本身就是浪费
二．怎样识别浪费？
我们有了理念，下一步是行动，首当其冲就是要识别研发过程中的浪费，个人总结例如以下识别浪费的模式：
1. 价值流图
价值流图（Value Stream Mapping, VSM）是精益思想中用于消除浪费的主要工具，其作用就是帮忙我们找到研发流程中哪些环节中存在浪费现象，整个生命周期中有多少时间是用在创造价值，又有多少时间是存粹的浪费。传统的软件研发过程价值流图能够抽象成例如以下（下方坐标中凹下去的部分代表产生价值的时间，突起的部分表示浪费的时间）：
2. 项目输入过滤
研发过程通常面向产品，而企业级应用或半互联网半企业级应用的产品终于通过项目进行实施和落地，这样项目线就成为研发过程的一个重要输入，而项目经理们站在项目线和客户的立场上提出来的需求和计划往往会和产品线、研发线有一定出入。假设本不应该进入研发环节的输入终于进入了研发环节就势必会导致浪费。怎样通过规划和分析去把控来自项目上的输入，让项目线需求可以尽量和产品线一致是减少研发成本、消除浪费的一个重要方面，所以项目输入也是我们寻找浪费的一个来源。
3. 会议聚焦
我们不得不常常召开这样的或那种会议，那开会是一种浪费吗？个人认为非常多时候是的。会造成浪费的会议一般会有一些共性，典型的有：
- 输入输出不明白
- 缺少主持人或主持人不善于引导
- 会议不是结果导向、无法形成有效决策
- 会议议程空泛而不能收敛
- 会议尽管能达成一致，但没有详细工作安排和责任人制度
- 即使有工作安排但缺乏跟踪和监控机制
- 会议相关的资料没有充分准备，也没有提前交付到參会人员
具有上述特点的会议非常大程度上不会有实质性的成果，开完一次之后还须要开第二次，假设把握不好浪费的不可是时间还是团队的气氛，须要进行分析和识别，看看我们每天的会议中是否具有以上“smell”。
4. 数据传递有效性对照
眼下主流的研发管理方法论中普遍觉得沟通和协作是研发成功的关键性因素，而沟通和协作的背后体现的实际上就是数据传递过程的有效性。假设有两个研发团队，当中一个团队中数据从团队中的一个人传递到还有一个人的过程不管在时间上或空间上都比还有一个团队有效，那两个团队的战斗力无疑是不一样的。数据传递在沟通模式、媒介、工具等各个方面都可能存在效率不高甚至不合理的地方，浪费也就在这些地方不断的滋长，从而消耗着研发团队的战斗力。
5. 管理活动梳理
有人说团队假设足够“自组织”，那我们就不须要管理了。这句话尽管听起来有一定道理，但未必太过虚无缥缈。但从管理工作本身入手分析在工作流程、文档管理、任务分配等各个方面上是否存在冗余或者不合理的管理活动确实不失为一种识别浪费的实践。管理是须要成本的，管理做的好、做的精细更加须要成本，但管理过程本身也可能向代码一样须要随着研发过程和团队的演变不断进行重构，重构的前提也就是须要我们对管理活动进行分析和梳理，找出当中的浪费之处并进行消除或压缩。
6. 流程运行力
不管是好的管理模式和理念，还是适合团队的研发模型，要想取得令人惬意的效果，归根揭底还是须要运行力。运行力来自非常多方面，如合理的团队组织架构、优秀的人才、高效的工具、良好的团队气氛等，这些通常都不是技术所能起决定作用的领域，却实实在在影响着团队的运行力。流程本身可能是合适的，但由于运行的人不行、或由于工具使用不当导致效率减少，这通常都是属于无法避免可是须要进行压缩的浪费形式。三．怎样消除存粹的浪费？
通过本文第二部分的识别工作，团队中的浪费现象已经摊在大家面前。当中有非常大一部分的浪费属于存粹浪费，这些浪费须要通过一定的思路和工作模式进行消除。个人总结下面9条作为消除浪费的主要实践：
1. 项目线的介入时机
首先我们来看研发团队的外围接口，这里把项目线看作是与产品研发线并列的另外一条工作线，这样项目线介入产品研发的时机就很重要。參考“怎样识别浪费”中提到的价值流图，我们能够看到第一步是项目线提出开发要求，然后第二步召开需求评审会议，第三步才是正式启动技术开发工作。假设项目线介入时机不合适的话，在第一步和第二步之间可能会有一个时间区间，第二步和第三步之间也可能会有一个时间区间，一方面步骤之间的时间区间本身就是浪费，并且对二步而言，需求评审之后假设技术开发迟迟不能開始，不管从需求管理和风险管理上而言都存在变数，这些变数的表现形式就是步骤内容须要调整甚至又一次来过，从而造成浪费。
2. 研发范围管理
范围管理是消除浪费过程中比較easy联想到的关注点，由于范围决定着开发工作量。从项目管理上讲，避免范围“镀金“和范围”潜变“是范围管理的一个课题；从研发过程上讲，如今”简单设计“、”涌现式设计“等理念也被越来越多的研发团队所推崇。研发范围管理一方面要关注由于项目/产品团队提出的一些不必要、不符合产品战略的功能需求，也要在开发者内部进行诊视，看是否有过度设计等现象的存在。
3. 高效决策
决策是行动的源头，源头假设没有把握好，兴许全部环节都可能是一种浪费，这是我们面对决策的一个视角；还有一个视角就是决策是正确的，但决策的过程是否高效。
关于决策一个关注点是决策支持过程，包含决策前数据准备、人员安排、产品调研等多个方面，这样做的必要性在于确保决策的正确性，避免出现拍拍脑袋就拍桌子的现象，这个过程通常由公司高层主导，研发团队进行配合。还有一方面，在上文“怎样识别浪费“中我们提到了一项实践叫会议聚焦，通常这能够是我们消除决策浪费的一个切入点。个人对全部召开的会议都要求使用会议邀请邮件，这个会议邀请邮件在部门级别形成邮件模板，该邮件模板对会议的输入、输出、议程进行说明，以便与会人员会前能够准备、会后能够回想，可參考：XXXX相关人员定于XXXX召开XXXX会议。
会议输入：
1. XXXXX，请參考SVN地址
2. XXXXX
会议议程：
1. XXXXX，XXX主导
2. XXXXX，XXX主导
会议输出：
1. XXXXX，落实人员和时间安排
2. XXXXX
请各位做好会议前的准备，有不论什么疑问请与我联系。
一个议题明白、输入完备、责任人导向的会议能确保决策的高效性，避免出现浪费。
4. 跨职能团队
跨职能团队用于消除在信息传递过程中为了确保信息有效性而产生的浪费。跨职能研发团队成员主要包含项目线、产品线、技术线、质量保证线等，大家环绕某一个产品线/平台开展全部工作，确保坐在一起并可以实时、面对面沟通。互联网开发环境下，跨职能研发团队还可能包含运营、客服等角色，但销售、市场等相关人员通常不在该团队中。这实际上是一种强矩阵的团队组织结构，全部人保持在同一认识水平和工作节奏中。针对从“数据传递有效性“、”流程运行力“中识别出来的浪费，非常多都可以通过该项实践进行消除。
5. 根本原因分析
缺陷本身就是一种最大的浪费。在开发过程中，bug不可避免，但这些bug的背后可能有其必定性，非常多时候并非开发者或者技术本身的问题，根本原因分析的目的就是帮忙我们找到出错的背后是否有其必定性，然后通过分析这些必定性并提供解决方法，从而避免类似bug的再次发生。经常使用的根本原因分析工具包含5个why、鱼骨图等。
6. 产品功能标准化
标准化有非常多层含义，项目管理标准化、产品功能标准化、开发流程标准化等都属于这一范畴，这里重点讲一下产品功能的标准化。当一个产品面向多个项目时，产品标准化就是消除浪费必需要做的一件事情。大家能够想象一下，假设每一个项目都有不同的输入，这些输入尽管都长得差点儿相同，但假设没有产品的标准化平台，来一个项目还得东抄一些代码、西拼一个功能，不但开发周期变长导致浪费，并且系统本身也会由于确保标准化而滋生bug，导致进一步的浪费。面对处于发展期的产品线功能，开发一套产品线功能，每次来项目时依据产品线生成框架再在其基础上二次开发一般是较好的做法。假设产品线已经比較成熟，那么产品的平台话就能够提上日程，从而为项目线适配产品线提供途径，最大限度降低由于项目线而导致的二次开发。
7. 技术评审
网上有一些技术评审无用论，但个人认为技术评审在消除浪费方面还是非常实用的。个人理解技术评审包含正式的技术评审和非正式的技术评审两大类，两者结合能有效的消除浪费。比如，产品经理在设计完产品需求之后、抛给研发之前，和UED进行产品UI风格和用户交互方面的讨论，这类就属于非正式技术评审，有助于把问题扼杀在开发过程之前。而类似需求评审、代码评审等都是属于正式技术评审的范畴，帮忙我们在研发过程中正确把握方向，避免因需求反复、代码维护等方面所引出的开发成本。
8. 过程资产建设
过程资产建设是一个组织级别的行为，体如今研发过程就是为了消除团队成员“再次学习“的成本。关于研发过程资产建设能够參考我的文章《轻量级研发知识管理--怎样帮助研发人员建设过程资产》，详细不再展开。通过文章中提到的轻量级的流程和实践能够在非常大程度上确保新人培训、开发交接、系统维护等方面所暴露出来的问题，从而消除浪费。
9. 流程重构
上面讲到我们要走一些流程，走流程非常多时候也是一种浪费。由于走流程须要人、时间和配套的步骤，假设流程过于复杂，实行成本非常高，这种流程一般会流于形式，没有产出的流程就是一种非常大的浪费；反过来说，假设一个流程中连责任人、运行的时机和详细的步骤都没有明白，那运行过程中势必会掺杂每一个人自己的理解和意愿，终于流程的运行变成相互扯皮的过程，运行力成为浪费的一种来源。流程相同具有时效性，须要随团队成员和产品战略的变动而做调整，不管是上述两种情况中的哪一种，流程重构如同代码重构是须要定期/不定期做调整和优化的。四．怎样压缩必要的浪费？
上文阐述的是怎样消除浪费的主要实践，但有些浪费一般是必要的，也是不可避免的，对这些浪费而言，我们的思路是尽量进行压缩，以下是个人梳理的7项压缩浪费的实践：
1. 代码质量
在消除浪费的实践中我们提到的“根本原因分析”关注的是消除那些引起产品质量问题的必定性因素，通常涉及的是开发流程、环境部署流水线上的因素。除了这些必定性因素之外，产品质量的提高须要质量保证部门的努力，但在精益思想中，通过測试手段进行质量管理是低效和不被提倡的，精益思想提倡的是内建质量，个人理解至少在技术开发者内部要确立质量意识，典型的因为开发者藐视代码质量导致浪费现象发生的场景有：研发团队没有确立开发环境和測试环境分离原则，前后端开发者各自完毕代码开发之后，仅仅是通过简单的联调就提交測试，没有在专属的开发环境中进行集成測试，导致提測的服务在測试环境中根本无法执行，须要开发者、測试人员多次交涉和调整才干部署成功，这是一方面；还有一方面，因为开发者没有进行充分的自測，导致非常多本应该在调试阶段就应该发现和解决的问题终于通过内部測试流程由測试团队暴露出来，这里流程运转所须要的额外成本实际上就是我们讲的能够压缩的浪费。
2. 可视化
可视化相同与数据传递的有效性有关，尽管我们能够通过“过程资产建设”等实践消除浪费，但沟通成本是一种实实在在的必要浪费，须要进行压缩。个人觉得可视化是一项须要推广的实践，信息的透明在敏捷等方法论中也备受推崇。可视化通常须要使用一定的媒介并配合一定的协作流程和报告系统，能够參考系列文章《研发范围和时间的“信息透明化”》。可视化的作用就是为团队和相关干系人提供信息辐射器，确保全部人对研发的范围、进度等达成统一认识。
3. 过程自己主动化
从过程改进角度而言，过程的自己主动化是一个能够持续进行尝试和探讨的入手点，对提高开发效率、减少由人为因素所引起的错误和浪费起到促进作用。日常工作中，过程自己主动化在潜移默化中影响着研发团队内部以及跨团队协作流程，通常包含程序开发、功能測试、系统部署和服务公布等领域，我们通过Ant、Python等脚本或Jenkins等工具平台进行过程自己主动化建设。
4. 并行project
并行project尽管听上去比較难把握，但可能非常多时候我们都在不知不觉中使用这一思想。比如需求评审之后，开发者编写代码和測试人员准备測试用例、前后台开发确定交互协议和接口之后同一时候进行开发等都是简单的并行化样例。并行就是分批思想，通过合理安排人员和顺序，能够把原来须要串行的任务变成并行从而提高效率。个人觉得并行project的难度在于管理接口和系统集成，假设能够保证接口的稳定性以及系统集成的成本控制，并行project在某些场合能够非常好的压缩浪费。
5. 短迭代
短迭代是一种敏捷思想，也是一种精益思想，就是通过尽早暴露问题从而尽早解决这个问题。由于软件开发是一项创造性工作，问题越在后期暴露则修复的成本就越高，造成的浪费也就越大。我们能够把短迭代形象的描绘成以下这张图（来自章显洲，《精益软件开发艺术》译者）：
通过上图，我们能够非常清晰的看到短迭代在压缩浪费过程中的价值所在。
6. Feature粒度
关于Feature粒度的讨论关注的是怎样在研发管理活动上达成一种平衡。对Feature粒度的划分能够採用下面方式：模块->功能线->功能点，即不管何种规模的系统，通过三级层次把范围划分到功能点级别，而研发团队面临的粒度即为一个个功能点。个人认为一个系统的功能点在20~50之间可能是最优的，过少添加开发者之间的信息传递成本，过多则导致管理活动成本的添加，两种情况都应尽量避免。
7. 单件流
单件流（single-piece flow）是精益思想中的一个关键词，意思就是不要让半成品工作在队列中堆积起来。软件开发中的半成品泛指部分编码实现的需求，或者是还没有进行測试、文档化和部署的代码，或者是还没有修复的错误。单件流思想的背后个人认为就是持续集成、持续交付的思想，要做到非常不easy。但通过Feature级别的代码提交、每日部署、高效的測试流程闭环等方式能够在一定程度上提高单件流化的水平，从而压缩在服务公布、系统集成方面所造成的必要浪费。五．小结
本文对精益思想中的识别和消除浪费理念在研发管理过程中的表现形式，以及结合个人平时的体会对怎样有效的识别、消除和压缩浪费的模式和实践进行了梳理。对精益思想中提到的推迟决策、总体优化等理念还须要进一步加深自己的理解并争取可以应用到日程研发管理过程中去。
