敏捷看板（kanban）实战与信息可视化

前几天忙于工作上的一些整理和汇报，没有很多时间投入在连载葵花宝典的事情上，所以耽搁了几天，今天继续。

本来这一式的名字叫做“观星”，取材于三国杀里诸葛亮的技能，玩过三国杀的同学们都知道这是怎么回事，诸葛亮在每个回合开始前可以摸5张牌，然后可以随意调整顺序放回去。 这个技能的关键是信息量，在软件项目中我们需要更多的手段去获取项目更多的信息，在看板方法里，这就是可视化的实践。

但是后来想想我不能老取材于游戏啊，我是个天文爱好者，对宇宙有着极大的向往和好奇。伟大的旅行者1号，旅行者2号，卡西尼号，新视野号，机遇号，好奇号，惠更斯号......还有哈勃望远镜，和即将发射的韦伯望远镜，当然也有悲壮的挑战者号和哥伦比亚号，它们都是代表人类智慧最最顶尖的科学成果，在我心中占据着非常神圣的位置。所以出于信息量，可视化的考虑，我把这一式的名字改成了新视野，那个近距离观察冥王星的探测器。

这一式的内容并不难，其实更适合在培训课程上通过提问-思考-回答这样的方式来帮助同学们理解，现在只用文字来表达的话，缺少了思考环节，可能会打点折扣。请同学们后面看到图例的时候，先不要往下滚去看答案，尽量通过自己思考然后和我的答案去印证，自己思考后所获得的，才是真正属于你们的知识。

延续上一式的看板：

现在为了可视化更多的项目信息，我们用带颜色的小圆点来表示不同的角色，蓝色表示开发人员，绿色表示测试人员。还是假设我们有7个开发，2个测试。我们可以让每个人手握一个小圆点，当他工作于某个需求的时候，就把这个圆点贴到这个需求上去，当他在这个需求上的工作结束了之后，就把这个圆点给拿下来。这样，我们就可以通过这个板知道我们的资源投入情况是怎么样的，以及其中可能存在什么样的问题。

（如果有同学对每一列下的数字表示什么含义不清楚的，请先移步阅读 第八式 TPS TOC了解一下）

CASE 1：

存在问题： 对测试的同学而言，在待测试队列里已经有了6个需求在排队，这时候应该聚焦在更早的完成待测试队列里的需求，而不应该去写后面需求的测试用例。开发同学有5个人在做开发，2个人在修bug，但是待开发的列里只有4个需求了，已经小于下限了，这时候开发同学应该考虑是不是优先去做些设计的工作。

CASE 2：

存在问题：在开发队列里排在最上面的需求只有1个人在工作，而排在下面的需求有3个人在工作，优先级高的需求反而投入的人少，这里可能存在开发人员投入不合理的情况。另外，有一个开发正在修bug，团队也可以考虑下是不是有人可以帮他一起修bug，加快这个bug的修复进度。

CASE 3：

存在问题：待测试队列里的需求数量控制的还不错，但是待开发队列里的需求已经小于下限了，这个时候没有在bug fix的开发应该去做些设计工作了。测试的同学，这个时候如果有需求的测试用例没有写完，是可以考虑去写用例的。

通过以上3个CASE同学们可以看出，只要运用得当，资源分布的可视化配合缓冲区的上下限，团队可以非常容易的看出目前的时间投入是否合理，是否存在潜在的问题，是否需要调整工作内容。不过这里请注意，上述3个CASE的问题，都仅仅是可能存在，并不一定是真的问题，也有可能真的是问题但是一时无法解决。出现这些现象，是在提醒团队这里可能有问题，需要去关注和分析。

除了资源投入可视化之外，我们也可以在看板上做一些障碍的可视化：

比如我们可以用一些颜色鲜艳的小便签，贴在存在障碍的需求卡片上，这样就一目了然的知道哪些需求存在障碍，可能需要额外的关注，或者采取些针对性的措施。

我们还可以在看板上增加一行停滞区：

我们把那些已经开始投入时间去工作，但是因为某种原因只能停工的需求放在停滞区里，停滞区里的需求大部分情况下是由于外部依赖所导致的，团队成员也可以针对停滞区里的需求采取一些必要的协调或资源拉动的手段。

