【阅读笔记】精益开发实践用看板管理大型项目

【阅读笔记】精益开发实践用看板管理大型项目

参考 精益开发实践用看板管理大型项目

一、我们如何工作（案例研究）

1、项目背景

• 项目背景

  PUST系统，主要帮助瑞典警察署快速记录，处理违规、犯罪的案件，提高警察的办公效率。该系统之所以复杂，有如下几个方面：

  • 与大量的遗留系统集成；
  • 用户体验必须非常好，因警察需要一边询问犯罪嫌疑人一边使用系统；
  • 安全性要很高；
  • 必须符合大量法律法规的规定。

• 项目版本时间线

  这个项目的目标是打算到2011年早期，就能让瑞典所有警察都使用。开发工作大约从2009年9月开始。第一个生产版本（试点）一年后发布，然后是每两个月发布一个更新版本。

  
  Note：频繁发布新版本的好处：每个版本更新的补丁小，每个版本的问题和风险也会降低。如果两次发布的时间间隔较长，则代码中的缺陷（比如sql注入）和错误就会越多。

  精益流程一个最重要的特点就是不断发展改进。有时我们发现了更好的解决方案；有时昨天看上去相当不错的解决方案今天就会带来新问题；有时环境变了，迫使我们做出改变来适应新环境。

  对于大型项目版本的更新，要考虑在最大程度上降低大型项目的风险，找到以小幅递增模式发布系统的合适方式，而不是将所有开发成果积累到一起，最后才来个让人措手不及的爆炸性发布。

  最理想的情况是，每次的增幅能够独立地为用户带来价值，为团队积累知识。

  比如在这个项目中，通过两个维度- 地理区域和犯罪类型，来切分整个项目。

  

  1.0版-1.2版：只向一个地区（奥斯特格兰，Ostergotland）发布的试点版本，仅支持几个常见犯罪类型，如醉驾和非法持有武器。其他类型的犯罪还是以旧的手动方式处理。在接下来的每一个更新版本中，我们都改进系统稳定性、增加支持的犯罪类型。
  1.3版：增加第二个地区（乌普萨拉市，Uppsala）。
  1.4版：将系统扩展到整个瑞典。这就是“主要”版本。
  1.5版：增加犯罪类型，与其他系统（如查抄物品跟踪系统）集成。

2、组织团队

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

随着项目团队从30人增加到60多人，我们开始遇到严重的沟通和协调问题，这是成长之痛的典型症状。本项目共5个团队：一个需求团队、三个功能开发团队和一个系统测试团队。还有一些人不属于以上团队，他们负责处理专门事务和协调工作，这些人是项目经理、项目管理专员、配置经理、电子学习专家、性能测试专家、开发经理、教练等。

• 功能开发团队

  三个功能开发团队为Scrum团队，每个团队都在一起工作，多职能，自组织，能够开发和测试完整的功能。

• 需求分析团队

  需求分析团队实际上是一个虚拟团队，所以团队成员并没有坐在一起，而是分散坐开，这样保证项目团队所有人都能够就近与需求分析人员沟通。

  • 一部分分析人员隶属于具体功能开发团队，从开发到测试全程跟进该团队负责的功能，全程回答问题并澄清需求。
  • 一部分分析人员关注项目的大局，并不隶属于具体功能开发团队。他们着眼于未来，定义概要功能区域。

• 测试团队

  测试团队也是一个虚拟团队

  • 一部分测试工程师隶属于具体功能开发团队，帮助开发团队测试并调试功能。
  • 另一部分测试工程师则关注项目大局，集中对发布候选版进行系统的整体测试和集成测试。负责协调这项工作的人被戏称为系统测试将军。

  之前团队存在的问题：之前开发团队中没有配备分析人员和测试人员，不同团队间主要通过书面文档进行沟通，而不是直接面对面的交谈，每个团队都只顾完成自己团队的任务，而不关心整个产品，随着越来越多的人加入项目，沟通问题会越来越严重，这种模式不利于团队扩展。比如需求分析团队获得需求文档签订认可之后，就完成了任务，并没有同开发人员跟进整个项目。

  Scrum敏捷方法组织团队的好处：各个团队具有了多职能特征，分析人员、测试人员和开发人员都坐在一起，团队之间的协作水平有了大幅提高。不过我们并没有彻底贯彻多职能团队的做法，还是有一部分分析人员和测试人员并不在功能开发团队里，这样他们就可以专注
  于项目大局，而不是单个功能。在这种模式下，团队很容易扩展，从而让我们既能够在短期着眼于功能，又可以长期着眼于产品，在二者之间找到了良好的平衡

3、每日立会

• 功能开发团队立会

  团队成员（包括隶属于某个功能团队的分析人员和测试人员）在任务板前大致围成半圆形，讨论他们当天要做什么以及需要解决什么问题。

  

• 不同专业角色的同步立会

  各个专业角色（需求分析、测试、开发）的成员分别碰头，更新同步各个功能开发团队所做的工作。

  所有测试人员都聚拢在测试状态板前，讨论如何最好地利用当天的时间。隶属于具体功能开发团队的测试人员刚刚跟各自所属的团队开完立会，所以他们可以分享各个团队的最新进展。

  

• 项目同步立会

  参加项目同步立会的人员被戏称为交叉团队（cross-team），就像整个项目团队的一个横向剖面。我们这个项目里，就是每个专业派一个代表，每个功能开发团队派一个代表，再加上其他几个人，比如项目经理、配置经理和敏捷教练。

  

  我们在项目同步立会上审视整个项目的状况，主要关注从需求分析到投入生产的各个工序是否正常运转：

  1. 每个团队今天在做什么？
  2. 现在有什么问题阻塞了我们的流程？
  3. 瓶颈在哪里？如何消除瓶颈？下一个瓶颈会出现在哪里？
  4. 我们的发布计划进展是否顺利？有没有人不知道今天要做什么工作？

  每个立会的时间严格限制在15分钟内，每个立会都有必须出席会议的核心人员。每个立会又都对外公开。

  如果每日立会上出现了15分钟内解决不了的重要问题，我们就跟相关人员单独召开后续会议来解决问题。

  每日立会的好处：项目多数人员只需出席一个立会。个别人员需要出席两个立会。这种方式把各条沟通渠道高效“挂钩”，保证了重要的知识、信息和决策在整个项目组内得以迅速传播。

  原本需要通过创建文档和流程规则才能解决的很多问题，在这些早晨的立会中直接得到解决。比如我们会在立会中决定哪个团队开发哪个功能，又比如决定我们今天是花时间开发客户可见的功能，还是实施客户看不到的技术基础架构改进。各个团队只需在立会中对这些问题进行讨论就可以当场作出决策，而不用专门为这些问题制定新的策略规则。这就是大型项目保持敏捷、不为官僚程序所拖累的关键。

4、项目进度板（看板）

1）看板内容

• 创意 & 功能

  综述卡：最左边的一栏是收集到的创意。这些创意都是概要功能区域。每个功能区域都写在一张综述（Epic）卡上。

  综述卡迟早会被拉入第二栏（正在分析，analysis ongoing），我们会在这里对其进行分析，并从功能角度将其分割成若干个用户故事。

  功能卡：用户故事都会写在第三栏中的功能卡（feature card）上。第三栏大致与Scrum产品需求清单（backlog）对应，不同的是功能卡并不严格排序。多数功能卡都以用户故事的格式写就：“作为X，我需要Y，以便能够Z。”例如：“作为调查员，搜索地址的时候我需要按区域过滤，以便能够快速查找到地址。”

  如果某个综述已被分析过（即已细分成若干功能），相应的综述卡就会被丢弃，代之以第三栏若干更为详细的功能卡。因此，综述卡绝对不会流出第二栏，功能卡则诞生于第三栏。

• 下十个功能 & 开发

  十个功能挑选：我们会挑出最重要的十个功能卡放入“下十个功能”栏中。通常我们会在每两周一次的会议上挑选功能。这个会议大致对应于Scrum的Sprint规划会议。

  开发：三个功能开发团队会根据各自的情况，把功能卡从“下十个功能”栏拉入他们自己的“正在开发”栏，完成功能开发和测试工作后，再拉入“等待系统测试”栏。

