if 我是前端团队 Leader,怎么用好看板进行任务管理

看板是一种非常常见的任务管理机制。我们使用到的大部分团队协作工具中都有看板的身影,例如 TowerTeambitionTrelloGithubGitlab

看板不仅可以用于团队协作,也可以用于对个人时间进行管理和优化。 可是你真的会用看板吗


Wiki 上面的解释是: 看板是丰田生产模式中的重要概念,指为了达到及时生产(JIT)方式控制现场生产流程的工具。及时生产方式中的拉式生产系统可以使信息的流程缩短,并配合定量、固定装货容器等方式,而使生产过程中的物料流动顺畅.

从上面的定义中需要注意以下要点:

  • 及时生产 - 这是一种通过减少生产过程中的库存和相关的顺带成本,改善商业投资回报的管理战略。
  • 控制现场 - 看板是一种现场还原现场控制方法
  • 拉式生产系统 - 传统的软件开发都是使用推(Push)模式,即规定某个任务由指定人在指定时间内完成。而拉式生产系统,更像生产者-消费者模式,看板就是一个信号等,当上游有已完成的任务,通知下游开始处理这些任务
  • 定量 - 流程上的每个环节是有固定带宽的,这有助于暴露流程上的瓶颈


《解析精益产品开发(一)—— 看板开发方法》 对看板总结得非常好, 看板工具的实质是:后道工序在需要时,通过看板向前道工序发出信号——请给我需要数量的输入,前道工序只有得到看板后,才按需生产。看板信号由下游向上游传递,拉动上游的生产活动,使产品向下游流动。拉动的源头是最上游的客户价值,也就是客户订单或需求。

下面会循序渐进,介绍看板应用的几个阶段。如果你的团队还停留在第一个阶段,不妨试试继续深入实践。


文章大纲


系列文章


第一阶: 从既有的流程开始, 流程可视化

将开发流程可视化是看板的最基本的用法. 上面是一个典型的看板实例,它直观地描述了一个功能项生命周期以及该团队的开发流程。它给我们展示了这样一个流程:

需求分析 -> 产品设计 -> 开发 -> 测试 -> 部署


流程的抽象

每个人、每个团队工作流程都不一样。在设计看板之前我们需要梳理一下自己的工作流程.

比如’个人‘的流程就非常简单了,就只有一个动作:’做与不做’. 所以个人看板通常是这样的

todo -> doing -> done

你会发现,即使很简单的流程,流程的每个环节都会有三个子模块:未做/正在做/已完成. 对于个人看板而言,划分这三个模块,主要是为了还原当前的现场。对于团队而言,这一点更为重要,你可以通过看板直观地跟踪任务开发的进度


我们团队目前的开发流程也很简单是:

设计 -> 开发 -> ...
  • 设计: 应用设计,可选,一般在开启一个项目或者重要的功能开发时会进行概要设计
  • 开发: 正常的开发流程

当然这仅仅是前端团队的’局部‘流程,完整的软件开发流程如第一个看板实例所示。因为我们不是一个’敏捷‘团队,只要负责前端开发这个环节即可. 大局上看需求分析产品设计测试以及部署不在我们的控制范围之内。所以不应归纳到我们的开发流程中。


不断改进的流程

流程不是一成不变的,它会随着实践的深入不断演化。举个例子,因为我们团队成员能力和经验不均匀,比如新手代码经常出 Bug,细节也没有做好。怎么解决?

首先想一下能否在流程上做一下改进, 来减缓或杜绝这种情况,提高代码质量?

反复思考和讨论后,我们决定在 开发 环节之后添加了一个 交叉测试/Review/用户体验测试 环节。这个包含三层含义, 交叉测试是指定其他人来测试、Review指的是代码层次的审查(白盒),用户体验测试则是从用户角度触发进行验收测试(黑盒)。


下面是改进后的看板(设计 -> 开发 -> 交叉测试):


看板的范围


颜值很高的个人看板


上面看到了’个人看板‘、’团队看板‘,以及’一个涵盖完整软件开发流程的看板‘。你会发现看板应用得非常广,可以应用于不同的层次,表示任务的粒度也不一样

我们前端团队内部就有两个看板,一个是周计划看板,一个是任务看板

