互联网公司敏捷成熟度模型实施办法

敏捷成熟度模型实施办法一、简介敏捷成熟度模型（AgileMaturityModel,简称AMM）,面向全体IT员工，通过8个维度x5个级别，对各团队的敏捷成熟度进行评估，并帮助团队寻找持续改进的方向和目标。该模型通过“需求管理”维度引导团队提升价值识别与需求管理的能力，促使团队“做正确的事情”；在“技术卓越”和“质量保障”的基础上，以“计划跟踪”引导团队确保“正确的事情”能够有效的落地和交付，并灵活的应对变化；通过“流程协作”和“共享职责”引导团队以经过共识的流程规范为基础，加强团队合作，提升团队凝聚力，并通过“度量改进”和“持续学习”维度引导团队在数据度量的基础上，持续改进，不断进步。每个度量维度分为“0-初始级”，“1-成长级”，“2-成熟级”，“3-优化级”和“4-创新级”五个级别，用于引导团队识别当前阶段的优化目标，确定持续提升的路径。相对于评估得分，我们更看重团队在发展目标方面达成共识，持续挖掘提升的办法并落地实施，不断实现自我改进二、使用方式1a.各维度自评团队自行组织并根据现状做出评估。方法如下：a）进入某个维度之后，成员自低向高默读各级描述。若所在的团队与某级别中任一条描述不符，则视为该团队还尚未达到该级别。此时，请停止阅读；b）准备好代表前一级别的手牌及为什么尚未达到该级别的事例；c）当所有人准备好手牌后，大家同时出牌，出牌评级低的组员向出牌评级高的组员解释尚未达到该级别的原因和事例，并相互讨论；d）通过再次默读并出牌，或直接讨论达成一致等方式，得出团队在该维度的自评级别，并绘入雷达图中。1b.改进措施讨论a）针对上一次自评的行动结果进行检视；b）将八个维度的结果绘制入雷达图中；c）对比之前的自评结果，选出2~3个维度讨论改进意见。建议选择方法：评级最低的维度，或退步的维度，或长期没有进步的维度，或严重短板的维度；d）选择出的维度，对标下一级别，针对尚未达到该级别的原因，讨论出改进目标、切实可行的行动及负责人；e）带走行动计划，会后采取行动持续改进。管理团队评估管理团队根据观察了解到的团队运行情况，给出团队的评估得分。讨论共识敏捷团队与管理团队一起对成熟度评估结果进行共识，并明确下个评估周期改进策略的过程。方法如下：a）每团队出2~3名代表，与管理团队一起共识团队当前的评估评估结果。b）管理团队根据评估结果对团队进行打分。最终得分=当前评估分均值*权重+（当前评估分均值-上次评估分均值）*（4*权重）-扣减分if（评估得分跟上次相同，没有任何提升）c）管理团队与敏捷团队共同确定下个评估周期的行动计划和跟进策略。

三、评估示例【第一次评估】得到团队的敏捷成熟度初始值。经团队讨论共识，选择技术卓越、共享职责两个维度作为改进方向，确定改进措施。壅度9012Q4壅度9012Q41计划跟踪1技术卓越1证11共享职责1建进01XX团队敏捷成熟眺呈图5012口4推埋学习03计划亲岩D.SD.4D.2M宣溟适a技术皇懑共享职责1?皇保迁SOfE【第二次评估】团队跟进上次评估之后确定的改进措施，在技术卓越、共享职责和度量改进三个维度的评估得分得到了提升。经团队讨论共识，选择需求管理、流程协作两个维度作为XX团队敏捷成熟度度量图育束费注计龙供U麒XX团队敏捷成熟度度量图育束费注计龙供U麒9012Q49013Q1需求冒里11谀麟11技术卓越12辰星保证1111共蛔12度宣醐0111改进方向，确定改进措施。【第三次评估】团队跟进上次评估之后确定的改进措施，在需求管理和流程协作两个维度的评估得分得到了提升，并确定下一步的改进方向和改进措施。

