3：对内防御的

　　构建是自动的。由测试和检查来保证团队内部的开发质量。持续集成的修复具有高的优先级。团队对持续集成的结果有信心。

　　2：频繁的

　　构建是自动的，而且构建的速度较快。构建的触发条件是明确的，通常每次代码提交都会触发构建。团队中的每个人都会触发构建，并且了解构建的状态。

　　1：重复执行

　　构建是自动的，但是执行的不够频繁。构建的触发是随机的或者频率是非常低的(低于每天一次)。构建的速度通常非常慢，比如一次构建超过半个小时。

　　0：可重复的

　　主要依赖于手动的方式构建软件，但是每次构建的方式都是相同的或者相似的。通常有相关的文档的指导。经常团队指定某个人负责构建软件，虽然大部分人都能够做这件事情。

　　-1：手动的

　　主要依赖于手动的方式集成软件。每次集成的方式可能不一样。经常团队中只有个别人能够将软件集成起来。

　　测试：

　　级别

　　描述

　　3+：全面集成的

　　全团队对测试负责。测试驱动整个开发过程。测试与构建完全集成。

　　3：测试驱动的

　　业务分析人员和开发人员均参与测试。测试在构建过程中自动执行。开发人员实践测试驱动开发。

　　2：集成的

　　开发人员参与测试。部分测试集成在构建过程中执行。大部分测试在软件开发过程中执行。

　　1：共享的

　　开发人员参与测试。测试并未集成在构建过程中。部分测试在软件开发过程中执行，大部分测试在软件开发结束后执行。

　　0：审查的

　　测试由专门的测试人员负责。有部分测试是在软件开发过程中执行。但大部分测试在软件开发结束后执行。

　　-1：独立的

　　测试由专门的测试人员负责。仅在软件开发结束后执行。

　　配置管理：

　　级别

　　描述

　　3+：企业级的

　　企业有统一的配置管理策略。

　　3：跨项目的

　　配置管理在多个项目之间协调。

　　2：自动的

　　配置管理策略与持续集成策略紧密结合，团队成员有频繁提交的意识。一般采用乐观锁策略，原子提交。

　　1：集成的

　　版本管理下的内容是受控的。通常在版本管理中的代码是可以编译的。开发人员能够访问到自己工作所需要的代码。开发人员按照一定的规则访问配置管理工具和提交代码。一般采用悲观锁策略。版本管理工具和构建过程集成在一起的。

　　0：基本的

　　有基本的版本管理。但版本管理下的内容不全面，或者不足以支撑团队的开发。

　　-1：无配置管理

　　没有配置管理。或者使用方式完全错误。