成熟度模型企业规模化推广敏捷和DevOps利器

摘要： 本文介绍了成熟度模型在软件开发行业的利用，重点论述了成熟度模型对于麻利和 DevOps 在企业中进行规模化推广的价值，探讨了成熟度模型的设计准则，并对于如何理智应用成熟度模型给出了倡议。

导言

在麻利和 DevOps 社区，只管对成熟度模型始终有些争议，但应用各种成熟度模型来领导转型的尝试却从未进行过；从笔者的从业经验来看，审慎地应用成熟度模型，对麻利和 DevOps 在企业中的规模化推广具备很重要的现实意义。

成熟度模型简介

“团队定期地反思如何能进步功效，并依此调整本身的举止体现”，这是麻利宣言的一个准则，它激励咱们继续地对软件开发办法进行改良。这种改良间接体现在晋升团队的效力（更多的价值，更快的交付速度，更高的交付品质，以及更低的老本等），最终服务于企业的业务指标。改良通常由团队交付业务价值所面临的问题或挑战触发，团队共同识别改良点，采取改良措施，查看改良功效，再发动新的改良；周而复始，永不停歇。

针对软件开发办法的改良没有起点，这个漫漫长路须要指引，成熟度模型正是为了满足这一需要。所谓成熟，意思是长大和成长，指生物体发育到齐备的阶段，或事物倒退到欠缺的水平。尽管成长的过程是间断的，但还是能够通过观察主体特色的显著变动来确定一些阶段，譬如人类成熟的过程能够分为婴幼儿、儿童、青少年、成年、老年等阶段。基于这个隐喻，成熟度模型应用一个结构化的框架，形容所关注的主体如何随着工夫的推移而倒退(成熟)；演进的每个阶段，被称为成熟度的一个级别，表明了在成长门路上的停顿。

在软件开发畛域，历史最悠久，也是最驰名的成熟度模型是 CMMI。CMMI 及其前身 CMM，是受美国国防部委托，由 Wattss Humphrey 在软件工程研究所 (SEI) 领导的团队所创立，以评估供应商无效交付软件我的项目的能力。该模型定义了五个渐进的成熟度阶段，从级别 1(最不成熟)开始，到级别 5(最成熟)完结；依据其成熟度特色对每个阶段进行形容，蕴含指标、实际和实例等。自上世纪九十年代初被提出之后，CMM 迅速为软件开发行业所承受，它所利用的成熟度模型构造，也被很多其它成熟度模型所借鉴，譬如 PMI 的组织项目管理成熟度模型等。

当麻利静止衰亡，并逐步成为软件开发的支流之后，尽管 CMMI 并没有被市场摈弃，但其粗浅的瀑布模式烙印，成为相当一部分麻利实践者们眼中的反面教材，也导致麻利和 DevOps 社区对成熟度模型的争议一直；但不可否认的是，随同着麻利和 DevOps 在企业的推广，成熟度的利用从一开始就呈现，且始终没有进行过；麻利教练的工具箱里少不了各种成熟度模型。

成熟度模型的类型

针对任何具备继续演进特色的主体，咱们都能够设计一个成熟度模型。主体范畴可大可小，取决于利用的须要；譬如，能够别离为麻利或 DevOps 设计一个模型，也能够设计一个范畴更广的研发效力成熟度模型来涵盖它们；或者，对于某些特定畛域，例如继续集成或者看板办法，也能够建设一个轻量级的成熟度模型。

成熟度模型次要有阶段式和连续式两种类型。其中，阶段式模型在整体上把成熟度分成多个阶段，每个阶段都有一组考察点；每个考察点用指标或满足指标的实际进行形容，展现了成熟度所关注的某个方面。

图一是阶段式成熟度模型的示例，扼要地形容了继续集成的五个成熟度级别；继续集成能力的晋升，是通过自低而高，逐个满足各级成熟度中所有考察点的指标来实现的，每个级别都建设在上一级的根底之上。

图一：阶段式成熟度模型示例

连续式模型同样蕴含多个考察点，每个考察点为一个独立的评估项；与阶段式模型不同，每个考察点都蕴含成熟度的几个阶段，各阶段能够用阶段性的指标，满足该指标的实际，或可能体现该阶段成熟度的行为进行形容。

