敏捷项目管理实战之质量管理.doc

1、敏捷项目管理实战之质量管理Abstract:本文以笔者的项 目管理实践为基础，介绍基于经验过程控制（Empirical Process Control）模型、缺陷预防以及敏捷价值观的敏捷质量管理思想及其实践。希望通过本文为广大项目管理人员提供质量管理的一些思路和经验分享。（本文如有更新，请见：http:/blog.viscenthuang.info。本文最初由本人发表在IBM developerWorks中文网站上，其网址是http:/ 进 一步介绍经验过程控制之前，我 们先看一个日常生活中应用经验过程控制的一个例子：在菜肴的烹饪过程中，人们往往先观察菜肴的颜色，或者用筷子检查其软硬度来判断菜

2、肴是否已 经煮熟。若不够熟，则继续煮。待到菜肴快熟时，我们开始放盐、味精之类的调 料。然后 尝尝菜肴的咸淡是否适中，若太淡了则继续加盐，直到我们满意为止。经过这样一个过 程，烹 饪者满意的一道菜肴才能完成。上述例子正好体现了经验过程控制的三大支柱透明性（Transparency ）、检查（Inspection ）、适应（Adaption）。透明性指影响最终产出结果的因素对于过程控制者来说可观察或者使其可观察。透明性在上述例子中表 现为：菜肴煮熟程度是影响菜肴质量的一个因素，而这 个因素可以通过菜肴的颜色或其硬度反映出来。检查指对影响最终产出的因素进行观察和评价的动作。上述例子中提到的 观 察菜

3、肴的颜色、 尝尝菜肴的咸淡就是检查。适应指检查过程中发现 不可接受的结果、偏差 时所采取的 矫正动作。上述例子提及的在发现菜肴味道偏淡的情况下采取的继续加盐的动作就是适应。从经验过程控制的三大支柱我们可以看到其问题驱动的性质。问题驱动是指在过程实施时所进行的活动是基于有哪些因素影响了最终产出的结果，而不是像一些传统的过程控制实施者是从一些预定义的活动集合中剪裁一些活动。从一个活 动 集合中剪裁出一些活动， 这本身就要求剪裁者对这个活动集合中的每个活动足够了解，从而能 够选择 适合自己的活动。 这个剪裁的过程使得这些传统的过程控制实施起来相对困难，而 经验过程控制因 为省却了剪裁的过程而使得其实

4、施相对容易。基于经验过程控制的质量管理其实施的基本思路是先通过经验或者对质量问题进行根因分析（Root Cause Analysis）发现影响质量的因素，再采取措施使 这些因素成 为可观察的因素（对应经验过程的透明性）。然后，在项目实施过程中对这些因素进行检查（对应经验过程控制的检查）。检查过程中发现不可接受的结果或者偏差时及时采取措施进行矫正以防止缺陷的引入或者缺陷流入下一道工序中（对应经验过程控制的适应），从而保 证了最 终产出的质量。缺陷预防孙子兵法谋攻中提到“百战百胜非善之善者，不战而屈人兵，善之善者”。每次打仗都取胜不是战争的最高境界，战争的最高境界是不 费兵卒而取得胜利。同样，在软

5、件开发过程中，找出所有缺陷并将其一一去除不是质量管理的最高境界。 质量管理的最高境界是将缺陷扼 杀在摇篮之中缺陷预防。经验过程控制三大支柱所体 现的其问题驱动的特性 说明了它可以帮助我们去实施缺陷预防。基于经验过程控制的缺陷 预防是通过使缺陷来源成 为可观察的因素，然后在 软件开发过程中对这些因素进行检查，发现 不可接受的偏差时及时采取措施 进行矫正，从而避免了缺陷的引入。比如，当我们发现开发人员对需求理解的错误、不全面是缺陷的一个重要来源 时，我们就可以应用经验过程控制的思想，先采取措施使开发人员对需求的理解成 为可观察的因素。然后 对其进行检查，若发现有需求理解上的偏差，则进行矫正，从而避

