看板还是Scrum

   随着负责敏捷的VP来到中国，看板也成为了这次讨论的热点。很多团队都在使用看板从而取代了之前的Scrum。

   看板源于丰田，是丰田生成模式的经典代表，几乎每个学习丰田TPS的企业都会不自觉的把看板当作第一个引入的模式，因为它直观有效。而敏捷将可视化作为很重要的一个要素，自然而然的会想到向看板要概念。那么看板有哪些特色呢？

  在传统的TPS中，看板有很多类型，比如工序间，工序内，信号，外协等等。以工序间为例，当后工具需要一些零件的时候，就将需求（包括规格、数量等等）写到看板上，然后交给前一道工序，那么前一道工序就需要按照看板的指示来生产，生产完后将零件以及看板提交到生产线旁的零件箱中，没有看板而生产出来的零件会被监督人员问责的。这是丰田拉模式的典型体现。那么这里体现了两个特点，一是只有在后道工序提出要求的时候，生产线才能发生流动；第二就是提出的需求必须明确，包括规格以及数量。这就明确了一条生产线的WIP能力。

  这些概念如何在软件开发中体现呢？软件流程发展到今天剖开一层层漂亮的外衣还是需求分析-》设计-》实现-》测试-》移交。那么这样每一步都可以看作是一道工具，每一道工具都有着对应的人员，比如多少个BA，多个少开发测试，多少个实施人员。他们的能力是确定的。所以在配比人员的时候是需要考虑各工序间均衡化生产流动避免浪费，比如你有4个实施人员，每个人可以实施2个故事，但是却只有2个测试，每个测试只能在同一时间测试2个故事，那么实施的产能就是测试的两倍，在实施阶段会出现人力的浪费。这个时候要么让实施人员同样具有部分的测试能力，要么按配比增加测试或者减少实施。每个工序都需要明确知道自己的能量。在能量达到上限的时候就需要阻止新的任务流入，当任务因种种原因无法顺利流出的时候需要立刻停到整个生产线，所有人员都集中到任务阻塞出，集中力量进行问题的排查解决。直到问题解决工作流回复常态。

  所以，看板其实也没有什么稀奇的东东，只是控制的粒度和角度不同。Scrum的话应该更多的是按照iteration来组织，并且生产力完全是按照团队的力量在进行。例如一个iteration2-4周，一个故事必须完成分析-》开发-》测试，然后才能启动下一个。而看板则没有很强的时间期间的概念，允许每一个工序有一些池的现象出现，但是要注意水的深度。所以Scrum看上去更适合于一般的里程碑明确的项目开发，而看板则比较好的适应在线软件或者维护类软件。比如我们公司的ERP，拥有30多年历史，光荣的积累了数万个bug，这些bug只需要带着修就行了，每个release能修多少就修多少，所以PO只要有空就给这些bug排排优先级，然后丢到backlog里面，那么BA拿出最上面的几个来细化，开发则负责修理，测试负责测试，文档负责调整旧的文档。是不是很象流水线作业？对于在线软件，因为是永远的beta版，所以也是每天都会有各种各样的反馈出现，那么这些反馈也会走比较类似的流程，最后再加上go live的工具而已。

  其实，丰田最让人印象最深的是他们不断改善的勇气和决心。而作为一个软件公司最需要借鉴的不是看板这样一个工具，而是背后的一种精神，那种不断进取永不满足的精神。有了这种精神，一切工具都是浮云，骑上自己的神马不是更爽？