扫码阅读
手机扫码阅读

刘华:看板那么好,为什么都成了摆设?

164 2024-04-04

模型是理想的,现实是复杂的。

都说看板方法是比Scrum更容易落地的方法,为什么现实是实施一段时间后,看板都成了摆设。这里的摆设,不光指那些竖起来后无人问津,板上卡片一直纹丝不动的物理看板,还包括通过Jira等敏捷项目管理工具设置了电子看板,但没有落实限制在制品等实践的情况。

现实中,大多数的“看板”都沦为了进度板,在我看来这些都不是看板方法,也没有得到看板方法的精髓和最大好处。

敲黑板

只有完整落实了以下3个实践,才是看板方法:

  1. 进度可视化;

  2. 限制在制品(Work-in-progress, WIP);

  3. 观察和改善流动。

为什么看似简单的看板方法落地过程都会走样呢?这里一定有一些现实的阻碍。我们一起来研究一下看板方法为什么在现实世界中会走歪。

这篇文章只提出问题,不提供答案,因为现实的问题没有标准答案,只有结合现实的思考才能找到适合自己的答案。

01

管理的粒度该多大

看板的第一个原则是进度可视化。

在我们日常管理中,放在看板里的,一般都是用户故事,在DevOps团队中,还会有大量的故障或用户请求的工单(为了简洁,我们把这些任务级别的请求也统称为用户故事)。引入看板或Backlog,其中一个目的就是把所有用户故事可视化出来,并让PO帮我们进行优先级排序。

但是从Jira(来自Atlassian的敏捷交付管理工具,原生支持看板和Scrum)把现有的用户故拉出来就傻眼了。我们一共有上千来自不同项目的用户故在Backlog中,以这个粒度呈现的Backlog摆在业务干系人面前是没有意义的,让人完全迷失在细节中,无法排序。

如果以项目为粒度进行排序,人员和资源就会全部投入到高优先级的项目中。但现实是,日常会不断有新的请求要插队,以金融行业为例,时不时就会冒出一些监管、合规、新客户的需求,我们在原计划的项目之外,还需要不断调剂人员来应对这些“编外”事务。


简单来说,以项目为粒度的优先级排序同样没有意义,除非优先级低的项目一律不做,但这并不会发生。


用户故到项目之间需要一个合适粒度的东西,业务能看懂,对全局意义明确,让业务干系人一眼就能确认这个是否应该在下一个迭代里做,对交付团队又是可执行的。我也曾经考虑过Epic是不是一个选项,但是Epic的粒度和范围同样无法标准化。


而且,交付团队和业务、用户往往是一对多的关系,也就是一个交付团队往往需要应对多个代表不同利益的干系人,这个中间也没有一个PO能摆平所有人。

02

需求的边界在哪里

看板的第二个原则是限制在制品。

看板源于精益生产。所以它是从生产领域移植到软件交付的方法。在生产领域,由于管理的对象是物品,它的边界清晰,而且是重复的。

但软件交付过程中,每个需求都是独特的,而且其边界可以无限扩展。这就导致了每个需求的复杂度是完全不一样的。有些需求可能几天都能搞掂,有些看似简单的需求,花上数月时间完全不足为奇。

要缓解这种差异,似乎我们唯一可以做的就是需求拆分,把一个大而复杂的需求拆分成若干个更小的、有业务价值的、可独立交付的用户故。使每个用户故的复杂度和开发周期都降低下来。

但要命的是,一个用户故事的开发往往不是自己团队能独立完成的,中间会有大量的外部依赖,一旦有了这些依赖,等待时间就会漫长且不可预测。

这会直接导致“限制在制品”的原则难以落地。

比方说,我的团队有3个开发人员,假设每个开发人员可以同时处理2个用户故,那么团队的限制在制品数量就是6,也就是在任何时候,只允许最多有6个用户故在开发中的状态。当这个限额满了以后,新的用户故事要么在Backlog里排队,等待那6个用户故事中有被完成的情况;要么和那6个用户故事的其中之一做交换。

但如果这6个用户故的开发过程存在外部依赖,它们就会停留在开发中这个状态很长时间,也许在这种情况下,团队开发人员的大量时间是在等待外部依赖的响应。

如果我们定下规则,一旦用户故因外部依赖停留就把它们移走,然后拉入新的用户故事进行开发。这样做确实保证了开发人员的时间不会浪费在等待上,但那些处于半成品的在等待外部依赖的用户故就会离开我们的视线,很容易成为“弃儿”,导致这样的半成品会越来越多,反而违反了精益的最小化“库存”的原则。

在这些现实情况下,要想软件需求实现像生产那样的“流动”根本不可能

03

多大的局是全局

板的第三个原则是观察和改善流动

在这个过程中,需要识别瓶颈。按照约束理论,所有瓶颈以外的改善都是徒劳。

看板通过把交付过程的全流程展示出来,并把出现瓶颈的环节可视化出来,帮助团队理解在整个交付过程中,哪个环节是瓶颈,从而知道改善从哪里入手。

这也为团队带来了全局观,避免局部改善。

但问题在于,一个项目、一个系统,往往存在非常复杂的依赖关系。一个团队找到了自己的“全局”瓶颈,但这个“全局”却是更高维度的局部。对于部门而言、公司而言,一个团队就是很小的局部。

那么我们的看板范围应该要多大呢?整个部门、整个公司还是整个宇宙呢?

看板方法作为一种管理手段,它的范围也决定了我们的日常管理范围。一旦管理范围太大,就会出现管理过载。

我们部门为了解决各项目团队、组件团队(也算是DevOps开发运维一体化跨职能团队)各自为政的问题,试图把所有项目都放在一个全局的交付计划中。也引入了规划化敏捷(SAFe)的部分实践,比方说每三个月一次的PI会议,组织所有项目干系人上百人规模的迭代计划会议,计划未来12周的交付。

这个过程成效未知,但痛苦指数不低。因为各个项目、各个系统的复杂性叠加在一起,是一个熵增的过程。

模型是理想的,现实是复杂的。我曾经说过,要实现真正的敏捷、精益开发,光有管理方法是不够的,如果系统和组织是复杂的、系统和组织间的依赖关系是复杂的,你一定会很快遇到瓶颈。这也是为什么组织架构、系统架构是我们转型过程中绕不开的话题。

你有遇到这些问题吗?你的解决之道是什么呢?欢迎留言讨论。

原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247484903&idx=1&sn=bd05cddff8dabd3157d2e0a3c4776c94&chksm=e9e26e63de95e775dccecf7835c13de597cb42ce66e5e1f57de3116e72d86ce73294ca495bfa#rd