软件QA应了解的过程监管悖论

    
多年前读过温伯格和太太Dani写的“系统设计基本原则-General Principles of Systems Design”一书，其中讲的过程监管悖论让我印象深刻，至今难忘。其大意是：


通常监管的主要任务是消除过程执行中的变异（variation），但正是这种变异让我们了解相关工作的质量，是主要的信息来源。因此，过程监管做得越好，获得的关于如何改进的信息就越少。
 

    软件QA应该学习、理解、在实践中体会这个监管悖论，因为创新驱动的研发过程更需要平衡好二者的关系。这个悖论告诉我们，在管理不确定性较高的软件项目时，估算不应过于精确，承诺不应过于僵化，项目流程不应过于严格，角色不应过于封闭。过于苛求和标准过程的一致会减少从研发体系外部传入的信息流，让体系很难具备一个重要的品质：适应性。
 
    CMMI 2.0关于QA的实践域（process quality assurance）有两条新增的实践
：
– PQA 2.1：基于以往质量数据策划、执行质量保障活动。也就是说，过程监管重点应该放在容易出现质量问题的地方，方式、方法要根据项目的具体场景，而不是僵化地使用一张放之四海的QA检查单去监管所有项目的过程执行情况。
– PQA 3.1：执行质量保障活动时，识别、记录改进机会。也就是说，QA需要从过程执行的差异信息中，识别出不适用或更好的过程实践，作为过程改进的来源之一。
 
    做好这两条实践
能够帮助QA解决好温伯格夫妇给出的过程监管悖论。