• 系统测试 & 验收 & 上线

  系统测试：测试团队定期清理“等待系统测试”栏，把功能卡拉入“正在进行系统测试”栏。一旦系统测试完成，测试团队就会将其放入验收测试环境，把功能卡拉入“等待验收测试”栏，然后返回，对新开发完成的功能开始新一轮的系统测试。

  用户验收测试：每隔两个月左右，都会有一批真正的用户过来，花两三天的时间做验收测试（基本上只是试用一下系统并给出反馈意见），这时候我们就会把功能卡挪入“正在进行验收测试”栏。

  上线：等到验收测试完成，发现并修复了最后的Bug以后，功能卡就会挪入“等待投入使用”栏。之后不久（产品发布后），功能卡会被挪入最后的“投入使用”栏。功能卡在这一栏会停留几周（显示我们有些成果正式上线了），不过之后就会被清理掉，以便给新来的功能卡腾出位置。

看板系统与瀑布流不同的地方在于：不同阶段的任务是并发执行的

我们的体系看上去很像瀑布式开发模式：需求分析→开发→系统测试→验收测试→核准上线。 其实还是有很大区别的。在瀑布式开发模式中，所有需求分析在开发工作开始之前就已全部完成，所有开发工作则在测试工作开始前就全部完成。

而在看板系统中，这些不同的阶段都是并行（甘特图）的。第一组功能进入用户验收测试阶段时，第二组功能还在系统测试阶段，第三组功能正处于开发阶段，第四组功能则处于需求分析和用户故事细分阶段。这是一个从创意到产品上线连续不断的价值流。

不过，我得说是半连续的价值流，我们的项目或多或少是一个从创意到“等待验收测试”阶段的连续价值流。大致每隔两个月才会核准新功能上线，而且是跟验收测试一起完成，所以新功能会在“等待验收测试”阶段停留几周。

2）项目一般节奏

1. 回顾总结会和规划会议，每两周开一次，一个早一天，一个晚一天，寻找改进流程的方法。

2. 随着功能的开发与测试，演示与测试是持续进行。

3. 大概在每两个月的阶段末期核准上线。

以上基本是Scrum迭代（sprint 迭代周期）的定义

3）如何利用看板处理紧急问题和障碍

将看板看做是含多条道路的交通系统，每张卡片代表一辆需要从左边驶向右边的车。

我们需要优化工序流，所以不能把任务板塞满，否则整个交通系统会瘫痪。因此这里我们需要空间和裕度（slack），让工序流动更快，而且还便于处理紧急情况。

如果某个功能进展停滞（例如，缺乏测试该功能必需的第三方工具），我们就在相应的功能卡上贴张粉红色便利贴，写清问题，落款和停滞开始日期。

我们在每日立会上着重移除这些障碍。就像交通系统一样，若障碍长时间得不到解决，就会对整个系统产生影响。而且，瓶颈路段会让全路段所有车辆慢下来，所以我们把所有精力都集中在解决这些瓶颈问题上。

便利贴上的日期表明问题存在了多久，落款则表明谁在负责解决问题。

项目进度板的好处：

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

2. 项目进度板的作用在于对于人数较多（eg：60人）的团队，每个团队都能看到他们的工作会如何影响（有时候是扰乱）功能上线的整体流程，团队之间的协作水平得到显著提高。

项目进度板或许是项目沟通最重要的工具，让大家对项目的整体状态一目了然，而且还能实时显示工序流动状态和瓶颈问题。

项目进度板存在问题：

如果把只跟具体团队有关的所有详细信息都放到大的项目进度板上，会显得太混乱，反而看不清项目全局。

因此为了解决这个问题，可以保留两个层次的任务板 - 一块大家共享的项目进度板加三块团队任务板（分别对应三个团队，在接收相应功能卡之后细分出来的任务）。

5、扩展任务看板（功能任务细分）

项目进度板上的开发栏从上到下分为三行，每个功能开发团队一行：

功能开发团队每次从“下十个功能”栏拉一张功能卡到“正在开发”栏，都会复制一张卡，贴到他们自己的团队任务板上去。

然后，每个团队的需求分析人员、测试人员和开发人员在分析立会上一起协作，勾勒出该功能的大致设计，然后把工作细分成具体任务。每项任务都会写得简明扼要，通常用动宾结构，例如，“写GUI代码”，“建数据库表”或“设计协议”。

Note：

1. 项目进度板上贴的是功能卡，而功能开发团队的看板上则贴有他们负责开发的具体功能和相关细分任务。
2. 每个团队都有自己的任务板布局，多数团队在他们的任务板上都标有同时进行的最多工作数 、“完成”的定义（DoD）和头像磁贴（表示谁在负责哪项任务）。

6、跟踪总体目标（当前版本）

项目总体目标通常就贴在项目进度板上。例如，2011年第一季度时，我们的目标是“4月5日交付没有重大缺陷、可以向全国范围发布的版本”。实现这一目标之前，还有一个里程碑，即3月14日向两个新增地区发布。

实现一个目标后，我们就为下一个发布版本写下新的目标宣言。目标宣言就是指路明灯。明确的总体目标有助于项目所有人员保持同步，明白对于下一个发布版本而言什么最重要。

现实检查包括如下内容：

1）投票 & 重新评估目标

一般每周或每两周都会做一次现实检查。通常项目经理会在项目同步立会上问大家：“你认为我们能实现这个目标吗？”然后每个人写下1到5之间的一个数字（有时候我们直接举手指）

5 = 绝对能
4 = 有可能
3 = 有点悬
2 = 不太可能
1 = 拉倒吧

这张图上是三轮投票的结果，从左至右分别是第一周至第三周的投票结果

只要投票结果中有2和1，我们就会重新评估目标，并讨论需要做什么改
变来提振信心。下面是一些可以采取的典型行动：

1. 消除障碍（“买台新的编译服务器，换掉有故障的那台！”）
2. 帮助解决瓶颈问题（“今天我们所有人都做测试！”）
3. 缩小范围（“如果把功能X从这次的发布版本中去掉，就还有可能实现目标！”）
4. 调整目标（“这个目标已经不现实了。我们来定个能真正实现的新目标！”）
5. 更加努力工作（“周日谁能来加班？”）

前四条中的任何一条都比第五条管用，因为问题的根本原因不是我们工作不够努力。实际上，有时候问题的根本原因是我们工作太努力了，以至于没时间思考。

2）模型预测评估

投票基本上凭直觉，但是有些时候可以通过如下指标或者可见的信息进行目标可行性分析：

1. 任务板上的功能卡，
2. 周期时间和速率等度量指标，
3. 以及各类图表，如下图所示的功能燃尽图。

右边伸出的两条虚线是趋势线，分别代表对下一次版本发布时能够按时完成的功能数量的乐观预测和悲观预测。

随着发布时间越来越近，我们会越来越清楚哪些功能可以做完，哪些做不完，所以不确定性（如下图中段所示）就会降低。

无论如何，持续做这种现实检查是检测和避免死亡行军（人人都知道会失败却仍然继续做下去的项目）行之有效的简单技术。如果大家能够对自己认同的目标形成共识，就会积极促进自我组织和协调。

反之，如果大家不了解目标，或者对实现目标没有信心，就会不由自主地将自己与业务目标脱离，只关心个人的目标，比如“只管开心写代码”或“做完分内的事就回家”。

7、就绪的定义（满足定义才可流入下一栏）

在项目进度看板大多数栏的顶部，我们都用蓝色彩笔写下相应栏的“完成”的定义，最重要的
两个定义是“可供开发”（ready for development）和“可供系统测试”（ready for system test），因为这两处是我们以前出问题最多的地方。

1）“可供开发”的定义（准备开发，流入“下十个功能/下五个技术故事”）

“可供开发”栏实质上表示“我们这里有一堆已细分好任务、估算完工作量和澄清了范围的功能，不过我们还没决定要开发哪几个功能，以及按什么顺序开发。

“可供开发”的定义：

一个功能要进入可供开发状态，就必须具备以下特点：

1. 必须有一个ID。可以通过ID来查询这些与该功能相关联的用例规范或其他文档
2. 必须有一个联系人。联系人通常是需求分析师，拥有该功能相关领域的丰富知识。
3. 必须对客户有价值。把综述分割成可交付的用户故事时，我们需要
   确保未丢失客户价值。
4. 必须经由团队估算。通常由一名测试人员、一名开发人员和一名需求分析人员组成的小组利用规划扑克进行估算（大中小），这种估算是估算工作量的多少，而不是估算时间长短。
   • 小指的是“在没有任何意外的状况下，大约花不到一周的时间就能够到达‘可供验收测试’阶段。”所谓没有意外状况是指我们找对了人，在没有干扰的情况下，专门负责这项功能。
   • 中指的是一到两周的时间（同样，在没有任何意外的状况下）。
   • 大指的是超过两周时间。大一些的功能可供开发前需要进行进一步细分。

2）“可供系统测试”的定义（该功能开发完毕，流入系统测试）

