用看板管理敏捷项目：提升效率、可预测性、质量和价值的利器

通过看板，项目人员可以随时掌握进度、发现问题并解决问题。本书作者率先在微软Xbox工程服务团队中使用看板，在此后的各类项目开发中，经历了无数次尝试与失败，从中不断总结经验与教训，写成了本书。在本书中作者介绍了看板的使用方法、详细步骤及要点，展示了如何让团队发挥看板的作用、协同合作，从而高效、简单、可预测地管理项目， 提供了各种图表、工作表单、常见问题解答和故障排除方法等，是一本非常实用的工具书。

作者简介

Eric Brenchner（埃里克.布伦内尔）：微软Xbox（微软开发的家用游戏机）工程服务团队的开发经理，率先在该项目上使用看板，也是微软XBOX.com、工程学习和开发主管，并负责Microsoft Office中共享功能的开发。加入微软之前，Eric是波音公司的首席科学家，负责大规模可视化、计算几何、网络通信、数据流语言和软件集成等方面的工作。他还是一位活跃的博客作者（I.M.Wright），拥有8项专利和应用数学博士学位。

译者简介
许 峰 DevOps、敏捷、精益IT转型顾问、培训师，专注于IT组织效能提升及数字化能力建设，帮助企业IT从传统研发及运维模式向DevOps、敏捷项目管理、精益IT、轻量级IT服务管理等现代化能力转型。有超过20年的IT从业经验，尤其聚焦在软件全生命周期管理。他的职业生涯履历包括软件开发专业人士、项目管理专业人士、软件及服务产品部门顾问，以及大型IT企业的高级管理人员。肖 蓬 PMP，ACP，CSP，DevOps Master。任职于一家通信行业500强企业，高级项目经理，有超过10年跨国大规模研发、运维等项目管理经验，熟悉产品生命周期管理，同时对于SAFe和LeSS等主流大规模敏捷项目管理的体系架构及应用有着深入的理解。所任职企业是敏捷项目管理实践的先驱之一，曾参与组织级别敏捷转型，多年来一直致力于敏捷项目管理方法的学习及应用，对于敏捷管理体系及工具有深入的理解和丰富的实践经验，善于带领团队应用新的敏捷管理方法提升效率。周 琴 CSM，PMP，DevOps Master，ACTP，软件开发经理情商教练和敏捷践行者。有超过10年的在世纪500强企业中实战的经验，负责研发企业级的项目及项目组合管理软件，专门为世界500强公司提供大规模敏捷、项目管理和项目组合管理的解决方案，帮助IT敏捷转型。同时，关注敏捷和看板开发，积极实践各种敏捷方法，曾担任过产品负责人、研发经理、敏捷教练，主持无角色团队和设计团队等敏捷转型的一系列工作。

有了看板，你花在项目上的每一分钟都可以为客户增加价值。这是一本可以帮助你实现这个目标的书。

推荐阅读

创建敏捷团队：ScrumMaster、敏捷教练与项目经理的实用指南

如客户般管理干系人（第2版）

敏捷实践指南

译者序

很荣幸，承蒙电子工业出版社编辑的邀约，我组织并参与了本书的翻

译工作。本书不是一本关于看板的理论书籍（虽然书中最后一章对看板相

关的知识体系进行了展开阐述），而是为那些希望用看板实际交付价值的读

者所编写的。作者汇聚了自己在微软 Xbox 项目组中引入看板方法时所采

用的实践、遇到的挑战及应对的措施，具有极强的实战价值。

在过去的几年里，我在很多公开课和企业内训课里带领过一个叫作《凤

凰项目——DevOps 业务模拟》的沙盘游戏。这个沙盘的设定是一家企业的

IT 部门在面对纷至沓来的各种业务需求、客户商机、日常操作及服务事故

时如何操作，以帮助公司业务取得成功的场景。在玩这个沙盘游戏的初期，

我们往往会看到所有游戏参与者急匆匆地在场地间往返奔跑、大声沟通，

以期完成手头的工作，而同时新的需求不断涌来。可以观察到，即便所有

