作者: 克里伯格  出版社: 人民邮电出版社 副标题: 用看板管理大型项目 译者: 李祥青  出版年: 2012-9 页数: 168 定价: 39.00元 装帧: 平装 ISBN: 9787115291776 豆瓣链接： http://book.douban.com/subject/11620809/

第一部分  我们如何工作

第1章  项目背景

1.时间线

每个发布版本都是了解真相的最佳时刻；发布的频率高，补丁小，每次发版的问题和风险也就少。

2.我们如何切割大象

要找到一个合适的方式，来切割大型项目。最理想的就是每次增幅能够独立地为用户带来价值，为团队积累知识。

3.我们如何让客户参与进来

根据客户列出的功能清单，制订项目地概要时间表和版本发布计划；如果可能组织 现场演示反馈和 定期的验收测试。并且开启 试点用户范围的反馈调查。

第2章  组织团队

软件开发项目的一大挑战在于如何将项目人员划分为多个大小适中的团队，并让这些团队相互之间紧密合作。

团队在一起办公很重要，开发团队转为scrum架构，让每个小团队具有多职能特征，分析、开发、测试人员坐在一起，提高团队的协作水平。

第3章  每天出席鸡尾酒会

每日立会 9:30-10:15。原本需要通过创建文档和流程规则才能解决的很多问题，在这些立会中得到解决。各个团队针对问题进行讨论现场决策，而不用专门为这类问题制定新的策略规划。保持敏捷、不为官僚程序所拖累。

1.第一拨：功能开发团队每日立会

每个功能开发团队可以遵循Scrum模式,回答：

       “我昨天做了什么？”  “我今天打算做什么？”  “遇到什么麻烦？”

当然这一切都要在10-15分钟结束，由团队的主管（等同于Scrum大师）主持。

2.第二拨：不同专业角色的同步立会

测试同步立会：讨论如何最好地利用当天的时间，而隶属于各自所属功能开发团队的测试人员，可以分享各个团队的最新进展。

需求同步会议：跟功能开发团队的分析人员也来参加，给整个需求分析团队汇报最新的信息。

开发同步会议：由各个功能开发团队的主管和开发经理组成，分享各自团队的最新信息。

3.第三拨：项目同步立会

每个专业一个代表，每个功能开发团队一个代表，再加上项目经理、配置经理等少数几个人。

主要关注从需求分析到投入生产的各个工序是否正常运转：

    “每个团队今天在做什么？”  “现在有什么问题阻塞了我们的流程？”  “瓶颈在哪里？”

    “如何消除瓶颈”  “下一个瓶颈可能会出现在哪里？”  “我们的发布计划是否顺利”  “有没有人不知道今天要做什么工作？”

第4章  项目进度板

任务看版工序流向：

    创意－> 功能－> 下十个功能 －> 开发 －> 系统测试 －> 用户验收测试 －> 上线

并非传统的瀑布流模式，在看板系统中，不同阶段都是并行的。

1.我们的节奏

每两周回顾总结，每两周规划会议，持续进行的演示与系统测试，每两个月的版本发布

2.如何处理紧急问题和障碍

不能把任务板塞满，那么整个系统将会瘫痪。设置优先级，着重解决路障和瓶颈问题，否则跳过。

第5章  扩展任务看板

项目开发速度很大程度上取决于团队成员对项目当前状态的熟知程度，如果人人都清楚项目的当前进展和未来走向，就比较容易同心协力向目标前进。

创建项目进度板，用来显示项目所有功能从需求、开发、测试到核准上线的最新状态，让我们对项目整体情况一目了然。

第6章  跟踪总体目标

如果人人都清楚总体目标是什么，就会更关注总体目标。

每周或每两周做一次实现检查，一般在项目同步立会上进行。 “你认为我们能实现这个目标吗？（1-5分）”

根据大家都能看到的数据，订制简单现实的版本发布计划，不试图隐藏任何不确定性。

否则，不了解目标或是对实现目标没有信心，会将自己和业务目标脱离，“只管开心写代码”或“做完份内事就回家”。