XX团队敏捷成熟模度景图的T学习计划战略H珈XX团队敏捷成熟模度景图的T学习计划战略H珈盖程U•作【第N次评估】团队基于上次评估的改进措施持续改进，并确定下一步的改进方向和改进9012Q4901迎9013Q2需求管理112计划跟踪111技术卓愁122底量保证111瀚呈协作112共享职责122度量改进011111措施，同时对成熟度模型进行优化。四、模型详述1、需求管理《人月神话》的作者弗雷德里克•布鲁克斯曾经说过，"产品开发中如果只有一件最困难的事，那就是精确的定义做什么。”需求管理，从来都是产品开发中的重点和难点。本维度用于评估团队是否对用户价值有清晰的认识，是否可以通过透明化的ProductBacklog反映商业目标，并进行科学有效的管理，以及团队将用户反馈与目标结合的技术能力和对用户反馈的响应能力。等级设定等级设定内容0-初始级团队没有对用户反馈的响应，或未利用用户反馈来影响团队的工作内容。需求获取比较随机，没有用户调研方面的技术方法，研究过程没有统一的流程或方法指导。交互设计没有清晰的交互设计流程框架指导。没有形成ProductBacklog，或者虽然存在ProductBacklog，但团队成员需要花费额外的精力进行索取才能获取到最新版本的ProductBacklog，未能实现

ProductBacklog的透明化。在体现形式上，需求表现为传统的需求文档，通常关注于需要实现的功能，未能体现预期的用户价值和商业价值.通常在项目早期就冻结需求，很难处理需求的变更。1-成长级开始引入定性或定量的方法对用户数据和用户行为进行分析归纳总结，并指导产品定位和发展方向。交互设计有一定的交互设计理论或方法支持。存在对所有成员可见的ProductBacklog。（意味着，任何人在任何时刻，不需要额外的沟通，都能够看到最新的ProductBacklog。）PO偶尔会对ProductBacklog进行管理（如ProductBacklogItem的梳理，优先级的调整和维护等）。以用户故事的形式对需求进行描述，但用户故事缺之一些重要的兀素，比如用户价值，AC（验收标准）等。用户故事的描述相对比较笼统粗略，同时，由于缺乏必要的信息，难以对用户故事进行估算。需求随着时间的推移逐步细化。2-成熟级史诗故事、用户故事、技术任务等待办事项之间的关系能够清晰的在ProductBacklog中得以体现。团队对用户反馈的响应有相应的承诺，并在多数时候履行承诺，对用户反馈的响应体现在组织目标中。交互设计具有设计理论和方法的支撑，尝试引入组件化设计提升设计效率，保证界面设计规范性与一致性。ProductBacklog满足DEEP原则。（注：健康的ProductBacklog需要满足DEEP原则，即详略得当的DetailedAppropriately，涌现式的Emergent，经过估算的Estimated，经过优先级排序的Prioritized）在ProductBacklog设定优先级时考虑用户反馈，根据从用户处获得的知识和观点对ProductBacklog中的内容进行调整。以标准的用户故事形式对需求进行描述，用户故事中包含对用户价值，AC（验收标准）等的描述，以便于就此对故事的规模、风险、优先级进行估算调整。

