你有没有遇到下面的问题
1. 团队有物理Kanban，确实觉得Kanban有价值，但是对团队提升效率讲不清楚带来了哪些价值；
2. 每天站会形式化严重，陷入了固定的形式：我昨天做了什么，今天做什么，遇到了什么问题，去发现该并没有帮助团队发现问题，提升效率。
3. 有了Kanban和没有Kanban之前没有什么变化，感受不到Kanban带来的价值。
...
如果你的工作中有类似的问题，可以读读下文，或与能给你带来灵感。
感受不到Kanban的价值，问题在哪里？
问题不是出在Kanban本身上，如何出在使用Kanban上。
Kanban是一种信息传递的介质，形式可以是各种各样。我们是用Kanban来帮助解决一些问题，达到一些目的，如果感受不到Kanban的价值，那么我们应该回顾，先看看自己是如何使用Kanban的，是否使用Kanban去关注价值，暴露问题。
如何使用Kanban？
确切的说需要更具情况而定，下面举了一个例子，你可以分析下面的例子从而思考自己的团队应该如何让Kanban服务于当前的团队。
Kanban驱动开发的例子
【1. 背景】
一个产品团队引入了Scrum、引入了Kanban，期望团队能够关注价值，拥抱变化，响应变化。但是事与愿违，虽然使用Scrum中的角色、活动，使用物理Kanban，但是每日展会上也是过于形式：表述自己昨天做了什么，今天做了什么，遇到什么问题。表面看上去团队很棒，一帆风顺的景象。但是一个两周的迭代过后，结果告诉我们此次迭代计划没有完成，没有交付确认的内容。
多过去了一两个迭代，问题依旧如何，还是没有完成迭代计划。团队都看是不安。问题的症结在哪里？是站会过于形式化？还是大家不愿暴露自己的问题？还是就不该用这种新的交付方式？
【2. 回顾思考】
回答这些问题之前我们先停下来，回顾下Scrum、Kanban、每日站会都是为了什么？
答案很简单，团队使用这些工具和流程就是为了关注整个团队聚焦的价值。
既然是关注价值，那么我们采取的行动都应该围绕这个价值去调整。督促团队站会上尽量暴露自己很好，是个办法，但是效果往往不够明显，如何暴露问题，应该是围绕价值去暴露问题。所以单纯的督促和重复询问往往得不到我们期望的结果，问题也不一定在督促和询问的过程中暴露出来。那我们该怎么办。
【3. Kanban驱动开发的流程】
我们可以按照下面的流程去产生对团队的调整：
1，锁定团队聚焦的价值；
2，回顾并找到在交付价值过程中出现了什么问题；
3，给出Action去解决这些问题。
【4，第一次改进Kanban】
Kanban体现了迭代过程中的价值流动，因此我们应该借助Kanban发现一些显性的问题。
团队通过回顾看板发现了一个问题：很多原本开发完的User Story卡会重复返工。重复返工会花费Dev的时间，每个迭代的时间有限。尽早暴露已经Dev Done的卡片的缺陷似乎是一个ROI（投入产出比）最高的Action。
经过锁定价值、分析原因后，形成了两个Action。
- 最后团队在Kanban上增加一个“Ready For Test”列，进入该列前提是：Dev要与QA、BA一同Sign-Off完成的User Story卡，若没有发现问题，则可以挪动至该列。
- 同时在每张卡上标记处经历的天数（画正字的方法）。
通过Ready For Test来提早反馈质量问题；
卡上标记天数，有利于显性的暴露问题哪些真的花掉很多时间的卡.
【5，第二次改进Kanban】
在改进后的迭代过程中，能够看到一些变化，User Story卡因为质量问题，无法向后挪动，因为质量问题，一张卡的工作实际工作天数被正字表现出来。每日站会也逐渐有了改善，从形式的介绍自己做的、要做的、遇到的问题，逐渐变化为根据User Story卡上正字，去发现风险，并在站会后跟进。
迭代中虽有改进，但是依旧有问题，毕竟走出舒适区是很困难的一件事。
团队应把交付价值作为目标，去发现团队中出现的新问题。
通过观察看板上卡片的流动，站会上表述的工作内容，团队发现了一个新问题：Dev人员倾向于尽快向后挪卡，这样看上去仿佛自己做了很多事情，但是往往卡停滞在了Dev Done，而不去是找QA，BA去将卡Sign-Off掉。Sign-Off时卡有一部分又被返工。
针对上面的问题，尽快的让卡向后流动时关键因素，Sign-Off时有部分内容被返工说明出现在前面Kick-Off环节。因此形成下面三个Action：
- 去掉Dev Done一列：促使Dev人员开发完成后就要找BA、QA去Sign-Off卡。
- In Dev增加约束：一个人一个时间点只做一张卡。做另外一张卡需要把现在的卡先Sign-Off
- In Dev增加挪卡约束：进入In Dev状态的卡必须先于BA、QA做Kick-Off。Kick-Off时由Dev向BA、QA表述这张卡要做什么，BA、QA在Dev介绍完之后进行补充，达成共识后可以挪动卡到In Dev状态。
读到这里是不是会有一种感觉：本来就应该这样做，为什么不一开始就讲清楚每个环节要怎么做。我的思路是这样的，欲速则不达，任何意见事情都不是一蹴而就的，与其一次性介绍一个大而全的过程，不如分步，针对问题解决问题，这个过程不单是解决问题放的过程，同时也是传递一种解决问题的思路的过程，即：授人以鱼不如授人以渔。介绍完整流程和分步实施两种方式各有利弊，但我认为后一种对有些团队会更灵活，团队增量变化，持续改进，最终形成自己的团队工作方式和团队文化。而回顾那些现在令人向往的大型公司，他们在成长过程中，也是锁定目标，由目的、有计划的逐渐将团队引导向目标的方向。
【6，第三次改进Kanban】
经过过上一次Action的影响，团队开始了新的迭代，那些约束使得Dev更加聚焦如何完成User Story而不是如何表述让自己看上去工作量“很饱和”。
团队聚焦价值，价值通过解决团队当前遇到的问题来获得。
回顾Kanban上User Story的分布，我们发现团队整体环节已经问题不大，这时再聚焦一张一张的User Story上信息，每张User Story卡上都会通过之前的正字显示出当前这张User Story卡实际已经工作的天数，通过这些天数和预估的复杂度对比，我们能够发现有些卡预估复杂度和实际工作出入比较大，但这是表象问题。造成的真正原因是什么？我们需要去沟通、去了解。
通过沟通，发现有两类信息导致了这样的结果：
一类是需求范围不确定，导致有部分需要额外多做一些事情，才能让功能完整的运行。
一类是技术原因：对开发工具、开发框架等不熟悉。
经过分析、整理。针对这两个问题制定Action：
- BA对需求需要描述的更为详细：避免一句话的描述、介绍需求至少要做到背景介绍、需求介绍、异常情况处理等描述
- BA和Dev统一描述需求的语言：当描述增多时，保持一定的格式能够降低阅读成本。
- 团队内培训开始聚焦：从简单大而全的培训，转为能够解决团队实际问题，ROI最高的技术问题培训和分享、上。
【7，第四次改进Kanban】
有些事情能够快速得到响应，朝着期望的方向发展并能够看到结构。还有一些事情并不是做了就能够立即看到结果，开发能力的提升就属于后者。
再上次迭代的Action中一共3个Action，其中的BA对需求需要更详尽的描述和BA和Dev统一需求的描述语言。沟通协调之后能够能够看到结果变化很明显。而Dev对User Story完成情况的改善仅仅通过培训短时间也是无法解决的。
围绕价值，我们回顾第四次迭代后的结果，部分内容有改善，如工具类的使用，但是开发质量依旧是问题，并没有根除。这是坏消息也是好消息，因为团队开始更加聚焦，提升交付质量了。
回顾开发过程。除了开发工具、开发环境、开发框架，还有一类能力就是如何让程序能快快速响应需求的变化。Dev不能只是被动接受需求变化，Dev应该考虑的应该是如何让程序易于维护，易于修改。而Kanban会反映出我们综合开发能力的结果。
所以针对Dev出现的问题，形成了如下Action：
- Dev需要能够清晰描述问题：遇到问题应该首先表述清楚问题所在，而不是描述中引入更多的问题来解释现在的问题。
- Dev需要刻意联系：如Simple Design、设计原则等
- 坚持事不过三的原则：技术债可以欠，但是上限就是某处变化3次是就要考虑重构，从而后续更易于维护。
- 问题拆解：培养将复杂问题拆解为繁杂问题，将繁杂问题拆解为简单问题。问题的拆解能力的提升能够直接影响到估点的准确性。
...
总的来说，后续迭代中关注的更加细致。这些细节的完善，会持续提升团队的交付能力。
再往后Kanban还能再帮助团队带来其他的帮助，实现更多价值吗？可以想想一个百人团队中如何使用Kanban；想想跨部门、跨团队的合作... ...
结尾
所谓Kanban驱动开发是一种团队管理思路，是一种将团队引导向专业化的一种方式。与其天天被动的站在的Kanban下，不如抬头看看Kanban，想想怎么用Kanban来实现我们的目标价值。
