您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
   
 订阅
  捐助
华为百人团队精益看板演进变革之路
 
作者:陈军
   次浏览      
 2020-1-15
 
编辑推荐:
本文介绍华为百人团队精益看板演进变革的历程,从建立看板到运作看板,取得小胜利,再到团队遇到困局,停滞不前甚至倒退,面对困局同团队一起再审视改进,重新走上了正确的道路。
本文来自于csdn,由火龙果软件Luca编辑、推荐。

1华为研发面临的挑战

客户分类:

传统运营商客户:运营商受到互联网企业的冲击,要求版本更新得更快。

企业客户:以华为的DCN数据网络中心为例,承载了大量的数据业务,企业对此格外重视,版本更新迭代较之以往提速许多。

终端客户:个人客户需求变化频繁,甚至是每天都在改变。

华为内部:团队庞大,产品、业务复杂。一个产品的解决方案有时会牵扯到上千人导致效率低下。

02为什么要选择精益看板

1.对研发冲击小:精益看板不会改变组织架构、人员角色,但可以将整体格式化、规范化。

2.适应性强:看板是“元流程”,它可以和任何流程相匹配,无需担心要怎么去融入看板。

3.可提升吞吐量:研发的吞吐量与车道流量十分相似,其相关定义如下图:

在研发过程中,难免会存在吞吐量非常小的环节,我们可以称其为研发中的瓶颈,瓶颈发生的地方称之为阻塞点。那么如何解决呢?关键在于保证WIP一定情况下缩短Leadtime,这可以从缩短Worktime和waittime两个方面着手。例如做自动化测试,可以大大缩短编译时间,提高整体“通道的流速”。

4.看板是一种持续改进的机制。

仔细观察上图,可以看到开发已经没有正在进行中的事项,但还有许多待办事项,这是由于测试环节处存在积压事项。但此时我们仍要进行深入的分析其究竟是不是瓶颈再做定夺。

在图中,异常卡片所代表的事项是环节中的阻塞点。异常卡片这一设置是看板上的可视化元素,可以让团队持续改进,把问题充分暴露出来。

03百人团队实施案例分享

下图是在引入一个新方法时,绝大多数团队会经历的历程。下面我们以引入看板为例:

出于产品的诉求,引入了看板机制,之后会取得一定的小胜利,但在使用过程中也逐渐出现新的问题,只有解决新问题后团队才能走上正确道路。

但大多数团队会由于没有正视问题而迷失在困局内,这不是引入模式的问题,而是团队使用方法出现了问题。

业务痛点

1.市场增加,需求增大:外部市场的增加,同时团队面临着组织的调整,团队的人数减少了,这种情况下更急需提升团队的产能。

2.需求变化快,需要快速响应:在研发无法满足市场时,需要进行一些变革,这也是引入精益看板的原因。但也需要考量项目团队是否与精益看板相匹配:第一业务诉求与精益看板是否相匹配;第二团队积极性是否高昂。

看板的引入

在引入看板时,存在两组实践。

第一组实践是建立看板,另一组为运作看板。并把八大实践分为两组,建立可视化过程。

价值流映射

将研发过程可视化,映射到看板上。

按照华为团队需求结构可分为三层:IR、SR、AR。

第一层IR是初始来自客户的需求,随后分解到第二层的系统需求,最后分配到团队级的AR。我们根据上述特点,建立了产品级看板和团队级看板。需求从上往下分解,状态从下向上卷积。

显示化流转规则

卡片的每一次向下流动都需要一个规则,这些规则是共同定制的质量条件,目的是为了保证每一步的进程都是良好可运行的。

但规则不是死的,是随着环境、研发的变化而变化,是可以被重新商议更改的。唯一的条件是,规则制定后必须严格执行。

规则的制定来源于自働化。众所周知,自働化是丰田的重要原则之一。丰田最早做自动织布机时,把传统的手动织布机改为自动织布机,但是问题来了,当有线断掉的时候织布机不会停止,这样出来的产品时残次品,后来经过改良在织布机出现故障时由人工 来检查重启,检查通过后才会继续运作。这也是内建质量的过程。

限制在制品

这是看板中最难实施的一个步骤。因为为保证投入的精力,每人同时只能干两件事情。

尽管在以往,一个人同时做多件事情被认为也是无伤大雅的。但这是由于需求流动无法被直观看到,最终极易导致需求流转不动,一直停留在开发进程中。这时候我们需要转换自己的视角,更多关注流动效应。

