团队从自己的现状出发，沿着成熟度模型的阶梯，不断追逐高的等级，实现持续改进；成熟度的等级本身在这个过程中自然而地成为焦点。但如果以成熟度等级为根本，特别是以拿证为目的进行评估，则很容易带来运动式，一刀切的“改进”。这个时候对等级目标的片面追求很容易让改进行动脱离团队的现状，非但违背应用成熟度模型的根本目的（即提升效能），而且评估活动本身会成为团队的负担（准备各种证据），对团队的正常工作形成干扰；一阵风之后，留下一堆作为证据的文档和弃之不用的流程工具，团队的一切行为照旧。等级本身并不重要，持续地改进以使得团队能够更好地服务业务才是根本，不可以本木倒置。
成熟度模型是工具，工具本身通常是没有对错的；刀既可以伤人，也能够救人，就看握在谁的手中，为了什么目的。所以，对成熟度模型的应用要慎重：我们可以用它来作为参照和模仿对象，但却不能把它设计成标准强迫大家遵守；我们可以用它来设定改进目标，但用来考核绩效可能事与愿违；我们可以把优秀团队秀出来能够激励其他团队效仿，但如果把暂时垫底的团队也公布出来却不是个好主意。
成熟度评估是模型应用和实现改进的手段之一，它基于模型提供的持续改进的蓝图，帮助我们在改进的征途上进行检查（识别当前所在的位置）和调整（确定进一步改进的方向）。成熟度评估不是为了获得一个期望的等级，然后结束；而是要通过评估建立一个基线，成为进一步改进的新起点，并给出下一步行动的建议。
评估活动本身可以有多种方式，抛开外部认证评估不谈，在企业内部有团队自我评估，交叉评估（利用敏捷和DevOps社区力量，不同团队交叉评估），以及集中评估（由企业敏捷中心的教练统一评估）等多种方式。特别推荐交叉评估的实践，它一方面解决了集中评估的资源紧张问题（想象一下几个教练对上百个团队进行评估的场景）；另一方面，也是更重要的是，它可以使不同团队有机会相互学习。
评估的结果包括团队在成熟度模型中所处的等级，做得优秀的地方，以及不足之处。团队基于这个结果，对标模型更高等级，分析可能的改进点，马上采取行动，投入下一轮的改进之中。作为敏捷和DevOps推广团队，既要基于评估结果发现共性问题，针对性提供集中培训和专项辅导；也要识别涌现出来的优秀实践，在组织层面进行分享。评估的结果建议汇聚起来，形成整个组织的成熟度画像；各团队成熟度的具体等级可以不公布，但整体水平的透明有利于各团队判断自己在整个组织中所处的位置，增强各团队的改进紧迫感。
需要警惕的是，成熟度模型通常是基于经验、观点，甚至假设所做的构建，而不是应用科学方法的结果。评估结果所给出的改进建议，仅仅是一种你的团队可以如何成长的假设，它的作用在于让你拥有一个相对靠谱的参照物，帮助你快速决断和采取行动；你要验证这个假设在你的环境中是有效的，或者是无效的（判断标准是能否能够提高效能指标）；然后快速调整，进行新一轮的尝试，从而实现持续改进研发效能的目的。
结束语尽管成熟度模型的应用在敏捷和DevOps社区的争议不会停息，但还是有组织能够从中获益；我们可以通过明智地使用它，使其成为撬动敏捷和DevOps在企业规模化推广的利器。存在即合理，对包括成熟度模型在内的任何方法和工具的使用，我们应秉承实用主义而不是教条主义，同时持有批判性思维和开放态度；“不管黑猫白猫，能捉老鼠的就是好猫”。