Kanban渐进式演进，让过程改进成为习惯

always_fly

团队应用精益Kanban方法的基本的改进过程，大致可以分为以下几步：

1        先可视化现状，透明团队现有工作流程、人员角色、分工、流转规则

2        结合WIP约束、数据分析（累计流图、分布图、控制图等）等手段，进一步可视化全流程中的问题与阻碍

3        团队根据这些问题和阻碍，设计有针对性的改进试验

4        实施改进试验，观察效果，形成反馈闭环

5        循环执行以上1~4步，渐进式的进行过程改进



做得好的团队，每个迭代，Kanban设计与运作方式总会有些新的优化和尝试，团队总会得到一些新的surprise和
learning。本文讲述平安科技综合呼入开发团队的Kanban渐进式演进的故事。



时间回到2014年2月，综合呼入团队组建，团队成员包括1个SA、2个测试、8个开发，以及1个敏捷教练。



最原始的看板



“看板”，熟悉而又陌生，曾看见其他团队每天早上对着一块板子说来说去的，那原本只是个传说。当教练拿
着一块版子放在我们面前时，心里还有一些小激动呢。立马，我们基于当前的开发流程，设计了我们团队的
第一个简易看板。



说明：

1、团队一个月发布一个版本，迭代周期也是一个月。

2、进入迭代后，我们主要有开发、测试和UAT测试阶段。

3、看板的左下方是燃尽图。工作量当时用的还是“人时”度量。



4、卡片分为紫色和绿色，紫色为技术任务，绿色为需求。当时的卡片那是相当的简陋呀



5、还有需求分析的看板和记录问题的看板





第1次演进



问题来了：

教练Z的问题：“迭代1失败，团队总结好多改进措施，怎样时刻提醒大家这些改进项呢？”

开发Q的苦恼：“这个迭代居然失败，原来DoD是这样定义的，早知道我们努力也许就能成功了，下次我得把
DoD记住才行。”

SA的烦恼：“业务从提需求到纳入迭代要经过好多环节，看板完全体现不了需求分析的过程”。



好吧，那就优化吧：

1、新增迭代一回顾以及DOD模块，我们在迭代方向上有整体规划。



2、看板在待办、需求分析、故事拆分、估算方面，改变了原有的分析到完成的粗放笼统式看板，开始有一定
的流程化进行。



3、看板整洁度提高，大家在整洁、美观方面开始注意，增强可视化效果。



第2次演进



问题又来了：

测试L的烦恼：“开发总是不进行开发测试，测试环境一大堆bug，反复修改几次还是会有问题。”

教练Z的问题：“敏捷也开始一个月了，团队的产能到底有多大，怎样看出团队的变化呢，需要数据支撑才行哦”。

开发Q的烦恼：“迭代还是失败了，可有几张卡片是由于关联系统无法支持联测，根本不赖我。”

SA的烦恼：”一个大的需求拆成几个BI，开发同事都不关注关联关系，我得将这些卡片关联标注出来才行”。



好吧，那就接着优化：

1、补充了卡片从‘进行中’移到‘已完成’的规则（需要开发截图），这样督促开发做好开发测试。

2、卡片上标注开发测试开始完成的日期，每日站会在卡片上记录投入工时。为数据统计做准备。

3、卡片上补充分类信息，更容易看出卡片之间的关系。

4、为更合理的配合关联需求的开发节奏，优化补充当前迭代的需求开发任务，并为这类卡片制定针对性的DoD。





第3次演进



问题接着来：

教练Z的问题：“已经过去两个迭代了，一个版本时常有紧急需求加入，迭代内容经常不可控，是不是一个月的
迭代太长了呢？”。

测试L的烦恼：“这次迭代又失败的，卡片周期内，开发占用了太多时间，完全没留给测试充足的测试时间。”

SA的烦恼：“BI采用人时进行共同评估时大家偏差比较大，也很难达成一致。采用点数是不是更容易达成一致呢”。



继续优化：

1、看板上的任务卡片变少了。原因是迭代三开始我们将迭代周期缩短为了2周，一个迭代的任务变少了，看上
去是不是清爽了不少 呢？

2、卡片上增加了一个计划开发完成时间。在开发同学领取任务时标注，测试MM们心里也算有底了。

3、卡片上标注的开始完成的日期开始发挥作用了，lead time被可视化出来了。大家看到了部分卡片开发测试周
期，有点长。

4、迭代燃尽图统一使用点数了。开发速率的稳定数据将会形成。



第4次演进



更深层次的问题开始暴露：

教练Z的问题：“上次迭代又失败了，我们已经连续失败4次了，开发只管自己开发完成，不跟进测试进度，测试任
务积压很严重。有些同事还同时处理几个卡片，导致卡片流转很困难，看板显得十分拥堵。而且每张卡片的
遇到的问题也很难暴露出来，这样下去卡片流通越来越老火，成功真是遥遥无期”。

教练Z的烦恼：“统计数据太麻烦了，大家记录的格式千奇百怪，有些记录也有缺失，得规范一下才行”。

测试L的苦恼：“开发bug太多了，全部积压到测试环境进行测试，我根本忙不过来。”



我们重构了看板，包括增加了WIP约束：

1、增加WIP限制：达到了疏通管道的效果。结合团队人力与历史经验，对WIP做了初始设置，开发WIP为9，
ci环境测试为5，stg测试为6。

2

、看板增加block区：由于部分任务受到关联系统的限制而暂停，所以增加stg block区域，便于新的卡片能流
进来。

3

