本文根据 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 正在内测中，预计年底开放公测，敬请期待！