1. 图书信息
英文原著
- 名称：Kanban: Successful Evolutionary Change for Your Technology Business
- 作者：David J Anderson
- 出版：2010 年
中文译本
- 名称：看板方法——科技企业渐进变革成功之道
- 译者：章显洲、路宁
- 出版：2014 年
- 字数：35.3 万
2. 个人感想
读《精益开发实战》时知道了看板方法，当时的粗浅理解是「 可视化管理 」，因为我个人更喜欢电子看板，团队迟迟没有引入「物理看板」，2015 年使用「电子看板」半年后还是回到了基于甘特图的老路。由于缺乏理论基础，总是在按照传统的项目管理思路使用看板，新瓶装老酒，感觉怪怪的。
David Anderson 在《看板方法》开篇以春天樱花季去东京皇居东御苑公园游玩的经历说明「看板并不只供制造业使用」，由此引出两个核心概念： Pull System 和 Work-In-Progress Limit 。公园本身就是一个拉动系统，游客便是在制品。游园的高峰期，通过发放卡片的方式来控制园内的人数，当所有卡片发放完时，新到的游客必须在园外的桥上排队等候，等待其他游客离园后回收的入园卡。
第四部分以「公路」和「海湾轮渡」为例说明 Bottelnecks 。先来看看「 能力受限资源 」的例子：
华盛顿 SR-520 公路是连接西雅图与其市郊柯克兰（Kirkland）和雷蒙德（Redmond）两区的高速公路，每天有 8 个小时处于严重的双向交通瓶颈状态。经历浮桥跨过华盛顿湖前，这条高速公路由三车道变窄成双车道，导致高峰期只发挥了 20% 的吞吐潜力，堵车长达 7 公里。
「 非即时可用资源 」并非瓶颈，但是，它们看起来很像瓶颈。普吉特海湾的轮渡系统是一个典型的例子：
普吉特海湾的三个轮渡系统把吉赛普（Kitsap）和奥林匹克半岛（Olympic Peninsulas）与西雅图市区连接在一直。其中一个是连接埃德蒙兹（Edmonds）东侧和金斯敦（Kingston）西侧的处在 SR-104 公路上。在地图上，这条轮渡航线显示为 SR-104 公路的一部分。通常它被标记为「收费」，而不是明确说明「到这里你得上船摆渡」。
开车到轮渡时，需要先付费，然后在一个等候区等候。等待时间大概需要 30 分钟，因为渡轮需要花 30 分钟时间渡过普吉特湾；之后渡轮还需要花 10 到 15 分钟卸下车辆，在返航前又需要花差不多的时间载上全部新的车辆。通常轮渡公司会投入两艘渡轮，因此每艘渡轮的运输时间差不多是 50 分钟一趟。在高峰时间，可能会投入 3 艘渡轮，把每次摆渡的等待时间控制在 35 分钟左右。
在我的团队，后台开发是「能力受限」，7 人项目组只有 1 人负责后台，既要设计 DB、REST API 还要对接 iOS / Android 和 Web 后台的功能开发。我本人是「非即时可用」，A 项目产品经理找我评审需求时，我可能在和 B 项目架构师评审设计；B 项目找我讨论下个月工作计划时，我可能在做 S 项目发布……使用物理看板后，站立会议拉动卡片时我们俩将被标注为 阻塞（Block） ，想想还有点儿小紧张呢 :D
再次回到东京皇居东御苑公园的例子，WIP Limit（游客上限）在这个示例中是确定的，但是在软件项目中任务通常无法精确估算，和朋友讨论时我经常被问到：
- 有些功能半小时能修改完，有些要一两周，怎么统一；
- 今天刚确认的需求明天又变了；
- ……
David Anderson 在书中把上面的问题称做： Variability 。
第 19 章作者深入讨论了「变异性的根源」，分为「内部变异」和「外部变异」。结合 19 章重新阅读本书第三部分，就能够理解作者为什么提出了 Value Stram / Work Item Type / Delivery Cadence / Prioritization / Class-of-Service / Operations Review 等关键活动了。
最后，David Anderson 在书中介绍的看板方法起源于「维护项目」，对于产品研发型项目如何应用看板还要进一步学习，希望能够在下一本书《看板实战》中找到答案。
3. 读书笔记
看板是一个日语词汇，英文字面意思是「信号卡」
3.1. 什么是看板方法
5 项核心特性：
- 可视化工作流程。
- 限制进行中的工作（work-in-progress）。
- 度量和管理流动。
- 明确过程策略。
- 使用模型来识别改进机会。
5 个附加的特性：
- 根据延迟（机会）成本进行工作项的优先级排序。
- 通过服务分类来优化价值。
- 通过产能分配（capacity allocation）来管理风险。
- 鼓励工艺和过程创新。
- 定量化管理。
3.2. 瓶颈 Bottlenecks
瓶颈分为两类
- 能力受限瓶颈（Capacity-Constrained）：无法完成更多的工作；
- 非即时可用瓶颈（Non-Instant Availability）：由于可用性的限制（但通常是可预测的）导致处理能力有限；
| 能力受限 | 非即时可用 | |
|---|---|---|
| 挖掘 / 保护举措 | 策略变更、增加 WIP 缓冲区 | 策略变更、增加 WIP 缓冲区 |
| 服从举措 | 策略变更 | 策略变更 |
| 突破举措 | 自动化、增加产能（资源） | 自动化、增加产能（资源）、改变策略 |
在使用突破举措之前，首先应该考虑使用挖掘举措。
实施一个战术性的瓶颈挖掘举措和服从举措计划时，可以从一个更长远的视角来规划战略性变革，以真正突破瓶颈约束。
3.3. 重新定义浪费 Redefining "Waste"
以经济学语言来对此进行解释，以成本（cost）来指代这些「浪费性」活动，将这些成本抽象地分为三大类：
- 事务成本（transaction costs）
- 前端（front-end）事务成本：初始准备成本
- 后端（back-end）事务成本：清理扫尾成本
- 协调成本（coordination costs）
- 破坏负载（failure load）
可以通过询问「如果可以，我们愿意更多地开展这项活动吗？」的方式来判别一项活动是否真的属于浪费。如果答案是否定的，那么这项活动就是某种形式的浪费。
3.4. 变异性的根源 Sources of Variability
内部变异，也称为「机会致因变异」，可以通过改变定义软件开发生命周期和项目管理过程的系列规则和策略来控制。
- 工作项规模 Work Item Size
- 工作项类型的混合 Work Item Type Mix
- 服务类别的混合 Class-of-Service Mix
- 不规则的紊流 Irregular Flow
- 返工 Rework
外部变异，也称为「可归因变异」，可以通过利用问题管理和解决能力以及风险管理能力来应用，可以通过利用根因分析和消除能力来降低或消除可归因变异。
- 需求模糊 Requirements Ambiguity
- 加急请求 Expedite Requests
- 处理不规则紊流 Irregular Flow
- 环境可用性 Environment Availability
- 其他市场因素 Other Market Factors
- 安排协调活动的难度 Difficulty Scheduling Coordination Activity
3.5. 价值流映射 Mapping the Value Stream
工作项类型 Work Item Type
- 需求 Requirement
- 功能特性 Feature
- 用户故事 User Story
- 用例 Use Case
- 变更请求 Change Request
- 产品缺陷 Product Defect
- 维护工作 Maintenance
- 重构 Refactoring
- 错误 Bug
- 改进建议 Improvement Suggestion
- 受阻问题 Blocking Issue
根据请求分配产能
- 变更请求 60%
- 维护工作 10%
- 产品文本变更 30%
工作项卡片详解
- 电子跟踪 ID 号
- 标题（写在中间）
- 进入日期（写在左下角）
- 固定交付日期（写在右下角）
- 负责人（磁贴、标签帖）
应对并行活动
应对次序无关的活动
管理共享资源
3.6. 设置在制品限额 Setting Work-in-Progress Limits
在每个横向泳道上为不同工作项类型显式定义 WIP 限额的卡片墙
- 工作任务的限额
- 排队队列中的限额
- 瓶颈前的缓冲
- 输入队列大小
capacity-allocation.png
3.7. 建立服务水平协议 Establishing Service Level Agreements
根据不同服务类别分配产能的看板墙
class-of-service.png
| 颜色 | 条款 | |
|---|---|---|
| 加急类 Expedite | 白色 | 参 P131 |
| 固定交付日期类 Fixed Delivery Date | 紫色 | 参 P132 |
| 标准类 Standard Class | 黄色 | 参 P132 |
| 无形类 Intangible Class | 绿色 | 参 P133 |
3.8. 度量和管理报告 Metrics and Management Reporting
- 跟踪在制品 Tracking WIP
- 前置时间 Lead Time
- 准时交付率 Due Date Performance
- 交付速率 Throughput
- 问题和受阻工作项 Issues and Blocked Work Items
- 流动效率 Flow Efficiency
- 初始质量 Initial Quality
- 破坏负载 Failure Load
3.9. 启动看板变革 Starting a Kanban Change Initiative
首要目标
- 优化现有流程
次要目标
- 高质量交付
- 提升前置时间的可预测性
- 提升员工满意度
- 为改善留出富余时间
- 简化优先级排序
- 使系统设计及动作透明化
- 设计能够打造高成熟度组织的流程
15.4 实施步骤 Steps to Get Started
启动看板实施的谈判
- WIP 限额 WIP Limits
- 优先级排序 Prioritization
- 交付 / 发布 Delivery / Release
- 前置时间与服务类别 Lead Time and Classes of Service
4. 金句
看板方法通过优化现有过程来驱动变革。启动看板方法的关键要义是， 变化要越少越好 。你必须要抵制住改变工作流程、职位名称、角色及其职责，以及当前在用的具体实践的诱感。不要试图去改变团队成员与其他合作伙伴、参与者、干系人的内驱力、专业自豪感和自我心理（ego）， 主要要改变的是在制品的数量、与上下游业务间的接口及交互方式 。因此，必须与团队一起把现有的价值流图描绘出来，不要试图去改变它或重新发明一种理想化的新过程。
看板方法暴露组织中存在的问题，由此可能会冠以使事情变得更加糟糕的罪名而被迫中止，并且其本身也会被视为是问题的一部分而不是解决办法。 因此，要谨慎对待这个问题。对于能力比较强且有较高成熟度的组织，由于预期之外的问题（可归因变异）很少，所以可以考虑采用约束较为严格的 WIP 限制规则。对于比较混乱的组织，把 WIP 的限制规则设得比较宽松为好，开始时，先把 WIP 限额设得大一些，通过创建持续改进的驱动力，将其逐步调低。
平衡工作与生活，不只是简单地在数量上平衡投在工作上的时间和留给家人朋友、爱好、激情，个人追求的时间，还意味着要能够 提供一种确定性，比如，如果有一名爱好艺术的团队成员希望在当地一所中学参加绘画课程，该课程每周三晚六点半开始，要持续 10 周，你的团队能为这位伙伴提供每周准时离开办公室去上课的确定性吗？
创造更理想的工作／生活平衡，可以增强公司在本地市场对人才的吸引力，有助于更好地激励员工，让他们在 几个月甚至几年中都保持高绩效水平，只有超负载工作才能完全挖掘出知识工作者的产能——这是一种极其错误的观点。超负载工作的状况，维持一两天或许可行，但可持续性不会超过一两周，为员工创造工作生活平衡，绝不让他们超负载工作，这才是明智公司的经管决策。
从选代（或时间盒限制）的层面来看，敏捷开发管理与传统项目管理非常相似，唯一的重要区别是，在项目过程中需要舍弃一些东西进行权衡时，传统的项目经理可能会选择延期交付、增加资源投入、缩减范围或三者不同程度地兼而有之； 敏捷项目的明确共识是缩减范围，保障交付时间。
网友评论