注意，停滞区里的需求和存在障碍的需求是有区别的，存在障碍的需求是指团队成员投入时间在这个需求里，但是存在某些障碍，比如技术难题，对这个需求的正常推进造成了阻碍，但是成员的时间还是继续投入在这个需求上。而停滞区里的需求是指团队成员已经开始做这个需求了，但是做着做着发现法做不下去了，没法投入时间，或者投入时间也没意义了，比如说成员突然生病休假造成停工了，或者外部依赖的一个接口还没完成，这类情况。

我们还可以在看板上设一条超车道：

哪个项目组还能不遇到些奇葩的紧急情况呢，设置一条超车道可以让项目组处理这些紧急需求的时候别和正常的需求搞混。但是请同学们记住，发生超车事件之后，一定要记得及时复盘，寻找超车的根因，并在以后尽可能的避免再次出现超车事件。

根据项目的具体情况，可以有很多可视化的方法体暴露尽可能多的信息量。所以我个人更喜欢物理看板，布局可以非常灵活的调整。何勉老师的《精益产品开发》里也例举过各种看板的布局，我从中也学习到了很多。但最重要的不是学到了哪种布局的看板，而是学到了如何通过可视化的理念去设计符合项目具体情况的看板布局。

在看板上折腾完了可视化方法之后，我们也可以在需求卡片上做些可视化的文章，我们设计了这样的需求卡片：

设计进度： 指这个需求当前的设计进度，只有设计进度到达了100%后，并满足了其他关于设计的DOD之后，这个卡片才能被移入待开发队列。

在这个卡片上，我们把所有的进度都用25%，50%，75%，100%来表示，我们认为不需要也不可能在进度评估上做的太精确。使用方法是在这个百分比的格子上填入日期，比如当一个成员5月5号的时候100%的完成了某个任务的时候，在这个任务的100%的格子里填入5/5就可以了。

任务描述：这一栏是设计的结果，并且要求尽可能具体。我们鼓励在这里填入具体的xxxx.java开发，或者xxxx.html, xxx.js开发，这样才能反映这个需求是经过充分的考虑和设计，如果仅仅是写前端开发，后端开发，coding，这样的任务是没有什么意义的。

负责人：当然就是负责人了，每个任务只能有1个负责人。

测试用例：表示测试用例的进度。一个需求只有当它所有的任务都100%完成，并且测试用例也100%完成，再配合其他的DOD，它才能转入待测试队列。

SD： Start Date

EE： Estimation Efforts

AE： Actual Efforts

其他的栏目都很容易理解，就不一一解释了。我们来看一下这个卡片的实例：

这个卡片的内容，并不难解读，假设今天是2月28日：

这个需求2月25完成的设计。

东方不败负责第一个类的开发，2月25开始的，评估16小时完成。

林平之负责第二个类的开发，也是2月25开始，评估12个小时完成。

左冷禅负责第三个类的开发，他从2月26开始，评估8个小时完成。

测试用例由令狐冲负责，他于2月27号完成。

在2月28（今天）的时候，卡片上的信息反映出来东方不败在27号的时候完成了75%，这已经超过了他16小时的评估了，可能是遇到什么障碍了。

林平之2月26就完成了他的任务，只花费了8个小时，提前完成，好同学是好同学，但是并不鼓励太保守的预估。

左冷禅2月27完成了他的任务，总共花费了16小时，比预估多了8小时，好歹也是完成了，但是要反思一下为什么比预估多了8小时。

这些信息告诉团队，现在这个需求的临门一脚是东方不败负责，如有条件允许，请协助他把这个任务完成掉。如果东方不败是个正常人，他这个时候一定会感受到同伴压力，这个是心理反应，不需要任何人去告诉他，这个时候如果有优秀的教练再煽风点火，这种压力就会起到正向的作用让东方不败自主的去提高效率。关于同伴压力更详细的介绍，请阅读第六式 隐袭。

以上这个例子，不管是林平之的提前完成，还是左冷禅的延迟完成，都是不鼓励的。因为如果赞赏了一个提前完成的行为，那保守评估可能会成为团队的一个常态。虽然不鼓励，但是也不必指责，把这件事情看得淡一点，团队成员一起坐下来看看下次怎样评估的更准确就好。只有当某一个成员连续多次都是提前或者都是延迟的时候，才需要专门的辅导。