精益思想如何加速企业的全局价值流动? -k8凯发天生赢家

发布日期:2022-08-01 13:38:19

分享到

精益思想(lean thinking)在数字化转型中一直扮演着重要的角色。精益源自20世纪50年代日本丰田发明的生产方法(tps),即精益生产。基于这套方法论丰田实现了成本效益结合,大大提升了日本汽车的质量与成本优势,使得世界汽车工业重心开始由美国向日本倾斜。

在之前的文章中,为大家详细地讲解了精益与devops的关系及实践,本文我们邀请到devopsk8凯发天生赢家的解决方案架构师黄锦辉,带来《精益思想在软件交付中的应用》主题分享,深入挖掘解析精益思想的内涵,以及在软件交付领域,精益如何实践应用,一起来看看吧。

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):

是精益制造或精益企业技术,用于记录、分析和改进为客户生产产品或服务所需的信息流或物料流。价值流图在下文“精益在软件交付的应用”中,我们会详细阐述。借助价值流图,能帮助我们:

  • 1. 提供价值交付全周期的视图;
  • 2. 建立客户视角的系统思维;
  • 3. 提供驱动改进的定量数据。价值流会量化很多数据或者指标,可以驱动我们不断持续地改善。


核心3:流动效率—优于资源效率

我们在整个软件交付周期中,经常遇到整体交付效率没有明显提升的情况,即流动效率低的问题。如何实现端到端快速价值交付?这需要从以资源效率为核心,转变为以流动效率为核心来组织软件交付过程。

▲ 图片来源于书籍《this is lean》

资源效率,是指从组织内部视角,审视各个独立环节的产出效率,关注的是内部资源及职能。而流动效率是指从客户的角度,审视客户价值顺畅流动的程度,关注的是客户价值。

前置时间:即从用户提出需求开始,到最终交付给客户整体价值的端到端的时间。例如,上文举例的医院,前置时间为42天。如果去一站式的私人医院检查,医生诊断快速,从初诊到确诊的检查报告,排队等待时间也大大缩短。因为一站式私人医院关注的是流动效率。

过度局部优化资源效率,可能会带来额外的工作,你在工作中不断切换任务,导致整体工作时间增加,使得下一个环节的人或者客户经常处于等待状态,流动效率低。


核心4:质量内建—尽早发现并解决问题

在丰田里有个实践“安灯拉绳”(andon cord)。在生产制造过程中,当一线员工发现其中的工序有异常,会拉动手边的绳子-安灯拉绳,值班经理便会很快看见拉动绳子的员工是在几号岗位、在车间哪条流水线,这时会和专家一起检查生产,群策群力。如在特定的时间段解决不了时,便会决定停止整条生产线的运作。

图片来源于网络

安灯拉绳的做法,强调尽可能在问题出现的第一时间去发现并且解决。如暂时解决不了便会停下生产线,不把问题留着转移到生产的下一个环节,这也是质量内建的体现。

质量内建,需要3个因素来体现:

① 建立信任的心理安全的环境
整条生产线停止运作的特殊情况,在绝大多数制造业工厂里是很大的事故,而丰田给予信任、心理安全的环境,来保障质量内建的实践。

② 可视化与透明性
整条生产流水线,以及安灯系统,都是通过可视化方式展示。

③ 群策群力
需要团队共同决策、一起解决问题。


核心5:持续改善—随时随地全员参与

改善,意味着持续改进,不断否定现状,寻求更高的水平。无论是在软件交付过程,还是个人职业生涯,改善的套路提供了一种面对未知的思路,从而渐进式地不断提升,持续进化。

需注意的是,改善并不是定期改善,而是随时随地全员参与。例如当软件开发中发现可以改善的环节时,应立即去改善。


03. 精益在软件交付的应用

1)实践1:价值流图在软件中的应用

第一层(最上层)为信息流,即供应商和客户之间的信息流,中间会经过发布管理过程。其中,信息流的需求,企业内部会用到许多工具,比如需求管理工具,版本工具,自动化工具等。

第二层(中间层)为生产的过程流。例如软件交付中,会经过需求分析设计、开发、测试、部署、发布投产等流程阶段。这里会涉及几个量化的指标-前置时间、周期时间、处理时间、安装时间,我们在下文再一一详细解释。

第三层(最底层)是根据各个阶段里量化的指标,去绘制时间流水线。例如需求分析(第一个凹处水平线)花了0.5小时,等待开发(第二个凸处水平线)花了1天,开发(第三个凹处水平线)用了1.5小时,继续等待(第四个凸处水平线)花了2天等等,以此类推,前置时间总共花了12.5天,处理时间为3.5天。

▲ vsm价值流图(图片来源于网络)

量化指标的概念:

① 前置时间(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的方法。

立即体验产品

专业售前团队详细介绍

在线咨询

电话:020-38847288

qq:3593213400

申请演示

请登录后在查看!

网站地图