Kanban渐进式演进，让过程改进成为习惯
团队应用精益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、取消了stgblock区域，主要是防止逃避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的定期回顾，寻求改进的契机
页:
[1]