人都全情投入，但结果往往不尽如人意。这时候，“更忙”已经不再是一个

可行的选项，我们需要一个系统来为我们服务。往往，这个系统和看板有

着密不可分的联系。

沙盘反映的其实是一个时间轴压缩了的工作场景。如果你的项目也有

下面的状况：各种需求快速堆积，人员不停地加班，但就是难以按照理想

的状况低成本、按时、高质量地交付客户价值，那很可能你也需要这样一

个看板系统。按照大野耐一的说法，“看板的目的是让问题浮现到表面。”

看板的启动非常容易（见第 2 章），而且它可以适配任何类型的项目，

无论是传统的瀑布式、Scrum 开发方法，还是运维类的工作，看板甚至也

适用于个人工作和生活的管理。但是要用好它并不容易，很多采用了看板

的团队往往把这块板仅当成一块需要应付填充任务的板，久而久之，团队

看不到它的价值，就不再采用了。

本书给出了用好看板最为实际的、全面的阐述，不但有待办事项管理、

看板墙设计、在制品限制调整、速度和质量度量等内容，还涵盖了任务估

算、工期计算，甚至讲述了如何把分支管理、持续集成、持续交付等整合

进看板中，让人大开眼界。考虑到大多数人对改变工作方法心存疑虑，作

者也据此在很多章节后面给出了“开诚布公的问答”，帮助解答在实践看板

过程中可能产生的种种疑惑。

翻译本书的过程充满了挑战和乐趣，我和另外两位译者肖蓬、周琴也

采用了看板方法管理我们的工作进度，记录并解决翻译过程中出现的一个

个问题，体验了看板在一项翻译工作中起到的积极作用。

最后，我谨代表译者团队对我们家人的支持表示衷心感谢，没有你们

的默默付出，我们不可能在较短的时间内完成这项工作。另外，感谢电子

工业出版社的刘露明编辑对我们的信任和支持，使整个合作过程高效而有

序。也期待我们的读者从阅读本书中获得实施看板的最大收益！

许 峰

前言

致 Corey Ladas，他曾建议我通过新的视角去观察。

我是一名专业的软件开发人员，已经在这个行业工作几十年了（目前

工作在微软 Xbox 项目上）。没人会因为我是认证的流程大师，或是狂热的

流程鼓吹者而付给我报酬。我是因为按时、低成本、高质量交付客户喜爱

的软件而得到报酬的。

我在具有高度不确定性的环境中从事软件开发工作，优先级、需求和

客户期望每天都在变化。我在竞争激烈的环境中开发软件，产品为争夺市

场份额而竞争，同行们也会为薪酬而竞争。我的软件开发同行们都处于同

样的环境中，无论他们在哪里工作，也无论他们生产什么产品。

我一直在寻找自己的竞争优势——使生活更轻松、更富有成效，同时

为我的客户带来更好的产品。20 世纪 80 年代，当我在 Leumi 银行、NASA

喷气推进实验室、Graftek 和美国硅谷公司工作时，我专注于现在所说的设

计模式①和单元测试；90 年代，当我在波音公司和微软公司工作的时候，

我和我的团队尝试了瀑布式里程碑和不同长度的产品稳定期、T 恤估算法、

① 设计模式（Design Pattern）：是对软件设计中普遍存在（反复出现）的各种问题所提出

的解決方案。这一术语是由埃里希·伽玛（Erich Gamma）等人在 20 世纪 90 年代从建

筑设计领域引入计算机科学的。——译者注

个人判断、缺陷监禁①、持续集成及设计和代码审查；2000 年后，我管理

的微软团队尝试了团队软件流程（Team Software Process，TSP）②、Scrum、

代码审查、静态分析、计划扑克、结对编程和测试驱动开发；2010 年以后，

我发现了持续部署、看板方法，并且在此基础上发展和演进 。

上面列出的一些方法你可能并不熟悉。我认识的专业软件开发人员大

多都不喜欢尝试新方法。通常他们从工作过的第一个专业软件开发团队中

学到一种适合他们的方法，并且希望一直坚持使用这种方法。

