一则物理看板的演进实践

作者：林晔琛 | 效能改进

一、背景

看板（并非特指 Kanban，下同）作为一种目视化管理工具，能够将团队成员的工作过程透明出来，帮助团队更好地发现问题和瓶颈，尤其是在特性团队中，更是会秉承看板的理念，将其与站会形成良好的配合和互动，充分发挥其目视化的作用。

在笔者的工作场景中，特性团队尚处于敏捷转型初期，并未养成良好的工作习惯，其中就包括看板使用不到位的情况，导致了站会活动效果不佳。于是，笔者尝试从「改变看板的使用姿势」切入，唤醒团队的自管理意识，逐步改善团队的敏捷氛围。

二、物理看板演进

1. Scrum 板：从失焦到聚焦

现象

每日站会是技术负责人发起的，没有固定的聚会场所，而且形式比较随意：团队成员围坐在办公室休息区的沙发上，抑或茶水间的吧台前，每个人端着电脑，在技术负责人的主持下被挨个儿点名，然后大家轮流在自己电脑上更新维护同一份在线表格中所负责的任务条目的状态（石墨、Confluence 之类的），站会过程中的其他时间就处理与会议无关的事务。

分析

责任失焦。作为技术负责人角色，主持人天然带有权威性，站会以该角色为中心，更像是个汇报的过程。
空间失焦。没有固定的场所，站会难以成为团队的一项工作习惯，大家在站会上的行为比较随意，就是意料之中的了。
目标失焦。每个人都等着被点名向老板汇报，所以往往只考虑自己的任务完成与否，难以与团队中其他人建立连接，更不用说关注到团队的共同目标和整体进展了。

改进

基于 Scrum 框架之三大支柱：透明、检视、调整，我们选择了从工作任务可视化入手，在一块白板上，直观地跟踪团队每项工作任务的进展和状态。

将白板用彩色胶带划分出多个行列，行（泳道）代表 story，在 story 下拆分出颗粒度不超过 1 个工作日的 task（不同颜色或大小代表不同的任务类型）卡片，都会经历 todo/doing/done 三个状态列。当 story 下的所有卡片都从 todo 转移到 done 后，即宣告 story 交付完成。

效果

责任聚焦。团队的工作都呈现在看板上，所以每个人不再需要带电脑，同步自己进展的时候会一并观察同一个 story 下的其他卡片所处状态，并与一起合作的同事进行交流互动。
空间聚焦。白板所在的位置，就天然成为团队开站会的场所，站会也越来越成为团队开始一天工作的仪式，无关行为越来越少，会议效率越来越高。
目标聚焦。大家围绕着 story 展开工作，每个人都能清楚地知道自己的任务是什么，任务背后的目标是什么，因此能够快速地暴露风险，关注障碍是否被移除。比如：曾经某个同学试图多任务并行，就立马被团队其他有依赖工作的成员发现和阻止了。

图1. Scrum 板实操图

2. 精益看板：从聚焦个人任务到聚焦团队目标

现象

经过在完成一个迭代中采用「物理看板+站会」的尝试后，团队成员逐渐适应了这种新型的站会方式，一上来就先将自己的 task 卡片拖动到对应的状态栏，然后开始相互交流 story 的状态或阻塞情况。

分析

我们从上述观察，意识到团队成员在看板工作模式的启发下，开始关注 story 的流动（原本只是技术负责人或产品负责人才会关注）。但此时的看板机制是只流动 task，而story 固定在看板最左侧列，无法体现其流转效果。于是，我们意识到当前的看板模式已经不能满足团队的使用诉求和工作习惯了。

改进

对价值流的关注是敏捷团队成熟度提升的体现，这则新闻真的令笔者和 ScrumMaster 感到兴奋。于是，我们开始着手构思基于精益价值流导向的看板模型。

在新的看板模型中，我们打算优先在「列」的维度表达研发过程的工作流，以体现 story 的价值流动（期待它流动得越快越好）。初定了「筹备/开发/测试/发布」4 列，并在每个列中再细分出 story 栏和 task 栏（现状：story 的颗粒度较大）。

与此同时，为了避免在 story 流动过程中，大家对能否往下个阶段流转产生歧义（比如：对于「结束开发阶段」这件事，开发同学认为是「编码完成」，而测试同学认为是「冒烟自测通过」），我们在每个节点声明了准入准出的条件（在敏捷中常被称为 DoD，Definition of Done），并透明在看板上，以提醒团队在移动 story 卡片时，根据标准进行核对。

效果

使用了新的看板，团队成员不再在站会上确认每一张 task 卡片的状态，而是将注意力转向影响价值流动的问题，并重点关注阻碍项。一旦某个环节变得不顺畅，就会立即体现在看板上（比如：story 或 task 卡片在此处积压），指引团队须重点关注并解决，以及时恢复它们的流动。

图2. 精益看板实操图

3. story 卡片的演进：管理从粗放式到精细化

现象

行文至此，习惯于使用电子看板的读者可能会产生一个疑问：物理看板如何度量？经过几个迭代的看板共创后，我们其实也意识到这个问题了，毕竟我们需要通过度量来指导改进。

改进

但由于物理看板在数据自动统计方面有其局限性，所以我们采取了一种简单易实施但效果又不错的数据收集方法，来支持敏捷团队在数据度量方面的诉求。

我们在 story 卡片上增加了其流经各个价值节点的时间填写动作。在站会上，当 story 卡片被准出并开始流向下一节点时，站会主持人将触发日期记录到 story 卡片上。

效果

在迭代结束时，我们可以从看板上收集到 story 流动相关的工作记录，整理后用于团队指导改进，于是，据此该团队便形成了反馈和持续改进的机制。

图3. story 卡片度量实操图

三、心得

看板原理和实施方法，业界有不少教科书式的介绍，但运用到实际场景中时，我们务必根据团队敏捷成熟度的情况进行适当裁剪，在「微改进」实践中持续探索与团队相匹配的看板。看板形式并无好坏对错之分，只要适合的就是最好的。

根据未来该团队的成长情况，我们将酌情考虑在看板上增加关于缺陷类 task 的卡片信息，以覆盖团队更广义的工作范围，进而有机会对精益看板上各阶段的在制品数（WIP，Work In Progress）进行限制，找到提升价值流动效率的契机。抑或是，当 story 颗粒度变小且趋同时，可以尝试移除 task 列，忽略细节，降低团队的认知负荷，诸如此类。

看板是一个很强大的工具，未来还有很多内容等待我们实践探索，欢迎读者在下方留言，共同探讨看板实践。

图4. 物理看板结合站会的实操图

延伸阅读

如果读者对效能改进也有兴趣，欢迎加入有赞效能改进团队，请将简历投递至：linyechen@youzan.com，我们共同探讨和实践。

欢迎关注我们的公众号

推荐订阅源

有赞技术团队