扫码阅读

手机扫码阅读

一篇文章掌握敏捷成熟度模型使用技巧

520 2023-07-13

敏捷成熟度模型(Agile Maturity Model，AMM)，是每个组织在推动团队敏捷转型过程中不可或缺的工具，但是越来越多的企业在使用AMM的过程当中容易错用、滥用，从而导致对团队敏捷转型产生错误牵引，这篇文章会介绍敏捷成熟度模型的使用原则和方法，帮助读者充分理解成熟度模型价值，更有效的助力组织敏捷成熟度评估。

成熟度模型的使用原则

关于敏捷成熟度模型是什么，以及应该包括哪些内容，诸如此类的问题完全可以在搜索引擎中找到案例和内容参考。这部分不是今天讨论的重点。文章的第一部分想跟大家分享的是成熟度模型使用的原则。我认为想要让成熟度模型充分发挥作用，需要遵循以下四个原则：

-成长牵引胜过绩效考核

-团队期望胜过领导命令

-改进计划胜过最终得分

-适合团队胜过打怪升级

1.成长牵引胜过绩效考核

首先，成熟度模型的核心是牵引团队持续改进和成长，在部分组织中会刻意地把成熟度模型与团队绩效关联，致使团队过分关注成熟度模型等级的提高。导致团队采用各种手段提升团队成熟度等级，甚至出现数据造假的情况。从而让成熟度模型的使用背离了初衷。

2.团队期望胜过领导命令

在团队基于敏捷成熟度模型，识别问题并改进的过程当中。团队需要自己判断哪方面是改进的核心，从而根据改进目标制定改进计划，要避免领导命令式的要求团队都按照领导期望的方向进行改进。每个团队都具有自己独特的环境和目标，把决策权留给前线的战士，才能避免纸上谈兵！

3.改进计划胜过最终得分；

成熟度评估的得分会给到团队明确的参考数据，但是团队需谨记，得分只是当前的一个结果而已，更重要的是基于得分情况规划出后续的改进计划，从而推动团队持续成长。

在成熟度模型运用的过程当中。得分的绝对数值高低没有价值，是否能够基于当前得分在未来有所改进才是重点。所以另一个需要避免的就是团队间的横向比较，团队由于在组织中所处位置不同，团队发展阶段不同、团队能力现状不同，会基于成熟度模型产生不同的改进方向和重点，横向比较错误的认为团队都应该具备同样的成长路径，从根本上就是错误的观点。

4.适合团队胜过打怪升级

大部分组织会错误地认为，敏捷成熟度评估分数的提高是一个持续的过程，只要还有更高的分数就需要一直向更高的级别努力。但是团队的成长需要长时间的能力和经验积累，适当的时候给团队喘息的机会，有利于团队巩固当前的核心能力，为未来的持续成长做好铺垫。所以，在某个节点上团队会找到适合自己的成熟度等级，在团队未产生明显的转变时过分地要求更高级别的数据反馈，无疑是拔苗助长！

成熟度模型使用步骤

成熟度模型的使用步骤，一般可以分为成熟度模型制定、团队成熟度评估、评估报告输出、团队改进计划制定、成熟度模型迭代几个动作。在这篇文章中主要介绍，对于对成熟度模型实践较少的朋友，往往比较陌生的模型制定和成熟度评估两个部分。

1.成熟度模型制定

模型的制定常见方式有两种：专家整理输出和专家引导下的团队共创。

（1）专家整理：

专家整理模型的第一步是对框架做整体设计，比如模型重点评估哪几个维度？每个维度会做怎样的拆分？

常见的维度可能包括产品管理、敏捷运作、团队治理、质量内建、技术卓越、敏捷文化等等。具体维度需要根据组织现状和诉求进行个性化设计。子维度的拆分则是在大维度的基础上拆分出更具体的类别，当然是否要拆分子维度也是基于专家判断进行设计。

大框架设计完成后，就会对具体内容进行细化，需要细化到每个评估项，评估项对应的评估等级以及计算方式等。

为了确保模型的客观和合理，需要通过多位专家的结对评审对模型内容进行把控，在多方评审通过后才可以进行发布使用。

专家输出的方法相对效率比较高，但是也会受到专家经验、能力以及对团队熟悉度等方面因素的限制。所以笔者更推荐通过专家引导团队共创来输出成熟度模型。