6、免了因需求理解偏差而引入缺陷。诚然，软件测试的目的是发现 缺陷。也正因此大多数公司和个人也就把测试人员定位成缺陷的发现者。然而，测试毕竟是一种事后控制型的质量管理手段，这不是上上策。能否往测试人员这个角色的职责的定义中增加一个缺陷预防的职能呢？笔者曾经在所带团队中引导测试人员往缺陷预防方面发展，在这方面多做 贡献，而不是 仅仅把自己定位 为缺陷的发现者。在开发测试一体化团队中，测试人员同开发人员 一起参与需求分析、 评审。项目经理可以通过一些奖励措施鼓励测试人员多去发现需求本身的错误以及开发人员对需求理解的偏差，从而避免了需求相关的缺陷。另一方面，测试人员往往习惯 于从发现缺陷中获得成就感。在

7、引导测试人员在缺陷预防上多做贡献的过程中，项目经理需要引 导测试人员使其认识到预防缺陷比 发现缺陷更加能够体现一个人的能力和价值。需求澄清需求规格说明书本身的错误、不明确是 软件缺陷的一个重要来源。因此，消除需求本身的 问题是缺陷预防的一个重要内容。笔者在所带的项目中是通过开展需求澄清活 动来消除需求本身的问题的。在开发团队内部进行需求 规格说明书评审之后， 评审 意见被汇总成一个列表，这个列表可以是一个Excel表格，我们称之为需求问题确认列表。然后，我们邀请客户过来和开发团队一起对问题列表中的每个问题进行讨论。团队成员负责提出和解 释问题确认列表中的问题，客 户代表则负责解答和澄清团队成员

8、提出的问题。客 户对于问题的回复我 们会记录到问题确认列表的回复一栏。需求澄清活动往往是以 头脑风暴会议的形式展开的，而不仅仅是一个一问一答的过程。对于客户当场给的问题回复，团队成员可能因为通过自己的分析 认为客户的回复是错误或者不合理的而当场对客户代表的回复提出质疑。客 户代表往往也因此 对其回复进行重新思考从而给出与会人员一致认同的回复。敏捷宣言中提到客户协作胜过合同谈判，需求澄清活动的基本前提就是客户代表的参与。因此它是符合敏捷开发的价值观的。表 1. 需求澄清活动管理思想 参与者 输入 输出敏捷价值观指导下的具体实践、缺陷预防思想全体团队成员、客户代表需求规格说明书，需求问题确认列表需

9、求问题确认列表需求宣讲团队成员对需求理解的偏差也是软件缺陷的一个重要来源。我们可以应用经验过程控制的思想对这种因需求理解偏差而引入的缺陷进行预防。其基本思路是先使团队成员对需求的理解成为可观察的因素，然后对这个因素 进行检查。 检查过程中发现 不可接受的偏差时及时采取措施进行纠正，从而避免了缺陷的引入。笔者通过在团队内开展需求宣讲活动来具体实施这个缺陷预防。需求宣讲是在开发人员开始编码、测试人员开始设计测试 用例前，由全体 团队成员参与的一个头脑风暴会议。在这个会议上，开发人员随机选取一个Story，然后口头表述其对所选择的Story的理解。通过这个讲解，开发人员对需求理解就成为了一个可以 观

10、察的因素。当其他与会人从需求讲解人的讲解中发现其对需求理解上的偏差时，可以及 时指出 进行纠正。其他与会人 员也可对其讲解提出疑问和质疑。当讲解人的回复无法得到 团队成员的一致 认同时， 则进行讨论，最终达到对需求理解的一致。而对于讨论 无法达成一致认识的问题，可以记录入需求问题确认列表会后再进行确认。当然，当开发人员被要求讲述其 对需求的理解时，可能会 说 他其实已经理解了需求只是不知道如何表述。且不论这句话是否属 实， 项目经理应当引导团队成 员意识到：在敏捷开发团队中，个人对需求是如何理解的，理解的对 与错，深与浅不是其一个人的事情，而是整个 团队的事情，因为它影响了这个团队最终交付的软

11、件的质量！从另外一个角度来讲，当一个人能清晰得表述一件事物时，才说明其对这件事物是真正理解的。虽然需求评审和需求澄清这两个活动也能一定程度上反映活动参与者对需求的理解，但是它们更多的是用于发现需求本身的问题。而需求宣 讲则是专门 用于检验活动参与者对需求的理解正确性和全面性。表 2. 需求宣讲活动管理思想 参与者 输入 输出经验过程控制、缺陷预防思想全体团队成员 需求规格说明书，需求问题确认列表需求问题确认列表设计会话（Design Session）与简单设计（Simple Design）设计阶段所引入的缺陷不仅包括设计本身的缺陷还包括了因编码人员对设计方案理解的错误和偏差而引入的缺陷。极限编