3-优化级团队能从政策法规、竞品分析（如其他相关相似产品）、用户反馈（如建议、BUG等）中有效识别并记录需求，并按照需求的方式进行跟踪与解决。PO定期与用户进行交流，团队会定期结合用户反馈，基于定性和定量的方法基础设定Backlog中的工作优先级。所有团队成员都参与到与用户反馈的响应中，并总能履行对用户反馈的响应的承诺，对用户反馈的响应体现为组织目标的核心。需求获取与需求管理有清晰的方法论指导，用户故事满足INVEST原则，且相互之间的关联和依赖关系得到有效的识别和体现，尝试使用影响地图、用户画像、用户故事地图、MVP（最小化可行产品、MinimumViableProduct）等实践指导工作。团队能够围绕用户故事实践端到端的需求管理和反馈，且需求处理过程对相关干系人高度可见（注：流程清晰，需求所处节点清晰，并通过工具进行可视化）。团队知道如何在其中长期计划中识别风险与不确定性，并基于团队的速率来调整项目范围。4-创新级团队从专注于功能实现转变为专注于产品实现，有能力识别正确的产品路线，共同提出和收集需求，并确定ProductBacklog的优先级。交互设计过程全面引入以用户为中心的交互设计流程，形成界面与交互规范，有比较完备的组件化库。2、计划跟踪本维度用于评估团队根据需要运用不同的技巧进行计划活动（Release级别和Sprint级别），以及在一个产品发布周期内，跟踪与监控计划的执行状况，管理风险，应对变化，最终实现用户价值交付的能力。等级设定等级设定内容0-初始级ProductBacklog缺乏恰当的管理，ProductBacklogItem未进行恰当的细化分解。团队未借助于估算方法（比如：StoryPoint等）做Release计划和Sprint计划。

团队速率不可知也不可信，或者每个迭代上下浮动偏差较大，导致Release计划和Sprint计划可信度不高。计划安排需要索取、汇报方可获得。1-成长级ProductBacklog优先级排序对团队清晰可见。计划信息放在公共的地方，可以方便的获取。（意味着，任何人在任何时刻，不需要额外的沟通，都能够看到最新的计划安排。）高优先级的ProductBacklogItem经过恰当的拆分和细化，其大小可以比较容易放入一个迭代进行交付实现。高优先级的ProductBacklogItem经过粗略的估算，以便用于计划制定。团队能够持续收集和统计历史产能数据（团队速率基于相同的基准进行评估，得到的速率可信，可以用来指导计划的制定），并且能够结合自身交付速率和交付物的完成标准（DoD）制定短期的发布规划（Sprint计划）。ScrumMaster负责监控风险和进度，并能知会给相关干系人。团队大多数时候可以完成Release和Sprint计划目标（注，不会在迭代结束的时候把一批任务手动移动到下个迭代）。2-成熟级团队能够掌握工作项分解和评估的技巧，共同对ProductBacklogItem的规模进行估算，有效识别潜在风险点，并结合团队速率制定Release计划和Sprint计划。用户故事具有清晰的验收标准（AC），各流程节点具有清晰的完成标准定义（DoD），确保团队认知一致。ScrumMaster主导，团队成员参与监控风险和进度。团队使用工具（如BurningDownchart等）来跟踪进度情况，并且能够有效的发现计划执行过程中的问题和风险。如果注意到偏差能及时采取纠偏行动，确保进展情况与理想进展趋于一致。能够持续达成Release目标和Sprint目标，在Release或Sprint结束时有能工作的软件进行演示（没有hacks）。3-优化级团队成员共同通过工具（例如运用Burningup/Buringdown图表或者度量值来

跟踪）有效的跟踪发布版本，共同积极监控风险和进度。如果注意到任何偏差都能及时采取纠偏行动，并及时通知给相关干系人。工作进展高度透明化，进展、阻碍、风险等内容可以通过工具（如白板，JIRA看板，Dashboard等）得以呈现。团队能够根据项目范围或资源上的改变来调整自己的计划，变化对于团队承诺的提交能力上影响甚微。4-创新级团队完全掌握并使用计划的技巧与方法，即使没有团队速度的历史数据，也能进行短期及中长期的计划，并且可以为项目干系人提供充足的数据来支持计划的立项。团队可以有效的应对项目交付中的各种变化和不确定性，如技术架构方案不确定性，中间需求变更或者方案变更，确保最终产品的顺利交付。团队工作结果高度可预测，所做计划高度可信，团队能持续完成承诺的交付。3、技术卓越本维度用于引导团队通过应用优秀的技术实践，不断优化代码架构，提升软件工程能力，提高团队持续集成和持续交付的能力。不仅让软件工作，更一直追求精益求精，并持续提升。等级设定等级设定内容0-初始级团队很少关注，也没有监控代码质量。验收之前，代码未经过评审（codereview）o设计、编码、测试用例尚没有形成规范。没有进行接口测试，没有自动化测试，缺陷引入率很高。没有结对，每个人独立工作（此处指的不是结对编程，更而是倾向于引导团队成员之间的相互支持与协作），从需求、设计、开发、测试到编写文档的工作线性进行。功能发布前置时间（也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。）很长，上线风险高。

