组织级在技术平台和开发模式不统一的情况下，在过程定义上一定要避免一刀切的标准软件开发过程。需要根据项目本身的特点和人员情况在满足项目目标的情况下进行适当的裁剪。
软件是人开发出来的，过程重要但是人更加重要，两者必须要考虑结合起来，任何强调和夸大一方面的都不合适。对于小型敏捷团队我们更加强调人的重要性，对于大型软件项目可能更加强调规范和过程的重要性，这必须要结合项目特点和实际情况。
所有认证和培训的市场，到中国就变味的原因，还是在于管理层的急功近利和不务实的态度，结果过了CMMI只是完成了一个形象工程和招标谈判的筹码。如果CMMI过程改进没有为组织真正带来质量提升和效率的提高，那么就很难长久。
CMMI提供了对多次迭代和快速原型的支持，但是实际上很多的PA，很多的评估师给出的建议仍然是基于瀑布模型的。而在实际的软件开发中，特别是交付周期只有2-3个月或更短的项目，很难基于瀑布模型进行开发。
全部遵循了CMMI的过程规范和要求，项目是否就一定能够成功？在这里答案仍然是不一定，关键的问题还是CMMI基于了太多的假设，比如组织能够提供技能合格的人员，需求基本上都能够保证是稳定的，而这些假设往往本身就无法满足。CMMI给我们一个基于很多假设的理想模型，而实际情况就是如果这些假设都能够很好的满足的话，可能你并不需要CMMI也可以很好保证项目成功。
CMMI强调证据，数据，过程和文档。CMMI告诉你需要做什么，你需要有证据来说明你确实做了，因此准备数据和文档过程是一个要耗费很大成本的过程，在前期我们本身还不成熟的时候更关心的是一项工作投入成本做了以后带来的实际效益即投入产出比。比如需求追踪会被我们经常认为是性价比不高的工作。
一个成熟的敏捷团队（例如ThoughtWorks）自然就具备CMM5级的成熟度，因为我们在面对项目时解决问题的过程是清晰的、可重复的、可度量的、可管理的、自我优化的。如果在软件过程改进中没有达到这些目标，就没有达到真正的改进效果。
文档不能完全代替沟通，但是不能够否认文档和代码的重要性。当我们注重开发过程的管理和规范的时候，软件项目和团队会走向成熟，而过程成熟的一个好处就是整个项目和团队不会完全依赖一两个牛人。项目在不断执行过程中的先进经验和教训能够真正的固化到过程中，形成组织和项目重要的资产。
CMMI每个PA需要做的事情，CMMI不会告诉你怎么去做，但是你必须要首先搞清楚的是为什么要做这件事情，其意义何在？我们在进行软件过程改进的过程中必须是目标和问题驱动的，这样才能够有批判的主动去改进。
文章来源于领测软件测试网 https://www.ltesting.net/
