@gaoxiaoyunwei2017
2019-03-19T16:05:48.000000Z
字数 4134
阅读 660
豆沙包
作者简介
潘瑞琪
华为云核心网产品线产品软件工程负责人
我今天要讲的主题是精益看板,换一个方式看软件开发,我们之前看软件开发的方式是比较传统的,所以多的标题是换一个方式看软件开发。
上图我们华为的一个开发场景,我们不是一个单产品,我们叫做解决方案。上面是一个比较大的我们叫做云化产品,里面有设计和测试,下面还有一些小的配套的产品,再下面是公共的组件服务,可以看到这样一个大的研发团队其实是一个大兵团作战,是一个上千人的作战,他们来自不同的部门和产品线,这会带来一些非常严重的问题,这些问题都会在开发过程中表现出来。
在研发过程中,我们永远在做一些效率提升的事情。我们的效率提升体现在几个方面,比如基础设施自动化,我们在进入云化之后投入了很大的精力在自动化部署上,我们基础设施的自动化率是非常高的,同时我们会做很多的软件优化,你要提出什么审批都是走电子流的流程。
这些本身都是优化的工作,但是这些东西对于开发人员来说,最后有一些问题始终没有解决,比如我们的团队无论是用什么看板都无法对齐,还有就是层级多,一千人的团队和二十人的方案是完全不一样的,我们有顶层设计,下面也有底层设计,从管理到设计,这个层级至少3—4级,无论你造成什么改进,最后还是加班比较多。
是我们的优化没有用吗?我们来看几个实际的例子,就是我们的单产品我们的用例可以到7万8万,我们通过自动化增加一些并行数量测试环境的方式,我们可以从周级变成小时级,但是在整个用例失败之后,我们的定位时间却是按周算的。每个用例失败还要分析,这个分析的时间就比较长,你跑的时间是小时,但是你定位的时间还是周。
第二个就是个人级的构建时长缩短到了1分钟内。你自己有一个版本,我们从10分钟降低到1分钟,但是我们的代码要在本地存很久,我的代码要入库是要和别人一起把这个测试做完了才可以回到主干的,这导致跨部门的沟通和
第三个就是通过自动化增量编译,我们用了很多的手段,让这个增量编译通过自动化让整个版本的时间至少缩短了50%,但是解决不了的问题是你发现一个版本经常要重新出了两三遍。
这是我一直思考的两个问题,一个是我们做了这么多的优化,我们认为大量的优化是被浪费给吃了,第二个就是我们其实都是在做局部优化,我们经常看到的都是局部的东西,我们拼命优化局部的点,我们觉得做得最好了,但是实际上并没有。
回到精益的概念上,什么是效率?
我们注重的是资源效率,比如说人、物料、或者测试环境,我们注重项目管理人员看到的资源效率是什么,是你这个人有没有在忙,你有没有工作,你的测试环境有没有闲置,因为这些东西停下来的话是一个很大的浪费。但是我们忽略了当中所有等待过程,我是很忙的,我的下游是没有办法处理我的工作的,所以精益里面最重要的一点我们强调的是流动效率。
我们看到开发人员很忙,一直在加班,但是整个交付的速度只是你预期的三分之一,下面这个图非常经典,我们回到我们常常遇到的情况。
我们经常抱怨两个事情,一个是开发团队交付太慢,开发团队的慢会有一个典型的场景,就是开发人员使用的测试环境是非常不专业的,这个场景下我们其实写完代码只花了一周的时间,但是部署和协调环境只要一到两天,这是开发团队交付慢的实际现象,开发团队说自动化的脚本都做好了,但一跑就失败,这个时候需要开发定位,但是开发团队没有时间解决这个问题。
从资源效率的角度,开发效率还是要增加产出,测试团队的人均效率要增加,这就延伸出我们软件开发特别明显的一个事情,就是你评价一个开发人员的生产效率的时候只有数量,我们从流动效率的角度看,开发去解决测试发现的问题,测试把开发的测试环境也纳入到资源池进行统一管理。
现在华为其实把整个测试资源拉通管理,通过一个统一的系统一起来管,这个问题就很容易解决,当然这是我们抽出一个简单的场景来做的。但是你的测试部的老大不会帮助开发部来做这些工作,因为这个不是他的绩效。
所以这边就抛出我们的观点,我们需要一个新的视角:
下图是我们研发过程当中使用的一个精益看板,我们挑几点来说。
第一个是把价值流可视化,把整个研发过程可视化,下面所有的卡片都是在一个价值流工作。
第二个就是不光要把流程弄出来,还要建立每一个点的规则,而不是开发人员想拖动就拖动。
第三个是进展管理可视化,我们看到这个上面包括第四点都有很多小的标记,三角形代表有风险,圆圈代表阻塞,就是我这边已经OK了,这个卡片不能继续的原因是其他的地方阻塞,我们通过标记来做。无论开发人员还是管理人员我们不发周报了,直接拿这个东西,在我们的版本例会上过就OK了。
第五个例会的时候对着问题开始讲就可以了。
第六个第七个第八个我们后面讲,第九个是我们的团队事务管理改善。
这是我们的一个大的概况,我们内部推动在300—500人的范围看板落地的情况。我们是协同作战,第一个阶段是把团队的价值流注入活动的机制流,变成一个可视化的东西,并且还有显示化的流动规则;第二个阶段就是试,我们发现瓶颈消除瓶颈,不断增加一些规则或者让这个活动做一些调整;最后是做一些持续改进的活动,我们是花了一年多的时间才走到第三阶段。
这个是华为开发产品需求分解的过程,可以看到其实我们是分了好几级的,对应的是我们的需求的流动关系,或者说是分解关系。第二个就是我们根据这个情况分成两类看板,下面是解决方案的看板,这个比较大的这个框是团队级看板,可以看到我们团队是怎么做开发活动的,我们的来源是谁来贴这个卡片,对这个卡片的内容进行定义。第三个就是频率,这个卡片出现的频率是什么,我怎么控制,后面是处理规则。最后是占比,大家都在提我的需求怎么排序,这个没有错,但是你凭什么说我这个东西的优先级更高,或者我该怎么排我的需求,有一个概念就是你做产能分配,做开发的团队都知道,我有业务的需求,也有技术债务的需求,但是有什么东西可以帮助你产能分配,如果我的产能分配里面规定我的产能分配必须有10%的精力必须在这个里面,我就不会拿技术需求和我的债务PK,我会固定两个甬道就是技术债务的,而不会和别的甬道混合。这个是项目立项的时候就要定的事情。
接下来这些价值流出来之后怎么呈现?还是相当于对我们的开发过程做一个解构,我们做了分层,最后的看板也是分层的,我们有解决方案看板还有团队级看板,把整个工作流呈现出来,右边我们对每个阶段会分5个状态,就是相当于这个卡片会有5个不同的阶段,测试阶段会有两个阶段,backlog是准备阶段,ready是立项阶段,complete和done是有区别的,一个是已经做完了的,这个东西我做完了,但是不代表整个做完了,要等下个阶段,而done代表完全完成了。
所以我们特别需要去做这么一个分配,开发人员是拉动式开发,开发人员做完了之后,由测试人员从C里面把活动拉出去,如果一直在C里面就是一个等待的状态,这是我们价值流整个的甬道设计。
上图是我们显示化的规则,我能达到这一步的入口条件是什么,或者我拖到D的时候我是符合显示化的规则的,你有了这些交付说明你这个阶段是OK的,你会把一些报告和链接放在里面,这个步骤非常重要,否则你的整个过程是没有办法管理的。
这是我们的一个实践,我们的开发团队有一个站会,领导和领导也有一个站会,开发团队提出困难,领导团队解决困难,我们搞了两层,每天都会有两个小的闭环。
看板本身最后会生成这么一个图片,里面有交付率,这个里面有一个阶段叫做部件联调,我们在这个阶段平均话费31.07个自然日做部件联调,但是我在这个阶段要到12.71天才可以进入下一个阶段,这个也比较好理解,我们每个开发团队每个服务团队自己开发的工作是非常快的,但是最后你发现这个是拉不通的,这就是一个瓶颈。所以公共团队是最痛苦的,大家都说他的效率最低,这个图片告诉我们他们的效率其实很高,他们卡在了这个红色的阶段,不是他们的效率低,是整个的效率的问题。
对于我们来说,我们虽然按照服务的方式构筑团队,但是我们有一个强势的组织去把控整个交付,这个是版本落地一个非常重要的事情。其实我们可以看到在这个阶段会有非常多卡片,这个时候我们就应该停止前面的开发活动,聚焦在这个阶段,先把这个阶段的任务解决。
这是反馈的一部分,本身精益里面就有很多数字,比如活跃度,比如流动效率,你不可能拿着某一个数据去做什么,这样会出很多问题,虽然流动效率我们追求很高,但是流动效率虚高也是有问题的,这个时候应该拿着所有的数据建模,这是我们做的一个尝试。其实我们的看板的数据应该有几十项,这个时候应该拿着这个东西做一个建模,去衡量整个的水平。
我们看闭环时长的数据是很低的,我们会认为这个团队的颗粒度太大,这个时候你的建议不是一个单点的数据分析,这个是没有意义的,你要从背后挖掘一些深层次的原因,所以这是看板在应用上的一个点。
当我们觉得这个看板很好用的时候,我们想把所有的东西都放在上面,我们把一些团队管理也放了进去,我们搞了两个不同的甬道,比如重要的走的流程就会非常仔细,某些环境我们做一些松口,这个是我们团队的看板。
这个就是我们做的看板,我们做了精益之后发现两个非常好的点,精益这个事情希望看到每个价值单元走到头,所以我们特别强调全功能团队。
我们希望通过精益看板激发组织活力。精益看板可以看到很多的瓶颈,按照我们以前的模式,项目经理指定,其实也可以做,但是结合我们研发人员的行为可以代理一些比较大的收益,我们给每个开发人员把所有的任务都列出来,当然我们会有一个定义,把目标工作量,难易程度,时间都会列出来,我完成这个时候开发人员自己去抢,在精益看板会产生一个卡片,会有你的署名,就相当于把这个活动和我们的主流层打通了,后面有一些积分之类的方式激发我们组织的活力。
这就是我今天的分享的内容,希望对大家有帮助。