精益思想(Lean Thinking)在数字化转型中一直扮演着重要的角色。精益源自20世纪50年代日本丰田发明的生产方法(TPS),即精益生产。基于这套方法论丰田实现了成本效益结合,大大提升了日本汽车的质量与成本优势,使得世界汽车工业重心开始由美国向日本倾斜。
在之前的文章中,为大家详细地讲解了精益与DevOps的关系及实践,本文我们邀请到DevOps解决方案架构师黄锦辉,带来《精益思想在软件交付中的应用》主题分享,深入挖掘解析精益思想的内涵,以及在软件交付领域,精益如何实践应用,一起来看看吧。
01. 为什么需要精益?
在数字化转型趋势中,业务敏捷(BVSSH)是核心目标,即更快(Sooner)、更安全(Safer)地交付更高质量(Better)的价值(Value)给到客户,同时让客户和员工满意(Happier),详细介绍如下:
① B-Better:
代表的是质量(Quality),例如更少的生产事故、更短的故障恢复时间(MTTR)和代码质量等。质量必须是内建的,而不是事后再检查。
② S-Sooner:
更短的上线时间。即缩短前置时间(Lead Time)、提高吞吐量(Throughput),提升流动效率(Flow Efficiency)
③ S-Safer
满足持续的合规性(Continuous Compliance),考虑性能要求(Agile not Fragile)。
④ H-Happier
客户满意和员工幸福。
DevOps和敏捷开发这两类软件开发方法论已被企业广泛采用,那为什么还需要精益呢?其实尽管我们在软件交付中已经应用DevOps和敏捷实践,但仍然会发现仍面临着如下挑战:
① 基本上没有人能够说清楚软件交付全过程,例如从用户提出需求开始,到最后将产品/服务交付给客户,会经过哪些步骤和工具,信息怎么传递流动
② 在研发过程中做了很多“优化”,软件交付周期却没有明显的缩短
③ 过度关注在人力方面,忽视了软件交付过程,导致内部资源利用率虽然有所提升,但整体软件交付效率实际是有下降的,反而会降低软件质量。
02. 精益思想与核心原则
1)精益思想的前世今生
20世纪50年代,大野耐一在日本丰田发明了丰田生产系统 (TPS),创立了高效益、低消耗的生产方式(后被MIT研究团队称为“精益生产”),经过多年的实践使得日本的汽车工业赶超美国。当时精益更多是应用于制造业领域。1996年,书籍《LEAN THINKING》(《精益思想》)出版,这本书高度归纳了精益思想和原则,并将精益方式逐步扩展到制造业以外的领域。随着2003年《精益软件开发》的出版,精益思想真正开始应用于软件领域中。
2)什么是精益IT?
精益IT协会将精益IT定义为:“精益IT是精益制造和精益服务的原则的延伸,用于信息技术产品和服务的开发和管理。其目标是不断提高IT组织为客户提供的价值以及IT人员的专业水平。”
精益IT专注于提高IT人员,IT流程和信息技术,以便为客户提供更多价值。精益的本质是一种思考和行动的方式。精益IT还提到了如下七个概念,其中“提升客户价值”,是精益追求的目标;“减少浪费”是精益的核心,即通过不断地去减少过程中的浪费,增加价值。
3)精益的五个关键原则
① 首先,要明确客户价值,一切价值都是围绕客户展开的;
② 其次,基于客户价值,建立以客户为中心的价值流;
③ 再次,建立快速的流动机制,消除过程的瓶颈和浪费;
④ 然后,所有的价值流都是围绕客户进行的,是由客户拉动,而不是生产后再推动给客户;
⑤ 最后,尽可能第一次就把事情做好,在每个阶段保障质量,并通过可视化建立反馈,持续改进。
4)精益的核心思想
基于以上五个原则,精益的核心思想包含如下5个方面:
核心1:定义客户的价值-谁是我们的客户
价值是由客户定义,代表了客户对于特定产品或者服务的需求。我们需要持续关注客户价值,以及他们从产品或服务中感知到的价值。
核心2:价值流思想-建立客户视角的系统思维
① 价值流:
是由将产品或者服务从概念到交付给客户的所有任务和活动组成,包含了所有的信息、工作和物料流。
② 价值流图(VSM):
是精益制造或精益企业技术,用于记录、分析和改进为客户生产产品或服务所需的信息流或物料流。价值流图在下文“精益在软件交付的应用”中,我们会详细阐述。借助价值流图,能帮助我们:
核心3:流动效率—优于资源效率
我们在整个软件交付周期中,经常遇到整体交付效率没有明显提升的情况,即流动效率低的问题。如何实现端到端快速价值交付?这需要从以资源效率为核心,转变为以流动效率为核心来组织软件交付过程。
资源效率,是指从组织内部视角,审视各个独立环节的产出效率,关注的是内部资源及职能。而流动效率是指从客户的角度,审视客户价值顺畅流动的程度,关注的是客户价值。
前置时间:即从用户提出需求开始,到最终交付给客户整体价值的端到端的时间。例如,上文举例的医院,前置时间为42天。如果去一站式的私人医院检查,医生诊断快速,从初诊到确诊的检查报告,排队等待时间也大大缩短。因为一站式私人医院关注的是流动效率。
过度局部优化资源效率,可能会带来额外的工作,你在工作中不断切换任务,导致整体工作时间增加,使得下一个环节的人或者客户经常处于等待状态,流动效率低。
核心4:质量内建—尽早发现并解决问题
在丰田里有个实践“安灯拉绳”(Andon Cord)。在生产制造过程中,当一线员工发现其中的工序有异常,会拉动手边的绳子-安灯拉绳,值班经理便会很快看见拉动绳子的员工是在几号岗位、在车间哪条流水线,这时会和专家一起检查生产,群策群力。如在特定的时间段解决不了时,便会决定停止整条生产线的运作。
安灯拉绳的做法,强调尽可能在问题出现的第一时间去发现并且解决。如暂时解决不了便会停下生产线,不把问题留着转移到生产的下一个环节,这也是质量内建的体现。
质量内建,需要3个因素来体现:
① 建立信任的心理安全的环境
整条生产线停止运作的特殊情况,在绝大多数制造业工厂里是很大的事故,而丰田给予信任、心理安全的环境,来保障质量内建的实践。
② 可视化与透明性
整条生产流水线,以及安灯系统,都是通过可视化方式展示。
③ 群策群力
需要团队共同决策、一起解决问题。
核心5:持续改善—随时随地全员参与
改善,意味着持续改进,不断否定现状,寻求更高的水平。无论是在软件交付过程,还是个人职业生涯,改善的套路提供了一种面对未知的思路,从而渐进式地不断提升,持续进化。
需注意的是,改善并不是定期改善,而是随时随地全员参与。例如当软件开发中发现可以改善的环节时,应立即去改善。
03. 精益在软件交付的应用
1)实践1:价值流图在软件中的应用
第一层(最上层)为信息流,即供应商和客户之间的信息流,中间会经过发布管理过程。其中,信息流的需求,企业内部会用到许多工具,比如需求管理工具,版本工具,自动化工具等。
第二层(中间层)为生产的过程流。例如软件交付中,会经过需求分析设计、开发、测试、部署、发布投产等流程阶段。这里会涉及几个量化的指标-前置时间、周期时间、处理时间、安装时间,我们在下文再一一详细解释。
第三层(最底层)是根据各个阶段里量化的指标,去绘制时间流水线。例如需求分析(第一个凹处水平线)花了0.5小时,等待开发(第二个凸处水平线)花了1天,开发(第三个凹处水平线)用了1.5小时,继续等待(第四个凸处水平线)花了2天等等,以此类推,前置时间总共花了12.5天,处理时间为3.5天。
量化指标的概念:
① 前置时间(Lead Time):
从用户提出需求开始,到最终交付给客户整体价值的端到端的时间。这是对客户关键的时间,客户只关注整体花费的时间,期间的过程客户并不在意。在如上价值流图中,前置时间为12.5天
② 周期时间(Cycle Time):
各个阶段团队处理的时间。例如需求分析花了0.5个小时,则周期时间为0.5个小时。
③ 处理时间(Process Time):
也称流程时间,是周期时间的总和。图中周期时间为0.5h+1.5h+1h+0.5h=3.5h,即对客户来说,有价值的时间是3.5h,其余等待的额外时间对于客户来说是没有价值的。
④ 安装时间(Setup Time):
环境准备的时间。例如代码开发需准备本地的开发环境,准备消耗了多长时间,即为安装时间
还有一种价值流图的延伸-流框架(Flow Framework),详情可见PPT及直播回顾。
2)实践2:消除浪费——区分3种活动类型
通过价值流把指标量化提炼出来后,我们下一步要做的是识别浪费,并进行改善。针对不同的活动类型,我们可以采取不同的方式。
① 消除非增值活动
非增值活动即完全不会带来价值的活动,例如库存、返工、等待等,这类活动需要直接消除。
② 最小化必要非增值
必要非增值,例如员工进行培训技能是必要的,但对于客户来说并不创造直接价值,这类活动需要最小化缩短时间。
③ 优化增值活动
增值活动,例如软件需求分析、代码编写等活动对于客户是增值的,这类活动需要借助工具平台(例如DevOps平台),提高端到端的效率
那么如何识别软件开发、交付过程中的浪费呢?通常浪费有如下八种:
3)实践3:内建质量——软件交付的质量门禁
从需求、分析、编码、测试到发布,每个阶段都需要设定质量门禁或者质量关卡。下图是我们实际项目中应用的DevOps平台端到端的流水线。在每个阶段对应设置质量红线,根据提前设定的规则或标准来判断是否可通行。
4)实践4 精益看板
设计精益看板时,需要考虑3个核心因素:
① 如何体现价值?
② 如何反映协作?
③ 如何暴露问题?
我们可以通过“5步法”,设计精益看板:
5)实践5:改善(Kaizen—日文)
改善的工具方法有很多,我们可以借助DMAIC框架,即:定义(Define)、度量(Measure)、控制(Control)、改进(Improve)和分析(Analyze)。
04. 精选互动问答
问:精益是否是敏捷迭代升级?
答:从时间来看,精益思想是远远早于敏捷和DevOps。精益思想是对20世纪50年代在丰田里实践的总结,敏捷是2001年由敏捷联盟提出,并且制定、发布了《敏捷宣言》,DevOps概念于2009年提出。目前流行的敏捷框架,scrum、SAFe、DevOps,甚至是PMI DA体系,底层思维均依赖或借鉴了精益思想。
在当今数字化转型中,精益、敏捷、DevOps是相辅相成的,实践者需要基于自身企业的情境(Context),选择适合自己的实践,没有One Size Fits All的方法。
申请演示