、在 Development列中增加常规任务卡片：因为开发经常有一些公共事情处理，但是在看板上无法体现。

4、增加了CI test列，希望通过加强CI测试减少stg的任务积压。

5、区别定义卡片上的小条，用不同颜色分别标示风险条、需求变更、测试bug等。



5、团队统一设计卡片模板，卡片信息更整洁、完善。



2014年5月，终于！综合呼入团队首次取得了当次迭代的胜利！看板的改进带来的效果那是相当的明显。

然而，这只是万里长征的第一个里程碑，改进的脚步永远不能停歇……



第5次演进



团队新的关注点出现了：

团队的吐槽：“这个看板也太难看了，有些线条很模糊，而且太呆板了”。

测试的烦恼：“加入了CI测试环境，测试环境bug还是比较多，开发测试的技能不足，ci测试需要有人把关才行，
不然就水了”。

教练Z的苦恼：“从统计数据的结果来看，卡片开发耗时最长，虽然开发补充了预计开发完成时间，但是经常
没有按照预计时间完成，必须给开发敲警钟才行哦。”



OK，有问题是好事，问题就是机会嘛，继续改进！

1、美化看板：用布条代替划线，规范字体，画图等方式使得看板更清晰整洁，更生动。

2、增加个人名片卡：每个卡片写名字，名片卡贴在卡片上表示该成员正在进行中的卡片， 每人限两个贴板，
也可于减少并行任务。

2、综合看板CI列中增加待验收环节：目前CI的验收由SA完成

3、开发列增加超期限制：表示离开发计划完成时间还有n天，1天，0天，或者已经超期。这样不仅敲了警钟，
而且每天开发都有移动的卡片，增强了站会的能动性。





第6次演进



还有问题吗？那是必须的！

教练Z的问题：“一些技术任务，不需要经过开发测试，看不到完成结果，有些开发还蒙混过关，需要我验收
通过才行”。

教练Z的烦恼：“上个迭代有两个卡片直接被测试放到block区域，关联系统卡的太久了，开发没有及时跟进，
测试又不停的领新的任务，block区域成了这些卡片的避难所了，问题得不到快速解决”。

SA的烦恼：“每天指着一张卡片说需求的状态，开发听的云里雾里的，也不知道需求到底是什么阶段了，需
求分析过程还得细分。”



办法总比问题多啊，MOVE ON！

1、用热映电影《X战警》英雄头像贴在名片卡上，提高团队热情。

2、在to_do 列中增加“紧急加入”任务，用于放置必须在这个迭代完成的突发任务。

3、在开发列增加技术任务验收区域，一些技术任务需要经过组长验收才能算完成，特此增加该区域

4、取消了stg  block区域，主要是防止逃避WIP限制，而不及时跟进问题。对于block的任务进行贴条跟进。

5、公示持续集成维护、生产问题处理、版本守护、scrum轮值的排班表，便于自觉值日。

6、对于需求分析的看板（第二块看板），SA进行了重新规划，分出了“需求意向”、“需求分析中”、“待估
算”、“估算完成”、“需求延后”等列。





第7次演进



现在的看板用起来已经挺顺手了，不过作为一个很有追求的团队，大家还是继续“掐”细节：

开发Q的烦恼：“代码评审每天占用的时间好多，可是好多人都不专心，有点浪费时间，怎样才能提高大家代
码评审的积极性呢”。

开发Q的烦恼：“上个迭代失败了，关联系统沟通耗费了太多的开发时间了，开发联调时间都不确定，关联系
统支持也不及时，这些东西应该在迭代开始前就确定下来”。

测试L的烦恼：“同一个需求，有关联的卡片我需要拉通了再测试一遍，测完之后这些卡片才能移走，而测试
又有WIP限制，导致不能领新的卡片，实际上单张卡片是测试通过的了，如果有一张专门的卡片表示该集成
测试就好了。”

教练Z的问题：“开发每天只处理了一张卡片，看来两个名片卡是多余的，留一张就够了，这样以后也不存在
并行开发任务啦。”

根据这些细节，继续演进：

1、增加紧急通道：用于处理优先级很高，需要优先处理的任务，目前处理的任务是明天发布的pir版本。

2、开发名片卡只保留一个，减少并行任务。

3、为了提高大家代码评审参与度和积极性，增加了代码评审PK榜，分个人榜单，老年队和中年队的对抗
榜单。

4、在每张story 卡片上增加关联系统信息，包括关联系统开发计划，关联系统名称。

5、针对关联紧密的story增加一张技术卡片，表示需要做集成测试



效果



团队实施看板改进半年多以来，效果持续显现，从下面的数据上可以观察到：

1、30天需求实现率持续提升，从30%左右提升到60%

2、单元测试覆盖率持续提升，覆盖关键业务场景

3、STG缺陷密度持续下降，从6左右下降到4

4、需求保持快速交付，积压量非常少

5、随着时间推移，lead time整体上有持续下降的趋势

6、lead time的分布是一个比较健康的“韦伯曲线”，可预测性提升



结语



综合呼入团队的看板演变成现在的样子，并不是一气呵成，而是持续在问题中寻找改进的方法，并将改进
方法体现在看板上，也是团队共同努力的结晶。



最后总结几点心得：

1. 以最小的变化引入变革，没有一个高大上的开始并不要紧，贵在坚持改进

2. 团队纪律性很重要，说到就要做到

3. 将看板作为团队的一面镜子，反映真实，衍生转变

4. 结合scrum的定期回顾，寻求改进的契机