EagleBear2002 的博客

这里必须根绝一切犹豫，这里任何怯懦都无济于事

软件工程管理-07-看板

发表于 更新于 分类于 ，
本文字数： 3.7k 阅读时长 ≈ 3 分钟

摘要

定义

看板方法，由 David Anderson 创立，它脱胎于大野耐一所创立的丰田生产方式（TPS），以及埃利亚胡·高德拉特（Eli Gol-dratt）的约束理论（TOC），并结合统计质量控制（SQC）、排队论（QT）、工业工程（IE）、软件成熟度模型（CMMI）等多个领域的知识，在软件开发社区中获得了极高的关注度，并迅速传播开来。

历史

大卫·J.安德森（David J. Anderson）

看板（Kanban）（大写字母“K”开头）方法指的是自 2006—2008 年间在 Corbis 公司涌现的渐进增量式的过程改进方法学。这是一个渐进的（evolutionary）和增量式的（incremental）过程。

看板（kan-ban）（小写字母开头）是一个日语词汇，英文字面意思是“信号卡”（signal card）。

看板资源

Kanban 例子 1

背景

团队是一个很小的开发团队，他们为一个大的保险公司服务，负责新发布的手机银行应用。这个团队负责在手机银行这个应用中开发新特性，同时还要支持和维护已经发布的版本。

开发出现了问题

  • 我们经常延迟交付
  • 估算常常不准
  • 整个团队忙得不可开交
  • 优先级不清楚
  • 需求来自四面八方
  • 互相不清楚谁在干什么

白板

  • 把项目原来在 Jira 中的工作内容贴在白板上。
  • 每个工作项一个记事贴。
  • 我们一般称电子工具为‘信息冰箱’。

白板：可视化工作

  • 你无法对自己没有看到的进行改进。
  • 让隐藏的工作无所遁形。
  • 为每个工作项建立一个即时贴即可轻易做到。
  • 帮你理清：
    • 谁在干什么
    • 你正在处理的工作
    • 进行中的工作数量
  • 工作可视化之后，信息将散播给看到的每个人。

工作流映射

工作项

卡片上有什么内容？

  • 从卡片上你可以看到工作项的进展状态。
  • 能够决定下一步如何处理。
  • 常见的属性为：
    • 工作项描述
    • 电子系统中的唯一标识
    • 完成期限
    • 谁在处理这个工作项
    • 工作类型（比如 bug 或者常规工作）

硬币传递游戏

硬币传递游戏说明

  • 你们中 4 个人请围着桌子坐下来，其他人分别选择一个坐下的同事站在其身后，并掏出手机打开计时器。
  • 每个人要把所有硬币翻一遍，然后传递给下一个人。当所有人都翻过所有硬币之后，他们就完成了工作，并交付给了客户。20 枚硬币。
  • “我来作为客户，为整个工作流计时。我会记录两个时间，一个是第一枚硬币到达我这里的时间，一个是所有 20 枚硬币到达我这里的时间。”
  • 我们会玩三轮这个游戏，第一轮的规则是每个工人需要把所有 20 枚硬币翻完后传递给下一个工人；每次翻 5 枚硬币；每一批次翻 1 个硬币。

硬币传递游戏结果

Work in Progress(WIP)

  • 在制品 （WIP）是同时进行中的工作数量，减少在制品使其快速流过整个工作流，即前置时间缩短。
  • 我们不再关注是否每个工人的工作都是最有效率的；
  • 在最后一轮中，前置时间是最短的，但每个工人的工作时间都延长了，从个人来看工作效率下降了，但整个团队的效率最高。

限制在制品 1

  • 致力于减少同时处理的工作项
  • 批量规模越小，前置时间越短
  • 流动效率提升的同时资源效率会有所降低
  • （类似传递硬币的游戏或模拟方法是教人抽象概念的很有力的方式）

限制在制品 2

  • 立即实施：停止立项并开始完成
  • 限制在制品将使改进机会浮出水面
  • 着手改进后会获得更快的流动
  • 不要企图找到一个唯一正确的数字作为团队的在制品限制规模。
  • 在制品限制不是仅为了设立规则，而是为了触发讨论

紧急工作

快速通道

  • 处理特殊情况的常用方式，如紧急工作
  • 通常在白板上刻划为单独通道
  • 快速通道的相关规则如下：
    • 任何时候最多只能有一个工作项在快速通道内
    • 每周最多有一个紧急工作
    • 快速通道内的工作项无需计入在制品限制

度量

度量

  • 有利于团队改进
  • 团队自己选择度量指标，但不要将度量指标用于绩效考核
  • 两个常用的度量指标为：
    • 前置时间是整个工作流的时间
    • 吞吐量是一定时间段内完成的工作项数量

看板例子 2

（来自 Kanban and Scrum making the most of both 一书）