（2）团队共创：

团队共创的优势在于能够吸收团队各角色成员的经验和反馈，在模型整理过程中，可以更接近于团队现状和诉求，也可以避免专家独自输出后，再花费大量精力对团队进行宣导讲解的工作。

但这样的方式，同时也要求参与的人员都要对模型有一定的认知，才可以产出比较符合期望的模型设计。

所以在团队共创的第一步就是要对参与者进行敏捷成熟度模型的培训，可能包括了模型价值、使用方法、常见维度、评分规则等。

第二、三步是成熟度模型框架和内容的共创，主要完成的内容与专家独自设计比较类似，也是要包括维度、子维度以及内容的梳理。相比于专家输出，这种方式需要在内容产出后引导团队对模型进行审视，是否合理、是否全面、是否具备牵引作用等。

第四步是成熟度模型使用模拟，核心目的是通过模拟真实团队使用的场景，发现模型设计存在的问题，从而对模型进行补充完善。确保模型与组织诉求以及未来牵引目标相符合。

最后一步还是回到模型的持续改进上。敏捷成熟度模型并非一成不变，一方面模型在运用过程中会发现需要改进的问题，另一方面组织发展目标的改变也会对模型产生直接影响。所以不管是敏捷教练还是团队都需要持续关注敏捷成熟度模型的实用性，在必要情况下对模型进行调整改进。

以上是成熟度模型制定的主要手段和方法，当然，想要制定高质量的模型需要不断沉淀经验，也需要充分利用专家知识和经验，但是以上内容一定程度上足以为企业的敏捷教练提供模型制定的基本思路。

2.团队成熟度评估

团队成熟度的评估需要采用多种手段，目的是确保成熟度评估结果的客观和准确。常见的方式会有一对一访谈、实地工作情况观察（Go-See）以及团队文档查看等等。这里重点介绍访谈和Go-See。

在实际工作当中，无论是咨询顾问还是组织内的敏捷教练都比较容易出现采用单一手段进行评估的情况，原因是希望减少评估时间，更加高效地获得评估结果。但是往往结果适得其反，导致评估结果与实际差异较大，无法反映团队真实情况。

（1）一对一访谈

访谈是通用技巧，在工作中会频繁用到，目的是获取人们的观点、经验和见解。在敏捷成熟度访谈过程中主要的访谈步骤包括：

1）访谈预备：准备访谈的场地和设备，确保访谈环境舒适，同时准备好访谈所需的材料，如访谈提纲、问题列表等。

2）选取受访者：根据团队架构和角色情况，选择适合的受访者，常规来说会覆盖团队涉及的所有角色，以确保信息充分完整。

3）邀请和安排访谈：与受访者联系并邀请他们参与访谈，安排合适的时间和地点，确保双方都能方便参与访谈。比较好的的做法是在访谈之前就准备好访谈日历，发送给访谈对象，并在访谈中动态调整、及时通知。

4）访谈过程：在开展具体的访谈前，对访谈背景和目标进行基本介绍，必要情况下要确保受访者同意录音或记录访谈内容。在访谈过程中，根据问题指引进行提问，倾听受访者的回答，并在需要时进行追问或深入探究。所以，过程中也非常依赖于访谈人的提问技巧，往往都是敏捷领域专家承担此类工作。

5）数据分析和发现：对访谈数据进行分析和整理，识别出重要的观点、模式和主题。通过分析数据，发现问题的关键因素和深层动因。

6）结果呈现和报告：将访谈结果整理成报告、演示文稿或其他形式，以便分享研究发现和提供对策建议。

（2）Go-See

Go-See方法是一种通过实地观察来了解和改进工作流程的方法。它可以用于发现问题、改进流程和提高效率。以下是在敏捷成熟度评估过程中Go-See方法的基本步骤：

1）目标设定：明确目标，确定你希望通过Go-See方法了解和改进的问题、过程或区域。比如，希望观察团队迭代计划制定的过程，观察团队站会运作效率、观察跨团队协作的是否高效等等。

2）选择观察场景和对象：选择一个具体的工作流程、现场区域作为观察对象。确保选择的对象与你的目标密切相关。

3）观察准备：在观察前，了解相关背景信息，并准备一个观察指南或提纲，包括要注意的关键点、问题或指标。

