看板因为成本低廉，使用方法易上手，被很多软件研发团队使用。
今天讲讲我看到的使用看板的几个常见的问题，以及如何避开这些问题，让看板发挥它真正的效用，让大家减少时间浪费，按时下班.
我曾经在一个没有使用过看板的团队引入TAPD（一款在线团队协同工具）作为看板。
在我引入TAPD之前，这个团队用一个在线表格协同工具在管理项目。
我在介绍TAPD上的看板（在TAPD里叫“故事墙”）的时候就强调，看板上的任务在完成之后应该即时移动，这个团队没有出现过“早会用来更新看板”这个问题。
直到我后来指导一个之前就在使用物理看板的团队。
我发现这个团队只有在开早会的时候会移动他们的卡片。后来我又指导另一个在用物理看板的团队，发现他们也是这么做的。
我就意识到这可能是一个普遍存在的问题，尤其是那些使用物理看板的团队。
他们的早会就是用来做移动卡片这件事，这意味着他们没有用正确的方式开早会，也没有用正确的方式移动卡片。
这样可以减少卡片在看板上的等待时间，从而缩短卡片的平均前导时间（lead time), 也就是卡片从进入管道，到从管道输出的时间。
前导时间是个看板术语，我换一个说法，可以理解平均交付一个需求的时间，这样大家就能看到这件事情的价值了。
有的朋友可能会说：
这种想法的问题在于，A卡片在看板上停留的时间变长了，因为它没有即时被下一个环节的负责人领走进行加工。如果你用同样的态度对待B卡片，B卡片的停留时间也会变长。
这个景象是不是很熟悉？
大家工作都很努力，进展也似乎很“神速”，但是到了计划发布的那天发现几乎没有卡片可以发布。
停止启动，专注完成
无论你们团队是单纯使用看板方法，还是使用Scrum+看板。你们都需要
这个上限的数量就叫做在制品限制。 如果是使用Scrum+看板，这个上限的就是你们在这个迭代计划要完成的那些卡片。
假如你们的看板上已经堆积了到达上限的卡片，那么你们要做的就是投入所有的团队力量，去专注把这些卡片推动到最后一列（完成），而停止启动（移入）超过在制品限制的卡片。
比如，下面这种情况如果出现，开发应该去测试在“测试中”的卡片，帮助“完成”这些卡片，而不是从需求池里拖进（启动）新的卡片。
全面性人才非常稀少和难以快速达到，但是我们可以把自己的团队成员往多面手/T型人才的方向去培养。一个成本低廉的方法就是团队内部的分享和培训。
卡片移动缓慢的常见原因是依赖性关系太多，和拆分粒度不够。
大家要在拆分方面再发力做一下，拆分的时候要考虑到尽量减少依赖关系。
如何进行拆分，业界有一个常被引用的文章就是这个需求拆分9种方法。请大家关注本公众号回复“拆分”获得需求拆分9种方法的思维导图。
这种情况也是偶然会看到，两个卡片的负责人，都已经做完了各自的卡片了，你等我，我等你，最后才发现双方都在等，把时间都浪费了。
解决方法是：
尽量在拆分的时候减少依赖;
有强依赖关系的卡片设置一个小小的项目经理，由其中的一位卡片负责人来担任，这个负责人负责将跟进这一群有依赖关系的卡片以最快速度移出管道。
看板的使用千变万化，今天先说这4个常见问题，我们后续再聊！
END
精选文章
一次性解决所有需求变更问题（赠需求变更流程图）
团队大了怎么管？
需求多做不完怎么办？
如何管理需求方期待？
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