尝试不同的方法是痛苦的，并且可能在最初阶段造成生产率下降，但

新的方法使我的团队能够超越同行们。我的团队比其他做类似工作的团队

要小得多，但成员们在相同或更少的时间内以更高的质量创造了更大的价

值。这并不是因为我的团队成员都是神人，或以其他人 20 倍的速度在工作。

（我拥有很好的团队成员，但他们并不是神话人物。）我的团队只是每小时

都能产出更高的价值。

你可以尝试所有我试用过的方法，但很费时，并且冗长乏味。虽然我

和我的团队从每次实验中都有新的收获，但并不是所有的方法都产生同等

价值。我现在和以前的团队仍然在不同程度上使用设计模式、单元测试、

持续集成、设计和代码评审、静态分析、计划扑克、结对编程、测试驱动

开发和持续部署，然而，对团队生产率和质量影响最大的是 Scrum——直 到 4 年前我们转换到看板方法。应用看板方法，我可以第一次在漫长的职

业生涯中坦诚地说：我的团队工作的每分钟都在为客户创造新的价值，没

有浪费时间和精力，产品质量得到了保证。

这本书讲述了如何在你的团队中复制我的成功。我已经做了所有的实

验，经历了所有失误。我从中选取了重要内容，用平实的语言和简单直接

的步骤展现出来，这样你就可以直接应用并从中获益。不要只是让你的同

行们读这本书、用看板，这会让你自己看上去是个老古董。按照书中描述

的简单步骤，开始创造出客户喜欢的、更好的软件，即高质量的、准时交

付的、低成本的产品。

谁应该阅读这本书

这本书是为希望尝试新的方法或有抱负的软件开发专业人士撰写的。

你可能从 20 世纪 60 年代就已经开始开发软件，也可能刚刚大学毕业；你

可能在一个软件公司工作或任职于大公司的 IT 部门中，也可能是自己开发

应用程序的程序员或网络开发人员；你可能是一名软件分析师、项目经理、

项目集经理、开发人员、测试人员、项目负责人或部门经理。只要你是一

名软件开发的实践者，就会发现这本书很有启发性，极具价值。

这本书提供了务实和规范的分步指导，以说明如何以最高的质量、在

最短的时间内、以最低的成本为客户创造最大的价值。本书中包含了图表、

工作表单、“开诚布公的问答”和常见问题，以阐明概念并指导你走向成功。

这本书还有一些章节特别针对那些想要从传统的瀑布式方法或 Scrum 转向

看板方法的读者。

尽管最后一章“更多资源及其他”涵盖了看板方法和其他技术背后的

基本理论，但如果你正在寻找更深入的参考资料，这本书可能不适合你。

学生、学者和顾问可能喜欢不同类型的内容，以做深入的理论分析和实践。

我在最后一章中列出了几篇这样的文章。

本书的架构

本书关注的是一个特性团队（3~10 人）在应用看板方法时可能经历的

过程。

? 第 1 章“获得管理层同意”，涵盖了获得管理层同意应用看板的方法和

步骤（开始应用看板之前的必要条件）。本章包括一封致公司经理的公

开信，并附有建议书。

? 第 2 章“看板快速启动指南”，可以让你基于现有的待办工作列表，在

几天内熟悉看板方法。本章还包括“常见问题”部分。

? 第 3 章“如期交付”，帮助团队成员填充并排序待办工作列表，估算项

目所需的时间和资源。

? 第 4 章“从瀑布式方法演进”和第 5 章“从 Scrum 演进”，适用于目前

使用传统瀑布模式或 Scrum 的团队。这些章节总结了针对使用看板方法

的争论，提供了适应或演进到看板的步骤，并回答了团队可能存在的疑

问。这些章节及其中包括的“开诚布公的问答”都是基于我将看板方法

引入传统瀑布式和 Scrum 团队的经验总结。

? 第 6 章“部署组件、应用程序和服务”，着重于用看板方法向客户交付

价值，从持续集成到持续部署。

? 第 7 章“在大型组织中应用看板方法”，适用于在大型项目中有数百或