团队有代码分支管理策略，但对于各分支创建、合并、删除等的操作时机、标准（如代码分支在何时，需要满足什么条件的情况下，由谁合并入哪个分支，分支合并之后需要执行哪些验证操作等）尚没有明确的原则和操作规范。1-成长级团队开始关注并使用工具对代码质量进行监控（比如，使用sonar，checkstyle等进行持续监控）在软件架构、接口、代码、测试用例等方面已经形成规范，但团队不太了解规范制定背后的原因，团队开始按照规范进行执行，但执行情况并不甚好。遵循代码集体所有制，在执行过程中，代码没有经过很好的讨论和设计，会出现需要返工重写的情况。有代码评审，但尚未成为例行且规范化的操作，固化到团队的迭代开发工作中。开始尝试进行自动化测试，测试是开发流程的一部分，但以测试人员为主，缺陷持续的引入。构建过程和测试过程需要手动操作，未形成自动化的持续集成流水线。团队共有统一的代码分支管理策略，在代码分支的创建、合并、删除等的操作时机、标准有明确的原则和操作规范，团队能够按照规范执行相关操作。2-成熟级软件架构设计、接口设计、数据库/表结构设计、代码、测试用例等可操作的规范，团队认可规范且清楚规范制定背后的原因，且各项规范得到执行和监测。代码集体所有，软件架构、接口、数据用表结构设计得以监控，在发生变更时会经过讨论和评审。不会出现返工重写的情况，方案讨论、代码评审、测试用例评审常态且有效。开始形成自动化测试的习惯，且团队内全部成员共同拥有自动化测试技能，并在需要时进行自动化测试用例的编写。通过自动化构建和自动化测试，建立起持续集成的流水线（自动化），并对软件质量进行持续监控。需求、设计、开发、测试到编写文档的工作有计划的并行进行，迭代开发的功能可以在迭代内发布上线。3-优化级具有较好的架构设计，对于涉及多个系统的功能，各系统可以单独部署上线。

通过功能开关、白名单、版本控制等方式确保上线过程安全可控且可灵活回滚。有成熟的灰度发布机制控制发布节奏并灵活控制已上线功能对不同用户群的可见性。大部分功能可以不需要客户端发版就能够实现，减少应用市场审核，能够有效的降低应用市场拒审、下架等风险。团队开始探索和实践软件工程的技术，如：简单设计、测试驱动开发、结对编程等（以上几条仅为举例），有本地化的实践并长期坚持。针对技术债务，团队把重构列入计划并坚持进行。交付频率进一步提升，可以在一周内实现新功能的增量发布，同时，也可以及时处理用户的反馈。软件系统基本不会出现线上问题。4-创新级在产品开发策略和方向上，技术卓越是商业运作的优先考虑方向之一。高预见性和低技术债务所带来的更低风险和更少开发成本，使团队有更多的时间在为用户开发增值功能。具有良好的架构设计，各系统具有较高的性能指标，灵活的扩展性。微服务架构有利于支持小规模团队运作，减少团队之间的依赖，支持devops能力的持续提升。自动执行软件交付和基础架构更改流程，可在其中快速、频繁且更可靠地构建、测试和发布软件。4、质量保障本维度用于评估团队产出物的测试验证被纳入研发流程管理的程度，以及测试验证由所有成员合作执行的程度。本维度同时关注利用自动化手段完成这些测试验证活动的程度。等级设定等级设定内容0-初始级很少预先考虑测试，没有将测试、验收等工作纳入用户故事的估算中（DoD的标准是到可上线的标准）。测试集中在迭代后期进行。