第7张  定义“可供”与“完成”

明确进度看板各栏的含义。

1.可供开发

已细分好任务、估算完工作量、澄清了范围的功能，不过尚未决定开发哪些和按照什么顺序开发，类似Scrum产品需求清单。

一个功能要进入可供开发状态，需要具体以下特点：

必须有一个ID；必须有一个联系人（需求分析师，拥有功能相关领域知识）；必须对客户用价值；必须经由团队估算；必须有验收测试情景。

2.可供系统测试

是指功能开发团队已完成他们能够想到的所有工作来保证某项功能正常，且没有重大缺陷。

开发团队需要花费一定时间确保功能质量：

验收测试自动化；通过回归测试；已给其他人员演示过；确保相关代码的可追溯性；在开发环境中测试过；已修改冲突，和主干代码合并。

3.两个定义如何提升团队协作

发现问题正是解决问题的第一步和关键一步。

只有不同角色的人员一起合作，对功能进行估算，然后细分成很小却又不会失去客户价值的可交付单位，并就验收测试达成一致意见，可供开发的状态才算真正实现。

第8章  处理技术故事

技术故事是开发者需要完成但客户并不感兴趣的事情，像升级数据库、清理不用的代码、重构糟糕的设计或对原有功能实现自动化测试等。

1.示例1:系统测试瓶颈

当系统测试成为瓶颈的时候，就没有必要再开发新功能增加负荷了。测试经历提出测试需求清单并排序，交给开发人员。

2.示例2:版本发布前一天

如果没有bug需要修复，开发人员就会处理技术故事。

3.示例3：7米长的类

必须马上启动技术故事重构这种类。这个例子表明，一直以来对设计关注不足而仓促行事，后果会有多么严重。

第9章  处理bug

1.持续系统测试

持续做系统测试，而不是全部堆到最后一刻。因为修复 bug是真正花费时间的大头。

2.立马修复bug

现在测试人员发现一个bug后，不是直接记录到bug追踪系统中，而是开好task，然后去找对应代码的开发人员。

这样做的特点在于，没有移交、没有延迟、不需要通过bug追踪系统来沟通，更有效率。原因如下：

早发现bug并修复比晚发现和修复有效率；面对面沟通更有效率；开发人员和测试人员能够相互了解对方的工作内容；不需要浪费很多时间去管理冗长的老bug列表

3.为何要限定bug跟踪系统中的bug数量

一般限定30个，这样可以让我们始终专注于最重要的bug，而不会成为管理负担。

4.Bug可视化

再确定前5个bug，登上项目进度看板。于是开发人员就有3个需要关注的输入队列： “下10个功能”、“下5个技术故事”和“下5个bug” 

5.预防bug重现

从某个具体模块中移除一些不必要的代码；

设置例行程序，确保有更多的时间进行重构；

多进行面对面的沟通，少依赖文档沟通；

开发期间与测试人员更加紧密地合作，做得更专业。

第10章  持续改进流程

战略相当简单：即假设人们天生希望项目成功，天生希望解决问题并改进工作方式。所以，我们需要做的就是创建一个能够促进和鼓励这种行为的环境。

如果人人都清楚我们的目标是什么、我们当前所处的位置，而且有正确的沟通平台，那么大家就会自我组织，朝着正确的方向前进，并持续摸索出尽快实现目标的方法。

1.团队回顾

开发团队，一般每一两周开一次，时长30分钟到2个小时不等，目标是：反省哪里做的好，哪里做的不好，以及需要做出什么样的改变。

改变通常包括：更频繁的检入代码；改变每日立会的时间和方式；更新代码编写规范；确定一个新的团队内部角色。

2.流程改进研讨会

交叉团队，目标是澄清并改进我们的工作方式。流程如下：

做好准备：会议开场，设定主题与关注焦点；

收集数据：回顾上次会议之后发生过什么，取得的成果和面临的难点；

产生见解：讨论数据及其意义，专注于最重要的难点问题，确定解决的具体方案；

作出决策：决定要实施哪些改变；