数千名工程师的团队，包括如何适应看板方法，以及如何对管理层报告

项目状态。

? 第 8 章“持续工程”，来自 James Waletzky，讲述了如何应用看板方法

维护已发布的软件。

? 第 9 章“更多资源及其他”，概述了看板方法的理论基础，并且介绍了

如何在前面几章讲述的实践基础上进行改进和超越。本章为那些想继续

学习和发展的人提供了更多资源。

致谢

我要先祝贺微软出版社成立 30 周年。Devon Musgrave 是在 Redmond

周年纪念派对上找我写这本书的。非常感谢 Devon 的建议和对这本书出版

的支持，也深深感谢我的编辑 John Pierce，他对书中语言的可读性和一致

性做出了卓越贡献。

这本书有 6 位评审者：David Anderson，Corey Ladas，Richard

Hundhausen，James Waletzky，Doug Thompson 和 Vijay Garg。Doug 和 Vijay

目前在我的两个团队工作，每天都使用看板。他们的反馈对于文章及示例

的清晰和准确至关重要。James Waletzky 是一位充满激情的敏捷实践者，我

们过去一直在一起工作，他坦率的态度、认真的评审指导了我多年来的写

作工作。James，带着我对他的敬畏，帮助我编写了“持续工程”（第 8 章）

这一章。Richard 很晚才加入这个项目，但提供了大量建议，并建立了看板

方法与敏捷项目管理的紧密联系。我深信，如果没有经过专家的细致评审，

就无法交付有价值的设计、代码或评论。从某种程度上说，这本书值得一

读主要归功于这些杰出的评审专家。

特别感谢 David Anderson 和 Corey Ladas。David 在整个职业生涯中一

直是项目管理方面的行业领导者。他是使看板方法产生演进的创始人。

David 在世界各地演讲，培训专业人士。自从我们多年前在微软合作以来，

David 就不惜花费自己的时间，慷慨地分享他的见解。他对这本书的准确性、

框架及措辞的贡献至关重要，意义深远。即使在旅途中，David 也花费了大

量时间仔细评审这本书，对此我深表感谢。

Corey Ladas 对我的思想和事业有影响深远。Corey 向我介绍了 Scrum、

敏捷、公理化设计①、TRIZ②、质量屋及许多其他技术。2007 年，Corey 邀

请我去看他和 David 应用看板的成果，我立刻被吸引住了。尽管还需要花

几年时间去尝试，我还是立即和尽可能多地向同行分享了这项成果。Corey

是一位深刻的思想者，他一直在挑战现状，无所畏惧、不屈不挠。他有时

会显得强硬并充满反叛性，但他总是以诚待人且富有洞察力。我有幸能把

他称为我的朋友。Corey 是我能写这本书的灵感来源。

最后，我要感谢我过去的经理们 Curt Steeb、Boyd Multerer 和 Kareem

Choudhry，感谢他们让 Xbox 成为一个如此优秀的工作场所。感谢我的团

队成员们，他们和我一起尝试新的方法，分享成功的喜悦。最后，也是最

重要的，感谢我的妻子 Karen，我的儿子 Alex 和 Peter，有他们的陪伴我才

能如此快乐！

下载

? 示例文件

我提供了几个示例文件，可以从下面的链接下载：

https://www.microsoftpressstore.com/store/agile-project-management-with

-kanban-9780735698956

第一份文件是可以提供给管理层的一封信及建议的样本，以获得他们

对于使用看板方法的首肯。第二份文件是一个 Excel 工作簿，其中包含了

书中所有示例的电子表格，包括计算在制品（Work in Process，WIP）限制、

估算完成日期，以及随时间推移度量生产率和质量的图表。

按照页面上的说明下载文件即可。

系统要求

我们提供的文件采用 Office Open XML 格式。使用这些文件的基本要

求是在计算机上安装 Excel 查看器和 Word 查看器。

勘误、更新，以及对本书的支持

我们已经尽一切努力确保本书及其配套内容的准确性。通过以下链接

可以获取本书的更新信息——按既定格式提交的勘误信息及其相关更正：