只有测试人员负责制定测试计划、执行测试和自动化测试。文档性交付物没有一致的框架结构，未针对文档内容提供验收标准，完成后只有非正式审阅，没有相关干系人参与的评审。1-成长级预先考虑测试交付过程，将测试，验收等工作纳入用户故事的估算范围。（备注：DoD为达到可上线的标准，因此在估算的时候需要考虑到各步骤中工作的规模、复杂度、风险等因素。）开始讨论测试策略，与相关工作的优先级和风险。测试工作平滑的分布在迭代的各个时期，很少出现没有工作可测的情况。团队共同制定测试计划，实施ATDD，验收用例按照Given-When-Then（在什么样的条件下执行什么操作得到什么样的结果）的形式清晰描述。团队开始定义相关的交付质量过程指标、对外交付质量指标分析团队质量保证方•面的现状和优化方.向。初步约定文档性交付物的框架结构，开始针对文档内容提供验收标准，并邀请相关干系人共同参与的评审。2-成熟级在用户故事计划阶段和迭代过程中，测试、验收等工作都已经进行充分的考虑。测试在迭代的较早时间进行，发现与解决问题数量曲线在整个迭代周期内相对平稳，没有太多问题滞留到后续迭代中。对各类型、各层级测试方式（如功能测试、性能测试、兼容性测试等）的适用范围和执行时机有清晰的规划和执行标准。自动化测试方法达到一定程度的覆盖，可以自动监控并保障每天的代码提交质量（比如，在代码提交时，分支合并前，分支合并之后，自动执行哪些测试用例，确保可以尽快的对代码变动予以反馈，及时发现问题）。团队持续遵守完成的定义（DoD），验收测试能充分验证所做功能，回归缺陷能够立刻修复。团队使用度量指标值辅助产品质量的提高。文档性交付物体现出一定的计划性，与商业目标基本保持一致。不同类型的

文档（预研，调研，设计，使用手册等）具有输出标准及评审流程，并得以执行。3-优化级团队考虑质量内建和风险前移，通过如需求评审、UI评审（UI规范）、设计评审（表结构，接口，关键需求点等）、代码评审、结对测试（注：考虑减少自己写自己测试导致的思维受限）等活动，将测试融于软件开发的各个阶段，从而最大程度上减少产品发布的稳定周期和上线风险。所有团队成员都参与质量策略和方法的学习、创建、部署和改进，验收测试驱动开发（ATDD）已被很好的实践，团队邀请相关用户参与测试验证。有完善的自动化测试策略，致力于提高自动化测试覆盖率，构建自动化防护网（场景覆盖与异常分支覆盖）。测试手段更加丰富，如静态代码检查、内存泄漏检查、性能测试（压力测试、负载测试）得以实践，各种测试手段可以有效的保障软件系统质量（包括内部质量属性和外部质量属性）。文档性交付物有较高的计划性，与商业目标保持一致，基于文档输出标准及评审流程，团队不同人的产出物稳定。4-创新级质量风险前移成为团队规划质量保证的核心思想。在迭代开发过程中完成集成测试和系统测试，质量保障措施可以达到支持每日随时上线的标准。5、流程协作"协作：指在两个或两个以上一起工作的人之间，循环式的知识互动以及相互学习的过程。这个过程是推动团队实现共同创新目标的一种智力工程。”-维基百科本维度用于评估团队内部相同角色成员之间、不同角色成员之间，以及团队与跨部门甚至跨公司的不同团队之间，基于共同的目标，在经过共识且不断优化的流程规范之下，进行沟通协作的能力和成熟程度。

