“ 模型是理想的，现实是复杂的。”

都说看板方法是比 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 周的交付。

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

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

觉得文章不错，顺手转发给朋友们吧。

分割线 卡通

关于作者

刘华（Kenneth）

• 敏捷、精益、DevOps 专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps 工具栈、Docker、Kubernetes (Google Kubernetes Engine, GKE)

• 曾在 GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100 等论坛发表主题演讲

• 阿里云、谷歌云认证架构师

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书和专栏《软件交付那些事儿》