【转】关于敏捷质量很好的论调，强烈推荐

想要理解敏捷软件开发为什么好，需要从软件质量讲起。那么软件的质量是什么？这个问题有很多中答案，我们不妨想看看传统质量理论对于质量是如何理解的。教科书上说，在20世纪质量管理的发展历程经历了质量检验、统计质量控制和全面质量管理三个阶段。其中，质量理念也在不断的演变。据说有这么几个阶段：

符合性质量
20世纪40年代，符合性质量概念以符合现行标准的程度作为衡量依据，“符合标准”就是合格的产品质量，符合的程度反映了产品质量的水平。比如说我做一个杯子，没什么特别的要求，也不是我神经质的艺术作品，就是普普通通的一个杯子，那么需要高矮长短，大小胖瘦，等等一干质量属性，我做好了可以拿着质量标准来对比，一眼就可以看出那里出了什么问题。通过是否符合这些标准判断产品具有相应的质量。
那么软件的质量理是不是符合性质量呢？我个人觉得不属于。虽然我们一样可以拿出各种各样的标准，比如故障率，比如bug数等等。但是这些标注都满足确不一定是好的软件，比如我写一个helloworld，虽然他可以没有bug。但是却发挥不了任何的作用。这样的软件就属于“高质量”的废品。正如赵辛梅评价方鸿渐，“你不讨厌，但是毫无用处。”，显然毫无用处的软件不会是真正高质量的软件。

适用性质量
20世纪60年代，适用性质量概念以适合顾客需要的程度作为衡量的依据，从使用的角度定义产品质量，认为质量就是产品的“适用性”。是“产品在使用时能够成功满足用户需要的程度”。质量涉及设计开发、制造、销售、服务等过程，形成了广义的质量概念。适用性质量的例子也很多，比如我买了一件 Givenchy西服（我还真买了一件），但是一时又没有特别正是的场合（目前还真没有什么正式的场合），于是我一天四顿牛排（其实只有一顿），于是就吃胖了，这件华丽的Givenchy就穿不上了。那么这件衣服从符合性质量来说，是优质品，但是从适用性质量来说，却不是一个高质量的产品——因为我穿不上。还有一句话，叫甲之熊掌乙之。也是适用性质量的标准体现。
那么软件的质量是不是适用性质量呢？我个人觉得，软件的质量至少是适用性质量。软件，尤其是定制软件／企业软件，就是量体裁衣。软件的基本质量就是要在用户使用的过程中发挥价值，支撑客户的业务发展。
书上说，从“符合性”到“适用性”，反映了人们在对质量的认识过程中，已经开始把顾客需求放在首要位置。但是它没说怎么才能做到把客户需求放到首要位置。我看光靠文档是堆不出来的，光考说说也是不行的。这个后面讲，戴明同学比我讲得好。

满意性质量
20 世纪80年代，质量管理进入到TQM阶段，将质量定义为“一组固有特性满足要求的程度”。它不仅包括符合标准的要求，而且以顾客及其他相关方满意为衡量依据，体现“以顾客为关注焦点”的原则。这个的最典型的例子是麦当劳，他所有的店铺从风格到食物都保持在同一水平，使你无论在那里，都可以得到一定的购物体验。也就构成了对麦当劳的满意性质量的验证。这个软件上也是有例子的，内举不必亲，ThoughtWorks大多数项目都可以达到“满意性质量”，呵呵谁让俺们是consultant涅。
我隐约觉得满意性质量应该是一个过程的质量，而不仅仅是软件的质量，但是目前没有好的想法，暂且按下不表。

卓越质量
......下略100字。个人觉得大多数软件还没有达到适用性质量，大多是过程也都没有达到满意性质量，卓越质量就先不说了吧。

总之，我们大体的认为软件质量主要是适用性质量起码是不会错的。那么怎么才能达到这个质量标准涅？俺是做软件的，质量管理还是看看Deming同学怎么说吧，不过他老人家的14点总是发生变化。我也只好断章取义，说说一个敏捷开发人员眼中的14原则：

1. 持之以恒地改进产品和服务 Create constancy of purpose for improvement of product and service

这个很明显嘛，small release，快速发布，每次发布都是对产品的持续改进。

2.采用新的观念 Adopt the new philosophy

敏捷啊...

3.停止依靠大规模检查去获得质量 Cease dependence on mass inspection

这个还有另一个说法，build quality in。TDD，QA/BA全程参与，都是build quality in的好方法。

4.结束只以价格为基础的采购习惯 End the practice of awarding business on the basis of price tag alone

这个...貌似是说请咨询吧...

5.持之以恒地改进生产和服务系统 Improve constantly and forever the system of production and service

这个是敏捷过程的持续改进，对应的实践大家可能比较陌生——Restrospective!!!

6.实行岗位职能培训 Institute training on the job

Pair Programming，Learning Lunch敏捷从来都不缺乏学习的机会，就看你有没有学习的动力了。

7. 建立领导力企业管理 Institute leadership

敏捷团队的终极目标，自组织团队，的管理是也。

8. 排除恐惧 Drive out fear

XP第一原则，勇气，不要恐惧。

9. 打破部门之间的障碍 Break down barriers between staff areas

只有开发团队的敏捷不是真正的敏捷，敏捷说到底，是将软件的供求关系从合约型转为合作型，本来就要是大破障碍。而且障碍不打破，就很难将敏捷实施到底。这也是很多同学尝试敏捷失败的原因，仅仅以为敏捷是技术层面上的事情，其实不是。从这个角度来所，敏捷方法的确是深刻而震撼心灵的变革，有些人... 呃...敏捷在十月...

10. 取消对员工的标语训词和告诫 Eliminate slogans, exhortations, and targets for the work force

恩，什么激情100天...封闭开发...见鬼去吧...不过restrospective的结果是要写在白板上的，准备时刻改进。自我表扬和自我批评，算不上训词吧。

11.取消定额管理和目标管理 Eliminate numerical quotas for the work force. Eliminate management by objectives

很多人都问过我，pair programming了之后，技校怎么办？嘿嘿，Deming同学已经说了，这样的考核不要也罢。

12 消除打击员工工作情感的考评 Remove barriers that rob the hourly worker of his right to pride of workmanship. Remove barriers that rod people in management and in engineering of their right to pride of workmanship

敏捷团队的自我评价很简单，360度，由于你几乎跟所有人都pair过，如果所有人都不说你好...这已经是rp问题了，就不是打击这么简单了...

13 鼓励学习和自我提高 Encourage education and self-improvement for everyone

同前，Pair Programming，Learning Lunch敏捷从来都不缺乏学习的机会，就看你有没有学习的动力了。

14 采取行动实现转变 Take action to accomplish the transformation

每次restrospective之后必须定出方案，以实践改进。