“可供系统测试”是指功能开发团队已完成他们能够想到的所有工作来保证某项功能正常，而且没有任何重大缺陷。不过，交付系统测试之前，他们只专注于测试该功能本身。

长久以来，系统测试都是一大瓶颈，其中一大原因就是在系统测试阶段会发现大量不必要的缺陷。“不必要的缺陷”是指远在开始系统测试之前，在功能测试阶段就应该发现的缺陷。因此，我们的可供系统测试的定义就把质量门槛提得较高，便于尽早发现非常麻烦的错误，同时要让功能开发团队也对质量负责。

“可供系统”测试定义：

1. 验收测试自动化：端对端功能层次的验收测试或集成测试已自动化。（可以使用Selenium或者Concordion自动化测试框架）

2. 通过回归测试：有时一个新功能会破坏现有功能，所以我们必须要保证定期运行所有回归测试。

3. 已演示过：开发团队已向团队其他成员、现场用户、需求分析人员、系统测试人员和可用性专家等人演示过该功能。演示的目的是尽早发现可用性方面的问题。

4. 清楚填写签入备注：签入该功能相关代码时，应当用该功能ID来标记签入备注，并填写容易理解的备注，说明都做过什么。这将保证最低限度的可追溯性。

5. 在开发环境中测试过：每个团队都有专用的测试环境，而且测试过该功能，免得开发人员说“在我机器上运行完全没问题”之类的话。

6. 已与代码主干合并：该功能代码应当已经合并到代码主干，而且任何代码合并冲突都已解决。

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

同样，只有不同角色的人员一起合作，从功能层次进行测试（包括自动化测试和手动探索性测试），来确定该功能可以放行，可供系统测试的状态才算真正实现。

8、处理技术故事（用户不感兴趣）

技术故事（Tech Story）是一些我们需要完成但客户并不感兴趣的事情，比如升级数据库、清理不用的代码、重构糟糕的设计或对原有功能实现测试自动化等。我们通常称之为内部改进（Internal Improvement）。

“可供开发”栏中的卡片数量相当多，囊括了功能卡和技术故事卡。我们并没有浪费时间去给所有这些卡片排出优先级，而是不断地根据当前任务的紧急程度确定下十个功能和下五个技术故事。

当开发团队有空接手新的工作内容时，可以从**“下十个功能栏”拉一张功能卡，或者从“下五个技术故事”栏**中拉一张技术故事卡。每日立会需要平衡两者的优先级。

技术故事卡右上角有一个绿色圆点，以跟功能卡区分。

• 案例1 - 系统测试出现瓶颈，开发自动化测试工具

  系统测试一度成为很突出的大瓶颈，所以当时已经完全没有意义再开发新功能，继续给瓶颈增加负荷。发现这个问题后，开发人员就开始专注于实施可减轻系统测试负荷的技术故事——主要是测试自动化的内容。
  实际上，测试经理当时的任务是创建测试自动化需求清单（Test Automation Backlog）并进行排序，然后通过“下五个技术故事”栏提供给开发人员。测试人员于是就变成客户了。

  

• 案例2 - 版本发布前代码的优化

  在主要版本发布的前一天，团队都希望先将该版本送出门，然后再开始接手新一轮的新功能。于是他们会专注于最后的Bug修复。如果当时没有任何Bug需要修复，他们就会处理技术故事——通常是些我们一直以来都需要完成但没时间做的工作，比如清理不用的代码、完成重构、学习新工具的使用等等。

9、处理Bug（快速找到并修复bug）

传统测试存在的问题：测试人员在开发周期末尾的系统测试时找到Bug，然后记录到Bug跟踪系统中。Bug跟踪系统中有成百上千个Bug，变更控制委员会则每周碰头，对Bug进行分析并排序，然后分配给开发人员。对所有参与的人来说，这个流程都既枯燥又低效。

1）持续系统测试

我们需要定期做系统测试，而不是全部堆到最后一刻。我们可以在已完成的功能基础上，提前运行一部分系统测试。

这样，最后的系统测试可能花的时间跟以前一样多，但修复Bug的时间大幅减少（整体时间减少），修复Bug的时间减少是因为我们已经提前发现并修复了很多Bug。

Note：

还有一个关键要素，就是自动化测试。我们不可能把所有测试都自动化，不过既然要一次次反复进行系统测试，我们就需要尽可能实现测试自动化。

2）限定Bug跟踪系统中Bug数量

原因：成百上千个Bug记录在Bug跟踪系统中，开发人员和测试人员需要通过Bug跟踪系统来沟通，比较低效，而且Bug跟踪系统中会积累太多老bug，变更控制委员会会议时间也会很长。

• 立即修复Bug

  测试人员发现一个Bug后，并不是直接记录到Bug跟踪系统中，而是写在粉红色便利贴上。接下来，开发人员和测试人员坐在一起现场修复Bug，或者开发人员自己修复Bug，然后马上再去找测试人员。这样做的特点是，没有移交、没有延迟、不需要通过Bug跟踪系统来沟通。

  延期的Bug基本上不在前30个Bug之列，但是会记到Bug跟踪系统里，这样做有可能在做数据挖掘的时候有用。

• Bug优先级排序

  1. 发现一个Bug后，第一个问题是“这是不是个拦路虎？”拦路虎的意思是“这项功能因为这个Bug而不能发布”或“修复这个Bug比开发新功能更重要”。我们把这样的Bug写在粉红色便利贴上。

  2. 如果这个Bug算不上拦路虎，我们就需要作出决策：“它比Bug跟踪系统中那30个里的哪个Bug更严重吗？”如果是这样，就把不重要的那个Bug从前30名列表中拿掉，给新Bug腾出位置。

  
  变更委员会会议仍然会召开，不过会议时间短了很多，也更为有效，因为只需要关注边缘案例即可，即只需顾及那些要先进行讨论才能确定优先级的Bug。

• “下五个Bug”栏 （Bug可视化）

  在前30个Bug中，我们还会确定前5个Bug。于是，开发团队就有了三个要关注的输入队列：“下十个功能”、“下五个技术故事”和“下五个Bug”。

  Bug卡会用红色记号笔书写，这样容易与功能卡和技术故事卡区分。

  

3）预防Bug重现（便利贴用完了不要扔）

有些类型的Bug会反复出现。通常都是些简单的问题，比如用户界面中的标签没有对齐或有错别字。

隔一段时间就有一个开发团队会召开缺陷预防会议，他们会选出一个重现的Bug，分析其根源。这个Bug怎么进入代码的？是什么系统问题在导致这种Bug反复出现？我们能做什么？Bug的根源有时与使用的工具有关，有时与策略和规则有关，有时则与文化问题有关。

如果是比较蹊跷的案例，可以通过画因果图来确定Bug的后果和根本原因，并以此为依据，提出切实可行的建议，避免今后出现类似Bug。

很多Bug并不是真正的问题，而是一种症状。产品中的Bug是流程有Bug的症状。如果你专注于修复流程，产品中出现的新Bug就会大幅减少。

10、持续改进流程（回顾会）

1）流程改进引擎（3要素，敏捷精益的基础）

流程绝对不是预先设计好的，尤其不可能独自一人完成。与其说我们的流程是设计出来的，不如说是我们发现的。我做的第一件事就是落实流程改进引擎（实际效果像发动机一般）。我们的流程基本模式如下：

1. 透明度：在显眼的地方设置看板，向所有人展示项目工作进展。交付物目标明确，人人都能明白。
2. 沟通：各个团队内部以及跨团队层面定期召开流程改进研讨会（每周或每两周）。
3. 数据：跟踪一些简单的衡量标准，看流程是否有改进。我们衡量的是速率和周期时间。

如果人人都清楚我们的目标是什么、我们当前所处的位置，而且有正确的沟通平台，那么大家就会自我组织，朝着正确的方向前进，并持续摸索出尽快实现目标的方法。
这种激励人们对流程作出革命性改进的思维就是敏捷和精益的基础。

2）流程改进研讨会（Process Improvement Workshop，Scrum回顾会）

流程改进研讨会基本上是Scrum的Scrum类型的回顾会议，目标是澄清并改进我们的工作方式。有时我们不用作出任何改变，只是澄清我们的现行流程——也就是说，消除混淆与误会，给出明确的描述和说明，让与会人员可以向他们各自的团队传达。作为教练，需要将这种会议融入到组织文化之中。

每个团队每一两周都会召开一次回顾会议，时长三十分钟到两小时不等。会议通常由团队主管主持（找外部主持人能让团队主管专心开会，而不是忙于主持。找外部主持人的方法：让团队A的主管去主持团队B的回顾会议）