图二是一个连续性模型的示例；这是一个 DevOps 成熟度模型，考察点包含 6 大畛域 36 个子畛域，每个具体考察点（子畛域）蕴含五个成熟等级的形容，图二展现了其中的一部分（需要畛域）：

图二，连续式成熟度模型示例

对于连续式模型，原则上成熟度的晋升能够从每个考察点独立发展（理论施行要思考实际的相互依赖和撑持），评估时针对每个考察点都给与一个等级。一种常见的后果展现形式是雷达图，如图三展现了某我的项目团队两次评估的后果，直观反映了：1）每次评估各考察点的等级；2）两次评估之间各考察点成熟度的变动；3）团队的薄弱点和劣势等。这些信息对于团队布局和跟进改良，具备很强的指导意义。

图三：连续式成熟度模型的评估后果示例

成熟度模型的价值

成熟度至多答复了三个问题：“我在哪？”（以后成熟度），“我要去哪里？”（指标成熟度），“我怎么样能力达到那里？”（两头经验哪些步骤）。而这，是团队实现继续的效力改良所须要解决的外围问题。

现实状况下，给研发团队设定有挑战性的指标，辅以信赖和反对，提供必要的资源，团队本人在指标的驱动下实现改良；但现实情况是，这种自发的改良往往不会如期而来。在组织中进行麻利和 DevOps 的规模化推广，最常见的问题是，少数的团队不晓得怎么继续改良，不晓得本人要改良什么，甚至不晓得本人到底做得怎么样。

麻利和 DevOps 教练能够补救这种缺失，在转型晚期帮忙团队顺利上路，但受限于教练资源（譬如几位常驻麻利核心的教练服务数千人的研发组织），教练来到团队之后，更漫长的继续改良之路须要团队本人走上来。咱们都晓得，教练最重要的产出是成熟的团队，特地是造就出合格的具备麻利意识的领导者，可能率领团队继续改良。正如丰田所提倡的“造物先造人”，当有优良的人才呈现，什么事件都会变得简略；然而，“十年树木，百年树人”，造就出合格的团队和卓越的麻利领导者是何其之难。

毫无疑问，企业一方面要有久远视角继续一直地在人才培养进行投入；但另一方面，也要应答眼前向业务交付价值的压力，疾速晋升团队效力。如何在教练资源无限的状况下，踊跃寻找出在整个组织层面投入产出比高，可能提供普及型服务，疾速奏效的方法？这是麻利和 DevOps 规模化推广必须答复的问题。通常做法是提供基础性赋能（培训、短期辅导）后，激励团队基于行为后果一直尝试，即创立一种继续改良的机制，容许团队犯错，在业务指标的引领下，尝试各种新的做法，疾速迭代，一直反思，有用则强化，有效则摈弃。

然而，正如心理学家，社会学习实践的创始人班杜拉所言：“如果人们不得不单纯依赖本人的行为后果来告知本人应该如何行为的话，学习将十分艰辛，更不用说其危险性了”。所幸的是，人类具备模拟的天才，学习不肯定要亲身经历。班杜拉的一系列观察学习钻研通知咱们，通过模拟别人的胜利，咱们能够学会各种各样的社会行为。对于麻利和 DevOps 的施行而言，成熟度模型实际上提供了一个现实的模拟对象。企业的麻利推广团队（譬如麻利卓越核心，DevOps 教练组，转型领导团队等），能够通过开发、保护、公布成熟度模型；答疑，评估和给出倡议，来撬动组织转型。

具体来说，利用成熟度模型能够在以下几个方面对转型具备重大促进作用：

第一，明确效力主张。

通过成熟度模型，向研发团队收回什么是冀望的高效能研发行为的明确主张；模型所提供的框架，系统性给出了在研发次要过程域（考察点）的效力改良的指标，是组织效力改良的思维纲领；围绕如何实现各考察点的指标，模型同时也提供了大量优良的麻利和 DevOps 实际倡议，是组织效力改良的行动指南。成熟度模型的公布，能疾速地为整个组织的继续改良建设参照体系。

第二，认清现状。

通过与成熟度模型的对照，团队能够很容易地评估出本人在麻利和 DevOps 施行上所达到的程度（处在怎么的阶段），这成为团队进一步改良的终点。在组织层面收集各研发团队的成熟度数据，可能勾画出组织整体的麻利和 DevOps 施行程度，一方面能够发现在效力晋升上的共性问题，集中力量攻坚薄弱点；另一方面也可能将以后的程度作为组织改良的基线，以此为根底布局下一步的改良。