因为研发的交付速度需要很快,所以研发人员的流动效率与资源效率理应很高。但实际上,效率是无法都达到百分百的。所以我们提倡提高流动效率,减少浪费,自然可以提高资源效率。

看板正是为我们提供了这样一个视角,把不可见的需求转化到可视化的看板上,把需求的变动转化为卡片的流动。

看板运作

运作看板首先有一个需求的填充,这个过程在华为被称为二次填充。从大的流程看,二次填充仍然属于IPD,但可以限制大的IPD,更好地管理风险。

第二个是通过看板站会管理流动效率。站会与以往不太一样,不再关注要做什么,遇到什么问题,而是关注卡片和价值的流动。

看板从右向左看,成员更多的关注如何让右边的卡片尽快向下流动。在这个过程中尽快解决可能存在的阻塞、瓶颈,其最终目的也是为了让卡片向下流通。

拉动式开发

拉动式开发是团队形成自组织非常重要的一点。这也意味着,如果你的团队想要做到拉动式开发必须是自组织的。在建立拉动式开发时,必须要关注上下游的每一步质量究竟如何,只有下游可以流动,上游才能被拉下来。

组织者必须具有全局观,善于发现问题。

建立规则

这些规则会定制的十分详细,包括团队运作看板时的操作规则。例如,看板站会之前,团队人员会把卡片拖动到正确位置,标记异常情况。

示例

观察下面看板图片:

在运作过程中,我们发现在团队级看板的AR一级,SDV测试内没有任何卡片,反而都堆积在Ready For SDV。看起来SDV是一个瓶颈,但实际上这是因为自身流程——批量式转乘造成的。

回顾改进:从下示意图中,可以看到批量式交互的累积流程是呈现阶梯状的,散点图是集中于某一时间交付。

在回顾改进时,我们制定了改进测试,每周进行小批量的SDV测试。

在有了这样的小胜利后,团队的趋势从上图变成了下图。团队从原来的的批量交付,修改大量缺陷。变成了当前的每周发现问题,每周进行修改。

困局与破局

在这个版本结束后,看板使用率就大大降低了。和其他团队沟通后,发现是因为团队太忙根本没有时间顾虑看板。

破局一:建立看板的分析请求分配产能

下图是Muri、Mura、Muda浪费示意图。

特别注意Muri、Mura直接导致Muda。Muri系统超载导致任务的切换,任务切换本身就产生很多的浪费。Mura系统的波动性会打乱团队的节奏,例如突然来一波需求导致系统过载进而产生浪费。

这个团队Mura情况比较严重,除了本身的特性包需求意外,还会有一些需要快速响应的小需求,导致团队疲于应付。解决方法是把团队人员分为两组,一组人做运营快速发布版本,小需求出现后,以固定的节奏快速发布。大的需求用火车版本。

美国海军陆战队有句话“慢就是稳,稳就是快”(slow is smooth,smooth is fast)。这和丰田的“均衡化”原则的原理相似,需求进入管道时一定是稳定的,如果不稳定会导致优化大打折扣。

破局二:找回需求

AR只是任务,不能称作需求。测试是检测SR,所以我们转换视角关注到需求上面,采用FO,拉通端到端。

破局三:减小批量

下图的瀑布中,总计44天,但编码只占用10天,后面20天是没有任何编码的。在这样的情形下,做的需求会较少。

解决措施:按周填充,减少SDV批量,减小SIT批量,加速价值流动,质量保证前移,减少fix时间段,增加编码实践,提升吞吐量。

04Q&A

Q:如何能真正做到减员增效?

A:看板。因为在业界里面,比较好流动效率才刚20%到40%,所以如果你的流动效率能达到40%,其实你有60%还是浪费的。所以如何不断的提升流动效率,让卡片流动越来越快带动吞吐量提高。只有不断的把水分给挤掉,这就是减员增效。

Q:华为是怎么突破精益看板中的坑呢?

A:最大的坑是思维的变化,对于某些看板上展示出的问题不以为然。我们团队认为要持续改进。持续改进其实已经是改善的结果。

改善要有自我批判的精神,能够不满足现状,能够有勇气去改进,然后才会用到相关的工具去做持续改进。在有了这种思维后,才会使用看板。所以首先要改善,其次才是改进。

   
次浏览       
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证