业界存在的问题

CMMI最近没有以往火了，原因之一是SEI发现中国和印度的很多企业在级别评估上造假，尤其是高等级评估。为此SEI还在4级以上做了复审的规定。

为什么那么多企业争先恐后地争抢高等级呢？因为想证明自己的质量高。

在软件外包，或者说项目开发（而非产品研发）中，进度、质量、成本、需求这些因素虽然可能达到的最终效果有限，但各自的投入却可能是无限的，只是每个因素都以对数曲线规律运行，任凭你投入10倍的人力物力，它只增加一倍。

所以，在投入之前，应该问自己：到底哪个是我的终极目标呢？

在软件外包或者说项目开发领域，成本是终极目的。

因为外包或项目的终极目的是交易，是一个以金钱购买人力的过程，如果成本超过了合同额，无论进度、质量、需求如何，交易的本质目标已经受到了伤害，甲乙双方迟早均会为此付出代价。

因此，甲乙双方应该审时度势地合理选择质量等级，来控制成本。

顺便说一下产品研发的终极目的是提供功能（即项目开发中的需求），剩下的三者则为其服务。

质量管理的等级

质量管理活动大致有以下这些，并因为实施了这些活动而可以达到对应的质量管理等级：

质量控制 Quality Control

质量保证 (Process and Product) Quality Assurance

质量定义 Quality Definition

量化质量管理 Quantitative Quality Management

根源分析与缺陷预防 Causal Analysis and Resolution

质量控制 Quality Control

实施质量控制的一个典型情况是有基本的软件测试行为，对应CMMI的1级（一个在CMMI模型中描述过，但没有定义的级别）。

为什么称之为Control呢？因为测试活动发生在产品完成之后，因此它本身不能直接提升产品的质量，但可以把产品中不好的部分检查出来。在制造业中，不合格品检出后会被扔掉，而软件界则把不合格品退回重新修改。

质量控制存在局限性：

1. 效果有限

正如我们不希望购买到被“返修”的汽车、家电一样，“重新修改”过的软件也是存在问题的，因为多数缺陷不是孤立的事件，而是软件整体质量低下的一个表象。

2. 成本高

如果一辆汽车只有完全安装好后才知道质量如何，而一旦知道了就只能整个扔掉或完全拆开修，将是一个很痛苦的事情。

而软件测试正是如此，在软件能运行之前是无法测试的，而测出了缺陷和发现了缺陷是两码事，得用肉眼重新“拆”开软件，才能找到缺陷的根源。

敏捷质量控制

敏捷开发中的持续集成和自动化测试可以有效降低成本高的问题，因为持续集成极大地加速了装、拆两个过程。

加速装的过程很好理解，为什么说可以加速拆的过程呢？

由于每次持续集成，被“装”进去的代码很少，所以一旦测试发现问题，就能很容易地判断问题存在的地方就是刚刚加进去的代码，或至少是由这些代码引起的，因而可以迅速定位问题。

这比在最终产品成型的时候才进行测试，拆的过程要快得多。

不过，既然知道持续集成是用来解决成本问题的，那么就别投入过多的人力做持续集成本身，要问自己一些问题，来判断持续集成是否发挥了作用，比如：

1. 项目的长度，是否长到需要中间持续集成？

如果只有1个月，估计1个月后大家拆装的速度也未必差到哪里去。

2. 即使需要持续集成，应该以何种频率和程度进行集成和测试？

切忌不要为了敏捷而敏捷。

3. 在集成后，是否顺便邀请了客户来观摩一下当前的产品，以便提出改进？

有些改进未必是代码缺陷问题，兴许是需求缺陷问题。

4. 这个项目有没有二期三期四期，是否需要把持续集成和测试环境搭建地好一点？

5. 这个项目有没有多个客户？（已经接近产品化了）

这影响到是否需要一个大环境同时架设多个客户，以便在为一家客户修改底层后，快速检查一下是否其他客户受到了影响。

……