4）实地观察：亲自前往现场，观察工作流程或区域的实际运作情况。尽量以旁观者的身份，注意细节和关键环节。可以的话不暴露身份，以确保观察到的是团队的真实情况。

5）记录观察结果：在观察过程中，记录重要的观察结果、问题、发现和不一致之处。成为后续成熟度评估的重要佐证。

6）与工作人员交流：必要情况下与现场的工作人员进行交流，询问问题、解释观察目的，并尽可能了解他们的想法、挑战和建议。

7）分析和总结：仔细分析和总结观察结果。识别问题、瓶颈或改进机会，并结合通过其他方式获得的信息找出解决方案或改进措施。

以上是成熟度评估过程中常用的两种方法的详细步骤。至此我们也介绍过了成熟度模型制定和评估的主要内容，关于报告产出、计划制定等内容读者感兴趣会在后续文章中逐步向读者介绍。

总结

这篇文章重点介绍了敏捷成熟度模型使用的原则和步骤，由于篇幅限制，并没有详细描述使用的全部细节，但阐述的内容是笔者在个人使用以及观察组织使用模型过程中认为比较重要的部分，希望能够给读者带来一些启发。也希望组织充分利用成熟度模型的价值，更好地牵引敏捷转型和组织发展！

推荐阅读：

敏捷教练不应被忽视的软技能

扔给团队一套标准流程为什么不能变敏捷？

想做好敏捷转型需要打通三条关键链

原文链接： https://mp.weixin.qq.com/s?__biz=MzUzOTgyNjc3NA==&mid=2247486885&idx=1&sn=8e0b8efdae1387d1840487529e9c30ec

相关推荐

如何破坏软件功能：常见缺陷模式

248

每个组织都应该沉淀属于自己的启发式列表。

一次CMMI虚假改进、评估的案例

429

早晨起来收到CMMI研究所发给所有主任评估师的一封邮件，是一个老外主任评估师，在中国的最近的一个评估经历。看到之后，心情极其沉重。这不是第一次看到、听到业内的这种做法，虽然以前，CMMI研究所的各方面人士在非官方的途径对中国与印度的评估有所抱怨，但是这是第一次CMMI研究所在全球范围内给所有的LA通报这么一个案例，这是一个有确切证据的案例。希望所有的中国的软件公司、中国的过程改进咨询公司、所有的评

我说CMMI之七：需求管理过程域

550

我说CMMI之七：需求管理过程域先讲讲需求管理的含义。何谓需求管理？需求管理就是管理需求的一致性。这里讲的需求指什么?指的产品与产品构件需求，对于软件而言通常就是软件需求规格说明书（SRS）。在CMMI模型中将需求分成了2类：客户需求，产品与产品构件需求。客户需求是采用用户的术语表达的，用户验收的依据，一般是由客户提出需求，由开发人员记录、描述、整理下来。客户需求是平衡了客户的需要、期望、约束和接口需求后的结果。产品与产品构件需求是采用开发人员的属于表达的，是开发方验收的依据。产品与产品构件的需求是基于客

我说CMMI之三：CMMI的构件

256

我说CMMI之三：CMMI的构件 CMMI中的内容是按照成熟度等级或过程域类别、过程域、目标、实践、子实践的方法来进行分类管理的，这些概念之间的整体部分关系可以参见下图。过程域的概念我们前面讲过了，这里不赘述。每个PA都有一个目的，在英文里明确区分了Purpose与goal这两个单词，我们翻译为了目的与目标。在中文里这2个单词病没有特别明显的区别。Purpose是一种抽象的，宏观的期望，goal是一种具体的，微观的期望。 PA之间有一定的关联性，互相影响，比如RD的输出为TS的输入，TS的输出又影

CMMI：收获的欣慰

250

晚上客户为我送行，今天是我最后一次现场咨询，12月底的正式评估我回避了。去年底我和他们一起努力，使他们公司通过了CMMI2级的评估，今年底将进行CMMI3级的正式评估。2年的时间，见证了他们的软件管理体系从无到有，从2级到3级的历程，回顾2年来的变化，甚感欣慰：Ø 项目经理能够编写比较详细的项目计划，进行比较完备的WBS分解；Ø 项目组每周都有例会，每个阶段都会里程碑评审，