等级设定等级设定内容0-初始级团队有约定俗成的需求和问题处理流程、项目与团队运作规范，但仅存在于团队成员的头脑中。在有新的成员加入团队时，需要几个迭代的摸索后才可以对团队的运作方式有清晰的了解和认识。团队成员对很多沟通和会议（敏捷实践活动的简称，包括会议、讨论、评审、交流等）的价值和原因不理解，感觉这些会议是浪费时间。会议的组织和方式不好，有时没有让应参与进来的团队成员参与（尤其是当涉及到远程团队成员时），会议效果经常不能达到原定目标。团队工作目标和优先级不够明确，或者不能够实时获取，会出现由于个别同事不在公司而难以决定当前工作重点和下一步工作安排的情况。团队没有基于明确的目标产生协作，团队成员经常各自独立工作，各行其事，沟通匮乏。1-成长级存在部分文档化的流程规范，但尚没有进行系统的梳理和归档；当团队识别到需要调整优化流程的时候，无法进行实时的更新和发布，可能导致团队成员在一段时间内理解不一致。团队工作的目标和优先级明确，不会出现由于个别同事不在公司而难以决定当前工作重点和下一步工作安排的情况。团队成员（包括远程成员，如果存在的话）了解各类沟通和会议的意义，并定期开会，沟通各自工作进度并更新状态，但对需要相互配合和协作的事项、问题风险等沟通不多。部分团队成员开会时参与不积极，会议效率不高。团队成员之间只有零零星星的成果和知识传递，只有ScrumMaster才关注和了解团队的整体进展情况，工作成果不够透明。2-成熟级针对需求交付工作，具有清晰的从需求产生到发布上线整个过程的端到端交付流程规范，流程中的各个节点均有明确的完成标准（DoD）；针对线上问题和日常测试发现问题，具有清晰的处理规则和流程规范，问题数量能够得到有效的监控。项目与迭代过程中的各流程节点，各会议事件均有明确的目标，时间点，输

入输出标准等，遗留事项能够得到有效的跟踪。流程规范已经文档化，并统一存档，团队对各流程规范、完成标准等有统一的认识，并遵照执行。团队新建或者需要变更流程时，经过讨论评议，以确保所有人达成共识，促进执行。当团队决定优化流程的时候，流程规范文档能够得到实时更新。团队成员不仅仅关注各自的工作进展，同时会关注到项目工作整体的优先级，进展情况，问题风险等，相关之间沟通顺畅，对各自的工作状况有清晰的了解。会议高效，且有简洁明确的信息更新，团队所有成员积极参加会议，且对他人的更新内容积极响应、提供有用的信息和反馈。3-优化级团队工作相关的流程节点和状态在工具（如白板，JIRA的看板，面板等）中得以体现，项目团队之外的人员可以通过工具清晰的了解项目的进展和问题风险等情况。内部沟通成果有效地被通过各种工具反映出来，为团队外的干系人提供有价值的信息。团队基于良好沟通确保高效工作并完成任务，奔赴共同的目标。团队成员会与本地和远程成员（如果涉及的话）结伴工作，距离对团队完成即定目标影响不大。沟通持续而流畅，团队成员能得到需要的指导和帮助。4-创新级团队主动与本产品线以及公司的其它团队合作，团队内外部信息透明，团队成员与其它团队分享最佳实践的经验，甚至结对解决问题。团队与其他合作方公司之间保持密切的协作关系，各方协作顺畅，共同为实现业务目标而努力。6、共享职责本维度用于评估团队成员对PO、ScrumMaster和团队成员彼此之间角色和职责的理解程度，以及成员在团队中实践各种角色的能力，旨在鼓励发展全功能、自组织团队。此处职