召开回顾会议的方式可以千差万别，但目标都一样：反省哪里做得好，哪里做得不好，以及需要做出什么样的改变。

改变通常包括以下内容：

1. 更频繁地检入代码。
2. 改变每日立会的时间或开会的方式。
3. 更新代码编写规范。
4. 确定一个新的团队内部角色，比如“编译版本主管”（保持编译版本整洁）或“守门员”（保护团队不受干扰）。

• 流程改进是一个不断调整的过程（快速响应）

  每周都开流程改进研讨会则过于密集，我们还没来得及执行上一个研讨会总结出的改变建议，就要准备下一个研讨会。

  但是，频繁的研讨会促使我们快速实施改变，研讨会每周都要开，我们必须保持会议简短、专注，这就迫使我们只能优先考虑最重要的改变，并在变革流程中采取较小的步骤。

  一旦解决了最重要的问题，就可以放慢实施改变的速率，调整到一个适当的程度，所以我们后来就改成两周开一次研讨会。

• 流程改进研讨会的流程

  1. 做好准备：会议开场，设定主题与关注焦点。
  2. 收集数据：回顾上次会议之后发生过什么，包括取得的成果和面临的难点。如果我们有主题，就围绕主题回顾具体数据。
  3. 产生见解：讨论数据及其意义，专注于最重要的难点问题，并确定解决问题的具体方案。
  4. 作出决策：决定要实施哪些改变。
  5. 结束会议：决定谁来做什么，以及下次会议之前需要完成什么。

  • 具体实施情况

    具体实施情况：

    • 会议开始时，我会让大家快速轮流发言，好让每个人都开口，比如，“用一个词形容你现在的感受”或者“你希望这次会议的最大收获是什么”。

    • 然后，我会提醒大家本次会议的目的，并提到今天会议的关注焦点是什么。有时我们会有具体的关注焦点（如，动机、度量、协作、测试自动化等等）；有时除了改进我们工作方式这个大目标之外，并没有具体的关注焦点。

    • 接下来，我们总结上次会议以来发生的主要事件，并讨论上次会议有关决策的完成情况。

    • 然后我们快速总结过去几周哪里做得好，有哪些较为积极的改进。有时我让参会人员把发言内容写在便利贴上，然后贴到看板上；有时他们说，我往白板上写。总结并肯定过往的改进对激励进一步的改进非常重要。

    • 然后我们快速总结目前的难点和挑战。如果有很多问题（通常都会有很多），我们就会排出优先级，通常是用计点投票表决或类似的方式。
      下面这个例子显示有两个栏的便利贴：“成果”与“挑战”。

      

      Note： 这里使用直觉投票表决的方式，而不用数据度量主要原因是：直觉的优点是，感觉到有问题通常是问题可能会发生的先兆，而硬性的度量数据只有在问题发生以后才能显示出了问题。我们主要用度量来支持流程改进，而不是推动流程改进。

    • 当我们列出所有难点并予以排序之后，我们需要选出一两个最重要的难点，作为本次会议的关注焦点。然后我们分成两三组，分别讨论并分析问题，寻找可能的解决方案。

      分组讨论都能产生几项具体的提议或备选方案，我会把这些内容都列在白板上。默认的方案始终是保持现状（“不要做任何改变”）， 并提示大家如果本次会议不能就新方案达成一致意见，会出现什么样的后果。

      对于每一项备选方案（包括保持现状的方案），我们都会进行头脑风暴，列出最明显的优势和劣势。对优劣难分的其他选项，我们会通过快速大拇指投票（5 ~ 1 优 ~ 劣）来分析。

    偶尔也有两个方案拥有同样的支持率，这时我们或者就任选一个，或者选容易做的，或者来一次一决胜负的投票（“假定要从方案D和方案E中选择，你会选哪一个？”）。作为会议主持人，我会确定每一种情况下的决策流程，来避免大家又为了决策流程而讨论不休（一群聪明人在一起很容易如此）

    作出有关流程改进的决策意味着作出改变。既然我们是在跟人打交道，改变就意味着可能遭遇阻力，尤其是来自那些没有参加会议的人员。我们争取每项改变都达成百分百一致意见（即与会的所有人都意见一致），从而大幅降低了阻力风险，极大地保证了改变能够顺利进行。

    严格控制研讨会时间，通常都在90分钟（包括极其重要的五分钟休息时间）。研讨会最后留出十分钟左右的时间，总结已作出的决定（在白板上列出），并确定具体的行动——谁什么时候要做什么。

3）掌控改变速率（流程改进提案）

存在的问题：

我们作出的改变太多，而通常一项较大的流程改变需要数天，有时甚至数周才能在一个60人的项目中完全见效。因此，当前一波改变的尘埃还未落定时，交叉团队又引入新一波的改变，导致很多团队成员很迷惑（甚至很沮丧）。

解决方法：

我们引入了一点官僚做法来降低改变的速率。如果有人需要作出不止影响本团队的改变，就需要提交一份流程改进提案。

流程改进提案模板会迫使你思考为什么要作出一项改变。

• “你要尝试解决什么问题？”
• “这项改变会影响到谁？”
• “执行这项改变涉及什么步骤？”

小案例：

此项提案的主旨是保留对客户更有价值的功能，还建议完全不应将那些估计规模很大的功能拉入开发阶段，因为这类功能很有可能会膨胀并堵塞流程。反之，应当将这类大功能分割成较小的可交付单位。

任何人都可以提交提案。通常写提案的人会出席流程改进研讨会。

引入这个小模板的目标是让我们控制改变的数量。所以，如果收到四项提案，我们可能只会实施其中的一两项，即便四项提案都非常棒。

11、管理在制品

如果你仔细研究项目看板，就会看到只有四栏表示在制品（WIP）。其他六栏都是缓冲区（或队列）

1）缓冲区的设置（ 保证不同速率的流程顺利衔接）

缓冲区存在的意义：

有时我们的确需要一个小缓冲区来保证两个流程之间的顺利衔接。例如，功能的开发速率与下一步的系统测试速率并非完全合拍，这时的缓冲则可视为“必要的浪费”。

思考是否有些缓冲区多余：

随着流程的改进，对这种缓冲区的需求就会减少。在进度看板上将缓冲区清晰标示出来，我们就更有可能不断自问：是否真的需要所有这些缓冲区？我们能做什么来减少缓冲区的数量？

老版本的项目进度看板：

当时我们注意到一点，我们浪费了太多时间争论哪个功能应当进入哪个缓冲区。于是我们干脆把第三个队列去掉，让开发团队直接从前十个功能中挑选，而不是让一批批功能进入Sprint等待开发（Scrum的Sprint开发模式）。

尽管各个开发团队都直接从下十个功能栏中拉入功能卡，他们却在以一种很聪明的方式进行：开发团队在开发同步立会上互相交流，讨论如何最佳利用各个团队的现有能力。

团队可以用他们自己的头像磁贴来标记“下十个功能”栏（甚至流程中更早阶段）中的某张功能卡，表示“我们团队开发这项功能最合适”。

2）在制品限额（避免下游流程负载重）

在制品限额旨在避免同时做太多工作，避免让下游流程负载过重。如果测试人员手头已经有太多工作，我们就不希望开发人员再持续不断地开发新功能，给测试人员增加负担，而是希望他们腾出手来帮助测试人员尽快完成测试。

“每个团队最多五个功能”的在制品限额是指，如果一个团队已经在开发五个功能了，那么只有当其中一个已完成并开始系统测试时，他们才可以再接手下一个新的功能。

3）制品限额只适用于功能卡

制品限额只适用于功能卡。技术故事和Bug修复不包括在在制品限额内。

1. 不包括Bug：是因为Bug通常都相当紧急，而且都相当小。
2. 技术故事却恰恰相反，技术故事有助于消除下游瓶颈。我们很多技术故事都与测试自动化和基础设施改进有关，而这两项工作都能提高质量，让测试人员的工作更轻松。

在制品限额已满的时候，开发人员该做什么？他们应当做任何能够协助或减轻系统测试的工作！为测试提供援手的一种方式是调动人力去做手动测试和Bug修复，还有一种方式是开发自动化程度更高的测试用例并改进测试基础设施。

采用在制品限额的一个后果是，有时大家会没事做。更准确一点说，在制品限额有时会强制大家去做与常规工作内容不同的事（例如，帮忙进行测试，而不是开发新功能）。

12、捕捉并使用流程度量（速率，周期）

我们追踪以下两个流程度量：

• 速率（每周功能数）
• 周期时间（每个功能的开发时间）