12、程所 强调的是简单设计虽然一定程度上降低了 设计本身缺陷的概率，并且也有助于降低设计方案理解偏差而引入缺陷的可能性。但是，从经验过程控制和缺陷预防的角度来看，我们仍然需要将编码 人员对设计方案的理解这 一影响质量的因素成为可观察的因素，并对其进行检查。笔者在所带的项目中开展设计会话活动。在 设计会话中，通常由设计人员借助白板讲解设计方案，其他人员对讲解的内容有疑 问和异议时可以提出集体讨论 。主 讲的设计人员也可以针对其讲解提出一些问题让其他参与人回答，以确定参与人是否真正理解 设计方案。 设计会话结束后，白板上的内容可以先保留一段时间，以方便事后再 查看。有条件的团队也可将其拍照存档。设计会

13、话中所讨论的设计方案可以事后由编码人员写入Story文档。由于相关人员事先都参与过设计会话，在Story文档评审时对其中的设计 部分多少也许自己的认识和意见， 这有助于发现对设计方案理解的偏差。设计会话体现了敏捷宣言中提到的个人与交互胜过过程与工具这一价值观，避免了仅仅通过设计规格说明沟通设计方案导致的沟通效率低下、 设计 方案理解偏差的问题，充分 发挥了人与人直接沟通的优势。表3. 设计会话管理思想 参与者 输入 输出经验过程控制、缺陷预防思想、敏捷价值观指导下的具体实践全体团队成员 需求规格说明书，需求问题确认列表设计方案版书单元测试评审单元测试是软件开发中被普遍接受的优秀实践，也是影响软

14、件质量的一个重要方面。有效的、充分的单元测试能够提高代码质量，从而有效避免了返工。但是如何保证单元测试得到有效的执行呢？按照经验过程控制的思想，我 们可以先使单元测试成 为一个可观察的因素，然后 对其进行检查。检查过程中发现偏差时及 时进行纠正从而保证单元测试 得到有效的执行。定义单元测试的产出物可以使单元测试活动成为可观察的因素。对单元测试产出物进行评审可以发现单元测试所覆盖的测试用例是否真正执行通过以及测试用例覆盖是否充分。若单元测试评审过程中发现有测试用例未通过的或者遗漏的， 则及时 反馈给开发人员进行纠正，从而避免了缺陷进入下一道工序Story测试。笔者曾经在一个基于SOA（Servi

15、ce Oriented Architecture）的项目中将单元测试过程中系统所产生的接口日志文件定义为单元测试产出物。在这个项目中，开发人员会将单 元测试过程中每个测试用例 执行时系统所产生的接口日志文件按所覆盖的测试用例的名称进行命名提交到配置库上，然后知会其他项目组成员进行评审。由于 这个单元测试产出物能够反映系统所要实现的功能， 评审人 员可以通过分析产出物判断每个测试用例是否真正执通过以及测试用例是否覆盖充分。 评审者把 评审过程中发现的测试用例未通过或者未覆盖等问题会整理成评审意见提交到配置库上，并知会开发人员进行处理。表4. 单 元测试评审 活动管理思想 参与者 输入 输出经验过

16、程控制 全体团队成员 单元测试例 单元测试产出物面对面代码复审在比较常见的轻型代码复审过程中，开 发人员提交代码到配置 库上，然后代 码复审人员从配置库上获取相应代码并借助一些代码复审工具将复审结果形成意见提交给代码作者进行处理，并跟踪复审意见的处理结果。代码 复审人员往往只在复审过程中有疑 问的情况下才找代码作者进行确认。这种轻型的代码复审复 审表面上执行起来比较容易，成本也比较低。但是它和敏捷宣言中提到的个人与交互胜过过程与工具这一价值观是相违背的。因为它缺乏有效的人与人间的交互。这种缺乏人员间交互的方式也 导致了评审结果最 终呈现给代码作者的往往是问题。 这一方面使得代码作者只是被动得发

