Good Enough Quality

Good Enough Quality

作者：袁琳

软件行业飞速发展，软件企业面临日趋激烈的市场竞争，常常面临这样的问题：

如何不断推陈出新，保持持续的竞争力。

如何在短时间内完成软件产品或软件项目的研发，最大化的满足客户需求。

如何及时跟踪不断变化和升级的开发方法、技术实现方式，来提高研发效率。

显然，这些问题反映出当前的软件开发模式越来越趋向于由市场驱动，软件企业需要不断适应市场变化、适应不断增长的用户需求、尽快研发并发布新产品、同时需要创造出高质量的软件产品。因此，对于软件开发来说，做好软件项目开发过程中时间、成本、质量的平衡尤为关键。软件开发的时间、成本是有限的，在给定的产品或项目背景下，如何控制软件发布质量、交付用户最满意的产品是一个巨大的挑战！

很多人会说，在激烈的市场竞争面前，产品质量是企业的命脉，是重中之重，必须要保证软件产品的“零缺陷”，于是他们便挖空心思生搬硬套 6sigma、CMM… 结果导致软件开发过程过于形式化、官僚主义，软件创新迟缓、不能快速占领市场，产品交付给用户后，用户说：这不是我想要的！

诚然，产品质量是企业生命的基石。不可否认，6sigma、CMM 是值得研究学习的科学理论，在军事航天、科研探索、大型电信领域都有非常成功的案例。但是，国内的众多中小企业面临巨大的市场竞争压力与内部发展创新的需要，还一味照搬6sigma，就值得反思了，是否有必要耗费大量时间、资源追求每百万个产品的不良品率少于3.4呢？

我们总是期望某种软件开发模式或开发方法能够适用任何类型、特点的软件开发过程，能够开发出高质量的软件产品，可是每当我们实际应用时，却总是会发觉，理想与现实的巨大差距。所以，软件开发方式、质量控制原则的实用性更重要。必须针对不同的软件开发特点，制定不同的质量控制原则。

随着各种敏捷开发方法及其它一些“轻量”开发方法的逐渐兴起，越来越多的软件组织意识到敏捷方法对于软件新产品开发有着良好的指导作用，在市场竞争中能够快速影响需求、缩短研发周期、及时放量发布，这样更有利于降低软件开发过程中的各种风险，通过不断与用户的沟通反馈，不断交付给用户满意的软件产品。越来越多的软件开发团队开始尝试各种敏捷实践，同时也在探索敏捷开发过程中的质量原则。在敏捷开发中，倡导质量Good Enough就OK，那么这个Enough到底是多少呢？在没有明确的原则的情况下，Good Enough Quality（GEQ）概念滥用，满意质量常被用来为软件中明显存在的缺陷做辩解，甚至有人认为软件供应商在软件产品中保留臭虫（Bug）是一种蓄意行为甚至是聪明的策略，这无疑造成了很大误解。

在2001年“敏捷联盟”建立之后不久，著名的软件测试科学家James Bach根据自己多年的实践经验和理论基础就针对不同软件开发的方法在满意质量的基础上提出了相应的质量原则。

满意质量的原则进行了系统化定义，满意质量定义如下：

（1）可带来足够的利益；

（2）不存在致命性问题；

（3）所带来的利益超过问题所造成的损失；

（4）在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。

同时，James Bach提供了一个用于评估GEQ的框架，该框架包括四个GEQ元素和六个GEQ视角，它们构成了一个提示问题集，可用来帮助相互沟通，或者帮助进行产品开发、产品改进、实现更好的实践活动等。GEQ框架的概要描述：

GEQ元素（factor）
　　四个元素基于GEQ的定义进行扩展，为评估软件产品质量。
1. 评估产品的利益
　　鉴别——对于产品的受益人而 言具有什么已知利益或潜在利益？
　　可能性——假设产品正如所设计的那样工作， 受益人有多大可能性会认识到每个利益？
　　影响——对受益人而 言， 每个利益的期望程度如何？
　　个体重要程度——从个体考虑， 哪些利益是完全不 可替代的？
　　整体利益——作为一个整体且假设没有问题， 是否具有足够的利益以满足受益人？
2. 评估产品的问题
　　鉴别——对于产品的受益人而 言具有什么已知问题或潜在问题？
　　可能性——受益人有多大可能性会发现每个问题？
　　影响——对受益人而 言， 每个问题的破坏程度如何？是否可以继续工作？
　　个体重要程度——从个体考虑， 哪些问题是完全不 可接受的？
　　整体问题——所有问题叠加在一起会怎样？是否有太多的非关键问题？
3. 评估产品质量
　　整体质量——根据GEQ视角， 利益是否看来超值于问题？
　　安全/完美边际值——如果需要或想要使利益超值于问题， 那么至少需要投入多少？
4. 评估改进产品的后勤问题
　　策略——有哪些策略可用于改进产品？
　　能力——具备 实现这些策略的能力吗？知道如何做吗？
　　成本——改进工作需要多少成本或存在什么麻烦？是否充分利用了资源？
　　进度——能否立即开始或稍 后再改进？能否在可接受的时间范围内实现改进工作？
　　利益——改进效果明确吗？有附加利益吗（如更好的士气）？
　　问题——改进工作会有多大可能带来负面影响（例如， 引入错虫、损伤士气、占用其他项目资源）？

GEQ视角（perspective）
　　GEQ元素是评估软件产品质量的必要条件而不是充分条件。为了执行可靠的评估，还必须同时从六个关键视角来检查每个元素：
　　1. 受益人——哪些人关于质量的意见起作用？（例如，项目团队、客户、商会、法院等）
　　2. 关键目的——什么是必须达到的？（例如， 即时生存、利润、市场份额、客户满意度等）
　　3. 时间尺度——质量改进成果的时间敏感性如何？（例如，立即、近期、长期、某个关键事件之后等）
　　4. 替代物——本产品与替代物相比如何？（例如，竞争对手的产品、服9. 务或解决方案）
　　5. 失败结果——如果质量比GEQ稍11. 差一些会怎样？是否需要对突发事件进行规划？
　　6. 评估质量——评估本身的可信度如何？是否令人满意？

　满意质量不等于轻视和放弃软件产品的质量工作，它更强调用理性的思维去分析软件产品或软件项目面临的市场压力、风险状况、种种困境，对软件产品的质量做出理性的决策，而不是循规蹈矩、死板的、刻意执行一些被强制的行为。因此，满意质量被认为是实用主义、功利主义的产物，即倡导使软件开发公司在短期内快速开发出满足用户需求、令用户能够满意的产品，而不是一味的追求完美、追求软件质量的“零缺陷”。对软件公司来说，也应该是最实际的策略，能够有效把握时间、成本、质量等各方面的利益的平衡，满足用户需要的同时，创造最大化的价值。

满意质量的思想已经开始不断被更多软件开发组织认可，很多软件企业开始尝试基于满意质量思想的各种实践，有些企业甚至鼓励尽早将产品投放市场，发布给用户，让用户参与Beta测试，由用户反馈试用过程中的各种体验和问题，这样企业在同用户在逐步的协作中不断提高质量和用户满意度，最终提供给用户满意的产品，同时也迅速占领市场，达到双赢的目的。