2.2.4 质量

从交付管道流出的交付产物是否能够满足客户的要求？这里的质量是指广义上的质量，包括产品设计、用户体验、功能完善等。质量是个约束性的属性，对于一个特定的产品来说，其质量要求通常是相对稳定的。质量保障是通过系统化的一系列活动，提供足够的证据说明软件产品是适合使用的（fI Tfor use）。

在从生产环境取得反馈之前，我们只能假设：只要有足够可靠的质量保障活动，我们就认为结果产品的质量是可以得到保证的。如果这个假设成立，当我们分析一个质量问题的根源时，就会发现原因肯定是前期的一些质量保障活动不合适或是不充分。当我们又假设，我们会在项目计划里包含合适的质量保障策略，那么如果质量出了问题，通常是计划和进度的可靠性方面的，以至于无法在计划的时间和资源范围内完成足够的质量保障活动。因此，进度可靠，是质量可靠的基础。

可靠性对于任何业务活动，包括软件开发都仍然具有极大的价值，这也是IEEE的软件工程目标。前面的推理过程实际也是很多公司推进流程改进的动力。这些公司的期望是，通过提升流程的可靠性，降低进度风险，从而降低进度风险带来的质量风险。不过在瀑布模型里，这种流程可靠性，一方面来自于对开发活动在各个维度上的细分，也就是精细化管理，以期事先能够把事情考虑得面面俱到，并通过流程手段保证该做的事情确实都会发生；另一个方面，其实就是在计划和流程上引入足够的缓冲空间。所谓缓冲，在实际开发活动中的表现其实就是等待，当然，人们总能找到充足的相对价值较低的活动填满这些等待时间，而且理由充分，不留痕迹；缓冲在流程中的表现，其实就是库存，通过库存平滑掉工作单元在各个生产环节停留时间不确定带来资源利用率的波峰波谷。这两类缓冲，其实都是影响组织效率的因素。

除了上面这种方式，另一种提高质量可靠性的手段是缩短反馈周期。

前面提到，质量的不确定很可能是来自工作量估算准确度、开发进度的不确定对测试活动完善度的挤压。在传统软件开发过程中，当开发人员告诉项目管理人员说代码完成了80％，这个数字对于最后的交付来说，代表了什么意义呢？在不知道这些代码质量的时候，我们并不知道要在后面的测试当中耗费多少时间，因此这条信息的有效性其实非常值得怀疑。如果当所有代码基本完成，才发现各个模块的缺陷密度很高，抑或是各个模块、功能无法一起工作，需要大量的集成和联调时间。到了这个地步，获取这些质量信息的时间己经太晚，对交付结果就己经没什么太大的价值。可靠性的信心来自充分透明的信息，信息的有效性和时效性直接决定了目标达成的可靠性。

提升信息有效性和时效性的关键手段是缩短信息的反馈周期。当我们能够在较小的粒度上，完成设计、开发和验证一系列活动时，其产生的质量和进度信息能更可靠地告诉我们，我们在多大程度上真正接近了最终的交付。在迭代开发模型里，如果每个迭代的交付物都是基本上达到可发布的质量水平，也就是说，大多数的质量保障活动都己经在迭代周期内发生，这在很大程度上就从流程上确立了质量优先的原则，减少了在项目后期需要在交付时间和质量之间做出妥协的机会。

最后，从长期来讲，质量可靠性指的是引入代码变更时所冒的风险。如果代码可维护性好，则风险低，如果基础设施能够迅速检验出大多数变更可能引入的问题，则风险低，反之则风险高。我们可以把质量分为当期版本的质量和持续提供高质量软件的成本两个问题，这其实就是产品外部质量和内部质量问题。