为什么使用看板方法
使用看板方法的原因是从设计上它就比Scrum要简单。关键是它比Scrum更容易在原有模式中切入和落地。看板方法一个好处是，它只关心某个工序用户故事并行交付的数量，而不关心要交付的用户故事的大小和时间，也就是说，单纯从运用看板方法的过程来看，它不需要做估算。
一、设计
从设计上看板就比Scrum要简单。关键是，它比Scrum更容易在原有模式中切入和落地。就算原来是完全的瀑布开发模式，也可以根据角色和工序来定义看板的格式，把交付过程和进度可视化，然后根据每个工序的交付能力限制在制品，形成拉动，进而观察交付的流动情况和发现瓶颈，并进行改进。这个过程不具有侵入性。相对而已，转型Scrum则要大刀阔斧得多。
二、好处
看板方法一个好处是，它只关心某个工序用户故事并行交付的数量，而不关心要交付的用户故事的大小和时间，也就是说，单纯从运用看板方法的过程来看，它不需要做估算。估算有多难，软件人都知道，就像业务人员面对KYC一样苦，特别是在估算被当成承诺的潜规则下。不管你花多少精力和时间，都没法把估算做得准确。
而Scrum的Sprint计划就是要做估算，即使采纳了故事点和扑克游戏这些新花招，都需要对用户故事的需求有充分的消化，而对于像银行等很多行业来说，需求都是晦涩且难以理解的，估算需要花费大量时间，也就是说，在下一个Sprint计划会议前，团队成员需要花时间准备才能保证Sprint计划会议的有效进行，带来的代价是，团队除了要面对当前Sprint交付冲刺压力外，还要费心费力为下一个Sprint计划会议做准备。更严重的问题是，在项目经理普遍追求量而不是质量的风气下，如果Sprint计划会议计划了这个Sprint要做10个用户故事，往往到Sprint结束的时候你要硬着头皮完成这10个用户故事，能坚持“期限不变，范围可调（Dates are hard dates, but scope can vary）” 的团队可能真心不多。这肯定会埋下质量隐患，XP倡导的不加班也成了黄粱美梦。我们看到行Scrum之形的团队不少，但能真正实现敏捷价值观的则凤毛麟角。