第三，设定改良指标。

指标驱动曾经写进古代组织的基因之中，小到 Scrum 小组，大到整个研发组织，如果领有麻利或 DevOps 成熟度的指标，将使得改良失去关注并更有保障（无论是工夫还是资源的投入）。成熟度模型的高阶段要求，是各团队的具体改良指标；在组织层面，也能够基于组织现状，设置一个总体改良指标，譬如达到不同等级的团队比例等，作为 OKR 自上而下合成到各团队（在设置 OKR 指标这件事件上必须谨慎，防止造成改良口头的形式化）。

第四：布局改良路线。

成熟度模型给出了团队从现状（低阶成熟度）到指标（成熟度高阶段）的门路（即须要通过哪些阶段）；攀登高峰不止一条路，但有的起伏平缓，而有的更为平坦，有教训的登山者晓得要走前人走过的路。成熟度模型所布局的门路，是前人实际的经验总结。诚然，团队采纳麻利或 DevOps 的成熟过程与生物体的成熟过程有很大不同，后者必须间断通过所有阶段，而麻利的采纳则不受这个限度；因而，在布局上不能教条，团队齐全能够依据本人的状况，造成特定的改良门路。

第五，营造竞争气氛。

以适当的形式，在整个组织层面展现汇总的成熟度数据；辨认在晋升成熟度过程中涌现出的优良团队并给与适度的表彰；激励亲历者讲述通过成熟度的晋升而带来效力晋升的胜利故事并鼎力宣传等。这些动作，都承载在企业的麻利或 DevOps 成熟度模型之上，不同团队之间容易产生共鸣，并存在肯定的可比性，可能在团队之间发明侧面的竞争气氛，带来改良的紧迫感。

第六，度量改良停顿。

通过麻利和 DevOps 来进行全面的效力改良，是一个继续、漫长和没有起点的旅程；团队要常常检视本人做得怎么样，是不是走在正确的路线上，而成熟度模型在这个过程之中能够成为掂量改良进度的规范；通过在改良过程中的继续评估，团队能够清晰地理解本人在改良路线上所处的地位，为后续改良流动的设计提供根据。

成熟度模型设计准则

设计什么样的成熟度模型决定了组织要定义什么样的研发效力规范，将怎么的行为作为团队模拟的对象。成熟度模型的设计必须回归应用成熟度模型的目标，即可能疏导团队和组织继续晋升效力，进而改善业务产出。为了实现这一指标，须要遵循以下准则：

第一，基于企业现状。

成熟度模型的通用性越高，则越是形象，落地领导的价值越低。鉴于麻利和 DevOps 办法和实际的多样性，以及其推广施行的灵活性，很难呈现一个适应各种场景的麻利或 DevOps 成熟度模型；为了可能领导改良，模型的设计肯定要基于企业现状来，思考企业的业务诉求、技术路线、人员程度和研发治理模式等束缚，而不是简略地瞄准现实的麻利或 DevOps 状态。

第二，具备导向性。

模型所蕴含的考察点，对各考察点指标的定义，以及对不同阶段的评估规范，都要具备明确的导向性，反映了组织的效力指标（交付速度优先，还是效率优先？更好的用户体验还是更低的老本？），效力关注点（弹性的组织，优化的流程，先进的工具，业余的人员等），以及组织对于达成指标的实际经验总结和洞察；通过这种导向性，疏导团队体现出组织所冀望的行为。

第三，关注指标。

对各考察点的设计，重要的是明确指明指标，而不是严格限定是否采纳了某种具体实际。每个考察点从低到高的各阶段，反映的是达到目标的水平；不同阶段的评估规范能够举出一些最佳实际的例子，但最佳实际不是重点，重点是通过这些实际帮忙团队达成阶段指标。通过对指标的关注，使得团队更可能理解差距，本人决定采纳何种措施达成指标，并在通往指标的征程中一直调整措施，而不是教条地采纳实际。

第四，绝对主观。

不同的评估者，在同一期间，对同一个团队，基于雷同的事实，应该可能给出近似的评估后果。量化数字要求天然可能达成这指标，但不用太强求量化，只有考察点的指标形容明确的，其反对实际或体现得行为是可观测的即可。成熟度模型设计之初，能够思考通过对试点我的项目的利用，对其信度和效度进行测验。再次揭示，不用谋求齐全主观，这不是考核；存在一些含糊，有肯定争议，引发一些探讨是无益的。

