让人又爱又恨的敏捷组成熟度评估

敏捷转型及敏捷团队运作过程中，我们会需要适时适机用到一些工具来让管理者或团队自身对所处状态做一个评估和诊断，这也是敏捷检视-调整过程的重要体现。

敏捷成熟度评估是很多组织在用到的一种工具。各家对敏捷成熟度有根据组织现状和战略目标来定制的不同评估模型，也有不同的评估机制。本篇用以介绍分享酷家乐特别适配了敏捷理论和公司运营形态的ATMM（Agile Team Maturity Model）敏捷组成熟度评估模型的实践经验。

如何加速研发，缩短从产品研发到推向市场的Gap Time 曾是困扰全球产研团队最大的难题。试想，一个灵光乍现的想法需要花费数月甚至数年，从概念澄清和调研、规划设计、开发、测试再到市场化，还有几个竞品会等你，还有几个客户愿买单?

在此背景下，敏捷开发流程有了萌芽。2000年春，一群满怀激情的程序员在美国俄勒冈州聚首，为加速研发速度，他们确定了两个核心目标：1、缩短交付周期，让市场来验证产品价值；2、尽可能聆听用户反馈并反映到新产品设计。作为敏捷最初的探索，虽然整体流程和标准与2010年第一版Scrum Guide内容有较大不同，但是对敏捷开发来说也是一个意味深远的里程碑时刻。

敏捷的定义和流程本文不做赘述，有兴趣的伙伴可以看一下Scrum Guide。本文主要将关注点聚焦在敏捷成熟度评估。随着敏捷开发被更多学者、企业、开发者等认可，越来越多的公司开始应用该流程为研发流程加速。随着敏捷开发流程的应用，敏捷走查的普及，对敏捷成熟度评估的需求也日益增长。就像一辆日常行驶了1万公里的BMW需要体检和保养一样。当站会、planning、review等敏捷会议成为日常，团队成员需要一种内部工具，由内向外帮助个人和组织了解当前敏捷实践和团队情况，并对症下药。

敏捷成熟度模型是一个基于经验不断演化优化的评估框架。我司从最开始借鉴其他公司的评估维度，到适配内部产研情况，从AMM1.0（Agile Maturity Model），评估开发组织当前敏捷状态的框架，升级为ATMM2.0（Agile Team Maturity Model），从多个维度衡量‘敏捷组’的成熟度，直至今日到ATMM3.0。ATMM源于敏捷但不限于敏捷，在落地应用过程中不断检验和调整模型，逐渐打磨为对组织和团队最适配状态，如基于公司项目的刚性交付诉求，在模型中引入对于团队交付承诺的价值观和能力等评估。毋庸置疑，一个适配了敏捷理论和公司运营形态的成熟度模型才能更好的评估敏捷组现状和将来的目标状态，帮助团队识别改善空间，明确改进措施。

Manager：团队运行了一段时间敏捷流程，不知道大家现在什么情况？

PO：需求上线一直被delay，到底是我需求写得太快还是？

Dev Team：怎么SP总是评估得不准，是我的问题还是需求的问题？

SM：站会都说进度正常，为什么到上线的时候就炸锅？

中医中的望闻问切是通过观察，聆听、询问对病人的整体情况做一个诊断，类比敏捷治理工具，如：敏捷走查、度量、成熟度等，个人认为望闻问切和敏捷成熟度评估最相近。评估人基于评估维度对团队进行引导讨论，聆听团队的分析，观察团队的行为，基于团队分享的案例和对未来期望确定整体改进措施和责任人。成熟度有一个相对明确的框架和场景设定，相比retro能更具像、系统和深入的帮助敏捷组和组织理解当前的状态，识别和最终目标之间的差别，为接下来的改进提供了方向。同时值得注意的是ATMM评估结果是该敏捷组的私有知识和经验资产，意在帮助敏捷组进行改进方向识别，不做团队间比较。

2022年1月，基于管理层想对某业务线现行敏捷组运行情况进一步了解的背景下，由PMO主导对团队内两个稳定运行的敏捷组进行了成熟度评估。下文将基于本人在成熟度评估过程中经验做一个过程分享和经验总结。