结束会议：决定谁来做什么，以及下次会议之前需要完成什么。

3.掌控改变速率

变化太多太快，会使团队成员迷茫和沮丧。

在犹豫不决时，就选择最简单的方案。这些完全取决于自己。

第11章  管理在制品

当信在邮车中运输时，它处于 工作状态；当信躺在你家的邮筒时，它处于 等待状态。

项目看板上会有很多的类似等待状态的缓冲区，在需求和开发中间，有三个缓冲区：

a.已通过分析得到确定但还没有选入“下十个功能”

b.已拉入“下十个功能”但还没有被具体开发团队接手

c.已经在具体开发团队手中但开发工作还没开始（可以简化）

1.采用在制品限额

在制品限额旨在避免同时做太多工作，避免让下游流程负载过重。

2.为什么在制品限额只适用于功能卡

技术故事和bug修复不包括在在制品限额内。

技术故事有助于消除下游瓶颈，能够提高质量，让测试人员更轻松。

在制品限额的精髓在于：努力完成一件事，而不是努力开始做另一件事。

第12章  捕捉并使用流程度量

流量度量可以找出哪里需要改进，变更是否带来了积极的效果。主要有两方面：速率（每周功能数）、周期时间（每个功能的开发时间）。

1.速率（每周功能数）

每周结束计算有多少功能卡可以进入“可供验收测试（本周）”栏。生成燃尽图，显示每周所完成功能的累计数量。燃尽图可以凸显问题，直观显示流量的改进。

2.为何不使用故事点

只计算功能数量，而不计算功能大小，这样过分简单化的速率有没有误导？从实践上来说，功能大小的分布其实相当均匀。

如此，提高精度并未增加多少价值，所以估算故事点就是在浪费时间。

3.周期时间（每个功能所需时间）

周期时间是指完成一项工作所需的时间，在项目中更具体的是指，x功能卡从“下10个功能”移到“可供验收测试”栏需要的时间。因为这部分流程是我们可以控制的。

怎样缩短周期时间，最廉价的方式就是控制在制品限额，找到一个平衡点，保证所有人员相互协作，问题能够得到暴漏，但不是一下子全部暴漏。

4.累计流量

累计流量图实际上并不能反映多少问题，会显得脆弱不堪，杂乱无章，但聊胜于无。

5.流程周期效率

流量时间效率（％）＝接触时间（实际开发功能的时间）／经过时间（周期时间）

大多数公司都在10%－15%的范围内，除非专门为此优化过工作流。

第13章  Sprint与版本发布规划

Sprint规划会议的目的在于弄清楚下一步做什么。会议内容分为两部分：梳理需求清单与挑选前十项功能。

1.需求清单梳理

挑选可以转入“可供开发”状态的功能卡。

2.挑选前十个功能

商业价值：客户最乐于看到的功能有哪些；

知识：哪些功能会产生知识（因此会降低风险）？

资源利用：我们需要平衡功能领域，这样才能让所有团队都有事做；

依赖关系：哪些功能最好组合在一起开发；

可测试性：哪些功能放在一起测试最合理，因而需要同期开发。

3.为何将需求清单梳理工作移出Sprint规划会议

先单独进行需求清单的梳理，然后再开Sprint规划会议。因为梳理工作非常耗时，应该重点讨论主要问题。

4.规划版本发布

对于长期规划而言，我们并不一定知道功能总数是多少。我们有的知识一对模糊的创意。我们将其称为综述或功能领域。

单独讨论每个总数并估算应将其划分为多少个功能，这种估算需要需求分析师、开发人员、测试人员都投入时间和精力。估算类似于估算故事点。

这样我们就可以基于真实数据做一个大致的估算，对多久完成一个综述给出一个比较精确的日期。

第14章  我们如何做版本控制

实施主线模型，稳定主干模式。

1.主干无垃圾

对于大规模的项目，主干始终稳定至关重要。稳定就意味着可以进行系统测试。