周计划看板任务粒度是’项目’或者’重大功能’,用于规划和跟踪每周的大概任务; 而任务看板则是各种细化的任务, 例如小的功能、Bug修复、细节优化. 粒度平均在1人/天以下,可以最大程度还原每个开发成员的开发现场。


在团队协作层面, 我们还有一个研发看板,这个和第一个看板例子相似,还原一个应用完整的研发流程,每个团队占用看板上面的一栏,展示和跟踪团队之间的信息流动:


研发看板


优先级划分

上面我们团队看板中,有几个比较特殊的栏: 计划/本周待办/缓冲区。主要栏主要目的是为了给任务划分优先级,让团队专注于目前应该优先处理的任务。

看板中优先级可以通过两种方式来处理:

1. 拆分看板:

例如优先级排序 缓冲区 > 本周待办 > 计划

  • 计划 - 近期需要进行的任务,有些任务优先级很低,可能一年半载都不会处理。这一栏有点像备忘录
  • 周计划 - 从计划栏中筛选部分任务,作为本周的’开发目标‘。表示本周计划要完成的事情
  • 缓冲区 - 从周计划中筛选优先级最高的任务,需要优先被处理
  • 已完成(周结束时间) 放置每周已完成的任务, 这个和周计划相对应,可以反馈’周计划‘完成的进度。

我们通常会每周’归档‘一次已完成栏。如果使用Tower,可以通过’查看归档‘,获取所有的以周为单位的历史记录


2. 设置任务优先级

在任务层级也可以设定特殊的标签,来标记任务的优先级。另外也可以将高优先级任务排在队列前面, 表示任务的优先级

下图使用 Tower 可以为任务设置优先级,它会使用不同的颜色来标注它:


推模型(Push)与拉模型(Pull)

还是左耳朵耗子, 他在某期节目提到的’x 型人才和y 型人才论‘,让我印象深刻, 他指出人才可以分为两种:

  • 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.


2. 避免中断,避免上下文切换

限制WIP的另一个好处,是减少成员并发处理多个任务的数量。

和计算机的进程一样,进程的上下文切换代价是比较大的。对于开发者来说,任务中断、任务调换也会浪费切换的时间,因为我们需要调整/回顾思路来投入新的任务流程。

所以说通过限制WIP,可以让成员专注于正在处理的任务,做完这个任务再去拉取新的任务。


3. 盈余时间

当下游出现阻塞,上游或下游可能就会出现盈余时间。这些盈余时间看起来像浪费,其实对于开发者或团队来说,可以做很多事情。比如:

  • 休息/学习:
    可以利用这段时间来学习。对于前端来说,必须不断的学习,提高自己的水平和竞争力,这对项目开发也是有益处的. 在996这种环境下,企业家逐渐剥夺了我们生产生产力的能力。
  • 帮助解决瓶颈:
    下游出现瓶颈了,我们可以停下来,帮助他们解决问题。例如其他同事因为某些问题卡住,我们可以帮助他一起解决问题;再比如下游测试环节出问题了,我们可以一起进行测试。作为一个团队齐步向前,变相提高团队凝聚力和责任心
  • 优化:
    反思流程问题,考虑如果提高产能
  • 其他事情:
    比如可以进行交叉测试和写文档,优化开发工具


WIP要限制多少?

在制品限制值不是具体可计算的,需要长期经验积累和磨合才能定下一个合适的值. 值越小,成员可以更专注于当前的事情,增强成员之间的协作。值越大,可以处理的事情更多,任务调度会更为灵活。

一个基于经验的、折中的公式是: 在制品上限 = 团队规模 * 2 -1




第三阶: 结合Scrum

Scrum 也是一个敏捷框架. 它的规则非常简单,但是要精通非常难。所以第三阶段,我们可以尝试将 Scrum 的某些规则融合到看板的管理流程中


简单介绍一下Scrum

上图一个典型的 Scrum 流程.

简而言之,Scrum 首先会将应用开发过程拆分为多个迭代周期,这个迭代周期称为 Sprint (一个冲刺),周期一般为1-4周。


在每次开始一个冲刺时,会从功能列表(Product Backlog)中,按照优先级和时间评估筛选出这个冲刺可以完成的任务列表,称为冲刺列表(Sprint Backlog); 接着就在这个迭代周期里专心完成这些任务

