为什么我更推崇看板方法

本文主要是介绍为什么我更推崇看板方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Scrum号称是最小的项目管理框架，但在看板方法面前，还是太复杂。2016年，我最大的收获就是接触了看板方法。之前一直被“看板”这个中文翻译误导，以为就是Scrum里面的进度板或白板，直到深入学习了看板方法，才顿然大悟。我认为看板方法才是最小的项目管理框架。

看板方法很简单，只有3个实践：

进度可视化；
限制在制品（Work-in-progress, WIP）；
观察和改善流动。

640?wx_fmt=png

所以从设计上它就比Scrum要简单。关键是，它比Scrum更容易在原有模式中切入和落地。就算原来是完全的瀑布开发模式，也可以根据角色和工序来定义看板的格式，把交付过程和进度可视化，然后根据每个工序的交付能力限制在制品，形成拉动，进而观察交付的流动情况和发现瓶颈，并进行改进。这个过程不具有侵入性。相对而已，转型Scrum则要大刀阔斧得多。

640?wx_fmt=jpeg

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

作为敏捷与精益大杂烩的DevOps，其实更多在工程实践上采纳敏捷实践，在项目管理框架上，其实它采纳精益（看板）的思想更多。

当然，业务和用户需要计划与承诺，不管采用任何方法，我们都要做估算。但计划与执行（交付）是两个不同层面的事情，关于这一点，可以参考罗辑思维的《计划的用处》（点击左下角的“阅读原文”可听/读全文），让你对计划有全新的认识。所以，计划与采纳看板方法的交付过程其实是不相干的，它们分别解决不同的问题，计划可以完全脱离在交付过程之外，我们甚至可以在计划上采纳传统的项目计划方法和工具，而交付过程采纳敏捷或精益方法。对项目而言，计划只是一个中间产物（output），交付才是其产出（outcome）。我们要确保的是在交付过程中，通过可视化、信息共享和频繁沟通，建立与业务/用户的互信，改变协作模式，共同应对变化和实现高价值的交付。但是在Scrum中，每个Sprint都要做计划，并如前面所说的，这个过程还会持续干扰到交付过程。

虽然看板方法没有要求进行每日例会，但并不妨碍我们在看板方法的基础上进行定期优先级排序会议、每日例会和定期回顾会议。请参考我的另一篇文章《开启你的敏捷之旅，只需要这5步》，就是以看板方法为基础。

最后还是要强调一点，没有限制在制品的看板只是一块进度板，没有实现拉动，等于没进敏捷和精益之门。为什么要强调拉动？传统的思维是不管下游交付团队的交付能力如何，一味把需求往下推，而实际上，如果交付团队只有3个人，即使一下子推给他们100个任务，他们同时也只能处理3-6个任务，后果是，这100个任务的优先级排序其实是交给了这3个对业务价值没有概念的人。但是拉动就不一样，只有下游有容量时才从上游拉入任务，那么当Product Owner知道交付团队的限制时，就会认真思考当下应该派哪些任务给他们才能使价值最大化，从而实现价值驱动交付。

从原则上说，Scrum与看板其实是相通的，但又各有差异。以下内容摘自我的书《猎豹行动：硝烟中的敏捷转型之旅》第六章“发现新大陆——初识看板”，以便给大家更清晰的概念：

看板是限制在制品的，其实Scrum也是，只不过方式不同。Scrum限制在制品的方式是通过Sprint计划会议限制每个Sprint放入的用户故事。看板则是通过在每道交付工序限制并行任务数量。