本文依据 CODING Compass 产品总监程胜聪 在腾讯云 CIF 工程效力峰会上所做的分享，进行了整顿与更新。文末可返回峰会官网，观看回放并下载 PPT。
DevOps 从工具化阶段迈入流程化阶段
软件工程从上世纪 60 年代倒退到当初，毫无疑问正处于 DevOps 的时代，这几年业内热火朝天的 DevOps 转型也印证了这一点。到当初这个阶段，企业在转型落地上也继续投入了这么多年，开始迫切希望看到成绩。大家广泛在思考一个问题，那就是 DevOps 是否真的对业务倒退和数字化转型带来帮忙，还是只是研发团队自嗨而已？
在最近一年帮助客户进行 DevOps 产品落地的过程中，咱们愈发意识到：研发治理真的不能只靠搭建工具链，还须要把这些工具利用到企业理论的业务流程当中。 咱们应该切实的为开发减负，而不是反而给业务的开发减少累赘。只有这样才可能切实晋升研发效力，更好地满足业务倒退的须要。
如果说，DevOps 在之前还属于工具化阶段，各式各样的工具层出不穷，那么在数字业务倒退迅猛的背景下，DevOps 正在进入一个新的阶段：流程化阶段。
企业应用 DevOps 工具依然存在挑战
先从一个典型的用户反馈登程，来看看以后用户所处的窘境：
下面这个客户深刻应用 CODING 一年多，他们对产品是否好用有足够的话语权。通过对反馈后果的整顿，能够看出工具化阶段的产品还是存在有余。一方面，客户充分肯定了当初抉择 CODING DevOps 的决定，团队中每个角色都可能在一站式平台上工作，很好地实现了研发一体化的指标；另一方面，只管咱们的一站式平台提供了团队所需的能力模块，然而不同模块之间的协作性还不能很好体现。
- 对产品来说，其关注的需要流动并不能很好关联到开发理论在做的事件，从而对停顿和危险不能齐全掌控。
- 对于开发来说，更新工作状态是很重要，然而因为这个事件并不会阻塞本人，是否及时更新就齐全取决于自觉性高下。于是很多时候，忙于合作编程的开发往往会遗记去做这个事件。
- 同时，作为绝对后置的测试，一旦提测，各种事项查看更是茫茫多，各种信息核查和更新就要破费大量的工夫，加上留给测试的工夫原本就不多，状况就显得特地困顿。
- 而再前面的运维共事更不用说了，只能重复叮咛发版之前要做好充分准备，各种验证查看都不能打折扣，而后就只能祷告别总是在敏感的公布窗口，呈现各种莫名其妙的问题。
总的来说，尽管在一个平台上的不同工具大家都用得很顺畅，但从全流程来看总感觉短少点什么。在工具之间的来回切换依然须要破费大量精力，而且还不能确保信息的正确性。种种这些，都是工具型产品的不足之处。
企业日渐关注研发治理的整体效率
这个案例并非个案，而是 DevOps 转型来到了新的流程化阶段的标记：企业日渐关注研发治理的整体效率，从强调某个工具的局部优化，转变为强调协同流程的全局优化。
工具并不能等同于整体效率，组织效力治理的经典实践 PPT 中就指出：一个组织的 3 个因素中，People、人是根底，Tools、工具对人进行赋能，让工作更有效率，而 Process、流程则是让人的行为与指标保持一致的载体。完满地实现一件原本就不应该去做的事件是毫无意义的，甚至还会对整体造成侵害。从全局上思考，一个好的流程不可或缺。
DevOps 产品应该打造成为进一步解放生产力的新型生产关系
在数字化的背景下，业务迅猛发展带来了软件系统的高复杂度，个体须要解决的事件变得更多，导致单人效率降落。为了晋升团队中每个角色的工作效率，企业谋求 DevOps 转型，心愿利用新兴技术和工具来迅速进步团队生产力。然而随着在技术和工具上投入越多，以及团队规模不断扩大，同时也带来了整体合作上的复杂度。而这些简单的依赖关系如同金字塔般层层传导至团队成员身上，造成了对原有工作习惯乃至了解认知的微小冲击。哪怕是一次简略的交付，都须要通过许多操作以及不同角色的协同，整个交付过程也因而显得软弱和低效：比方工作上下游的契约和标准缺失，研发过程的透明度不够，须要在不同工具平台之间来回切换等等。
如何能力让不同的工具，有机地共存于一个残缺的流程当中呢？如何为团队打造高效的流程，让人可能顺畅地实现高质量的软件开发，并公布到生产环境中？在这个过程中，团队成员不须要去解决不必要的简单问题，陷入细枝末节之中，又或者是长时间的期待延误。咱们应该解放团队成员的生产力，让开发能把精力集中在能真正产生业务价值的工作上。这是以后很值得思考的事件：就像生产力决定生产关系一样，咱们须要更先进的研发治理产品来赋能研发团队，来满足现今数字化业务倒退的需要。
CODING Compass：DevOps 流程化阶段的研发流程治理产品
通过对 DevOps 实际落地中凸显进去的问题的梳理，咱们得出了以下 2 个方面的意识：
1. 组织层面的 DevOps 转型须要领域专家
7 月份信通院公布的《中国 DevOps 现状调查报告（2021）》中就指出：靠近 30% 的企业因为短少 DevOps 专家导致推动落地迟缓。而在咱们服务客户的时候，也往往须要提供征询，通过专家诊断、制订流程，而后依据理论状况、设定要晋升的指标以及具体的实现门路。DevOps 产品要做的是：提炼出业内卓有成效的研发治理教训、并内嵌到产品当中，疏导客户团队把优良的习惯固化下来、继续优化，从而实现高效的研发治理。
2. 合作中团队成员的最大痛点是“什么都要懂”
在现有已提供的工具的根底下，团队凭着对 DevOps 的奢侈了解，是能够初步协同起来的。然而，用户所面临的合作问题的确存在：比方不足跨职能流动的能力拉通，流动之间的合作标准缺失，难以辨认研发过程中的危险，个体在工作中须要了解的上下文过多，还有跨职能的许多操作只能手工解决等等。这些看上去琐碎，然而这些问题累积起来迟迟得不到解决，便会造成团队成员极大的“心力损耗”，甚至导致了优秀员工对打造高效组织产生狐疑。
DevOps 深入倒退到了现今阶段，代表着行业对研发治理产品的新的冀望：从麻利到 DevOps、再联合 LEAN 精益思维的理念，朝着加强可视化和可追溯性、谋求标准和效率的方向倒退。基于察觉到的这些痛点，CODING 联合本身实际和行业成绩教训，致力作出了产品的降级，来帮忙客户更好地晋升研发治理能力。
Compass = 工作流 + 标准 + 自动化
CODING 打造了全新的研发流程治理产品 Compass，包含 3 个次要能力：别离是 （串联各种流动造成的协同）工作流，还有 （晋升研发流动一致性的规范）标准，以及 （触发后置流动的）自动化。代表着 CODING DevOps 在原有 DevOps 工具链的根底之上，融入了 Know-how 的局部，让客户可能充沛借鉴业内卓有成效的实践经验，做到高效的研发治理。
Compass 如何晋升研发治理能力
简略的说，Compass 的产品逻辑就是定义流程、标准过程、高效流转、辨认瓶颈并领导改良。
1. 首先，研发过程当中存在着各种各样的流动。
比如说产品经理会创立需要到 backlog 外面，团队发展布局会纳入到迭代当中，并进行工作合成、工作认领或者调配，开发会创立分支、写代码、提交合并等等，而测试则是设计用例、执行测试，而后团队提测、通过品质门禁之后并创立公布单等等。
咱们晓得，这里列举的有些是同一种角色外部产生的，有些却是须要不同角色去协同实现的，实际上它们的进行存在着先后顺序。
2. 其次，辨认出要害的协同流动并串联成为残缺的工作流。
依照不同角色归类好这些流动之后，会发现同一角色的某些流动主观上就是另外一些流动的前提。比方需要被创立进去之后、才有可能被纳入迭代，分支存在之后、能力有对应的代码提交和 MR，用例设计完了、能力在它的根底上关联对应的需要等等。这些外在的关系导致了它们的流动流转必然是自发实现的。
对于剩下的要害节点，咱们从整体研发的视角，依据理论工作状况，人为定义好它们的依赖程序，并把它们串联起来。比方工作拆解结束能力创立对应的个性分支，有了 MR、并且需要关联了测试用例之后能力提测，而后执行测试、给出测试报告、最初提交公布单。这样就造成了残缺的工作流。
3. 再次，通过标准来保障流动的强壮流动，以及自动化驱动流动进行高效的流转。
为了保障流动流转的健壮性，咱们能够对其中的某些流动设定准入准出标准，不符合规范的则给出正告并阻止持续流转。比方纳入迭代中的需要要给出验收规范、作为用例设计的根据，测试报告中的通过率要满足肯定数值能力创立公布单等等。另外，对于某些能够标准化创立或者触发的流动，能够设定自动化规定。当前提条件取得满足时则主动流转，也不须要团队成员切换到另外工具中去更新状态、或者手工创立下一个步骤的工作。这样一来就造成了一个颠三倒四的团队合作工作流。
4. 最初，把研发具体步骤跟业务定义好的价值流阶段映射到一起，提供洞察剖析。
标准和自动化可能产生准确的流动记录，从而为效率度量提供实在牢靠的数据，进行无效的洞察诊断和领导改良。比方前置工夫和解决工夫的差别、工作完成率 / 准确率等等。这是价值流治理（Value Stream Management）的根底。
以上就是 Compass 的产品设计理念，咱们心愿可能通过流程驱动合作中的开发行为，让流程中的每个人都能够专一于本身的价值。同时积淀下来的过程数据可能精确的透视研发过程，并且基于数据的洞察剖析来领导研发过程的继续改良。
总结
CODING Compass 是一款基于 CODING 原有 DevOps 工具链的研发流程治理产品，蕴含流程编排、流程驱动、规定束缚及价值流转。心愿可能帮忙企业拉通管理者的指标预期和研发团队的具体执行，用最小的协同老本实现最高的响应能力，从而最大化研发效率。
以后 Compass 正在内测中，预计年底凋谢公测，敬请期待！
返回观看 CIF 峰会回放