该帖子同步发自：(铁托的博客  访问该博客)

　　对于软件开发来说，源于丰田生产管理系统中的“看板系统”是一种用于安排工作的非迭代方法。它并不使用固定时长的迭代和计划会议的工作方式，而是完成先前的工作后才从backlog中取得新的故事来做的工作方式。

　　Dave Nicolette (Valtech公司的一个敏捷教练)说道：“在敏捷社区中，有一些人似乎变成了干零活的人。他们仅掌握一种敏捷工作的方法，却把它来遇到的解决所有问题.当你只会接管道时，那么所有的事情在你眼里就都都成了管道。”全面学习并扩展敏捷技能而不仅仅是那些SCRUM或XP的基础是非常重要的，比如熟悉像看板等其它工具。

　　在软件开发团队中有各种各样的方法来实现看板系统。James Shore(《敏捷开发的艺术》一书的作者)就写过一种：“团队从backlog中拿到一个故事后，实现它，一旦完成就交付它。然后再拿下一个故事，实现并交付它。他们的工作就是完成并尽快地交付它，团队一次只做一个故事。”依James所说，让看板真正发挥作用有几个关键因素：

　　最小化可交付的特性(MMF)：一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护，(很像Scrum中的产品Backlog)，但对队列的大小有严格的限制(James认为应该是两到三个，最多七个)。

　　在线生产：团队总是在做最重要的事，直到完成它，而且在一个时段内只做这件事，并把它分成很多小且离散的任务。

　　估算：放弃正式的计划与评估，而假设所有的MMF都有相似的大小。通过记录完成每个特性的平均时间，来估计队列中剩余的特性还需要多长时间。

　　紧急任务：偶尔也会有紧急任务。要为紧急任务留有一个通道，这个通道会绕过了队列，一旦紧急任务走上这个通道，那就要求团队尽快地完成它.所以额外的紧急任务不受正常的backlog的限制。

　　缺陷：一旦出现缺陷，如果任务还没有完成的话，就要立刻修复它，否则就被放入backlog中。

　　David Anderson(《敏捷管理》作者，而且是看板系统的力荐者)说道，他的成功密诀就是：“关注质量，减少在线产品，根据需求及优先级来平衡能力”。

　　Corey Ladas回答关于“为什么使用‘拉’的方式?为什么使用看板?”这样的问题时，说道：

　　具有不同技能的人不得不在一起工作，来交付产品的特性。别做那些没人要的特性;别写那些你编程时不需要的规范;别写你测试不了的代码;别测试那些你不能部署的代码;……我认为看板比其它已知的工具更有效地解决了这一问题。

　　David Laribee为其前任雇主Xclaim引入了看板，因为在使用XP的两年后，他还是面临很多障碍和麻烦。另外，他感到，在计划、回顾和演示上浪费了很多时间。而且最终每一个好的敏捷团队都会有自己的工作流程，"当然，我们不可能在第一天就找到这样的流程.我们首先要根据已知且广泛应用的实践建立一个好的基线，这些实践包括TDD，滚动式计划等等。然而，好的敏捷团队会持续调整他们的过程以适合他们的产品及客户的需要。"