试着回想一下，敏捷把价值、质量和约束作为三角形的三个顶点，可见质量在敏捷价值观中的重要地位
质量分为两种，外在的和内在的
客户质量（外在的）交付短期的价值，技术质量（内在的）随着时间演变而持续交付价值。工作质量差导致不可靠的产品，更严重的是，导致产品远远不能满足未来客户的需求。在真正了解外在和内在质量的基础上，着手建立新型商业模式。外在质量体现在观察者的眼里，内在质量正是工程师所追求的
敏捷宣言的格式时X 胜过Y，例如“个体和交互胜过流程和工具”，这句话并不是说流程和工具不重要，只是强调了个体和交互更为重要。同样，范围、进度和成本 不是不重要，商业价值和质量重要
软件的一个关键问题在于我们经常为了满足进度、范围和成本要求而使得内在质量下滑。客户今天或许很满意，但是随着时间的推移，技术债务增加，客户的满意度会大幅度降低。随时间推移交付价值的能力与内在质量紧密相连
为什么内在质量如此重要？内在质量有两部分构成：可靠性（正确运行）和适应性。首先，软件正确运行吗，其次软件有适应能力吗 ？
敏捷开发人员和测试人员懂得减少技术债务（提高内在质量）很重要很重要。许多人错误的估计测试时间，主要是因为他们不了解测试。只是粗略的评估“编码用了5天，我猜测试应该也就用3天吧” ，一般来讲，测试时间与编码时间无关，而是与缺陷密度有关。
举个例子
一次编码工作，4个开发，用10天 产生 4 KLOC （千行代码）
假定 每发现并修复一个bug 用0.5 天
if ( 缺陷密度==1个bug/KLOC )
{ 测试时间=0.5*4*1= 2天}
else if （缺陷密度==15个bug/KLOC ）
{ 测试时间=0.5*4*15=30天
//不做最小单元测试，也没有自动化测试}
else
{测试时间=凭经验 、评估最乐观、最悲观，计算平均值=N 天}
由此可见，编码缺陷密度大，测试时间容易延长至10~15倍，但几乎没有项目计划可以允许那么长的测试时间
面对许多开发团队，甚至经理，都会问 为什么测试会需要那么长时间——于是乎责备测试团队。然而，最影响测试时间的或许不是测试团队的工作绩效，而是开发团队编码的高缺陷率
内在的品质，体现在整个产品的生命周期中，只关注客户满意度和外在品质的组织往往会使产品的关键价值 在整个产品生命周期变得不堪一击。留住客户部分原因取决于适应他们不断变化的业务需求，因此关注内在品质成为维系客户的一种重要策略，一定要重视 重视 再重视
