一则物理看板的演进实践
source link: https://tech.youzan.com/evolution-of-real-kanban/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作者：林晔琛 | 效能改进
看板（并非特指 Kanban，下同）作为一种目视化管理工具，能够将团队成员的工作过程透明出来，帮助团队更好地发现问题和瓶颈，尤其是在特性团队中，更是会秉承看板的理念，将其与站会形成良好的配合和互动，充分发挥其目视化的作用。
在笔者的工作场景中，特性团队尚处于敏捷转型初期，并未养成良好的工作习惯，其中就包括看板使用不到位的情况，导致了站会活动效果不佳。于是，笔者尝试从「改变看板的使用姿势」切入，唤醒团队的自管理意识，逐步改善团队的敏捷氛围。
二、物理看板演进
1. Scrum 板：从失焦到聚焦
每日站会是技术负责人发起的，没有固定的聚会场所，而且形式比较随意：团队成员围坐在办公室休息区的沙发上，抑或茶水间的吧台前，每个人端着电脑，在技术负责人的主持下被挨个儿点名，然后大家轮流在自己电脑上更新维护同一份在线表格中所负责的任务条目的状态（石墨、Confluence 之类的），站会过程中的其他时间就处理与会议无关的事务。
- 责任失焦。作为技术负责人角色，主持人天然带有权威性，站会以该角色为中心，更像是个汇报的过程。
- 空间失焦。没有固定的场所，站会难以成为团队的一项工作习惯，大家在站会上的行为比较随意，就是意料之中的了。
- 目标失焦。每个人都等着被点名向老板汇报，所以往往只考虑自己的任务完成与否，难以与团队中其他人建立连接，更不用说关注到团队的共同目标和整体进展了。
基于 Scrum 框架之三大支柱：透明、检视、调整，我们选择了从工作任务可视化入手，在一块白板上，直观地跟踪团队每项工作任务的进展和状态。
将白板用彩色胶带划分出多个行列，行（泳道）代表 story，在 story 下拆分出颗粒度不超过 1 个工作日的 task（不同颜色或大小代表不同的任务类型）卡片，都会经历 todo/doing/done 三个状态列。当 story 下的所有卡片都从 todo 转移到 done 后，即宣告 story 交付完成。
- 责任聚焦。团队的工作都呈现在看板上，所以每个人不再需要带电脑，同步自己进展的时候会一并观察同一个 story 下的其他卡片所处状态，并与一起合作的同事进行交流互动。
- 空间聚焦。白板所在的位置，就天然成为团队开站会的场所，站会也越来越成为团队开始一天工作的仪式，无关行为越来越少，会议效率越来越高。
- 目标聚焦。大家围绕着 story 展开工作，每个人都能清楚地知道自己的任务是什么，任务背后的目标是什么，因此能够快速地暴露风险，关注障碍是否被移除。比如：曾经某个同学试图多任务并行，就立马被团队其他有依赖工作的成员发现和阻止了。
2. 精益看板：从聚焦个人任务到聚焦团队目标
经过在完成一个迭代中采用「物理看板+站会」的尝试后，团队成员逐渐适应了这种新型的站会方式，一上来就先将自己的 task 卡片拖动到对应的状态栏，然后开始相互交流 story 的状态或阻塞情况。
我们从上述观察，意识到团队成员在看板工作模式的启发下，开始关注 story 的流动（原本只是技术负责人或产品负责人才会关注）。但此时的看板机制是只流动 task，而story 固定在看板最左侧列，无法体现其流转效果。于是，我们意识到当前的看板模式已经不能满足团队的使用诉求和工作习惯了。
对价值流的关注是敏捷团队成熟度提升的体现，这则新闻真的令笔者和 ScrumMaster 感到兴奋。于是，我们开始着手构思基于精益价值流导向的看板模型。
在新的看板模型中，我们打算优先在「列」的维度表达研发过程的工作流，以体现 story 的价值流动（期待它流动得越快越好）。初定了「筹备/开发/测试/发布」4 列，并在每个列中再细分出 story 栏和 task 栏（现状：story 的颗粒度较大）。
与此同时，为了避免在 story 流动过程中，大家对能否往下个阶段流转产生歧义（比如：对于「结束开发阶段」这件事，开发同学认为是「编码完成」，而测试同学认为是「冒烟自测通过」），我们在每个节点声明了准入准出的条件（在敏捷中常被称为 DoD，Definition of Done），并透明在看板上，以提醒团队在移动 story 卡片时，根据标准进行核对。
使用了新的看板，团队成员不再在站会上确认每一张 task 卡片的状态，而是将注意力转向影响价值流动的问题，并重点关注阻碍项。一旦某个环节变得不顺畅，就会立即体现在看板上（比如：story 或 task 卡片在此处积压），指引团队须重点关注并解决，以及时恢复它们的流动。
3. story 卡片的演进：管理从粗放式到精细化
行文至此，习惯于使用电子看板的读者可能会产生一个疑问：物理看板如何度量？经过几个迭代的看板共创后，我们其实也意识到这个问题了，毕竟我们需要通过度量来指导改进。
但由于物理看板在数据自动统计方面有其局限性，所以我们采取了一种简单易实施但效果又不错的数据收集方法，来支持敏捷团队在数据度量方面的诉求。
我们在 story 卡片上增加了其流经各个价值节点的时间填写动作。在站会上，当 story 卡片被准出并开始流向下一节点时，站会主持人将触发日期记录到 story 卡片上。
在迭代结束时，我们可以从看板上收集到 story 流动相关的工作记录，整理后用于团队指导改进，于是，据此该团队便形成了反馈和持续改进的机制。
看板原理和实施方法，业界有不少教科书式的介绍，但运用到实际场景中时，我们务必根据团队敏捷成熟度的情况进行适当裁剪，在「微改进」实践中持续探索与团队相匹配的看板。看板形式并无好坏对错之分，只要适合的就是最好的。
根据未来该团队的成长情况，我们将酌情考虑在看板上增加关于缺陷类 task 的卡片信息，以覆盖团队更广义的工作范围，进而有机会对精益看板上各阶段的在制品数（WIP，Work In Progress）进行限制，找到提升价值流动效率的契机。抑或是，当 story 颗粒度变小且趋同时，可以尝试移除 task 列，忽略细节，降低团队的认知负荷，诸如此类。
看板是一个很强大的工具，未来还有很多内容等待我们实践探索，欢迎读者在下方留言，共同探讨看板实践。
如果读者对效能改进也有兴趣，欢迎加入有赞效能改进团队，请将简历投递至：[email protected]，我们共同探讨和实践。
Recommend
-
97
分享创造 - @graetdk - 不知道各位有没有在一些影视作品中看到过这样的东西：一个显示器或者大屏幕，上面有着不断增加的数字，这个数字可能是收入，订单什么的，反正看着挺爽![]( https://ws1.sinaimg.c
-
80
加入表格、看板和日历，更全能的数字笔记工具：Notion 2.0
-
46
敏捷是理想型指标和原则，看板和Scrum是帮助团队坚持敏捷原则并完成工作的基本框架。本文详细介绍了在Scrum和看板之间做出选择时要考虑的关键因素，以及如果我们无法做出决定时该怎么办。 Scrum和看板实践之间的区别很容易总结出...
-
57
本文作者依据工作中项目实践的所思所想，并结合案例等分享了数据看板设计过程中需要注意的一些问题，供大家一同参考和学习。 写在前面 说来惭愧，最近在页面设计上踩了不少的坑，于是想着把产品设计中遇到的问题和心得拎出来讲讲，希望能给更多的新人产品经理提供...
-
16
基于Grafana搭建的 在线教育业务看板 于2020年初创建并随着疫情慢慢发展壮大起来，覆盖腾讯课堂、企鹅辅导、ABCmouse...
-
10
看板组件的高度业务封装richardBillion神经网络调过参，现做前端来搬砖在中...
-
16
本文适合喜欢倒腾效率工具的小伙伴和 Go 语言初学者 本文作者：HelloGitHub- 蔡文心 这里是维护...
-
12
大道理小聪明系列 - Redux + Hooks 工程实践一则“都 1202 年了怎么还有人在用 Redux”——这大概不少人看到这篇文章的第一反应。首先先表明一下，这篇文章并不讨论是不是应该使用 Redux，这是...
-
4
当我们的产品准备支持Kanban项目时，我的小伙伴在工作文档里同时看到了“Kanban”和“看板”并露出疑惑的神情，“Kanban”难道不是“看板”的拼音吗？这两者有什么区别吗？今天我们就来聊一聊~Kanban VS 看板Kanban起源于日语单词かんばん的英语写法，...
-
4
记实践 CSS 3 中几个 background-* 属性时的陷阱一则本文摘自 勾三股四 更早时期的 不老歌 博客。发现最近自己的CSS编码能力有生...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK