刘华：看板那么好，为什么都成了摆设？

管理的粒度该多大

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

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

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

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

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

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

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

需求的边界在哪里

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

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

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

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

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

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

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

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

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

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

多大的局是全局