华为大规模敏捷开发实践：如何从 0 到 1 落地 DevOps？

根据 Gartner 报告，2015 年 DevOps 还处于技术关注的最高点，转眼到了 2018 年，DevOps 以及 DevSecOps 都已经从关注度高峰下沉到了具体实践阶段，而正在攀爬关注度高峰的是 DevOps 工具链和工具链的编排。华为云 DevCloud 首席技术布道师在 QCon 全球软件开发大会（广州站）2019 上发表了相关演讲，他的分享主要介绍了中大型企业如何落地敏捷 + DevOps，有效提升研发效能的经验和实践。

本文整理自 QCon 全球软件开发大会（广州站）2019 的演讲，出品人希望我能够分享大型企业如何进行大规模敏捷开发的议题，于是我将分享话题定为《大到不能慢——敏捷 +DevOps，大企业也能高效能》。

为何需要快速灵活的研发响应能力？

首先，我们来拆解本次的演讲题目。

大到不能慢，这与现在的时代背景相关。开发者可能也有体会，生活和社会的节奏越来越快，变化越来越快，企业越来越需要更快、更频繁地创新，才能够在这个竞争越发激烈的 VUCA 时代存活下去。任何已经占据江湖地位的大公司都无法松懈，必须持续提升企业自身的响应速度和能力。

按照敏捷宣言诞生之日来计算，敏捷已经 18 岁。按照敏捷在国内开始萌芽的日期计算，也已经 13 岁了。前两年，IT 领域、软件领域各种新趋势频出，敏捷颇让人有种廉颇老矣的感觉。然而，哈佛商业评论先后于 2018 年 3 月刊载《HR 迈向敏捷》、5 月刊载《规模化敏捷》；麦肯锡也在其季刊中连续刊载有关敏捷银行的文章。敏捷像老树新枝一般，再次成为热门议题。只是其内涵相比刚开始限于在敏捷软件开发领域，已经有了很大扩展。

至于 DevOps，简单来说，已经进入深水区，即快速成熟阶段。以 Gartner 的报告来看，2015 年，DevOps 还处于技术关注的最高点，市场对其期望很高。转眼到了 2018 年，DevOps 以及 DevSecOps 都已经从关注度高峰下沉到具体实践阶段，开始啃硬骨头，而正在攀爬关注度高峰的则是 DevOps 工具链和工具链的编排。

接着我们再来看“大企业”，到底什么叫大？参照国家统计局的说法，根据《统计上大中小微型企业划分方法（2017）》的标准，软件和信息技术服务业，只有企业从业人员规模在 300 人以上的，才能算是大企业。

再来看高效能，度量是一件非常重要、非常难做好的事情。根据所处行业、企业自身的业务特点和企业特点、当前关键问题等各方面差异会有不同定义，但我们可以倾听业界的一些声音。VersionOne 的年度敏捷报告是敏捷圈的权威报告，填写者反馈了他们度量敏捷项目成功的标准，包括客户 / 用户满意度、业务价值交付、速率等指标，不过报告并没有给出一个基准值。DevOps 部分，在 DORA 发布的 2018 年《加速度：全球 DevOps 现状调查报告》中，DORA 提出了软件交付和运维效能的概念，它包括以下五项关键指标：前置时间、部署频率、变更失败、恢复时间、可用性。我们可以参考这些观点，但是要靠自己找出适合企业现状的效能指标作为指引。

DevOps 实践

规模化是硬骨头，审视自身、因地制宜，最适合的办法才是最好的

那么，解决方案在哪里呢？我们可以看看目前的规模化敏捷方法论和 DevOps 方法论，看看有什么启发。

• LeSS：大规模 Scrum，以 Scrum 为基础。LeSS 分两个模式，LeSS 模式宣称适合 8 人团队、最多 8 个团队共 64 个人的情况，LeSS HUGE 模式则号称可适应数千人规模的产品研发；在敏捷方法方面，LeSS 以 Scrum 为核心，工程实践维度，有实践指导材料，DevOps 的部分则没有发现什么详细介绍的内容；

• SAFe：大规模敏捷框架，完整的 SAFe 框架可以分为四个层级，团队级适合 5~9 人团队、项目群级适合 5~12 个团队（约 50~125 人）、大型解决方案级适合数百人规模、组合级适合 500~1000 人规模；敏捷方法论方面，介绍了 Scrum、XP、Kanban 方法，主张团队自主选择，工程实践方面有所提及、但没有特别详细的介绍，DevOps 部分也只是有所介绍而已；

• DevOps：目前来看并没有所谓的某个标准或是一统天下的方法论，各家厂商甚至各家企业都有自己的说法，也没有什么可供参考的标准文献去判断 DevOps 方法论适合多大规模的企业。

接下来，我们需要审视自身是什么情况？客观地看待自己，才能够找到靠谱的解决办法。

首先要明白，组织结构需要跟随战略。创业阶段企业的业务单一、所以组织结构通常是扁平化的，成长阶段企业会快速构建起层级组织结构以适应不断增长的企业规模，成熟阶段的企业往往采取矩阵式组织结构以支撑企业多元化的业务，转型阶段的企业必须通过组织创新为各个业务单元赋能，激活组织和个体，才能在庞大的业务体量和灵活的组织机能之间取得平衡。

