这是鼎叔的第一百一十九篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社）。

本合辑前面的内容都是从项目敏捷维度来度量的，上一篇介绍了技术团队的工程成熟度度量，聊聊阿里巴巴的卓越工程。如果我们把视野再扩大一些，如何针对产研团队整体敏捷状态进行准确的评估呢？只有找准团队敏捷短板的指示器，才能找对自我提升的好策略，持续实施正确的敏捷动作。

什么是 AMM

这里我先介绍一下敏捷成熟度模型（Agile Maturity Model，AMM），它是由 ThoughtWorks 公司提出的一套评估组织现状，设定改进目标，监控持续改进和度量敏捷成效的模型，分为 6 个度量维度：需求、测试、代码集体所有、协作、保障和治理、简单性，给每个维度的可观察现象或行为进行打分，用雷达图等方式可视化呈现。

注意：AMM 是问卷调查评分方式，而上文提到的卓越工程是平台自动评分方式。

敏捷成熟度模型是团队的一面镜子，评估和识别团队当前的优劣势。围绕设定的敏捷成熟度目标设立基线，定制适合本团队敏捷现状的可视化仪表盘，帮助大家聚焦迭代改进的路径。最终目的是培养出一个能自组织提高效能的团队，同时打造出有竞争力的产品。

敏捷成熟度模型以团队为核心来整体评估现状，关注三个视角——管理、产品和技术，和上篇的成熟度量化方式一样，根据评估总分可以对应到五个级别：

入门级：团队刚刚接触敏捷理论，实践动作不规范，团队有指定角色，但还处于磨合中。
基础级：团队已有了良好的迭代节奏，能够在完成每个迭代的过程中通过回顾，持续微改进。
规范级：团队已掌握了基础的完整敏捷实践理论（在产品，技术和管理层面），能在实践中保持严格的敏捷纪律，有稳定的持续交付节奏。
成熟级：团队敏捷过程已经非常成熟，能够良好地响应各种市场变化和用户变化。
卓越级：团队有能力发明新的技术和实践，解决各种未曾遇到过的阻碍和低效难题。

整个敏捷成熟度的可调查问题众多，大部分要点在合辑的敏捷关注中都有相关阐述，对应每个级别都有相应的评分区间，便于单项打分，最后汇总分数判断团队的整体敏捷度级别。

对于 “是否一贯做到” 的行为调查问题，可以按频率来选择答案，比如 “一贯如此”（90% 以上场合能做到），“经常”（60%~90% 场合做到），“有时”（30%~60% 场合做到），“很少”（30% 以下）。也可以由团队具体定义不同级别应匹配的行为频率。

本文尽量少给具体的定级数字，以免被读者当成行业共识的衡量方案。不同团队有不同的业务类型、发展阶段和文化特征，会导致其优先采纳的敏捷措施差异很大。

下面尝试从这三个视角提供系列调查问题（划了考点），让读者有一个整体印象，这些问题也是对公众号过去知识的精华回顾。

大家可以参考它们来制定团队自己的成熟度调查问卷，也可以针对局部敏捷实践范围进行成熟度的度量改进，牵引出下一阶段如何提升的具体路径。但要避免僵化的指标考核，避免它成为团队间绩效 PK 的工具。

以后我们还会呈现这套思路，分别针对工程效能和精益需求，来设计更具体更聚焦的成熟度调查问卷。

管理视角

管理视角评估的敏捷成熟度体现在自治理团队、沟通协同、快速响应等方面。推荐的评估问题有：

1 是否具备跨职能的全功能特性团队（产品、开发、测试等），所有人是否全职参与迭代？全功能特性团队的规模是多少？推荐 7~11 人作为最佳规模。

2 团队所有成员是否随时可以顺畅交流？能否随时面对面交流，是否因为异地办公导致内部问题响应不及时？

3 团队和产品经理能否遵循迭代日历节奏，按时完整地进行各项关键迭代活动？每个特性团队是否有制定合理的迭代日历？迭代周期是否在 2~4 周内，且能固定保持？

4 团队各种会议是否富有成效，议程准备充分且聚焦，不拖堂，参与度积极？是否总是有清晰的会议纪要，达成指导下一步行动的成果。

5 团队各个角色的业务目标是否一致，每个迭代的目标是否明确，能否共担责任？团队是否承诺共同为质量负责，而不是个人对问题负责？

6 团队是否有效利用了看板机制，把各种管理信息透明化，能随时检视和调整？包括产品规划路线图，发版计划，迭代风险和改进事项。SM（Scrum Master）是否在站会后更新了看板信息并记录阻碍和风险，并在会后对其跟进，确保阻碍被移除？

7 团队是否共同估算工作量大小并承诺迭代工作范围，不会受到领导或外部专家的影响？团队根据自身实际情况和历史迭代速率制定可行的迭代计划，能否做到既不过度承诺，又不过于保守？团队是否已经形成持续改进的文化，制定了切实可行的改进措施，并明确了关键责任人？

8 团队的人员稳定性是否良好？团队的氛围是否灵活且积极，能够应对外部冲突？每个成员是否能感受到自己的工作是有价值的，内部满意度高？

9 对于大型团队（由多个敏捷特性团队组成），是否存在高效机制（如 Scrum of Scrums）在多个团队中例行协调，保证干系人参加，成功管理关联特性的依赖和风险，对齐发布计划并成功实施？