能角色指需求、设计、架构、开发、测试等职能岗位。等级设定等级设定内容0-初始级团队成员不能完全理解相互的角色职责和责任边界，或者团队成员虽然能够理解各自的角色，但只是单兵工作，只专注在自己的职能范围，因而会影响团队的效率和效益。团队内有一人可以承担ScrumMaster角色的工作，且基本上由此人长期承担ScrumMaster的工作。ScrumMaster负责主导团队工作中各种会议和事件的如期进行。PO负责官理ProductBacklog和优先级设定。团队成员之间有清晰的技术栈、所负责业务领域的划分，各团队成员专注于各自的职能范围。1-成长级PO负责官理ProductBacklog的内容，团队认可ProductBacklog内容，并支持、协助PO对ProductBacklog进行管理。团队成员已经形成自行维护sprintBacklog的习惯，ScrumMaster只需监督和提醒。团队成员能够协助ScrumMaster进行迭代开发过程中的各项会议和事件，确保相关工作的有序进行。ScrumMaster对团队成员的工作内容都很清楚，并识别团队运作和需求交付过程中的问题和风险。团队成员在部分技术栈、业务领域形成互相备份的机制，团队偶尔出现因为某位成员短期休假导致工作停滞的情况，但不会对交付产生明显的影响。2-成熟级团队成员对彼此的角色职责充分理解，并调整各自行为习惯来形成协作和分享的工作方式。团队成员理解并支持ScrumMaster和PO的工作。

ScrumMaster能够有效的帮助团队排除干扰并保证迭代被有效跟踪。ScrumMaster协助，团队成员主导各种会议和事件的有效进行。团队成员了解相互的的工作内容，共同识别项目交付中的问题和风险，并能够及时将信息同步给相关干系人。团队成员按照技术栈、业务范围形成互相备份的机制，构建成熟的排兵布阵地图，确保团队成员在休假期间项目工作可以正常进行。3-优化级尝试发展全职能团队，团队成员开始尝试补位其他人的职能角色。当计划中的缺勤、休假发生时，团队可以自我管理与调整补位，对团队交付能力影响不大。团队中ScrumMaster这个角色的工作有备份人员，当ScrumMaster不在时，备份人员可完全承担该角色的工作，能够协调团队解决迭代内遇到的问题，并对跨领域的问题有一定的推动能力。团队成员在技术栈、业务范围方面一专多能，按照“T”型人才的模式进行发展，每个团队成员都有自己精通的领域，并同时熟悉两种及以上的技术栈和业务划分。4-创新级团队能够以成功的交付为共同目标，共同承担责任，不计较于划清各自的责任。团队中的任何成员可以承担ScrumMaster角色的职责，可以帮助团队解决迭代中遇到的障碍，对跨领域的问题解决具有较强的推动能力，以确保DoD按照约定完成。团队有能力识别正确的产品路线，共同提出和收集需求，并确定ProductBacklog的优先级。团队内部成员可以跨越职责的界限，实现技术栈和业务领域的全栈工作，可以灵活地支撑价值交付工作。7、度量改进管理学大师彼得•德鲁克曾经说过，"你如果无法度量它，就无法管理它”。本维度用于评估团队基于数据化的度量标准对工作进行衡量和管理，并持续改进优化的能力。等级设定等级设定内容0-初始级团队没有形成量化的度量指标和度量方法，工作进展情况、好快难以进行管理和评估，往往依靠感性的认知进行评估。团队没有例行的迭代回顾会，或者，偶尔召开回顾讨论会，但没有将其固化到项目进行过程中，可能会因为项目进度或其他原因将回顾讨论会延期，甚至是取消。1-成长级有零星的度量指标指导团队工作，但没有经过系统的考虑和设计，导致团队度量数据相对比较片面。针对工作过程中的重点事件，比如严重的线上问题，进度严重延期，重大阻塞问题等，团队有意识的及时进行回溯讨论，探讨更好的工作方式。团队定期开展迭代回顾，但成员参与度不高，没有充分的发表个人意见。迭代回顾会之后没有形成后续的改进措施，或者改进措施可行性不高，导致最终的改进效果不好。2-成熟级团队具有体系化的度量标准和数据指标，用于对其工作进行衡量。团队能够

持续监控相关数据指标。团队定期开展回顾活动，且能够针对团队的工作状况和方式进行充分的讨论，识别出团队工作中做的比较好的，与需要改进的方面。在回顾活动中，团