评估流程

评估人：PMO

参与人：敏捷组全体成员

1. 成熟度评估方案制订:基于敏捷组业务和运营情况，结合团队有项目交付需求，明确本次度量维度为五个评估维度：团队角色和协作、产品需求、计划和监控、以客户为中心、质量保证

2. 对敏捷组全部成员进行成熟度评估流程和维度培训，只有对成熟度评估有充分认知和认可，团队的参与积极性才能被更大程度的激发，评估效果才能不断提高 

3. 以团队为维度进行成熟度评估沟通会，再次介绍各维度详细情况和评分标准。根据评估场景描述，邀请团队有针对性的进行10分钟讨论，给出最终评分和案例分享，过程中度量负责人可引导讨论的有效进行并进行沟通记录

4. 根据团队评分编辑雷达图，根据头脑风暴时团队分享的案例以及高阶场景最佳实践对团队现状复盘和对未来改进措施确认，责任到人，明确完成时间

5. 敏捷组对后续Action进行长期跟进，对结果负责。

（示例数据）

团队反馈

完成成熟度评估的敏捷组均表示该评估能较精准地反映出团队的运行情况，很有意义。通过团队一起头脑风暴，对各个维度，各个评分要求进行有效的梳理和盘点可以让团队成员对敏捷组运行有更清晰的认识。基于各个评分标准的案例描述，团队会反观自己，提出可行的改进措施。各改进措施匹配明确的负责人和完成时间，由敏捷组统一监控完成情况，培养团队凝聚力和责任感。此外，在复盘评估过程中团队可能会针对当前产品、需求、质量等因素综合梳理出原来没有意识到的问题和需求，如对前端、测试资源的需求等。查漏补缺，从而进一步完备敏捷组的配置，提升敏捷组的潜在战斗力。

ATMM是为敏捷组和组织提供的衡量"敏捷组"成熟度的工具，对团队来说也是一个内观，以期追求更好状态的机会。如何高效优雅的进行成熟度评估对流程评估人有一定的要求。流程评估人需要对各个维度评分有清晰的认知，对团队目前情况有大致的判断。过程中，评估人需要对整体流程进行引导和聚焦，如，在评估过程中有效引导团队的思考和讨论。评分不是一个数据，而是对团队进行各重要维度全方位的体检，以案例论事。邀请敏捷组以团体形式对未来期待和目标进行设定，对措施进行实施。

完成成熟度评估只是一个开始，不是一个结束。最佳的状态是完成评估后团队成员对团队成员、团队协作、团队现存问题等有了清晰认知。能够较明确的知道出现在的问题根因是什么，团队应该如何应对，如何解决，什么时候完成等。

Manager：团队运行了一段时间敏捷流程，不知道大家现在什么情况？

Manager：敏捷组整体成熟度还是比较高，尤其是质量保证稳度，评分有5分。需要更多关注的是产品需求和计划和监控模块。

PO：需求上线一直被delay，到底是我需求写得太快还是？

PO：团队说我的需求文档写得像散文，不够落地和明确。后面我会更关注文档质量，在需求评审的时候和大家产生有效的信息传递减少需求误差和返工。

Dev Team：怎么SP总是评估得不准，是我的问题还是需求的问题？

Dev Team：后端开发以新人为主，在评估SP的时候存在比较大误差。TO近期会对内进行一次devdesign和估时培训，提升大家的估时能力和意识

SM：站会都说进度正常，为什么到上线的时候就炸锅？

SM：产品需求没有澄清，开发估时太乐观。进度监控是一个比较综合的事情，不能只催进度，要从根源解决问题

参考文档

Planview, 2022, The History of Agile https://www.planview.com/resources/guide/agile-methodologies-a-beginners-guide/history-of-agile/

AMM敏捷成熟度评估框架介绍 https://blog.csdn.net/huver2007/article/details/76168482

Henriques and Tanner, 2017, A SYSTEMATIC LITERATURE REVIEW OF AGILE AND MATURITY MODEL RESEARCH

Muthu Ramachandran, 2009, Agile maturity model (AMM): A Soware Process Improvement framework for agile soware development practices

Schwaber and Sutherland, 2018, Scrum Guide