10 特性团队或大型敏捷团队是否有例行的交流分享，及时传播重要的经验教训（每 2 周至少分享一次）？有价值的信息（产品、技术、过程等）能否及时有效的沉淀下来，而不是靠口头交流，成员获取信息非常方便？团队是否及时运用项目协作工具，准确更新项目信息？

11 团队是否有明确的 DoR、DoD 定义并全员形成共识？产品需求进入迭代开发之前是否满足了 DoR？迭代内所有计划应完成的故事（考虑风险影响因素之后）是否都能达到 DoD（通过了集成和验收测试）？

12 团队是否能有意识地控制每个成员的并行工作量，避免频繁在多个任务中切换？

产品视角

产品视角评估的敏捷成熟度体现在关注用户、价值驱动、可持续发展等方面。推荐的评估问题有：

1 产品人员是否准时参加团队敏捷实践活动，例如需求梳理会议、站会、桌面检查、迭代结果演示和迭代回顾会议等？

2 产品经理是否通过用户故事的形式来定义需求，并给出详细的验收标准？用户故事是否总是符合 INVEST 原则？团队是否能清晰呈现用户使用产品的历程（比如使用故事地图等方式），让业务和开发对需求场景的理解能够准确对齐？

3 产品团队是否维护并及时更新了所有未完成工作的产品待办清单？其中包含了新特性，优化特性，遗留缺陷和技术类故事等工作，并全部进行了排序。清单上的事项是否具备 “越近越细，越远越粗” 的特性？

4 近期的用户故事是否都已经拆分到了适合迭代开发的颗粒度（5 人天以内）？

5 产品设计是否为涉及界面的功能准备了原型（DoR 的条件之一）？原型验证阶段是否引入典型用户参与，获得真实可信的反馈？

6 团队是否能够在迭代中尽早将完成的故事展示给产品经理和干系人（尤其是客户），搜集反馈并进行调整。

7 新版本软件的发布周期是多久（从进入需求到全量发布）？

8 团队能否持续围绕产品愿景和目标，关注市场和竞品的情况？整个团队成员是否被清晰的传达了产品的愿景和可量化的目标？持续将洞察转化为产品规划和设计中，基于可量化的成功衡量标准进行监控并形成提升闭环，则可以获得高分评价。

9 团队是否已对目标用户进行清晰的分类和画像，对用户行为进行系统理解，针对其特征进行针对性的需求分析？能够具体阐述清楚服务对象和场景化的用户旅程，描述如何解决他们的诉求，能带来什么收益，并在整个研发工作中进行关联考虑，则可以获得高分评价。

10 团队是否会通过定性研究识别机会点以及背后的动机，将洞察结果注入到产品改造过程中？是否会通过定量研究，通过采集用户行为和反馈数据，为产品假设提供数据论证，以便调整后继发展策略？

11 团队是否有完整的需求价值评估维度，能进行合理的需求拆解和优先级综合排序？对新需求是否有清晰的 MVP 定义和发布规划，能够及早验证想法？

12 团队是否整合了内外部所有的用户反馈渠道，且触达最终用户的成本足够低？能否尽早审核用户反馈并正确分类，将反馈数据的处理过程形成高效闭环？

技术视角

技术视角评估的敏捷成熟度体现在设计简单、持续交付、质量保障等方面。推荐的评估问题有：

1 是否存在业务知识和技能的单点瓶颈（即缺乏其他人备份）？团队各个职能可以互相备份技能。不会因为人员缺席导致进度被阻塞。

2 TL 和团队是否针对所有技术故事的验收标准达成一致？应完整覆盖业务关心的功能、非功能性需求、业务规则和范围。

3 在实际编码之前，测试人员是否已经完成对完整测试场景的第一轮分析和设计？测试是否和开发人员对用户故事的验收测试场景达成了共识，避免理解歧义导致的返工？

4 开发人员在转测试之前，是否已给测试以及产品人员进行了当面演示（按照验收标准和验收测试场景）？

5 团队是否建立了例行的代码评审机制，并保证评审发现的问题能进行修复？最好情况是，每天都有例行代码评审，但花费时间可控（1 小时以内）。记录内容以共享知识为主，且记录的问题能回溯。

6 团队是否有经验丰富的架构师或者技术负责人，作为特性团队的成员，参加团队关键研发活动，传递技术经验，并独立交付任务？包括：贡献核心代码及评审把关，识别技术债务，优化测试策略，跟踪质量内建指标，推广合适的前沿技术，在技术风险和方案落实上和 PO 达成一致计划。如果架构师把精力过多投入到其他工作（人员管理、任务分工、非技术会议等），则评分会降低。
架构师在代码方面的贡献应包括：框架搭建或引入、技术难点攻关、核心业务逻辑实现，代码简洁化封装和风格一致化。

7 团队是否在新特性进入开发之前就完成了技术方案的概要设计？概要设计评审重点关注外部依赖、组件模型、数据结构和性能等因素，尽早识别技术风险。所有故事都能确认技术方案并归档。

8 产品与外部相关系统的依赖关系梳理完毕，能够独立编译、测试和升级。相关系统包括后台相关服务、第三方接口、调用公共框架和公共组件等。

9 配置管理是否统一，包括被测应用代码、单元测试、自动化测试脚本，数据库操作脚本和环境自动配置脚本，均存放在统一源代码库中？存放的目录应合理，保证一次性成功提交。

下一篇，我们聊聊不同成熟度发展阶段该如何达成，以及如何设计敏捷调查问卷。