1）速率（每周功能数）

对于速率（生产能力），我们只在每周结束的时候计算有多少张功能卡可以进入“可供验收测试（本周）”栏。我们在进度看板底部的速率栏内记下这一数字，然后将功能卡移入“可供验收测试（上周及以前）”栏，表示这些卡已经计过数。

• 燃尽图的使用（折线图）

  我们用每周速率生成燃尽图，可将其用作现实检查工具，检验版本发布计划是否切实可行；其次，根据这一数据来预测截至某个时间点大致可完成的功能数。

  

  燃尽图的作用：

  1. 燃尽图可用来凸显问题：各个团队都在努力工作，但系统测试因为各种原因成为瓶颈，于是所有的功能都在排队等着测试团队测试。人人都可以看到进度看板上卡片堆积，人人都可以看到一周一周过去，速率仍然为0。这就会给大家一种紧迫感，让开发人员逐渐转移工作重点，向测试团队伸出援手，而不再只是专注开发新功能，继续给测试团队雪上加霜。
  2. 燃尽图还用来直观显示流程的改进。例如，在下图中我们可以看到，第二季（Q2）比第一季度（Q1）的平均速率（曲线的斜度）翻倍了。这种可视化结果有助于激励所有人都去不断改进流程。

  

• 为什么不使用故事点（功能权重）

  在进行速率度量时，是否存在问题：衡量速率的时候不应该考虑功能的大小吗？

  理论上来说，需要。不过，实践上来说，功能大小的分布其实相当均匀。我做过一个小实验， 根据预估的大小给每个功能分配一个权重，所以小=1公斤，中=2公斤，大=3公斤。多数敏捷团队会将其称为故事点，即开发一个功能所需时间的相对预估值。

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

2）周期时间（每个功能的开发时间）

我们衡量的另外一个标准是周期时间（Cycle Time，或生产周期）。周期时间是指完成一项工作所需的时间，或在我们项目中更具体的是指，X功能卡从“下十个功能”栏移到“可供验收测试”栏需要多长时间。

周期时间也很容易衡量。每次选好一张功能卡放入“下十个功能”栏，我们就在卡上记录下开始日期。每次一张功能卡到了“可供验收测试”栏，我们就记下完成日期。

• 为什么不全程衡量周期时间，直到产品上线？

  我们计算周期时间只截至“可供验收测试”阶段，因为这部分流程处于我们的控制范围内（因而可以优化）。而且，根据以往的经验，验收测试阶段很少会发现严重问题。所以，通过衡量截至“可供验收测试”阶段的周期时间，我们其实已经覆盖了工作流中最具风险的部分，这对我们就已经足够了。

• 周期时间的度量 & 设置度量目标

  如果一项功能实际开发时间是三天，那么按日历计算，总共就需要20天左右。造成这种差异的原因通常包括：多项任务同时进行、缓冲冗余以及功能卡排队等候进入流程下一步等等。

  我们还注意到一个很有意思的现象，即功能的大小与周期时间没有相关性。

  

  有些小功能用了大概七周的时间，而有些大的功能也才用了两周时间。事实表明，功能大小并不是影响周期时间的主要因素，其他因素，如专注程度以及是否有骨干人员可用，则更为重要。

  我们仔细审视了这个数据，并设定了几项有挑战性但切合实际的目标，以便引导改进工作：

  1. 稳定速率：每周的速率应大致相同，而不是分布不均。
  2. 提高速率：我们目前的平均速率是3，目标为5。
  3. 缩短周期时间：我们的平均周期时间是6周（不过缩短得很快），目标为2周。

  假设我们实现了前两个目标，达到了每周5个功能的稳定速率，这对第三个目标缩短周期时间会有什么意义？

  

  我们如何将周期时间从六周缩短到两周？答案是，要么将速率提高三倍（增加时间和人力），要么将在制品数量除以3。

  减少在制品数量时，需要考虑到的一点是，如果减得过多，就可能出现其他副作用，比如大量人员空闲下来。这又会对速率产生负面影响，从而又增加了周期时间。所以，我们得找到一个平衡点。

  有了度量，就可以表明我们的前进方向正确无误，这一点很重要（度量分析对流程改进起到支持作用）。

3）累积流量

看板的一大优势在于可以实时显示瓶颈位置，不过显示不了历史趋势。

累计流量图是看板圈内用来形象化展示历史瓶颈的常用工具。每天数一数每一栏中都有多少项，然后用下图这样的累计流量图显示出来：

从下面这幅图中很难得出什么有用的结论。即使得出了结论，也有可能是错误的。例如，时间轴的中段好像显示了我们的工作突然大量减少，但实际上是因为我们决定不再将技术故事统计在内（开发团队才有，需求清单里没有）。有些情况下，一些功能卡被我们移放到看板边缘，因为这些功能的开发工作暂停了，所以每天统计看板故事卡的人员就未将其统计在内。

不过，我们仍然在尽职尽责地收集这一数据，主要是因为我总听到其他教练和精益人士在说累计流量图非常有用。每天收集数据只需要花几分钟时间，所以何乐不为？

4）流程周期速率

流程周期效率具有如下意义：

经过时间（Elapsed Time）是指一项功能从项目进度看板的左边抵达右边所需的时间（=周期时间）。

接触时间（Touch Time）是指实际开发测试（或“接触”）一项功能所用的时间。换句话说，就是该功能卡处于在制品栏的总天数，而不是处于排队栏/缓冲池栏的时间。

这会给我们一些很有意思的数据，比如会发现：“嗨，X功能的开发测试只用了两天时间，但却在项目看板上待了20天才下来！流程周期效率只有10%啊！”。大多数公司都在10%–15%的范围内。

13、Sprint与版本发布规划（可供开发，下十个功能）

Sprint规划会议的目的是确定哪些功能要进入“下十个功能”栏。

会议内容分两部分： 梳理需求清单与挑选前十个功能。

1）需求清单梳理（可供开发）

需求清单梳理就是挑选可以转入**“可供开发”状态的功能卡，这是Sprint规划会议前半部分的内容（需求团队相当于Scrum模式下的产品负责人**）。

我们分成几个跨职能小组，通常每个小组各有一位需求分析师、一位开发人员和一位测试人员。每个小组拿几张功能卡，用规划扑克进行估算。在功能卡上写下小、中或大。如果某张功能卡是“大”，则做进一步细分，或决定暂时将其排除在“下十个功能”范围之
外。他们还会讨论出适当的验收测试方案，并写在卡片背面。

• 问题：为何将需求清单梳理工作移出Sprint规划会议？

  几次Sprint规划会议后，我们注意到梳理需求清单非常耗时，导致Sprint规划会议总是匆忙结束。

  于是，我们最近开始单独进行需求清单的梳理，然后再开Sprint规划会议。通常在Sprint规划会议之前的几天，需求分析团队的一位分析师会与一位开发人员及一位测试人员就接下来的某项功能进行一次非正式的讨论。然后就会对该项功能进行细分、估算，并制定验收测试方案。

2）挑选前十个功能

现在我们手上有一堆功能卡，需要讨论哪些功能应当进入项目看板的“下十个功能”栏（更重要的是，哪些不能进入该栏）。

影响这一决定的因素如下：

• 商业价值——客户最乐于看到的功能有哪些？
• 知识——哪些功能会产生知识（因此会降低风险）？
• 资源利用——我们需要平衡功能领域，这样才能让所有团队都有事做。
• 依赖关系——哪些功能最好组合在一起开发？
• 可测试性——哪些功能放在一起测试最合理，因而需要同期开发？

3）规划版本的发布

我们很清楚自己的速率：以前平均每周完成三个功能，现在则可以完成四到五个。这个数据对长期的版本发布规划非常有用。

存在问题：

但问题是，对于长期规划而言，我们并不一定知道功能总数是多少。我们有的只是一堆模糊的创意。我们可以暂且将其称为综述（epic）或功能领域（feature area）。

前面在使用速率进行流程度量时，并不按故事点来估算功能的大小，因为实践表明功能大小的分布其实相当均匀。但对长期规划而言，我们看的主要是综述，而非具体功能。

解决方案：估算综述（创意）的功能数

单独讨论每个综述并估算应将其划分为多少个功能，需要需求分析师、开发人员和测试人员都投入一定的时间和精力。估算过程类似于估算故事点，不过我们讨论的问题是“这一综述有多少个功能”。

一旦估算好每个综述的具体功能数，我们就可以统计功能总数，然后按照过去每周三至五个功能的速率进行划分。

经验和教训：