另外 Scrum 还定义了各种活动, 来进行持续的反馈和调整, 例如:

  • Sprint计划会议 - 在开始一个冲刺前,计划一个周期内需要做哪些任务,对任务进行时间评估
  • 每日立会 - 同步开发进度、发现开发中的障碍、增加交流和沟通
  • 评审会议 - 在冲刺结束时举行,用于检查计划中的工作,哪些完成了,哪些没有完成。有些团队会让功能的负责人演示自己所做的功能,然后 PM 会看这个功能是否达到了要求
  • 回顾会议 - 在冲刺结束时举行,回顾和反省本次迭代遇到的问题、以及如何改进

另外,Scrum还定义了各种角色和价值观。这些不在本文的范围之内,我们也不会全部照搬. 有兴趣的读者可以查看参考文献


融合到看板中

设定开发周期

瀑布式和敏捷的明显区别就是开发流程分割成多个迭代过程。按Scrum的定义就是一个’冲刺‘.

在我们实际的开发中,会以一个星期作为一个开发周期。我觉的一周的时间刚刚好,时间太长很难对任务时间进行评估,而且未知因素也会更多.

在一个星期开始前,从’计划‘栏中筛选本周要进行任务,拖进’本周待办’栏。这个过程就有点像 Scrum计划会议


每日回顾

笔者每天开始工作时,就会将团队成员聚集在一起,对着看板简单询问任务开发的进度,回顾昨日的工作,看是否出现障碍。如果有障碍则及时处理障碍,如果任务超出预期,则考虑是否应该重新调整计划。

总之就是尽早暴露问题,保证流程的顺畅。在这里看板就是一种重要的沟通工具。每日询问的时间都很短,一般都不超过10分钟,这个过程有点像 Scrum 的每日立会

Tower中,完成任务后我们不会直接将卡片拖入已完成列表,而是在最后一个环节点击’已完成‘,这样方便次日对已完成的任务进行回顾,回顾完成后再统一拖入’已完成‘栏


流程监控

燃尽图

燃尽图是常见的Scrum进度跟踪工具。它的外形如下:

横轴为开发周期,纵轴为任务量. 理想状态下,任务量在周期结束时应该变为0,也就是说理想的线段是一条对角线(蓝线), 这也是一条参考线。如果在某个指定时间点,红线高于蓝线,则说明进度有些延迟,反之就是超前

使用燃尽图,我们一般会通常会在每日回顾时在燃尽图上绘制一个点,表示截止到此刻未完成的任务量


累计流量图

累计流量图统计每一天每一栏的在制品数量。从而可以反映不同环节任务处理速率,以及暴露环节之间的瓶颈:




看板一日游

下面模仿经典的文章《看板一日游》 实践一下本文讲述的看板使用流程。我们使用的工具是 Tower,这个也是我们团队目前在使用的,功能基本够用。


设计看板

假设我们的前端团队有3个人,开发流程是这样的: 开发 -> 交叉测试 -> 部署。按照上面学到的知识,我们设计了这样的看板布局:


创建任务

现在点开Tower任务创建窗口. Tower 的任务功能已经非常丰富了。为了更方面其他人处理任务,我们对任务进行了一些规范


  • ① 标题: 以 [scope] 概述 (时间评估).
    • scope 是指任务的范围,例如项目A,项目B
    • 时间评估 要求对耗时较久的任务进行评估。我们一般推荐任务的粒度在3h 到 2d之间,小于3h考虑将任务进行合并,大于2d则考虑继续拆分任务
  • ② 指派负责人: 可选,不指派则说明采用拉模式
  • ③ 任务的Deadline
  • ④ 设置任务优先级
  • ⑤ 详细说明
  • ⑥ 细化任务
  • ⑦ 依赖任务
  • ⑧ 任务标签: 可以指定任务的类型,例如功能、Bug、优化、重构


开始吧

首选计划一下这周需要这些什么:


开始工作,按照优先级排序 ,放入缓冲区:


认领自己的任务


ok,完成了,放入下一个栏



下游达到在制品限制了,不行, 得清一下,停下手动的工作,做一下交叉测试吧



次日问询回顾,任务完成的还不错,有遇到什么问题吗?完成回顾后将任务正式拖入已完成


😫好累,不写总结了,就这样吧,

本文完!


扩展资料