团队应用精益Kanban方法的基本的改进过程，大致可以分为以下几步：
1. 先可视化现状，透明团队现有工作流程、人员角色、分工、流转规则。
2. 结合WIP约束、数据分析（累计流图、分布图、控制图等）等手段，进一步可视化全流程中的问题与阻碍。
3. 团队根据这些问题和阻碍，设计有针对性的改进试验。
4. 实施改进试验，观察效果，形成反馈闭环。
5. 循环执行以上1~4步，渐进式的进行过程改进。
做得好的团队，每个迭代，Kanban设计与运作方式总会有些新的优化和尝试，团队总会得到一些新的surprise和learning。本文讲述平安科技综合呼入开发团队的Kanban渐进式演进的故事。
时间回到2014年2月，综合呼入团队组建，团队成员包括1个SA、2个测试、8个开发，以及1个敏捷教练。
1:最原始的看板
“看板”，熟悉而又陌生，曾看见其他团队每天早上对着一块板子说来说去的，那原本只是个传说。当教练拿着一块版子放在我们面前时，心里还有一些小激动呢。立马，我们基于当前的开发流程，设计了我们团队的第一个简易看板。
说明：
1、团队一个月发布一个版本，迭代周期也是一个月。
2、进入迭代后，我们主要有开发、测试和UAT测试阶段。
3、看板的左下方是燃尽图。工作量当时用的还是“人时”度量。
4、卡片分为紫色和绿色，紫色为技术任务，绿色为需求。当时的卡片那是相当的简陋呀。
5、还有需求分析的看板和记录问题的看板。
2：第1次演进
那么问题来了：
教练Z的问题：“迭代1失败，团队总结好多改进措施，怎样时刻提醒大家这些改进项呢？”
开发Q的苦恼：“这个迭代居然失败，原来DoD是这样定义的，早知道我们努力也许就能成功了，下次我得把DoD记住才行。”
SA的烦恼：“业务从提需求到纳入迭代要经过好多环节，看板完全体现不了需求分析的过程。”
好吧，那就优化吧：
1、新增迭代一回顾以及DOD模块，我们在迭代方向上有整体规划。
2、看板在待办、需求分析、故事拆分、估算方面，改变了原有的分析到完成的粗放笼统式看板，开始有一定的流程化进行。
3、看板整洁度提高，大家在整洁、美观方面开始注意，增强可视化效果。
3:第2次演进
问题又来了：
测试L的烦恼：“开发总是不进行开发测试，测试环境一大堆bug，反复修改几次还是会有问题。”
教练Z的问题：“敏捷也开始一个月了，团队的产能到底有多大，怎样看出团队的变化呢，需要数据支撑才行哦。”
开发Q的烦恼：“迭代还是失败了，可有几张卡片是由于关联系统无法支持联测，根本不赖我。”
SA的烦恼：“一个大的需求拆成几个BI，开发同事都不关注关联关系，我得将这些卡片关联标注出来才行。”
好吧，那就接着优化：
1、补充了卡片从“进行中”移到“已完成”的规则（需要开发截图），这样督促开发做好开发测试。
2、卡片上标注开发测试开始完成的日期，每日站会在卡片上记录投入工时。为数据统计做准备。
3、卡片上补充分类信息，更容易看出卡片之间的关系。
4、为更合理的配合关联需求的开发节奏，优化补充当前迭代的需求开发任务，并为这类卡片制定针对性的DoD。
4：第3次演进
问题接着来：
教练Z的问题：“已经过去两个迭代了，一个版本时常有紧急需求加入，迭代内容经常不可控，是不是一个月的迭代太长了呢？”
测试L的烦恼：“这次迭代又失败的，卡片周期内，开发占用了太多时间，完全没留给测试充足的测试时间。”
SA的烦恼：“BI采用人时进行共同评估时大家偏差比较大，也很难达成一致。采用点数是不是更容易达成一致呢。”
继续优化：
1、看板上的任务卡片变少了。原因是迭代三开始我们将迭代周期缩短为了2周，一个迭代的任务变少了，看上去是不是清爽了不少呢？
2、卡片上增加了一个计划开发完成时间。在开发同学领取任务时标注，测试MM们心里也算有底了。
3、卡片上标注的开始完成的日期开始发挥作用了，lead time被可视化出来了。大家看到了部分卡片开发测试周期，有点长。
4、迭代燃尽图统一使用点数了。开发速率的稳定数据将会形成。
5：第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等。
6、团队统一设计卡片模板，卡片信息更整洁、完善。
2014年5月，终于！综合呼入团队首次取得了当次迭代的胜利！看板的改进带来的效果那是相当的明显。（本资讯于2016-06-14首次发布）
