质量管理由Alan S.Koch读取时间分钟内
高贵质量成本答案可能会令你大吃一惊对 包括评语 评语QA基础建设准备测试 算作你"申请成本故障代价有多高
工程师花时间诊断重整 开发进度滑动 支持成本攀升失效成本是更高质量成本,超出你直接控制范围可间接控制成本 通过投资评估成本 最小化故障成本 降低总质量成本 并增加预测性
质量成本评估故障成本
质量成本对任何项目都很重要,所以谨慎管理者寻找方法控制成本质量成本我们可以控制 东西像执行审查 准备测试 维护质量评估基础评估成本但也有一些质量成本我们无法控制
故障代价发生在我们身上测试期间和发布后每次发现缺陷时都产生这些低质成本失效成本有多种形式:
- 开发商花在调查和诊断缺陷上的努力, 并重编设计代码校正
- 滑动时间表 测试发现缺陷 需要重试重试
- 客户支持费用大都用于帮助客户处理我们发运给他们的所有缺陷,而开发商花更多时间调查和重整工作
- 最大故障成本几乎无法量化客户恶意缺失 市场名声败坏 产品势头下降
质量成本中的某些构件受我们直接控制,而另一些构件不受我们直接控制,因此,降低那些我们能够实现的成本并期望用那些我们无法控制的成本实现最优是合情合理的。不幸的是,注重降低评估成本可增加我们总质量成本,因为它可能导致故障成本更大增加
持续报告行业故障成本随项目进展而指数上升减少评估活动延迟检测缺陷,确保检测到缺陷时费用更高得多。
利用评估减少故障成本
多数组织依赖编译器和各种测试消除产品中的大部分或全部缺陷从图1可以看出,这不是最有效的消除缺陷方法每种方法都检测不到产品缺陷的50%,而且往往比这差得多。此外,它们发生在项目生命周期晚时,缺陷最昂贵修复活动分类为“故障质量成本”,因为绝大多数时间用于处理故障
| 活动类 | 成本质量 | 有效性 |
|---|---|---|
| 结构化个人评审 | 评估 | ------------- |
| 软件检验 | 评估 | ----------- |
| 非正式同侪评审 | 评估 | --------- |
| 编译 | 失效 | -------- |
| 单元测试 | 失效 | ------ |
| 集成化 | 失效 | -- |
| 贝塔测试 | 失效 | -- |
| 系统测试(和性能测试及其他测试) | 失效 | -- |
| 验收测试 | 失效 | -- |
| 遍历 | 评估 | - |
对比各种评审相对有效,不仅因为他们能检测出60%-80%的产品缺陷,还因为这些缺陷更早检测出,而成本低得多才能纠正。分类为“实用质量成本”,因为只有一小部分时间用于响应故障评估活动比故障活动消除更多缺陷
图1注解
成本质量列表示该活动的大部分时间用于评估或处理故障切需认识到只有首编译与故障无关万一没有缺陷,我们只能运行一次编译程序同理,只有首试与故障无关所有诊断、重试和重测试都因故障而必需 。 )
有效性列表示缺陷百分比有可能检测和工程师时总成本查找、诊断并清除每一项缺陷
审核清单基于最佳做法在有些情况下,效率相当低。
编译、单元测试、集成化、贝塔测试、系统测试和验收测试的顺序确实表示它们在消除缺陷方面的相对效率(而不仅仅是生命周期顺序)。
单元测试列表基于最佳做法多开发商从未接受测试训练,
行走比清除缺陷更有效培训
经济学指针我们运用评估成本原则(直接控制成本)以降低故障成本(难以控制成本 ) 。原理引导我们反直觉建议, 即如果我们想大幅度降低总质量成本, 我们必须大幅提高评估成本命题真有效吗
假设所有故障成本(每美元) 都由软件有限数目缺陷引起每一个漏洞比目前省钱比现在省钱 都代表着公司底线上的钱可更及时清除的缺陷都表示时间或日(或周!)保存避免向客户运输的每一缺陷都降低支持成本,而我们做船舶的每一个有用特征都无价良好意愿,建立公司名声和市场份额
审核最经济方式检测并消除缺陷测试相对无效消除缺陷,但它仍然是我们开发生命周期的必要部分与其继续使它成为主要的缺陷清除机制,不如用它验证我们早先初级缺陷清除活动的有效性:评审和检验
控制中
唯一控制总质量成本的方法就是从不可控制故障成本转向可控制评估成本评估活动逐级增量,如评审(假设做得好),我们可以期望我们的失败活动会相应并大减量
如果我们把原理推向逻辑推理, 我们就会发现自己处于令人羡慕的状态, 将质量成本大都移向方程评估方程侧面这就意味着我们质量成本不仅会大幅下降,而且还会更加可预测和易于管理质量成本非但没有发生在我们身上,反而会成为我们控制项目并保证项目成功的工具
艾伦S狗万体育新闻Koch,PMP编译Agile软件开发:评价组织方法,讲写并咨询有效项目管理