敏捷开发从宣言到原则，再到实践，也有组织开始进行敏捷的认证活动。
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
前几天听得一个敏捷基础类的介绍，已经将过程加到敏捷开发时间中，认为可以将Fast同Process联系起来，认为流程或工具是使团队更快速。
还是那句个体和交互胜过过程和工具，就是说，过程和工具的作用是不可忽视的，谁要是忽略甚至摈弃过程和工具，那就进入一个教条主义的泥潭中。
说起敏捷，经常会被人问起同CMM这个软件成熟度模型（Capability Maturity Model for Software）之间的关系
为了容易比较，我可以将敏捷软件开发中的思想，理解为软件能力“敏捷度”模型，CAM-Capability Agile Model for Software。这样，就可以把敏捷开发同相对传统的软件过程管理下的开发简单地区别，并可以更容易对比。
1，CMM更注重过程，认为过程可以保证软件开发能力的成熟度，就是说，可以通过过程保证一个软件在各个阶段更加可控，获得的结果更加可靠，就是说可以更容易计划，按时间完成计划，在规定时间内获得高质量的成果。
CMM认为软件开发虽然不可以度量，但可以根据科学的方法，通过量化数据发那个是尽量准确地将软件的需求，计划，开发，效率，测试，结果，以及人力、成本等需要管理的要素加以约束。
CAM 更注重开发者的个体和软件本身，注重客户业务和软件需求的变化，从而以更快速的方式适应这些变化，从而达到软件的最终结果更适合业务需求。
CAM也同意软件开发过程中的各个要素，如需求、设计、构架、开发、测试，但是更强调分阶段呈现，先运行起来，然后再重构，使用户和各环节可以在最快时间内看到运行的系统，从而避免方向的偏差和交流的错误，以最小的代价获得这些，而不是过度设计，过度计划，过度管理带来的高成本。
2，从自然规律上讲，一个事物成熟度越高，其敏捷性就会降低。如一艘大船，在稳定，安全，容量，速度等方面占有优势，其具有很高的成熟度，但是其敏捷性就不如小船。人类也是这样，个体和团队，当其稳定成熟后，抗风险等能力提高，单会使成员变得官僚，决策和执行力稳定但不适合变化。
所以，软件开发的过程的成熟度和敏捷性，是两个互斥的选择，可以通过两个方面的改进模型，以适合特定规模的项目或特定规模的开发团队。
3，从软件开发管理科学的不断探索可以看到，在CMM类的过程管理方法理论和实践中，不断将长周期的开发方法改变为短周期和螺旋式的开发，这点在Agile的演讲中一般不会提到，Aglie的演讲总是将瀑布式开发作为其攻击的目标，让人们认为Agile解决了长周期的弊端。
所以，长周期还是短周期都不是Agile和CMM的区别焦点，而是设计和重构成为他们重要不同之处。即通过不断实现-重构的是敏捷方法，而通过设计-实现-重构的是过程式的方法。由于加入设计的环节，成熟度自然要比简单设计的Agile要成熟，迭代周期要少，开发进度要可能要快一些。
4，CAM类的开发认为文档也不是很重要，所以，除了必要的文档外，描述构架、设计、代码的设计认为可以不要了，认为代码就是设计。
随着软件开发工具的不断升级，开发语言更加自然语言化、图形化，的确很多既不能及时更新的文档可能会造成更坏的后果，所以可以不要。
简要结论：
成熟度还是敏捷度，到底要哪一个？成熟度可能会将敏捷度包含进来，成为一个分支；还是敏捷度将成熟度解决在过程之外。
还是两者本来就是融为一体的，可以共存，只是需要一个过程。
只是这些方法都形成各自的利益链后，再融合起来就比较困难了。