我们付出高昂代价换来的一大经验教训就是，如果没有给力的版本控制系统，要在多团队项目中做好版本发布规划几乎不可能。

14、做好版本控制（主干，开发分支，系统测试分支管理）

在团队从30人扩展到60人前，我们就应当先将版本控制系统搞定。很长一段时间以来，我们的版本控制系统都有严重问题，主干与分支都是断裂的。实际上，我们曾有一段时间甚至单独设置了一块看板，专门追踪主干上的所有问题！

这里通过主线模型来保持主干稳定，方法如下：

1）主干无垃圾（监控主干，检入立即版本编译测试）

从主干的角度而言，产品以谨慎的步骤逐渐递增的同时，主干始终稳定至关重要。在我们的项目中，稳定就意味着可以持续进行系统测试（随时可供系统测试）。

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

人为错误在所难免，我们也会犯错，也会检入破坏主干的代码。不过没关系，只要错误能被及时发现并得到修复（或回滚）即可。我们的持续集成系统始终监视着主干，任何时候检入了代码都会立即进行版本编译和测试。

2）团队分支（检入到主干/检出到分支）

每个团队都有自己的团队分支，这样他们可以在开发期间检入并共用代码（有些团队有几种不同类型的团队分支）。团队分支的政策比主干宽松得多。代码必须编译，所有单元测试都必须通过，但功能不一定非要完成或测过。采用团队分支的目的是向开发人员提供一个检入未完成代码的地方。

基本上，变更连续不断“向下”检出（checkout）（从主干到团队分支，再到工作站），而“向上”检入（从工作站到团队分支，再到主干）则在固定的点进行。

每天早晨，团队主管将主干上的所有变更与团队分支合并，立即处理所有合并冲突。同样，每位开发人员也要每天将团队分支上的所有变更与他们各自的工作站合并。
只要开发人员认为自己的代码已经很稳定（即，代码已编译，单元测试已通过），就可以将代码检入团队分支，与团队其他成员共享。

只要团队认为他们已经完成一个功能，可以采取下列行动：

• 检出主干代码并与团队分支合并（以防万一当天有其他团队已更新过主干代码）；
• 最后一次检查代码，确保团队分支代码已经稳定（即可供系统测试）；
• 将团队分支合并到主干。

Note：未合并分支（或分散代码）是一种技术债。

3）系统测试分支（在主干的基础上创建，只进行Bug修复）

系统测试或多或少都是持续进行的（而不是只在版本发布周期末期进行）。既然系统测试是测试不同功能组合成整体后的运行情况，我们就需要一个稳定的系统版本来运行测试。也就是说，除Bug修复外，我们不希望在进行系统测试期间添加和更新任何功能。

因此，我们可以在主干基础上创建一个系统测试分支。因为主干始终处于可随时开始系统测试的状态。

一旦创建好系统测试分支，我们就将该版本部署到系统测试环境中，并开始运行系统测试。所有功能在合并到主干之前就已运行过自动化回归测试脚本，所以在系统测试期间，我们主要做手动情景测试和探索性测试，捕捉较小的Bug。

这个用来测试的系统版本不受主干上任何变更的影响（该分支在修复Bug时不用从主干上更新代码），就等于为测试人员提供了一个稳定的测试版本（系统测试分支）。

如果系统测试发现了Bug，开发人员就直接在系统测试分支上修复Bug，然后直接将修复合并到主干上。这样，Bug修复能够快速到达所有团队分支上。

• 在进行系统测试时，开发团队需要做什么？

  系统测试需要数天才能完成，有时甚至需要数周时间。在此期间，还有团队在往主干上添加新的功能。所以，我们会在主干的最新版本基础上创建一个新的系统测试分支，将其部署到系统测试环境中，然后运行一系列新的系统测试。

  

  这种工作方式确保我们始终都有一个可以交付验收测试的稳定版本。

  我们并不是每次都运行所有的系统测试。有时会选择一组子测试，具体取决于系统修改了哪些部分，以及我们离版本发布日期还有多长时间。

  版本控制系统是多团队开发项目的真正核心。

  要搞清楚从改动一行代码到上线使用需要花多长时间，这可能是项目中最最重要的度量指标！

15、为何我们只用真实看板（可演变，可线下协作）

提出的问题：

多数电子工具都能自动生成各种详细的统计数据、进行备份，还可以远程访问、生成不同的视图，等等。既然有那么多新颖灵活的电子工具可以选择，为什么我们还要使用传统、笨重、凌乱的真实看板呢？

1）真实看板可以演变

我们的看板版面结构变更过多次，用了两三个月的时间才稳定下来。版面稳定下来以后，我们才开始用黑色胶带来分栏——之前都是手工画分割线，因为变化太频繁

2）真实看板可用于线下组会协作（改善组织企业文化）

如果没有真实看板，“每日鸡尾酒会”就很难进行。

如果采用电子看板，我们可以用投影仪将看板投影到墙上。但这样就会缺乏互动，即大家无法从墙上拿下卡片边讲边示意，无法在卡片上写下文字，也不能在立会期间将卡片移来移去。大家可能要坐到自己座位上以后才会更新看板——这样虽然便利，却没有多少协作性。

真实看板有助于**改变一个组织的企业文化：**能够看到互动模式的变化，以及团队之间的信任是如何通过每天在看板前的协作而提升的。

3）电子看板适合线上协作（pingCode）

在我自己的公司Crisp中，我们需要用看板来追踪咨询项目和销售线索。我们很少能聚在一个办公室内，所以真实看板行不通。我们需要电子形式的看板，但又不想牺牲“墙”的灵活性。

谷歌绘图（Google Drawing）是非常棒的解决方案（现在2022年很少人用了，可以使用pingcode，创建kanban项目 ）！它是在云上的，所以人人都能够同时看到并更新看板，以及跟踪进度。

如果都在同一处办公，我们肯定会用真实看板。不过，对于分布式组织来说，谷歌绘图（等电子看板工具）是我们目前所能找到的最接近“墙”的工具。

4）其他电子工具（Bug跟踪，版本发布规划）

我们的确采用了几个电子跟踪系统，作为真实看板的补充，比如Bug跟踪系统和用来做版本发布规划的各种电子表格。不过项目进度看板是“总看板”。我们一致同意要保证项目看板反映真实情况，并保持实时更新。所含信息与项目看板内容相同的任何其他电子文档都被我们视为看板的“影子”——如果有信息不同步的情况，始终以看板为准。

我们也曾讨论过引入电子工具来复制项目看板上的概要信息。这样我们就可以将部分度量自动化，并制作一个高层概要电子看板，让位于其他地方的管理高层和相关人员都能够看到。保持电子看板和真实看板信息同步可能需要花费一些精力，但可能很值得。这个电子看板跟其他电子工具一样，会成为真实看板的补充，但不是替代它。

16、经验教训（从上面的案例，即组织变革出发）

此案例的真正主题是组织变革！下面是从变革推动者角度总结出的几个关键要点

• 了解目标（“完善”是方向，目标不一定可行）

  把所有人都召集到一起，让大家就“完善”的定义达成共识。

  “完善”的流程、组织和工作环境应当是什么样的？这将成为指示你所在组织变革方
  向的指南针，因此目标不一定非要切实可行。

  完善是方向，而不是终点！拥有了明确的方向，再专心评估改进工作就会容易得多。

• 不断实验（流程演变，而非完美设计）

  不要试图寻找完美的解决方案。可能压根儿就没有所谓的完美解决方案

  正确的做法是，寻找微小的渐进式改进机会，并将其视作实验机会。实验有可能实现预期改进，也有可能不会实现，但能让我们从中积累经验教训，然后用于设计新的实验。

  伟大的流程不是设计出来的，而是逐渐演变出来的。所以，重要的不是流程，而是我们用来改进流程的流程。

• 拥抱失败（从失败中学到什么？下一次做怎样尝试？）

  有些变革行不通，有些变革甚至会把工作搞得更糟。不必为此担心，因为失败不可避免。担心失败则是创新的最大敌人。我们应当反思的是“我们学到了什么？下次应当做出什么尝试？”，而不是“我们怎么会失败？是谁把事情搞砸了？”

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

• 解决真正的问题（什么问题，是否真实存在，是否有更重要的问题）

  无论何时尝试作出变革时，都要不断问自己：“我在解决什么问题？这个问题是真实存在的还是假设的？还有没有其他我应当先解决的更重要的问题？

  如果不能确定，就要询问别人！我们一不小心就会去钻研些无关问题或假设问题。

