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