2016年敏捷项目管理实战之质量管理 .docVIP

敏捷项目管理实战之质量管理 Abstract:本文以笔者的项目管理实践为基础，介绍基于经验过程控制（Empirical Process Control）模型、缺陷预防以及敏捷价值观的敏捷质量管理思想及其实践。希望通过本文为广大项目管理人员提供质量管理的一些思路和经验分享。（本文如有更新，请见：。本文最初由本人发表在IBM developerWorks中文网站上，其网址是/developerworks/cn。） 作者：黄文海 经验过程控制 经验过程控制是一种问题驱动的轻型过程控制模型。在进一步介绍经验过程控制之前，我们先看一个日常生活中应用经验过程控制的一个例子：在菜肴的烹饪过程中，人们往往先观察菜肴的颜色，或者用筷子检查其软硬度来判断菜肴是否已经煮熟。若不够熟，则继续煮。待到菜肴快熟时，我们开始放盐、味精之类的调料。然后尝尝菜肴的咸淡是否适中，若太淡了则继续加盐，直到我们满意为止。经过这样一个过程，烹饪者满意的一道菜肴才能完成。 上述例子正好体现了经验过程控制的三大支柱——透明性（Transparency）、检查（Inspection）、适应（Adaption）。透明性指影响最终产出结果的因素对于过程控制者来说可观察或者使其可观察。＂透明性＂在上述例子中表现为：菜肴煮熟程度是影响菜肴质量的一个因素，而这个因素可以通过菜肴的颜色或其硬度反映出来。检查指对影响最终产出的因素进行观察和评价的动作。上述例子中提到的观察菜肴的颜色、尝尝菜肴的咸淡就是＂检查＂。适应指检查过程中发现不可接受的结果、偏差时所采取的矫正动作。上述例子提及的在发现菜肴味道偏淡的情况下采取的继续加盐的动作就是＂适应＂。 从经验过程控制的三大支柱我们可以看到其问题驱动的性质。问题驱动是指在过程实施时所进行的活动是基于有哪些因素影响了最终产出的结果，而不是像一些传统的过程控制实施者是从一些预定义的活动集合中＂剪裁＂一些活动。从一个活动集合中剪裁出一些活动，这本身就要求剪裁者对这个活动集合中的每个活动足够了解，从而能够选择适合自己的活动。这个剪裁的过程使得这些传统的过程控制实施起来相对困难，而经验过程控制因为省却了＂剪裁＂的过程而使得其实施相对容易。 基于经验过程控制的质量管理其实施的基本思路是先通过经验或者对质量问题进行根因分析（ Root Cause Analysis）发现影响质量的因素，再采取措施使这些因素成为可观察的因素（对应经验过程的＂透明性＂）。然后，在项目实施过程中对这些因素进行检查（对应经验过程控制的＂检查＂）。检查过程中发现不可接受的结果或者偏差时及时采取措施进行矫正以防止缺陷的引入或者缺陷流入下一道工序中（对应经验过程控制的＂适应＂），从而保证了最终产出的质量。 缺陷预防 《孙子兵法·谋攻》中提到“百战百胜非善之善者，不战而屈人兵，善之善者”。每次打仗都取胜不是战争的最高境界，战争的最高境界是不费兵卒而取得胜利。同样，在软件开发过程中，找出所有缺陷并将其一一去除不是质量管理的最高境界。质量管理的最高境界是将缺陷扼杀在摇篮之中——缺陷预防。经验过程控制三大支柱所体现的其问题驱动的特性说明了它可以帮助我们去实施缺陷预防。基于经验过程控制的缺陷预防是通过使缺陷来源成为可观察的因素，然后在软件开发过程中对这些因素进行检查，发现不可接受的偏差时及时采取措施进行矫正，从而避免了缺陷的引入。比如，当我们发现开发人员对需求理解的错误、不全面是缺陷的一个重要来源时，我们就可以应用经验过程控制的思想，先采取措施使开发人员对需求的理解成为可观察的因素。然后对其进行检查，若发现有需求理解上的偏差，则进行矫正，从而避免了因需求理解偏差而引入缺陷。 诚然，软件测试的目的是发现缺陷。也正因此大多数公司和个人也就把测试人员定位成缺陷的发现者。然而，测试毕竟是一种事后控制型的质量管理手段，这不是上上策。能否往测试人员这个角色的职责的定义中增加一个缺陷预防的职能呢？笔者曾经在所带团队中引导测试人员往缺陷预防方面发展，在这方面多做贡献，而不是仅仅把自己定位为缺陷的发现者。在开发测试一体化团队中，测试人员同开发人员一起参与需求分析、评审。项目经理可以通过一些奖励措施鼓励测试人员多去发现需求本身的错误以及开发人员对需求理解的偏差，从而避免了需求相关的缺陷。另一方面，测试人员往往习惯于从发现缺陷中获得成就感。在引导测试人员在缺陷预防上多做贡献的过程中，项目经理需要引导测试人员使其认识到预防缺陷比发现缺陷更加能够体现一个人的能力和价值。 需求澄清 需求规格说明书本身的错误、不明确是软件缺陷的一个重要来源。因此，消除需求本身的问题是缺陷预防的一个重要内容。笔者在所带的项目中是通过开展需求澄清活动来消除需求本身的问题的。在开发团队内部进行需求规格说明书评审之后，评审意见被汇总成一个列表，这个列表可