一个功能的代码部分完成后，将代码检入主干并把功能卡拉入“可供系统测试”栏之前，我们会先从功能层次对其进行彻底测试。只有通过所有功能层次的测试，才会将代码检入主干并移动功能卡。

从主干的角度而言，产品以谨慎的步骤逐渐递增的同时，主干始终保持稳定，且随时可供系统测试。

2.团队分支

每个团队都有自己的分支，政策较主干宽松，不过代码必须编译，单测必须跑通，功能不一定非要完成和测过。

主干、团队分支保持同步的方式类似于git的检入检出方式。（相当于develop分支）

3.系统测试分支

系统测试是持续进行的，需要一个稳定的版本（相当于stage分支）。在主干的基础上创建系统测试分支。发现bug后，开发人员直接在该分支上修复，然后合并到主干上。

系统测试往往是好几轮的。

版本控制系统是多团队开发项目的真正核心。要搞清楚从改动一行代码到上线使用需要花多长时间，这是项目中最最重要的度量指标。

第15章  为何我们只用真实看板

原因在于看板可以演变（变更往往多变）、需要协作（否则立会难以进行）。

第16章  经验教训

通过案例来讲的真正主题是组织变革。

1.了解目标

就“完善”的定义达成共识，完善的流程、组织和工作环境应当是怎样的。这些将是组织变革的指南针。完善是方向，不是终点。

2.不断实验

寻找微小的渐进的改进机会，并将其视作实验机会，在积累中总结经验教训，然后设计新的实验。伟大的流程不是设计出来的，是逐渐演变而来的。

3.拥抱失败

唯一的真正的失败时未能从失败中吸取经验教训。

4.解决真正的问题

不断问自己：“我在解决什么问题？这个问题是真实存在的还是假设的？还有没有其他我应该先解决的更重要的问题？”

5.拥有专职变革推动者

至少拥有一名专职的变革推动者，完全专注于推动、领导和协调变革过程。

6.让人们参与进来

不要自己提出变革提议，将你看到的问题可视化呈现出来，让相关的人员参与进来，提出他们自己的解决方案。这样的变革更容易被接受。

第二部分  技术详解

第17章  敏捷与精益概述

广义而言，精益与敏捷是两组具有高度兼容性得价值观和原则，都阐述了如何成功地进行产品开发。Scrum、XP和看板是将这些原则运用到实践中的具体方法，相互重叠却别具风格。

1.敏捷概述

《敏捷宣言》: 个体和互动胜过流程和工具； 可以工作的软件胜过详尽的文档； 客户合作胜过合同谈判； 响应变化胜过遵循计划。

2.精益概述

精益原则：

1.全局优化（专注于整体价值流、交付完整产品、着眼长期）；

2.消灭浪费（构建错误的功能、拒绝学习、辗转现象）；

3.品质为先（最终验证不应发现缺陷、采用测试先行的开发模式让流程具有防误机制、打破依赖）；

4.不断学习（可预测的性能来自于反馈、保持选择方案、最后可靠时刻）；

5.尽快交付（快速交付、高质量和低成本是完全相互兼容的，排队理论适用于软件开发，管理工作流比管理进度表要容易得多）；

6.人人参与（自主性、成长性、使命感）；

7.不断提高（失败是个学习机会、标准存在的目的就是要被质疑和提高的、使用科学方法）。

3.Scrum概述

基本上前16章就是在讲Scrum。核心概念如下：

1.按优先顺序排列的产品需求清单；2.跨职能团队；3.Sprint；4.持续调整版本发布计划；5.持续调整流程。

4.XP概述

极限编程（XP）除多数理念和Scrum相同外，还增加了团队内部的工程实践，包括：持续继承、结对编程、测试驱动开发、集体代码所有权、增量式设计改进。

5.看板概述

看板是敏捷软件开发的精益方法，规则很简单：可视化工作流、限定在制品、衡量并管理周期时间。

Scrum专注于结构和沟通，XP增加了工程实践，看板则专注于将工作流可视化，并对瓶颈进行管理。

6.看板管理的典型一天

（略）

第18章  缩减测试自动化需求清单