• 拥有专职变革推动者（内部，外部人士则更理想）

  变革很难，涉及人事的变革更是难上加难，而组织变革总是会涉及人事。一个关键的成功要素是，至少应拥有一名专职的变革推动者，完全专注于推动、领导和协调变革过程。

  如果有两位专门的变革推动者则更为理想：一位内部人士，一位外部人士。

  • 内部人士（通常是员工）拥有特定领域知识，知道什么工作应该找谁，他了解组织的历史以及以往的成功做法。
  • 外部人士（通常是咨询专家）则可以提供全新的视角，他拥有帮助其他公司完成类似变革的成功经验。

  文化可以定义为“所有人都遵循但却不会注意到的做法”，内部人员容易“不识庐山真面目”，而外部人士则更有可能注意到现状并提出质疑。

• 让人们参与进来（可视化问题，让大家认识问题的存在，而不是强迫改变）

  多数人都喜见变革，他们只是不喜欢被别人改变。所以，在做任何改变之前，首先必须让有可能会受到影响的人参与进来。强迫人们去改变通常都不会见效，最终只是多此一举，而且让人很痛苦。如果人们抵制你伟大的变革提议，那就有可能是你没把问题说清楚，要么就是你没找出真正的问题。

  更好的做法是，先不要自己作出变革提议！而是将你看到的问题用可视化方式呈现出来，让那些相关的人们参与进来，提出他们自己的解决方案。如果是大家自己提出来的意见，人们就会更容易接受变革！一旦所有人都认识到问题真的是问题，而且需要解决的时候，你就已经事半功倍了！

二、技术详解

1、敏捷和精益概述

广义而言，精益与敏捷是两组具有高度兼容性的价值观和原则（共同价值观，但起源不同，前者源于制造业，后者源于软件开发），都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说，它们是精益和敏捷软件开发里轻度重叠的三种不同风格。

Scrum、XP和看板都有很具体的技术，如Sprint规划会议（Scrum）、结对编程（XP）和限定在制品（看板）。这些技术都可视作流程工具。
这三种工具的功能都有相当程度的重叠，例如，三种工具都建议使用真实的任务板将当前工作以可视化方式展现出来。

1）敏捷概述（价值观 和 原则）

术语敏捷软件开发（Agile Software Development）出现于2001年。当时，来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地，探讨软件开发如何取得成功。此前，他们都各自创立了不同的新方法，如Scrum、XP和动态系统开发方法（DSDM）。研讨会期间，他们总结出一些强大的共同观点，形成了软件开发如何成功的共有愿景，即后来人们熟知的《敏捷宣言》 。内容如下：

我们正在通过亲身实践以及帮助他人实践，探寻更好的软件开发方
法。通过这项工作，我们建立了如下价值观：

• 个体和互动胜过流程和工具
• 可以工作的软件胜过详尽的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

也就是说，虽然右项也具有其价值，但我们认为左项具有更大的价值。

研讨会结束后，他们就支撑这些价值观的以下十二条原则达成共识：

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，要通过敏捷过程掌控变化。
• 经常地交付可工作的软件，比如相隔几星期或一两个月就交付，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自于自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。

《敏捷宣言》是一份呼吁变革的历史文档。宣言中的文字在全球成千上万人心中引起深刻共鸣，引发了软件开发革命。十年后，所有作者（其中一位除外）再次聚集在相同地点，重申他们依旧支持敏捷价值观和原则。因此，尽管软件行业发生了翻天覆地的变化，《敏捷宣言》却经历住了时间的考验。

2）精益概述（精益原则）

精益起源于日本丰田公司的“TPS”（丰田生产方式），即助力丰田成为全球最成功汽车制造商的生产方式。实践证明，TPS的基本原则“丰田之道”几乎适用于所有行业，包括软件开发。

敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业，敏捷起源于软件开发。

越来越多的软件开发组织在探索如何将两组原则完美结合，从而应用于从产品创意到交付的完整开发链。
帕彭迪克夫妇在将精益原则与软件开发结合方面做出了卓越贡献，以下是他们精炼出的精益原则。

1. 全局优化：局部的优化长期来说，会对系统整体优化不利。

• 专注于整体价值流：从概念到现金。从客户需求到软件部署。
• 交付完整产品：客户不要软件产品，他们要解决问题（完整团队提供解决方案）。
• 着眼长期：警惕导致短期思维和优化局部业绩的治理和激励体系。

2. 消灭浪费：浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下：

• 构建错误的功能。
• 拒绝学习：我们有很多策略都干扰了我们学习，例如，只按计划行事、频繁移交、决策与工作分离等，而学习则是开发的精髓。
• 辗转现象：那些干扰价值顺利流动的做法，例如，任务切换、请求清单冗长、大堆未完成的工作等等，都只能达到事倍功半的效果。

3. 品质为先：如果在验证过程中总是能发现缺陷，那流程就有问题。

• 最终验证不应发现缺陷。
• 采用测试先行的开发模式让流程具有防误机制：测试（包括单元测试、端对端测试和集成测试）必不可少。
• 打破依赖：系统架构应当支持随时添加功能。

4. 不断学习：规划工作非常有用。学习则必不可少。

• 可预测的性能来自于反馈：可预测的组织不会猜测未来并称之为计划；反之，他们会培养能力对未来做出响应。
• 保持选择方案：视代码为实验——使其具有容变性。
• 最后可靠时刻：在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策，也不要事后才做出决定！

5. 尽快交付：

• 快速交付、高质量和低成本是完全相互兼容的：以速度竞争见长的公司拥有很高的成本优势，他们可以交付优质的产品。
• 排队理论同样适用于开发，而不仅仅是服务行业：以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
• 管理工作流比管理进度表要容易得多：建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。

6. 人人参与：聪明、有创造力的人员的时间与精力，是当代经济的稀有资源和竞争优势的基础。

• 自主性：最有效的工作小组是半自治团队，有一个内部主管从头到尾负责完整、有意义的任务。
• 成长性： 对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
• 使命感：将工作与价值挂钩。只有相信自己工作的意义，团队成员才会全心投入工作，实现这种使命。

7. 不断提高：结果不是重点——重点是培养人、发展体制，使之能够交付结果。

• 失败是个学习机会：即使是非常小的失败都会被深入调查并纠正的，做到一丝不苟的时候，才可能获得最可靠的性能。
• 标准存在的目的就是要被质疑和提高的：将现行的、最知名的做法纳入人人都遵循的标准，与此同时鼓励所有人质疑并改变标准。
• 使用科学方法：教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

3）Scrum概述（专注于结构问题和外部沟通）

Scrum是由杰夫•萨瑟兰（Jeff Sutherland）和肯•施瓦伯（KenSchwaber）于20世纪90年代早期共同创建的一种软件开发过程。Scrum根植于经验过程控制和复杂自适应系统理论。

• Scrum的核心概念

  • 按优先顺序排列的产品需求清单

    将产品分割成一组小而具体的可交付物，即产品需求清单。产品负责人对产品愿景进行定义，并按商业价值以及风险和依赖关系等其他因素对需求清单进行排序。

    

  • 跨职能团队

    将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。每个团队都有一位产品负责人负责定义愿景和总体的业务优先顺序，以及一位Scrum大师专注于改进团队、消除障碍。

    

  • Sprint（规划会，一个迭代周期，持续集成）

    将整个开发时间划分成多个短小的、固定的迭代周期或Sprint（通常为
    两周或三周）。开发团队自行决定每个迭代周期要完成多少个产品需求
    清单项。每个迭代周期最后都要演示已通过测试、能够发布的版本。

    

  • 持续调整版本发布计划（产品负责人和客户合作）

    产品负责人与客户一起合作，在每个迭代周期之后仔细检查发布版本，
    根据所得的结果，不断优化版本发布计划，并更新优先排序。

  • 持续调整流程（回顾会）

    开发团队通过每个迭代周期之后的回顾会议不断优化开发流程。

    所以，Scrum开发模式意味着：
    不是由一个大团队用很长的时间来开发一个大产品……
    ……而是由一个小团队用很短的时间来开发一个小功能。

    但定期集成，以构成整体。

  在实践中，不纳入XP的核心工程实践而通过Scrum模式取得成功是非常困难的。

4）XP概述（专注于团队内部的工程实践）

极限编程（XP）是肯特•贝克（Kent Beck）于20世纪90年代中期创立的软件开发方法。该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的，实际上包含了大多数相同要素。例如，XP中的现场客户（on-site customer）就大致等同于Scrum中的产品负责人（product owner）。

Scrum可被视作XP的“包装纸”，专注于结构问题和外部沟通。

XP除多数理念都与Scrum相同以外，还增加了一些团队内部的工程实践，包括以下内容：