只要企业规模不同，所谈论的敏捷、DevOps 就有所不同。在《规模》书中，作者论证认为我们不可能将艺术界或自然界中组织的规模扩大到巨大无比的尺寸。对研发组织来讲，即无法把一个运转良好的 10 人团队的角色分工、协作模式、工具等各方面的结构直接复制并线性扩展用于一个 100 人的大项目或大部门，这样做是无效的。我们需要针对不同的规模，选择和设计相对应的整体方法才行。

DevOps 是实现规模化高效研发的重要一环。人多了，协作起来就会有很多麻烦，比如代码提交时的冲突，超高量级测试用例的执行效率问题等。但在 DevOps 模式下，做好正确的架构、技术实践、文化规范，高绩效的大型组织仍能支撑其小团队维持极高的生产率以及每日的高频度部署 。

执行落地，要有方法有理论，更要脚踏实地、步步为营

好，那么具体应该怎么做呢？

指导思想是要高瞻远瞩、考虑周全，但同时要脚踏实地、步步为营，扎扎实实地实现目标。可以参考如下公式来建设各方面能力：

（工程方法 + 最佳实践 + 生态） x 工具平台 = 能力

具体操作层面，可以参考如下过程：

• 首先选定一个方法论 / 流程 / 套路，学习消化：如果敏捷、DevOps 对组织来讲是新的知识，那我们就必须考虑学习本身的特点，在尚不理解的时候是很难去进行所谓的适应性调整的，所以最好是先选定一个模型，从僵化执行开始，晚些再复盘改进；

• 然后选择团队 / 项目，敲定整体实施方案，开启试点：前面选定的是主体方法论，但还需要用其他实践来辅助填补单个方法论的空缺，比如以 Scrum 框架为主，辅以部分极限编程的工程实践以及 DevOps 实践作为补充；

• 接着就是在试点执行过程中，组织层面要为后续扩大范围打造基座：包括方法论落地的相关经验教训要提炼并转化为可复用、适合推广的智慧资产，以及一批种子选手，后期扩展至更多团队时，他们可以发挥榜样带头作用辅导团队，还有一些能力最好能固化到工具里面；

• 扩大范围时，要考虑扩展策略，是横向扩展还是纵向扩展，也有可能是同时开展：即有经验可以横向扩展至其他团队 / 项目，直接参考实施，也可以考虑将团队级试点纵向扩展应用于更大规模的项目 / 项目集，这就需要在即有经验基础上进行调整和完善，补充一些实践解决更大规模研发才会面临的问题；

华为云 DevCloud 团队转变历程

以华为云 DevCloud 团队的转变过程来介绍，除了进行团队协作模式的服务化转型，还有很多其他实践也都需要一并落地才行：

实践 1：组织结构和产品架构螺旋相适配；

实践 2：Two pizza team，全功能团队，特种作战；

实践 3：按周迭代，小步快跑，持续规划；

实践 4：服务自治，独立需求排序，开发，部署上线；

实践 5：兼听则明，持续规划，价值排序；

实践 6：与客户联合敏捷，众创，对齐客户商业价值；

实践 7：架构解耦，服务 / 微服务化；

实践 8：云基础设施下，猴子军团出没，耐抗才能高可用；

实践 9：兼顾效率与安全的软件仓库，高速下载，便捷实用；

实践 10：自动化流水线，缩短上线时间，Built-In Quality；

实践 11：企业级仪表盘，基于数据科学决策；

实践 12：运维、监控、运维专家经验沉淀到系统；

实践 13：灰度发布，友好 / 公测，运营运维配合；

实践 14：VoC 驱动，持续规划，数据分析，动态调整，有错就改。

优化组织结构

待上述一切落地，我们要考虑进行组织结构调整或者说落实组织结构调整的事情。麦肯锡在其季刊中表明观点，认为企业必须转变经营模式和组织结构，才能大规模推广敏捷模式。总之，如果敏捷 +DevOps 对组织和业务发展有益，那正如前面讲过的，这个组织结构和模式就需要落到实处，以便能够长期支撑新的业务战略落地，形成竞争优势。

上述过程可能比较耗时、较为漫长，所以很多人会关心是否可以加速？能否一步到位？我们称之为 Big-Bang 模式，这不是不可能，只是相比循序渐进的方式，前期准备需要更全面、更长时间。因为，引入敏捷和 DevOps 对于大多数企业来讲都是一种外来元素，会带来变化，而借鉴萨提亚变革模型，我们知道人们面对变化的第一反应是抗拒、然后是陷入混乱和痛苦挣扎，如果没有充分准备，组织整体就会长时间陷入变革混乱期，且士气低落，那可就不妙了。

敏捷 DevOps 学习建议

最后，还有一些建议给到组织和开发者：

• 把握趋势，方向大致正确，组织充满活力：我们认为未来是万物互联的数字世界、是智能化的世界，而软件工程则需要解决可信的问题，盯准大方向，才不会做无用功；

• 借力成熟的实施方法，避开常见陷阱；

• 站在巨人的肩膀上，省力：借鉴业界的成熟经验，减少自己趟坑的各种代价；

• 利用各种学习资源，提升自身能力；

• 千里之行，始于足下，DevOps 之旅，健康自检起步：在 DevCloud 我们用自己的专家服务 DevOps 成熟度评估进行自检，并参考建议持续改进，企业可以通过一些手段对自身的 DevOps 实践能力进行自查并根据结果制定战略。