看板不是？

  • 看板并不是一种软件开发生命周期的方法学，也不是一种项目管理的方法。
  • 实施看板时，需要当前已经有一些在运行的过程，这样便可应用看板来逐步改变当前运行的过程。

Kanban 与 Scrum

  • 看板更加适应支撑维护团队
  • Scrum 更加适应全新开发团队（不绝对）

Scrum 和看板都是过程工具

  • Scrum 和看板都是适应性很强的，但相对而言，Scrum 更规范一些。Scrum 多了些约束，少了些选择。
  • RUP 的规范性相当强——它有 30 多种角色，20 多种活动，70 多种工件；
  • XP（极限编程）比 Scrum 又规范一些。它囊括了 Scrum 的大部分内容，还多了很多相当具体的工程实践，例如测试驱动开发和结对编程。
  • Scrum 的规范性比 XP 弱，因为它没有规定任何具体的工程实践。但它又比看板规范，因为它规定了迭代和跨功能团队之类的东西。
  • Scrum 和 RUP 的主要区别在于，RUP 给你的东西太多了，你得自己把不需要的东西去掉；而 Scrum 给你的东西太少了，你得自己把需要的东西加进来。
  • 看板几乎对任何做法都是开放的。它仅有的约束就是将流程可视化和限制在制品。它离做什么都行只有几步之遥，但仍有令人惊异的力量。

别把自己绑在一种工具上

把工具搭配着用，用在合适的地方。

无法想象几乎不用 XP 的 Scrum 团队还能成功。很多看板团队也在做每日立会（Scrum 实践）。有些 Scrum 团队也把 backlog 条目写成用例（RUP 实践），还会限制队列大小（看板实践）。只要有用就行。

不过我们还是要关注每样工具有哪些约束的。假如你在用 Scrum，又决定不用固定时长的迭代（或是其他任一款 Scrum 的要素，3355），就不要说你在用 Scrum 了。Scrum 本身已经足够浓缩了，如果你去掉一些东西，然后还叫它 Scrum，那这个词就失去了意义，只会带来困扰。

经验主义

Scrum 和看板都是经验主义的产物，你用的时候需要先进行试验，然后根据自己的环境作调整。

它最核心的一点就是反馈环。改变=>检查结果=>从中学习=>继续改变。一般而言，反馈环越短越好，这样可以快速调整过程。

  • 平均生产周期。每次有任务到达“Done”这一列（不管它叫什么吧，反正是最右边那一列）的时候就更新数据。
  • 瓶颈。典型症状就是 X 列里面堆满了卡片，但是 X+1 列里空空如也。找找板上哪里有“气泡”吧。

寻找 WIP 例子

资源利用率低：

  • WIP 上限提醒我们要采取行动，改善瓶颈；而不是把没完成的工作堆个没完。

  • 但要是 WIP 当初设成 4 的话，我们早就能有所反应了，这样平均生产周期还能表现得好点。所以这是要平衡的。我们度量平均生产周期，不断优化 WIP 上限，以此优化总生产周期。

Kanban 与 Scrum 的相似性

  • 都是既精益又敏捷、都是拉动式计划、都限制了 WIP。
    • Scrum 的 WIP 按单位时间限制；看板的 WIP 按流程状态限制。
  • 都以透明的方式驱动过程改进。
  • 都关注于尽早交付、频繁交付可发布的软件。
  • 根基都是自组织型团队。
  • 都需要把工作拆分。
  • 发布计划都是根据经验数据（生产率/生产周期）不断优化的。

Kanban 与 Scrum 的差异

Scrum 看板
规定了固定时长的迭代。 固定时长的迭代是可选的。计划、发布、过程改进等活动可以各有各的节奏。它可以由事件驱动，不用非要固定时长。
团队承诺当前迭代做完一定量的工作。 承诺是可选的。
用生产率作为计划和过程改进的默认度量手段。 用生产周期作为计划和过程改进的默认度量手段。
规定了跨功能团队。 跨功能团队是可选的。可以有专职团队。
任务必须分解，以便在 1 个 Sprint 里面能做完。 没规定任务规模。
规定了燃尽图。 没规定专门的图表形式。
间接限制（每个 Sprint 的）WIP。 直接限制（每个工作流状态的）WIP。
规定了估算。 估算是可选的。
不能往进行中的 Sprint 里面加任务。 只要有人手富余就可以加任务。
一个 Sprint Backlog 归一个团队所有。 一张看板图可以由多个团队或多人共用。
规定了三种角色（PO、SM、Team） 没有规定任何角色。
每个 Sprint 之间重置 Scrum 板。 看板图一直保留着。
规定了经过优先级排序的产品 backlog。 优先级排序是可选的。

参考文献

  • Anderson, David J. (April 2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 0-9845214-0-2。
  • Marcus Hammarberg and Joakim Sunden. 2014. Kanban in Action (1st ed.). Manning Publications Co., Greenwich, CT, USA。
  • http://www.infoq.com/minibooks/kanban-scrum-minibook