A2--于旭东--热模型冷思考：领域化治理效能提升案例.pdf

1、于旭东快手 高级研发效能专家于旭东快手 高级研发效能专家之前工作于网易云音乐，阿里巴巴菜鸟网络，诺基亚网络等公司，主要专注于研发组织数字化管理、研发效能度量体系和研发效能工具平台建设、敏捷/精益/DevOps等方法实践，帮助多个组织实现研发效能提升，在组织研发效能管理体系建设和组织敏捷转型等领域具有丰富管理与实践经验。杭州敏捷社区建设者，Regional Scrum Gathering，敏捷之旅，TiD质量竞争力大会，DevOpsDay，GOPS全球运维大会，DevOps国际峰会，NASAC全国软件与应用学术会议，QCon+等大会组织者和话题分享者目录CONTENTS研发效能模型0102研发效

2、能问题分析领域化治理03研发效能改进结果04总结思考05PART 01研发效能模型流量公式：Q=A*v（v：流速，A：管道横截面积），影响流量的关键因素包括：流速和管径大小，其中流速受到水压、管道摩擦力和水质黏度等因素的影响。研发效能的本质是在有限的时间和成本下，快速、高质量的交付更多有效产品需求，帮助业务实现高效的探索，取得业务成功，影响因素：1、管径大小（A）：即研发团队可用资源，研发在产品需求上资源投入越多，交付的需求数量越多2、流速（v）：等同于需求流动的速度，与需求研发交付周期成反比，在其他条件相同的情况下，需求研发周期越短，流速越快，交付的需求数量越多我们可以从缩短需求交付周期（提

3、升流速）、增加有效资源投入（增加管道横截面积）和可验证的学习（效能转换函数）三个方向做功帮助团队提升研发效能降低本质复杂度增加投入改善工作方式提升效率降低偶然复杂度PART 02研发效能问题分析产品需求两周交付率低是影响团队效能的主要原因团队研发周期长主要是由于产品研发复杂度高导致的软件产品研发复杂度主要受两个因素影响：1、业务领域的复杂性，如复杂的业务算法和业务逻辑，这属于本质复杂性，几乎无法避免；2、软件产品实现的复杂性，如不合理的软件架构和代码复杂度带来的研发认知负担，这属于偶然复杂性，是我们重点优化的方向。Fred Brooks 没有银弹巨大的单体工程对研发产生了诸多的负面影响1、单体

4、工程包体积大，部署成本高2、代码复杂，理解困难3、耦合高，开发成本高4、测试复杂，测试成本高5、互相依赖，部署成本高PART 03领域化治理白盒化分析摸清现状：分析服务端现状，结合公司白盒化经验，确定主要问题领域分析和设计：小需求尽量不跨域；大需求按领域拆分，有强相关领域主R模块化结偶代码结构调整：功能代码迁移到各自领域模块，不涉及逻辑变更，需求分支自行处理引用冲突依赖解耦：分析调用依赖，外部依赖的服务抽象至proxy子包中，修改调用点领域化拆分工程拆分：不影响业务迭代下完成工程和部署的拆分，各个领域工程独立，服务隔离风险评估：变更范围可评估，风险可控，架构成熟度相关指标达标领域自治治理依赖分

5、层、逐层治理：“一级领域”依赖、“二级领域”依赖、“三级领域”依赖（可选）、服务（外）依赖、服务（内）依赖、资源依赖稳定性策略分层：服务内部强依赖为主（核心业务足够收敛）、领域内部强弱依赖不作限制（强依赖可以少量存在）、领域之间不建议有强依赖领域X模型挖掘仓库中的“暗知识”复杂仓库下（2k+files，1.8k class，300k+lines code）通过问答快速学习理解PART 04研发效能改进结果领域化指标：领域化治理的直接结果，如领域数量等效能过程指标：说明领域化拆分对关键研发过程的影响，如编译部署时长，阶段周期等效能结果指标：领域化治理对团队研发效能北极星指标（人均产品需求交付数）

6、及其关键影响指标（产品需求研发周期、产品需求两周交付率）指标名改造前改造后领域数量1个7个单工程代码行XX万行X万行/工程包大小957M423M人均服务数人均4.1个服务人均3.1个服务单领域表数50张13张/领域工程编译部署时长：当单体结构通过领域化治理拆分为多个服务，降低了单工程代码量以及包大小，显著提升了编译部署效率，工程编译部署时长降低32%需求颗粒度（研发复杂度）：产品需求平均颗粒度降低30%，其中服务端子任务颗粒度降低42%，而大前端子任务颗粒度则仅降低9%，产品需求颗粒度的下降主要源于服务端子任务颗粒