看板是一种非常常见的任务管理机制。我们使用到的大部分团队协作工具中都有看板的身影,例如 Tower、Teambition、Trello、Github、Gitlab…
看板不仅可以用于团队协作,也可以用于对个人时间进行管理和优化。可是你真的会用看板吗?
Wiki 上面的解释是:看板是丰田生产模式中的重要概念,指为了达到及时生产(JIT)方式控制现场生产流程的工具。及时生产方式中的拉式生产系统可以使信息的流程缩短,并配合定量、固定装货容器等方式,而使生产过程中的物料流动顺畅。
从上面的定义中需要注意以下要点:
《解析精益产品开发(一)—— 看板开发方法》 对看板总结得非常好, 看板工具的实质是:后道工序在需要时,通过看板向前道工序发出信号——请给我需要数量的输入,前道工序只有得到看板后,才按需生产。看板信号由下游向上游传递,拉动上游的生产活动,使产品向下游流动。拉动的源头是最上游的客户价值,也就是客户订单或需求。
下面会循序渐进,介绍看板应用的几个阶段。如果你的团队还停留在第一个阶段,不妨试试继续深入实践。
第一阶:从既有的流程开始,流程可视化
将开发流程可视化是看板的最基本的用法. 上面是一个典型的看板实例,它直观地描述了一个功能项
的生命周期以及该团队的开发流程。它给我们展示了这样一个流程:
需求分析 -> 产品设计 -> 开发 -> 测试 -> 部署
每个人、每个团队工作流程都不一样。在设计看板之前我们需要梳理一下自己的工作流程。
比如“个人”的流程就非常简单了,就只有一个动作:‘做与不做’。所以个人看板通常是这样的
todo -> doing -> done
复制代码你会发现,即使很简单的流程,流程的每个环节都会有三个子模块:未做/正在做/已完成
。对于个人看板而言,划分这三个模块,主要是为了还原当前的现场。对于团队而言,这一点更为重要,你可以通过看板直观地跟踪任务开发的进度
我们团队目前的开发流程也很简单是:
设计 -> 开发 -> ...
当然这仅仅是前端团队的‘局部’流程,完整的软件开发流程如第一个看板实例所示。因为我们不是一个’敏捷‘团队,只要负责前端开发这个环节即可。大局上看需求分析、产品设计、测试以及部署不在我们的控制范围之内。所以不应归纳到我们的开发流程中。
流程不是一成不变的,它会随着实践的深入不断演化。举个例子,因为我们团队成员能力和经验不均匀,比如新手代码经常出 Bug,细节也没有做好。怎么解决?
首先想一下能否在流程上做一下改进, 来减缓或杜绝这种情况,提高代码质量?
反复思考和讨论后,我们决定在 开发 环节之后添加了一个 交叉测试/Review/用户体验测试 环节。这个包含三层含义,交叉测试是指定其他人来测试、Review 指的是代码层次的审查(白盒),用户体验测试则是从用户角度触发进行验收测试(黑盒)。
下面是改进后的看板(设计 -> 开发 -> 交叉测试):
上面看到了‘个人看板’、‘团队看板’,以及‘一个涵盖完整软件开发流程的看板’。你会发现看板应用得非常广,可以应用于不同的层次,表示任务的粒度也不一样。
我们前端团队内部就有两个看板,一个是周计划看板,一个是任务看板。
周计划看板任务粒度是’项目’或者’重大功能’,用于规划和跟踪每周的大概任务;而任务看板则是各种细化的任务, 例如小的功能、Bug修复、细节优化. 粒度平均在1人/天以下,可以最大程度还原每个开发成员的开发现场。
在团队协作层面, 我们还有一个研发看板,这个和第一个看板例子相似,还原一个应用完整的研发流程,每个团队占用看板上面的一栏,展示和跟踪团队之间的信息流动:
研发看板
上面我们团队看板中,有几个比较特殊的栏: 计划/本周待办/缓冲区。主要栏主要目的是为了给任务划分优先级,让团队专注于目前应该优先处理的任务。
看板中优先级可以通过两种方式来处理:
1、拆分看板:
例如优先级排序 缓冲区 > 本周待办 > 计划
我们通常会每周‘归档’一次已完成栏。如果使用Tower,可以通过’查看归档‘,获取所有的以周为单位的历史记录
2、设置任务优先级
在任务层级也可以设定特殊的标签,来标记任务的优先级。另外也可以将高优先级任务排在队列前面,表示任务的优先级。
下图使用 Tower 可以为任务设置优先级,它会使用不同的颜色来标注它:
还是左耳朵耗子,他在某期节目提到的x 型人才和y 型人才论,让我印象深刻,他指出人才可以分为两种:
大部分人都是x型人才,所以企业需要花高一点的薪酬雇佣y型人才来管理和驱动x型人才。但我认为这不是天生的,在后天给予一定的责任和鼓励,或者在某些管理机制下,我们也可以成为 y 型人才,甚至成为 y 型团队。很多敏捷理论就推崇‘团队自治’、希望团队以及成员可以自我驱动,推动业务的发展。拉模式也能体现这种思想.
传统团队都使用推模式,由Leader将任务分配给团队成员, 指定完成的时间和各种指标。这种方式也称为推动系统(Push System),它一般依赖于时间的排定,时间到了就被’被动地‘推动去做某些事情.
而看板非常适合拉模式。所以看板也被称为信号板(Signal),你可以将任务当做一个“事件”,由事件来驱动工作(类似生产者-消费者模式)。这还是有点像工厂的流水线,上游的产出就是一种’事件‘,下游主动去拉取上游的物件进行处理。
这种模式的好处是,Leader 不需要再去关心细微的工作分配和决策,让团队成员自己有效地安排事件。另外这也可以避免出现这样一种情况:团队成员只熟悉其中某些项目,或者只会做、只负责一类事情。这使得成员离岗时,团队会变得比较被动,因为其他成员对离岗成员的工作情况不熟悉。因此拉动模式,也可以让团队成员离开自己的舒适区,参与和熟悉各种项目
我们目前使用的是混合型, 有些任务是提前指派合适的人去做的,而如果看板中没有指定负责人,这个任务就可以由任何人来负责,推拉结合。
流程上的多个环节会像管道(pipe)一样,通过输入输出连接在一起:
tasks -> (流程1) -> (流程2) -> Done
上一个流程的输出(Done),就是下一个流程的输入(Todo)。按照理想的状态,信息流应该是流畅、平稳地在管道上流淌的。如果某个环节出现瓶颈,那么可能会导致忙的忙死,闲的闲死。
如果你有细心思考,看板的流程管理方式有点像’工厂的流水线作业‘,如果某个环节阻塞,这个环节就会堆积很多元件,而下游则会出现空闲等待情况, 而该环节的上游也会被阻塞。
通过看板的现场还原,我们可以容易地发现这种流程上的瓶颈。怎么解决这个问题?
这个可以类比程序,当我们发现程序上的一个性能问题时,通常有两个解决的方向:
下一节会介绍,我会介绍通过设置在制品数量(带宽),让看板更容易地暴露瓶颈。
通过看板我们可以得到这些好处:
第二阶:在制品限制
大部分团队对看板的应用只停留在第一阶,即流程可视化。看板的魅力远不止于此。第二个阶段,我们要开始限制在制品的数量。
什么是在制品
在制品(Work-In-Process WIP), 也称为半成品。顾名思义就是部分未完成的任务。
在看板中,一些栏会有在制品限制,用于限制该环节‘同时’可以处理的事情。换句话说就是限制某个环节的‘流量带宽’,或者说节流。
1. 更快暴露瓶颈
尽管在‘第一阶’时,我们也可以识别出流程的瓶颈,但并不是特别直观,至少从看板上较难察觉。
你可能要详细跟踪询问,才能了解哪个流程卡住了。
限制了WIP后,每个环节的带宽是固定的,比如‘测试’环节的WIP限制是6,如果’测试‘环节到达限制,上游就没办法给它塞其他任务了。这就暴露了‘测试’环节的瓶颈
怎么设定WIP的限制额也是比较重要的,设置太小,会导致并发处理的任务量变小,资源可能得不到利用,太大又不容易暴露瓶颈。下节会介绍如何设置WIP。
1、避免中断,避免上下文切换
限制 WIP 的另一个好处,是减少成员并发处理多个任务的数量。
和计算机的进程一样,进程的上下文切换代价是比较大的。对于开发者来说,任务中断、任务调换也会浪费切换的时间,因为我们需要调整/回顾思路来投入新的任务流程。
所以说通过限制WIP,可以让成员专注于正在处理的任务,做完这个任务再去拉取新的任务。
2、盈余时间
当下游出现阻塞,上游或下游可能就会出现盈余时间。这些盈余时间看起来像浪费,其实对于开发者或团队来说,可以做很多事情。比如:
在制品限制值不是具体可计算的,需要长期经验积累和磨合才能定下一个合适的值. 值越小,成员可以更专注于当前的事情,增强成员之间的协作。值越大,可以处理的事情更多,任务调度会更为灵活。
一个基于经验的、折中的公式是:在制品上限 = 团队规模 * 2 -1。
Scrum 也是一个敏捷框架. 它的规则非常简单,但是要精通非常难。所以第三阶段,我们可以尝试将 Scrum 的某些规则融合到看板的管理流程中
简单介绍一下Scrum
上图一个典型的 Scrum 流程。
简而言之,Scrum 首先会将应用开发过程拆分为多个迭代周期,这个迭代周期称为 Sprint (一个冲刺),周期一般为1-4周。
在每次开始一个冲刺时,会从功能列表(Product Backlog)中,按照优先级和时间评估筛选出这个冲刺可以完成的任务列表,称为冲刺列表(Sprint Backlog);接着就在这个迭代周期里专心完成这些任务
另外 Scrum 还定义了各种活动,来进行持续的反馈和调整, 例如:
另外,Scrum 还定义了各种角色和价值观。这些不在本文的范围之内,我们也不会全部照搬. 有兴趣的读者可以查看参考文献。
设定开发周期
瀑布式和敏捷的明显区别就是开发流程分割成多个迭代过程。按Scrum的定义就是一个‘冲刺’.
在我们实际的开发中,会以一个星期作为一个开发周期。我觉的一周的时间刚刚好,时间太长很难对任务时间进行评估,而且未知因素也会更多。
在一个星期开始前,从“计划”栏中筛选本周要进行任务,拖进’本周待办’栏。这个过程就有点像 Scrum 的计划会议
每日回顾
笔者每天开始工作时,就会将团队成员聚集在一起,对着看板简单询问任务开发的进度,回顾昨日的工作,看是否出现障碍。如果有障碍则及时处理障碍,如果任务超出预期,则考虑是否应该重新调整计划。
总之就是尽早暴露问题,保证流程的顺畅。在这里看板就是一种重要的沟通工具。每日询问的时间都很短,一般都不超过10分钟,这个过程有点像 Scrum 的每日立会
在 Tower 中,完成任务后我们不会直接将卡片拖入已完成列表,而是在最后一个环节点击‘已完成’,这样方便次日对已完成的任务进行回顾,回顾完成后再统一拖入‘已完成’栏
流程监控
燃尽图
燃尽图是常见的 Scrum 进度跟踪工具。它的外形如下:
横轴为开发周期,纵轴为任务量. 理想状态下,任务量在周期结束时应该变为0,也就是说理想的线段是一条对角线(蓝线), 这也是一条参考线。如果在某个指定时间点,红线高于蓝线,则说明进度有些延迟,反之就是超前
使用燃尽图,我们一般会通常会在每日回顾时在燃尽图上绘制一个点,表示截止到此刻未完成的任务量
累计流量图
累计流量图统计每一天每一栏的在制品数量。从而可以反映不同环节任务处理速率,以及暴露环节之间的瓶颈:
下面模仿经典的文章《看板一日游》 实践一下本文讲述的看板使用流程。我们使用的工具是 Tower,这个也是我们团队目前在使用的,功能基本够用。
设计看板
假设我们的前端团队有3个人,开发流程是这样的: 开发 -> 交叉测试 -> 部署。按照上面学到的知识,我们设计了这样的看板布局:
现在点开Tower任务创建窗口。Tower 的任务功能已经非常丰富了。为了更方面其他人处理任务,我们对任务进行了一些规范
首选计划一下这周需要这些什么:
开始工作,按照优先级排序 ,放入缓冲区:
认领自己的任务
ok,完成了,放入下一个栏
下游达到在制品限制了,不行, 得清一下,停下手动的工作,做一下交叉测试吧
次日问询回顾,任务完成的还不错,有遇到什么问题吗?完成回顾后将任务正式移入已完成
本文完~
来源:https://juejin.cn/post/6844903953939824654
选择一个平台,传递你的声音。DevOps 国际峰会 2022 · 北京站,讲师招募开始啦,扫描图片二维码,立即报名~
近期好文:
投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118.
点个“在看”,少个“bug”