目标驱动已经写进现代组织的基因之中，小到Scrum小组，大到整个研发组织，如果拥有敏捷或DevOps成熟度的目标，将使得改进得到关注并更有保障（无论是时间还是资源的投入）。成熟度模型的高阶段要求，是各团队的具体改进目标；在组织层面，也可以基于组织现状，设置一个总体改进目标，譬如达到不同等级的团队比例等，作为OKR自上而下分解到各团队（在设置OKR目标这件事情上必须慎重，避免造成改进行动的形式化）。
第四：规划改进路线。成熟度模型给出了团队从现状（低阶成熟度）到目标（成熟度高阶段）的路径（即需要经过哪些阶段）；攀登高峰不止一条路，但有的崎岖陡峭，而有的更为平坦，有经验的登山者知道要走前人走过的路。成熟度模型所规划的路径，是前人实践的经验总结。诚然，团队采用敏捷或DevOps的成熟过程与生物体的成熟过程有很大不同，后者必须连续经过所有阶段，而敏捷的采用则不受这个限制；因此，在规划上不能教条，团队完全可以根据自己的情况，形成特定的改进路径。
第五，营造竞争氛围。以适当的方式，在整个组织层面展示汇总的成熟度数据；识别在提升成熟度过程中涌现出的优秀团队并给与适度的表彰；鼓励亲历者讲述通过成熟度的提升而带来效能提升的成功故事并大力宣传等。这些举措，都承载在企业的敏捷或DevOps成熟度模型之上，不同团队之间容易产生共鸣，并存在一定的可比性，能够在团队之间创造正面的竞争氛围，带来改进的紧迫感。
第六，度量改进进展。通过敏捷和DevOps来进行全面的效能改进，是一个持续、漫长和没有终点的旅程；团队要经常检视自己做得怎么样，是不是走在正确的道路上，而成熟度模型在这个过程之中可以成为衡量改进进度的标准；通过在改进过程中的持续评估，团队可以清晰地了解自己在改进路线上所处的位置，为后续改进活动的设计提供依据。
成熟度模型设计原则设计什么样的成熟度模型决定了组织要定义什么样的研发效能标准，将怎样的行为作为团队模仿的对象。成熟度模型的设计必须回归使用成熟度模型的目的，即能够引导团队和组织持续提升效能，进而改善业务产出。为了实现这一目标，需要遵循以下原则：
第一，基于企业现状。成熟度模型的通用性越高，则越是抽象，落地指导的价值越低。鉴于敏捷和DevOps方法和实践的多样性，以及其推广实施的灵活性，很难出现一个适应各种场景的敏捷或DevOps成熟度模型；为了能够指导改进，模型的设计一定要基于企业现状来，考虑企业的业务诉求、技术路线、人员水平和研发治理模式等约束，而不是简单地瞄准理想的敏捷或DevOps状态。
第二，具有导向性。模型所包含的考察点，对各考察点目标的定义，以及对不同阶段的评价标准，都要具有明确的导向性，反映了组织的效能目标（交付速度优先，还是效率优先？更好的用户体验还是更低的成本？），效能关注点（弹性的组织，优化的流程，先进的工具，专业的人员等），以及组织对于达成目标的实践经验总结和洞察；通过这种导向性，引导团队表现出组织所期望的行为。
第三，关注目标。对各考察点的设计，重要的是明确指明目标，而不是严格限定是否采用了某种具体实践。每个考察点从低到高的各阶段，反映的是达到目标的程度；不同阶段的评价标准可以举出一些最佳实践的例子，但最佳实践不是重点，重点是通过这些实践帮助团队达成阶段目标。通过对目标的关注，使得团队更能够了解差距，自己决定采用何种措施达成目标，并在通往目标的征程中不断调整措施，而不是教条地采用实践。
第四，相对客观。不同的评估者，在同一时期，对同一个团队，基于相同的事实，应该能够给出近似的评价结果。量化数字要求自然能够达成这目标，但不必太强求量化，只要考察点的目标描述明确的，其支持实践或表现得行为是可观测的即可。成熟度模型设计之初，可以考虑通过对试点项目的应用，对其信度和效度进行检验。再次提醒，不必追求完全客观，这不是考核；存在一些模糊，有一定争议，引发一些讨论是有益的。
第五，保持动态演化。组织业务目标和所处的环境在变化，组织的内部环境在变化，软件开发方法和实践本身也在快速变化，今年还备受追捧的方法和实践可能明年就过时；因此，成熟度模型必须适应这种变化，保持演化，以吸收业内最新的成果，来更好地适应你的环境，帮助企业达成目标。
如何运用成熟度模型