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

看板是一种非常常见的任务管理机制。我们使用到的大部分团队协作工具中都有看板的身影，例如 Tower、Teambition、Trello、Github、Gitlab…

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


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，完成了，放入下一个栏



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



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


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

本文完！


扩展资料