17、现问题和解决问题。被 动 得发现和解决问题往往导致当事人对问题及其解决方法印象不深刻从而极易导致相同或者类似问题重复得出现。虽然我们可以将复审过程中典型的问题形成检查表由开发人员在代码提交前对检查表中的项目进行自检，但是这个检查表往往也是在重复的问题被重复得发现后才形成的。另一方面，这种代码复审往往给代码作者一种挑刺的感觉，而作者自 认为代码中比较优雅的部分往往也被人忽略了，因为那不是问题因此复审人员也不会将其指出。 这容易导致开发人员对 代码复审的本能性排斥心理，因 为人总是倾向于被他人肯定，而不是 总是被人指出问题。笔者在所带的项目中开展面对面代码复审。面 对面代码复 审活动中，代 码作者

18、通过电脑显示器或者投影仪向其他参与人展示其代码并逐行对其代码进行讲解。其他参与人则对其讲解进行分析判断，并将其分析判断的结果提出同其他复 审人员进行讨论 。复 审人员发现比较优雅的代码时可以及时指出来，并对代码作者 给予肯定。因此，面对面代码复审某种程度上也是编程经验和优秀实践的一个交流形式。另外，对于经过讨论后确认的问题则记入代码复审意见表由复审人员跟踪其处理结果。代码作者对其代 码讲解的过程某种程度上说 也是其本人对其代码进行回顾和再思考的过程。因此，代码讲解过程中，讲解人往往会自己发现代码中的问题，从而对发现的问题有深刻的印象，这有助于避免同 样或者类似的问题再次产生。另一方面，由于代码

19、中的问题会当众暴露出来，对代码往往有种敝帚自珍心理的开 发人员在代 码复审前会小小谨慎地去检查代码，从而避免当众出丑。因此，面对面的代码复审某种程度上也是一种缺陷预防的措施。表5. 面对面代码复审活动管理思想 参与者 输入 输出敏捷价值观指导下的具体实践代码作者、其他开发人员代码 代码复审意见记录Story演示与转测试控制左传庄公十年提到夫战，勇气也！ 一鼓作气，再而衰，叁而竭。返工不仅增加了成本，阻碍了进度，还影响了士气降低了 质量。返工往往是由于某道工序缺乏它的入口条件控制。比如，Story转测试这道工序如果没有控制其入口条件，则很容易由于事先未评估被转测的Story质量导致在测试时仍然有

20、大量的缺陷存在。 这就意味着在第一次 转测试后，开 发人员需要修复大量的缺陷，并且开发人员在修复缺陷的 过程中往往又引入了新的缺陷，进而导致了对于同一个Story需要进行多次修复缺陷和多次转测试的工序才能使这个Story满足质量要求。因此，对Story 转测试这道工序进行入口控制可以有效避免返工现象。任何一个Story在其转测试前，我们要首先评估其质量是否 满足一定的要求才决定其能否 转测试。笔者在所带项目中通常以Story演示作为Story 的转测试控制。Story演示要求开发人员在Story转测试前召集该Story的测试人员及其他相关人 员对该Story 的各个 验收测试用例的执行情况进行

21、展示。其他参与演示的人员则根据展示的 结果分析各个验收测试 用例是否真正通过， 进而评价所演示的Story的质量水平并决定所演示的 Story能否转测。Story演示过程发现的问题以及疑 问可以记录入Story 演示记录 。Story演示记录样例见表6。表5. Story演示活动管理思想 参与者 输入 输出敏捷价值观指导下的具体实践Story开发人员、Story测试人员Story验收测试用例、Story交付件Story演示记录表6. Story演示记录样例Story名称 参与者 演示日期 问题及疑问 问题处理结果 演示结果XXX Story 张三、李四、王五11年12月10日某按钮点击后页面上报Javascript错误未处理 通过结论经验过程控制模型为敏捷质量管理提供了一个简单易行的理论指导。缺陷预防是质量管理的一个重要思想，而经验过程控制模型可以帮助我 们具体实施缺陷 预防。另外，敏捷宣言所体现的敏捷价值观也为质量管理提供了思想指导。参考资源 What is Scrum：Ken Schwaber在这篇文章中介绍了经验过程控制模型。 敏捷宣言：这里阐明了敏捷开发的核心价值观。 Extreme Programming Explained：Kent Beck著，其中有关于简单设计、设计会话以及敏捷开发中客户参与的内容。