为什么我更推崇看板方法

看板方法才是最小的项目管理框架。

0
108

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

看板方法很简单,只有3个实践:

  1. 进度可视化;
  2. 限制在制品(Work-in-progress, WIP);
  3. 观察和改善流动。

所以从设计上它就比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之形的团队不少,但能真正实现敏捷价值观的则凤毛麟角。

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

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

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

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

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

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


原则上,在Scrum里,不建议在Sprint中间加入新的用户故事。但在看板里,任何时候都可以把新的请求放入Backlog中并排序,团队有闲置产能时便把优先级最高的请求拉入进程中。


在Scrum里,一个用户故事的大小必须是能在一个Sprint内能完成的。在看板里,由于跟时间无关,没有这个限制,它只关注并行任务数量。


而两者相通的地方有:

  • 都基于敏捷与精益的原则,追求价值,消除浪费;
  • 都是基于拉动的计划系统;
  • 都限制在制品;
  • 都通过透明化来获取快速反馈;
  • 都聚焦更早和更频繁地交付软件;
  • 都需要把大需求拆分成小故事。

小结我对以Scrum为代表的敏捷和以看板为代表的精益的理解:

  • 敏捷:小步推进,快速反馈,频繁验证
  • 精益:聚焦价值,加速流动,减少浪费
- leansoftx.com -

发表评论

请输入评论内容
姓名