http://aka.ms/pmwithkanban/errata

如果你发现了尚未列出的错误，请通过以上页面提交给我们。

如果你需要其他支持，请给微软新闻手册支持部门发送邮件：

[email protected]。

请注意，微软软件和硬件的产品支持不再沿用以前的地址。有关微软

软件或硬件的帮助，请转到：http://support.microsoft.com。

微软出版社免费电子书

从技术概述到关于特别主题的深入研究，微软出版社的免费电子书涵

盖了广泛的主题。这些电子书以 PDF、EPUB 和 Mobi 适应 Kindle 的格式

提供，可以从以下网址下载：

http://aka.ms/mspressfree

希望听到你的反馈

在微软出版社，读者满意是我们的首要任务，你的反馈是我们最宝贵

的财富。请通过以下页面告诉我们你对这本书的看法：

http://aka.ms/tellpress

我们知道你很忙，所以我们只选择了几个问题。答案将直接被转到微

软出版社的编辑手里（我们不要求提供任何个人信息）。先提前感谢你的

反馈！

保持联系

让我们保持联系以继续共同探讨。你可以在 Twitter 上找到我们：

http://twitter.com/MicrosoftPress

目录

第 1 章 获得管理层同意 ．． 1
一封致经理的公开信 ．．． 2
开展后续工作 ．．． 6
清单 ．．． 7

第 2 章 看板快速启动指南 ．．． 8
第 1 步：记录团队的例行工作 ．．． 9
第 2 步：重新布置看板墙 ．．． 10
第 3 步：为混乱设限 ．．． 14
第 4 步：定义完成规则 ．．． 17
第 5 步：召开每日站会 ．．． 19
常见问题 ．．． 23
清单 ．．． 33

第 3 章 如期交付．．．． 34
填充待办事项列表 ．．．． 35
确定最小可行产品（MVP） ．．．． 37
为工作排序，包括技术债务 ．．． 39
估算特性和任务．．．． 41
跟踪预计完成日期 ．．． 44
目录 XVII
调整团队规模 ．．．． 47
清单 ．．． 52

第 4 章 从瀑布式方法演进 ．．． 54
将看板方法引入瀑布式团队 ．．． 55
在特性团队中应用看板方法 ．．． 59
在开发新特性之前完成现有特性．．．． 60
定义规范和处理缺陷 ．．． 62
让客户参与 ．．． 65
庆祝绩效改进 ．．．． 68
开诚布公的问答 ．．．． 72
清单 ．．． 80

第 5 章 从 Scrum 演进 ．．． 81
将看板方法引入 Scrum 团队 ．．． 83
Scrum 角色和术语与看板方法的对应关系 ．．．． 86
Scrum 事件的演进 ．．． 88
庆祝绩效改进 ．．．． 89
开诚布公的问答 ．．．． 94
清单 ．．． 100

第 6 章 部署组件、应用程序和服务 ．．． 102
持续集成 ．．． 103
持续推送 ．．． 108
持续发布 ．．． 111
持续部署 ．．． 113
清单 ．．． 118

第 7 章 在大型组织中应用看板方法 ．．． 120
从大型项目前期规划中获取待办事项．．． 121
根据依赖关系对工作排序．．． 124
适应里程碑 ．．． 129
与管理层及外部沟通项目状态．．． 131
对延迟交付或不稳定的依赖项采取应对措施 ．．． 134
在产品稳定期内保持生产率 ．．． 140
清单 ．．． 142

第 8 章 持续工程．．． 144
定义术语、目标和角色 ．．． 145
确定持续工程的负责人．．． 148
设置支持级别 ．．． 150
协作以提高效率．．． 152
实施持续工程工作流程的看板 ．．． 155
看板方法 ．．． 159
常见问题 ．．． 160
清单 ．．． 164

第 9 章 更多资源及其他 ．．． 166
将看板扩展到业务和生活新领域．．． 167
将敏捷、精益与看板相结合 ．．． 172
为什么看板有效．．． 176
超越看板 ．．． 184
清单 ．．． 196