• 持续集成：拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
• 结对编程：在一台工作站上进行结对编程（一个写代码，一个审查代码），从而使学习效果最大化、设计质量最大化、缺陷最小化。
• 测试驱动开发：采用测试代码驱动系统的设计。编写自动化测试脚本，然后编写刚刚足够的代码以使其通过测试，接着从根本上重构代码，提高其可读性，移除重复代码。清理并重复这一过程。
• 集体代码所有权：允许（实际上是鼓励）开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识，确保整个系统的设计都一致、易于理解。
• 增量式设计改进：从最简单的设计开始，然后运用重构等技术持续不断地改进设计，而不是从一开始就做好完整的设计。

上述许多实践都互为基础：

例如，如果系统的自动化测试覆盖范围不足，那增量式设计改进就很难实现、令人生畏且风险很高，

而若要测试覆盖范围足够，则需要通过测试驱动开发和结对编程才可实现。不过，如果所有的测试都必须手动触发，而且只能在开发人员的本地工作站上运行，问题就会让人更头痛，所以，我们就需要一个持续集成系统在后台自动完成上述工作，等等。

5）看板概述（专注于工作流的可视化）

看板是敏捷软件开发的精益方法。

实际上，看板有着多方面的意义。从字面上看，看板是日语单词，是“可视卡片”（或标志）的意思。

大卫•安德森（David Anderson）于2004年率先提出了软件开发的精益思维实施方法和约束理论 。在唐•赖纳特森（Don Reinertsen）等专家的指导下，演变成为大卫所称的“软件开发看板系统”，现在人们都将其简称为“看板”。

虽然看板应用于软件开发还相当新颖，在精益生产中却已有半个多世纪的历史了。

看板的规则很简单。不过，跟象棋一样，规则简单并不意味着游戏简单。

• 看板的作用

  1. 可视化工作流：

  • 把产品切分成小块，将每一块写在一张卡片上，然后将卡片贴到墙上。
  • 墙上的每一栏都有名称，以此显示每张卡片在工作流中所处的位置。

  2. 限定在制品（WIP）：针对工作流的每个状态，明确限定正在进行中的工作项数量。
  3. 衡量并管理周期时间：完成一个工作项的平均时间。优化流程，让周期时间尽可能短、尽可能可预测。

  

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

• 看板管理小案例

  从上到下简单反映了看板中功能卡片的流向和阻塞情况（工作流可视化，对瓶颈问题管理）

  

  

  

  

  

  系统测试遇到瓶颈了，限定在制品数额为2，不能对功能卡D进行开发

  

  完成对功能卡C的开发之后，协助测试人员实现系统测试，部署等

  

  

2、缩减测试自动化需求清单（偿还测试自动化债务）

很多有遗留代码库的公司在转向敏捷的时候都遇到一大障碍：测试未实现自动化！

测试未实现自动化的情况下，要在系统中做出改动就会非常困难，因为一旦发生问题，也不会有人注意到。等到新版本正式上线，真正的用户发现缺陷时，局面就会非常尴尬，而且修复起来代价高昂——更糟的结果是导致一系列修复，因为每次修复都会引入让人预料不到的新缺陷。

这就让开发团队非常害怕改动代码，因此就不情愿改进代码设计。于是，随着开发工作的推进，代码质量呈螺旋形下降。

1）4种解决方法

方法1：忽略问题。让产品衰败而亡；

方法2：采用测试驱动开发模式，从零开始重新构建系统，保证测试覆盖率达标。

方法3：单独启动一个测试自动化项目，由专门的团队提高产品的测试覆盖率，直到达标。

方法4：让团队在每个迭代周期都逐渐提高测试覆盖率。

Note：第三个方法存在风险，谁来具体实施测试自动化？单独的团队吗？如果是这样，是否就意味着其他开发人员不需要了解如何运行自动化测试？他们什么时候做完？什么时候才算测试自动化“结束”？

2）在每个迭代周期提高测试覆盖率（第4种解决方案）

• 列出测试用例

  用头脑风暴的方式列出最重要的测试用例，下面是一个假设的在线银行系统示例：

  

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

  首先，按风险大小划分测试用例。目前暂时忽略手动测试成本。如果丢弃其中一半的测试，您会保留哪些测试？这个因素要综合考虑失败的可能性和失败的成本。

  标出风险高的测试：

  

  手动执行测试的话，每一项测试都需要多长时间。哪一半的测试花费的时间最长？把这些测试标记出来。

  

  估算一下每一项测试编写自动化脚本的工作量。标出工作量最高的那一半。

  

  手动测试成本在每次运行测试的时候都会发生，而自动化成本则是一次性的。所以，编写测试自动化脚本实际上是投资，而不是成本。

• 按优先顺序对列表进行排序

  关于哪些测试应当先予以自动化，基本上你需要做的决定有以下三个：

  • 风险高但手动测试容易的测试，或者风险低但手动测试难度大的测试。
  • 易于手动测试且易于自动化的测试，或者手动测试难度大且自动化难度也大的测试。
  • 风险高且难以自动化的测试，或者风险低且易于自动化的测试。

  做好这些决定就可以按优先顺序排列测试用例。在这个银行示例中，我决定首先对手动测试成本进行优先排序，然后是风险，再然后是自动化成本。下面就是我排好序的测试自动化故事需求清单（从上至下，优先级递减）：

  

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

  不论是否有测试自动化需求清单，每个新功能都应包括功能级别的自动化测试。这是XP的实践，称为客户验收测试。如果不做功能级别的自动化测试，一开始就会让产品陷入一团乱麻。

  不过，除了实施新故事外，我们需要花点时间将以前故事的老测试用例自动化。那需要花多长时间呢？开发团队需要与产品负责人具体协商。

  • 可行的建议或共识

    例如，我们可以同意让团队将80%的时间花在开发产品需求清单列举的新功能上，然后把20%的时间花在测试自动化需求清单上。那么，在每次的迭代规划会议上，团队就需要同时从两个需求清单中拉入故事卡。

    

    再比如，我们还可以达成以下一些共识。

    • 每个迭代周期都要实施一个测试自动化故事。
    • 每个迭代周期都会实施若干测试自动化故事，故事点总和不超过10。
    • 每个迭代周期都会先完成产品需求清单的故事，然后若有剩余的时间，再来实施测试自动化故事。
    • 产品负责人会将测试自动化故事合并到总体的产品需求清单中，开发团队会对所有故事一视同仁。

    重点是测试自动化债务得以一步一步逐渐偿还。
    等到测试自动化需求清单上的一半故事完成后，我们基本上可以跳过其余的老测试用例。

3、用规划扑克估算需求清单大小（每个成员都有解释的机会）

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

• 未使用规划扑克之前存在的问题（成员想法容易受某个成员提议的影响）

  假设我们在Sprint规划会议上，产品负责人让所有团队成员思考某个功能的大小，A先生认为自己非常清楚实现这项功能都需要做什么工作，而且没多少工作要做。B女士和C女士则比较悲观。D先生和E先生在偷懒。

  

  当产品负责人询问团队其余成员的意见时，因为A先生最先说出来，就严重影响了团队其余成员的判断。B女士和C女士或许认为工作量应当是中或大，我们就没有机会听到她们的解释，而这恰恰有可能是很有价值的信息！

  

• 用规划扑克进行估算（5张卡牌）

  我们的规划扑克实际上用的是数字：

  • 1代表小，2代表中，3代表大。
  • 问号牌表示：“我完全没概念。这项功能可能很大，也可能很小。”
  • 咖啡杯牌表示：“太累了，脑子卡住啦。我们休息一下吧！”

  

  Note：如果问号卡用得很频繁，团队就需要再好好讨论一下这项功能，让团队成员多了解一些信息。

  还是假设我们在Sprint规划会议上，产品负责人让所有团队成员思考某个功能的大小，等他们出完牌后，所有牌要同时翻开，显示每个人的估算结果。

  

  分歧好大。团队成员，尤其是A先生和C女士，需要讨论一下这项功能，为什么他们的估算结果会有很大分歧。经过讨论，A先生意识到他忘记这项功能还需要完成一些很重要的任务。C女士则意识到按照A先生的设计，这项功能可能没那么大。

  Q：只要估算出现较大分歧，就平均估成中不可以吗？

  A：不可以，如果团队讨论了分歧原因，然后在此基础上重新开始一轮估算的时候就不可以。某位成员可能会说服其他成员某项功能应该为小，因为该功能已经在另外一个系统上实现，可以直接重用。或者反之，有位成员说服了团队其他成员某项功能应该为大，因为存在一些大家都没有考虑到的风险。