测试未实现自动化，会产生修复时高昂的代价。

1.怎么办

每个迭代周期逐渐提高测试覆盖率。

2.如何每个迭代周期都提高测试覆盖率

a.列出测试用例

b.按风险大小、手动测试的成本、自动化测试的成本将测试分类

c.按优先顺序对列表进行排序

d.从优先级最高的开始，每个迭代周期都对若干测试实施自动化

3.第1步：列出测试用例

用头脑风暴的方式列出最重要的测试用例。

4.第2步：测试分类

丢弃一半的测试，保留哪些测试，分别按照风险大小、自动化测试成本和手动测试成本分类。

5.第3步：按优先顺序对列表进行排序

这个决定依据具体情况来决定。

6.第4步：每个迭代周期自动化若干测试

在做产品需求清单的时候，留20%的时间在测试自动化需求清单上。循序渐进。

7.这能解决问题吗

不会在短期解决，不过会让问题更容易解决。

第19章  用规划扑克估算需求清单大小

规划扑克能让团队以较快的速度完成规划工作（估算开发一项功能需要的工作量），同时也让规划工作更准确、更好玩。

1.不用规划扑克进行估算

在Sprint规划会议上，第一个说出项目功能有多大的人会严重影响团队其余成员的判断。

2.用规划扑克进行估算

能够盘活每一个团队成员，对不同意见进行讨论分析，最终达成一致。（五种牌：小、中、大、？、咖啡）

3.特殊牌

？：完全没概念，功能可能很大，可能很小。如果这个牌出现的频繁，这个时候团队就应该再好好讨论该功能，让团队成员多了解一些信息。

咖啡：“太累了。脑子卡住了。我们休息一下吧。”

如果出现较大的分歧，不可以简单的平均估中。比如认为小是因为某项功能可以重用，认为大时因为存在一些大家都没有考虑到的风险。

规划扑克最大的价值就在于玩牌时引发的对话与沟通，而估算结果本身则只是顺带来的好处。

第20章  因果图

因果图是以图解的方式进行因果分析的一种简易、实用的方法。

1.解决问题，而不是解决症状

症状一般出现在某处，而根本原因则在另一处。

2.精益问题解决方法：A3思维

精益思维的核心宗旨之一是改善——持续改善流程。

在提出解决方案之前，需要花费大量时间对问题的根本原因进行分析并以图示的形式显示。

因果图的优点在于：直观无需解释、显示增强回路。

3.如何使用因果图

选定问题，困扰你的任何问题，并写下来；

“向上”追踪，弄清业务后果，即你的问题所造成的“可见损坏”；

“向下”追踪，找到根本原因；

确定并标出恶性循环（循环路径）；

将这些步骤重复几次，调整并理清因果图；

决定要解决哪些根本原因，以及如何解决（即要实施哪些对策）。

4.示例1:发布周期长

不断提问为什么，发现恶性循环，找出根本原因。否则会草率得出结论，并实施无效的甚至是适得其反的变更。

5.示例2:上线版本有缺陷

根本问题通常会导致多个问题。

6.示例3:缺乏结对编程

缺乏信任和所有工作时间都必须有所产出是没有去实践XP的根本原因。

7.示例4:很多问题

很多根本问题，可以通过实践Scrum得到解决。或者将Scrum与看板结合。

8.实际问题：如何创建并维护因果图

实体白板和便利贴。

9.陷阱

太多的剪头和图框（移除多余的图框、专注于深度优先而不是广度优先、接受不完美、将自己限定在范围明确的问题上、将因果图划分为多个部分）；

过于简化；

参杂个人情绪（不做个人对象攻击）。

10.为何采用因果图

建立共识、发现问题对业务的影响、找到根本原因、消除恶心循环。

因果图虽然有用，关键却是解决问题的方法本身：提问的角度、由此展开的讨论以及调查发现。甚至无需画图，只要谈话过程中脑中想像就足够了。

第21章  结语

只有经过实践证明的知识才站得住脚。

附录  术语表：如何避免高深术语