第五，放弃动静演变。

组织业务指标和所处的环境在变动，组织的外部环境在变动，软件开发办法和实际自身也在疾速变动，往年还备受追捧的办法和实际可能明年就过期；因而，成熟度模型必须适应这种变动，放弃演变，以排汇业内最新的成绩，来更好地适应你的环境，帮忙企业达成指标。

如何使用成熟度模型

团队从本人的现状登程，沿着成熟度模型的阶梯，一直追赶高的等级，实现继续改良；成熟度的等级自身在这个过程中天然而地成为焦点。但如果以成熟度等级为基本，特地是以拿证为目标进行评估，则很容易带来静止式，一刀切的“改良”。这个时候对等级指标的片面追求很容易让改良口头脱离团队的现状，非但违反利用成熟度模型的基本目标（即晋升效力），而且评估流动自身会成为团队的累赘（筹备各种证据），对团队的失常工作造成烦扰；一阵风之后，留下一堆作为证据的文档和弃之不必的流程工具，团队的所有行为依旧。等级自身并不重要，继续地改良以使得团队可能更好地服务业务才是基本，不能够本木倒置。

成熟度模型是工具，工具自身通常是没有对错的；刀既能够伤人，也可能救人，就看握在谁的手中，为了什么目标。所以，对成熟度模型的利用要谨慎：咱们能够用它来作为参照和模拟对象，但却不能把它设计成规范强制大家恪守；咱们能够用它来设定改良指标，但用来考核绩效可能大失所望；咱们能够把优良团队秀进去可能激励其余团队效仿，但如果把临时垫底的团队也公布出来却不是个好主见。

成熟度评估是模型利用和实现改良的伎俩之一，它基于模型提供的继续改良的蓝图，帮忙咱们在改良的征途上进行查看（辨认以后所在的地位）和调整（确定进一步改良的方向）。成熟度评估不是为了取得一个冀望的等级，而后完结；而是要通过评估建设一个基线，成为进一步改良的新起点，并给出下一步口头的倡议。

评估流动自身能够有多种形式，抛开内部认证评估不谈，在企业外部有团队自我评估，穿插评估（利用麻利和 DevOps 社区力量，不同团队穿插评估），以及集中评估（由企业麻利核心的教练对立评估）等多种形式。特地举荐穿插评估的实际，它一方面解决了集中评估的资源缓和问题（设想一下几个教练对上百个团队进行评估的场景）；另一方面，也是更重要的是，它能够使不同团队有机会互相学习。

评估的后果包含团队在成熟度模型中所处的等级，做得优良的中央，以及不足之处。团队基于这个后果，对标模型更高等级，剖析可能的改良点，马上采取行动，投入下一轮的改良之中。作为麻利和 DevOps 推广团队，既要基于评估后果发现共性问题，针对性提供集中培训和专项辅导；也要辨认涌现进去的优良实际，在组织层面进行分享。评估的后果倡议汇聚起来，造成整个组织的成熟度画像；各团队成熟度的具体等级能够不颁布，但整体程度的通明有利于各团队判断本人在整个组织中所处的地位，加强各团队的改良紧迫感。

须要警觉的是，成熟度模型通常是基于教训、观点，甚至假如所做的构建，而不是应用科学办法的后果。评估后果所给出的改良倡议，仅仅是一种你的团队能够如何成长的假如，它的作用在于让你领有一个绝对靠谱的参照物，帮忙你疾速决断和采取行动；你要验证这个假如在你的环境中是无效的，或者是有效的（判断规范是是否可能进步效力指标）；而后疾速调整，进行新一轮的尝试，从而实现继续改良研发效力的目标。

结束语

只管成熟度模型的利用在麻利和 DevOps 社区的争议不会平息，但还是有组织可能从中获益；咱们能够通过明智地应用它，使其成为撬动麻利和 DevOps 在企业规模化推广的利器。存在即正当，对包含成熟度模型在内的任何办法和工具的应用，咱们应秉承实用主义而不是教条主义，同时持有批判性思维和凋谢态度；“不论黑猫白猫，能捉老鼠的就是好猫”。

点击关注，第一工夫理解华为云陈腐技术~