Confluence使用成熟度模型

Posted 2023-04-23

参考技术A         Confluence是一个用户上手极快的产品，功能非常直观，使用门槛非常低。但要把Confluence用好，特别是在企业内完全发挥它的作用，还是需要花一些时间和金钱进行学习和实践的。参考Confluence的官方文档及ACP-200考试心得，下面给出我对Confluence使用成熟度的定义，共分为五级，从简单的知识管理到系统集成。需要说明的是，日常使用中并不是严格按照五级递进进阶的，而是混杂着各级别的内容，但是由于各级别学习和实施难度的不同，还是能明显看出各企业在使用中的成熟度差别。

1级（知识管理）：开始定制空间主页面，建立清晰有层次的页面树结构，使用标签，配置与Jira集成，开始使用页面模板；

2级（项目协同）：开始使用关注功能，定制个性化页面模板，开始配置空间侧边栏，标准化标签；

3级（社交）：开始维护个人概要信息并使用个人空间，使用评论、引用和赞的功能，开发新页面模板，关注他人的空间和页面，

4级（用户体验）：在页面中熟练使用宏、富文本、图片、任务、连接，开始修改默认的空间权限配置，开始使用快捷键，熟练使用Wiki Markup，使用图表展示数据，设置页面布局

5级（集成）：开始使用第三方插件，定制开发用户宏，与其他系统集成，内嵌多媒体文件及外部网站多媒体资料，使用移动端访问系统

        很多企业对于Confluence的定位就是知识管理，甚至只是产品文档管理，那么在1级使用是完全没问题的。但如果想充分发挥Confluence的能力，就需要结合具体需求，定期对Confluence进行巡检，引入外部力量，发现和总结最佳实践，螺旋式提升成熟度。

成熟度模型：企业规模化推广敏捷和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在企业规模化推广的利器。存在即合理，对包括成熟度模型在内的任何方法和工具的使用，我们应秉承实用主义而不是教条主义，同时持有批判性思维和开放态度；“不管黑猫白猫，能捉老鼠的就是好猫”。

 

点击关注，第一时间了解华为云新鲜技术~