- ISBN：9787121421679
- 装帧：一般胶版纸
- 册数：暂无
- 重量：暂无
- 开本：其他
- 页数：336
- 出版时间：2021-10-01
- 条形码：9787121421679 ; 978-7-121-42167-9
本书特色
全面：覆盖项目管理、DevOps、工具平台、组织建设等研发效能的全领域知识体系。 实战：揭秘一线大厂研发效能提升的实践内幕，助你规避误区，少走弯路。 权威：作者多年互联网大型公司研发效能建设的经验总结，收录行业知名大会热门演讲的精华内容。 先进：囊括研发效能提升的前沿技术与理念，与时俱进。
内容简介
内 容 简 介本书汇聚了行业前沿的研发效能提升实践与案例，同时提炼出大量方法论和经验反思，以诙谐、幽默而又不失严谨、详实的风格，多角度、多方面覆盖研发效能领域的核心知识，深入浅出，发人深思。全书采用从概要到细节、从方法论到案例、理论联系实际的写作思路。章和第2章通览研发效能的概念与背景，并对研发效能进行由浅入深的解读；第3章以敏捷开发为主线，讲述项目管理中的提效实践；第4章介绍了行业流行的DevOps实践，并衍生讲解了目前流行的DevSecOps、AIOps、DevPerfOps，以及混沌工程等内容；第5章和第6章立足于工具建设，详细介绍了流量回放、精准测试、服务虚拟化，以及AI在研发效能提升中的应用等12个大大小小的工具、系统与设计理念；第7章介绍了组织效能提升的多种手段，同时给出作者从实践中总结的大量经验和误区；第8章为案例篇，通过对四家不同形态企业的研发效能提升的实战讲解，帮助读者举一反三、融会贯通。本书适合IT行业的各类从业人群，无论是技术人员、项目经理、产品经理，还是团队管理人员；无论是初入IT行业的新人，还是资深专家和高层管理者，都能从本书中得到启发。
目录
第1章 软件研发效能概论 1
1.1 到底什么是研发效能 2
1.1.1 研发效能提升案例1：前端代码的自动生成 3
1.1.2 研发效能提升案例2：临界参数下的API测试 4
1.1.3 研发效能提升案例3：基于流程优化的效能提升 5
1.2 研发效能的“**性原理” 6
1.3 研发效能的另一种解读 7
1.4 基于工具协作的研发效能提升 8
1.5 基于MVP原则构建研发效能的持续改进 11
1.6 研发效能提升*佳实践的探索 12
1.6.1 从痛点入手 13
1.6.2 从全局切入 14
1.6.3 用户获益 15
1.6.4 持续改进 16
1.6.5 全局优化 17
1.6.6 效能平台架构的灵活性 18
1.6.7 杜绝“掩耳盗铃” 18
1.6.8 吃自己的“狗粮” 19
1.7 研发效能的发展方向与未来展望 20
1.8 总结 21
第2章 研发效能的进阶解读 23
2.1 研发效能与霍桑效应 25
2.1.1 霍桑效应 25
2.1.2 霍桑效应的负面影响 26
2.1.3 霍桑效应的正面影响 27
2.2 摩尔定律与反摩尔定律 28
2.2.1 摩尔定律 28
2.2.2 反摩尔定律 28
2.2.3 反摩尔定律对研发效能的意义 29
2.3 不容忽视的沟通成本 31
2.3.1 信息熵 32
2.3.2 沟通信息熵衰减 32
2.3.3 自解释编程 34
2.4 研发效能对现代大型软件企业的重要性 35
2.5 总结 37
第3章 项目管理中的提效手段 38
3.1 敏捷项目管理概述 39
3.1.1 敏捷宣言 40
3.1.2 常见的敏捷开发方法 42
3.1.3 敏捷角色 45
3.2 敏捷项目管理中效能提升的五大要素 47
3.2.1 自组织团队 47
3.2.2 持续改进 48
3.2.3 频繁交付 48
3.2.4 消除对立 49
3.2.5 未雨绸缪 50
3.3 敏捷项目管理中的常见误区 50
3.3.1 敏捷开发就是快速开发 51
3.3.2 敏捷开发应当抛弃文档 51
3.3.3 敏捷开发只适合小微团队 52
3.3.4 敏捷开发沦为小瀑布开发 52
3.3.5 敏捷是没有约束的 53
3.4 建立度量体系：无法度量，就无法改进 54
3.4.1 选择度量指标 55
3.4.2 构建度量体系 58
3.4.3 度量的误区 59
3.5 可视化：打开窗户看世界 60
3.5.1 项目管理中的效能可视化 61
3.5.2 效能数据可视化 64
3.6 提速：依赖解耦，提升交付速度 65
3.6.1 提速的切入点 65
3.6.2 高频的威力 68
3.6.3 避免竖井效应 68
3.7 消除变量：控制复杂度 70
3.7.1 约束 70
3.7.2 控制 71
3.7.3 抵抗熵增 71
3.7.4 远虑 72
3.8 未雨绸缪：防御性管理 73
3.8.1 及时暴露风险 73
3.8.2 防御性管理 74
3.8.3 Plan B 74
3.8.4 避免盲目自信 75
3.9 总结 76
第4章 DevOps落地实施精要 78
4.1 DevOps核心解读 80
4.1.1 DevOps的“六大武器” 81
4.1.2 自动化、自动化、自动化 82
4.1.3 DevOps生命周期精解 83
4.1.4 DevOps不适合的场景 86
4.2 代码、分支与流水线 86
4.2.1 代码质量 87
4.2.2 分支与工作流 91
4.2.3 流水线 94
4.3 持续集成与持续交付 96
4.3.1 持续集成与持续交付的轻量级实施 98
4.3.2 持续集成与持续交付的误区 101
4.4 容器技术在DevOps中的应用 103
4.4.1 无容器化管理 104
4.4.2 持续集成的容器化 104
4.4.3 持续交付的容器化 105
4.4.4 测试环境的容器化 107
4.5 混沌工程 109
4.5.1 Chaos Monkey 110
4.5.2 混沌工程的实施要点 111
4.5.3 混沌工程的相关工具 114
4.6 DevSecOps的由来与发展 115
4.6.1 传统软件安全开发体系面临的挑战 115
4.6.2 新技术对软件安全开发提出的挑战 118
4.6.3 DevSecOps概念的诞生与内涵 119
4.6.4 DevSecOps工具 121
4.6.5 典型DevSecOps流程的解读 124
4.7 AIOps的行业实践 126
4.7.1 AIOps的知识体系 128
4.7.2 AIOps实施的关键技术 129
4.7.3 AIOps的应用场景 133
4.7.4 AIOps在运营保障中的应用 134
4.7.5 AIOps在成本优化中的应用 137
4.7.6 AIOps在效率提升中的应用 139
4.8 DevPerfOps初探 142
4.8.1 全链路压测的局限性 142
4.8.2 DevPerfOps全流程解读 144
4.9 软件产品的可测试性和可运维性 149
4.9.1 可测试性的例子 150
4.9.2 可运维性的例子 151
4.10 总结 152
第5章 基于工具的研发效能提升（基础篇） 154
5.1 造数能力 155
5.1.1 通过服务接口实时造数 156
5.1.2 异步造数与造数平台 156
5.1.3 黄金数据集 158
5.1.4 生产数据迁移 159
5.2 流量回放 160
5.2.1 传统流量回放技术 161
5.2.2 请求对比 162
5.2.3 高级流量回放技术 163
5.3 精准测试 166
5.3.1 什么是精准测试 167
5.3.2 精准测试的工程化实施 168
5.3.3 精准测试的应用 170
5.4 异常场景测试 171
5.4.1 一个交易服务逆向流程补偿机制的设计 172
5.4.2 使用JVM-Sandbox制造异常场景 174
5.4.3 兼容异常场景测试和正常场景测试 176
5.4.4 异常场景测试平台 176
5.5 测试模块化 178
5.5.1 可复用单元 179
5.5.2 切面化 181
5.5.3 模块化案例 181
5.6 测试环境治理 183
5.6.1 测试环境的标签化容器方案 184
5.6.2 测试环境的配置管理 185
5.6.3 测试环境的可用性巡检 186
5.7 总结 187
第6章 基于工具的研发效能提升（进阶篇） 189
6.1 服务虚拟化 190
6.1.1 Hoverfly的搭建方式 191
6.1.2 Hoverfly的六大模式 192
6.1.3 Hoverfly对有状态请求的支持 197
6.2 变异测试 200
6.2.1 变异测试的概念 201
6.2.2 两个基本假设和六大定义 201
6.2.3 变异测试步骤 204
6.2.4 变异测试实战 204
6.3 高效API自动化测试的分层设计 209
6.3.1 原始状态 210
6.3.2 API定义层 213
6.3.3 Service层 214
6.3.4 TestCase层 219
6.3.5 测试数据层 221
6.4 高效GUI自动化测试的分层设计 223
6.4.1 Page Object 224
6.4.2 Page Section 225
6.4.3 Flow 226
6.4.4 Action 226
6.5 AI在研发效能提升中的应用 228
6.5.1 AI在测试结果分析中的应用 229
6.5.2 使用aiXcoder开发代码的效率提升 231
6.6 单元测试用例的自动化生成 234
6.6.1 EvoSuite 235
6.6.2 Diffblue Cover 239
6.7 总结 240
第7章 组织效能提升 242
7.1 工程效能部：从哪里来，到哪里去 244
7.1.1 工程效能部的背景 244
7.1.2 工程效能部的组织建设 245
7.1.3 工程效能部的未来 247
7.2 业务中台与质量中台 248
7.2.1 中台的深入解读 249
7.2.2 业务中台解读 250
7.2.3 质量中台解读 251
7.3 组织建设中的研发效能度量 252
7.3.1 度量失败的案例 253
7.3.2 度量失败的原因 254
7.3.3 组织建设中的研发效能度量精解 255
7.3.4 组织建设中的研发效能度量误区 258
7.4 高效组织建设的*佳实践 263
7.4.1 不要制定冲突的目标 264
7.4.2 善用激励手段，敢用惩罚手段 265
7.4.3 规避形式主义，勇于做减法 266
7.4.4 重视创新，鼓励“小轮子”经济 267
7.5 企业级研发效能提升的常见误区 268
7.5.1 试图提升研发效能的绝对值 268
7.5.2 迷信单点局部能力 268
7.5.3 过高估计普适性的通用研发效能工具的能力 269
7.5.4 用伪工程实践和面子工程来滥竽充数 270
7.5.5 忽略研发效能工具体系的长尾效应 270
7.5.6 盲目跟风 271
7.5.7 研发效能的“冷思考” 271
7.6 总结 272
第8章 业界优秀研发效能提升案例解读 274
8.1 大型全球化电商公司的“去QE化”实践 275
8.1.1 “去QE化”带来的问题 277
8.1.2 “去QE化”的工程建设 278
8.2 CODING团队的组织效能变迁 288
8.2.1 作坊式的团队组织 288
8.2.2 “稍微”敏捷的团队组织 289
8.2.3 产品制的团队组织 291
8.2.4 基于工具优化助力组织建设 292
8.3 大型通信行业公司的研发效能提升实战案例 293
8.3.1 DevOps实践 294
8.3.2 敏捷开发实践 296
8.3.3 研发效能的度量 298
8.3.4 案例总结 299
8.4 某大型金融行业公司的性能测试提效之路 299
8.4.1 背景与挑战 300
8.4.2 基础平台建设 301
8.4.3 性能测试体系建设 303
8.4.4 案例总结 308
8.5 总结 310
参考文献 312
节选
1.6.1从痛点入手 研发效能提升八项实践建议的**项，是“从痛点入手”。很多时候，当我们手上拿着锤子的时候，看什么都像钉子。但是研发效能的提升恰好是反过来了，我们要先找到哪些是*碍眼的钉子，然后用体系化的方法论去打造合适的锤子。 所以在推行研发效能的早期阶段，我们通常会采用自下而上的策略，从一个个工程实践中的实际痛点（钉子）入手，从解决问题的角度打造研发效能提升的亮点，此时我们追求的是“短、平、快”，遵循的是将问题点逐个击破的原则。比如下面这些场景： ?本地编译耗时长：提供增量编译和分布式编译能力。 ?本地测试困难，测试环境准备复杂且耗时长：基于Kubernetes的Pod提供一键搭建测试环境的能力。 ?自动化测试用例数量大，执行回归时间过长：采用并发测试用例执行机制，使用几百、几千台测试执行机并行执行用例，实现用硬件资源换时间。 ?自动化测试用例维护成本高：测试用例采用模块化和分层体系，实现低成本的自动化用例维护。 ?测试数据准备困难：引入统一的测试数据服务（TestDataService）能力。 ?研发后期阶段，代码递交集中，缺陷井喷：推行测试左移策略，鼓励研发自测，遵循“谁开发、谁测试、谁上线、谁值班”的原则。 ?性能缺陷在研发后期发现，修复重测成本高居不下：从性能测试转变为性能工程，让性能融入软件研发的各个环节，而不是*后的一锤子买卖。 ?安全问题频现：将安全测试能力纳入研发的全生命周期，实现DevSecOps，而不是早期的SDL（SecurityDevelopmentLifecycle，安全开发生命周期）。 ?集群规模庞大，发布过程耗时过长：各个层级的并发部署能力，集群内节点的并发、集群间的并发等。 ?项目的过程数据都是后期集中填充，失去度量意义：项目的过程数据由工具自动填充，不再依赖工程师手工输入。比如，开发完成的时间不再依赖于开发人员手工填写，而是由Jenkins构建完成后自动填写，以保证所有过程数据的真实有效性，从而为后面的度量和改进提供可靠的信息输入。 1.6.2从全局切入 第二项是“从全局切入”。很多时候我们会尝试去优化某个具体的环节，而忽略了全局优化的可能。 举个例子，我们去医院看病，在挂号时经常会出现排队半小时，而实际挂号可能就花费两分钟的情况，接下来很可能又是漫长的排队等待医生就诊，好不容易进入了诊室，可能问诊不到五分钟就又被要求去验血……整个过程中实际有效时间的占比很小。如果这个时候我们还试图去优化挂号本身的时间，而不去关注优化各个环节的等待时间，那显然是错误的方向。因此，效率的提升既要关注单个步骤的优化，也要专注减少步骤与步骤之间的无用等待。这一点体检中心就比公立医院做得好很多，我们很少会见到体检中心每个科室门口都大排长龙的情景，因为体检中心出于经济利益的考虑会关注吞吐量，会通过全局排队调度优化来实现更高的盈利。 回到软件研发领域，你会发现类似上面医院这种不合理的排队现象随处可见，比如软件缺陷的流转，软件需求的实现与交付，软件制品包发布等待，等等。这些也是提升研发效能需要重点关注的领域，需要从全局理清楚全流程，识别出等待浪费的时间，通过流程再造与优化实现全局效率的提升。 1.6.3用户获益 对于研发效能的提升，有一点我们必须牢记，那就是成功的标准不是研发效能平台的成功，而是客户的成功。只有客户获益才是检验研发效能项目成功的唯一标准，下面我们再总结一些要点。 伪需求：伪需求是指研发效能团队自己臆想出来的需求，是属于典型的“手里拿着锤子，看什么都像钉子”的典型案例。那么如何识别伪需求呢？识别标准其实很简单，就看用户是不是愿意和你分摊成本，如果业务线已经开始做了，或者想要开始做，那就说明那是业务线的刚需，如果研发效能平台能帮助用户提供方案，那么研发效能平台的接入就是水到渠成的事情。笔者见过很多这类刚需的例子，比如微服务架构下集成测试环境的搭建就是其中的典型。 结构问题：著名商业顾问刘润说过“结构不对，什么都不对”。比如，两个和尚分粥的故事想必大家都听过，一碗粥两个和尚要均分，但是分粥的和尚总想多喝点粥，那怎么才能做到无监管情况下的公平呢？教育分粥的和尚说出家人“以少吃为怀”吗？显然一旦没有了监管，他就会给自己多分点，解决这个问题的*好办法就是一个和尚分粥，另一个和尚选粥——这个体制就决定了分粥的均匀性。 因此，好的策略是承认每个人都是自私的，但是我们制定的策略要能够在人人都是自私的基础上获得全局利益的*大化。如果全局利益*大化是建立在要求每个人都是大公无私的基础上，那就是失败的设计，因为这必然会导致失败。回到研发效能提升这个问题上，我们必须抱着“不是我们的研发效能平台有多好，而是业务线用了以后有什么提升”的态度来定位自己，才能从结构上获得成功的筹码。 服务意识：理解了上面的观点，再来理解服务意识就很容易了。在研发效能平台落地的过程中，我们需要和业务线互助以实现双赢，业务线收获现成可用的方案，研发效能平台收获*佳实践的沉淀，这些*佳实践的沉淀是至关重要的，为后期的批量成功复制提供了技术基础。 1.6.4持续改进 持续改进是研发效能平台自身发展的必经之路。很多问题在开始时，我们的关注点是如何快、速简单地解决问题，但是当用户量和接入团队日益增长后，我们更需要关注解决方案的普适性和通用性。如果一开始就试图寻找完美的方案，那么必然会得不偿失。 比如，我们需要在Jenkins中通过hook机制去触发一些操作（比如代码静态扫描、单元测试等），*简单的做法就是在hook中实现操作的具体步骤，这种实现在开始的效率很高，也非常容易实现，但却不是*优的方案，因为hook中的代码只会被执行一次，而且hook越来越多以后，各种实现都散落在各个地方，难以维护，一旦有新的需要（比如要加入慢SQL扫描），就需要改hook实现，而且这种做法也违背了IaC（InfrastructureasCode）原则。 更好的做法是引入研发效能的消息中心，通过下游操作的订阅模式来实现未来的可扩展性。但是，如果我们从一开始就创建消息中心，实现的难度和成本都会大增，业务线有可能就等不及这个方案，从而研发效能的提升就无法如期落地。所以我们认为，研发效能的落地可以采取“先圈地、后改进”的策略。 1.6.5全局优化 研发效能提升的落地，光靠自下往上和光靠自上往下都是行不通的，而是应该双管齐下，“从两边往中间挤”才是切实可行的方案。 研发效能提升的初期，主要是靠“自下往上”的工程实践来实现各种痛点问题的各个击破，比如通过分布式编译来降低编译的时长，通过AI技术来自动生成单元测试的用例，通过分析代码递交历史自动推荐*合适的代码评审者等。通过这些专项的效率提升逐渐向管理层证明研发效能提升的实际价值，由此引起管理层对研发效能的重视，进而为管理层从上往下推进研发效能的提升打下基础。 随着研发效能实践逐渐进入深水区，单一领域效能提升的边际效应会逐渐递减，此时基于横向拉通的全局优化变得非常关键，自上往下的推动在此时将会起到关键的作用。很多横向跨部门的流程优化和整合必须借助管理层的力量才能有效地向前推进。 1.6.6效能平台架构的灵活性 这里我们先来讲两个概念：“唱戏的”和“搭台的”。刚开始做研发效能的时候，我们既是搭台的又是唱戏的，在研发效能平台（搭台）的基础上提供各业务线的解决方案（唱戏）。但是，当业务线的接入规模不断扩大的时候，各个垂直领域的多样化需求越来越多，我们已经很难应对各家的个性化非通用需求了（每家要唱的戏都不同）。此时，研发效能平台的开放能力就成为关键，它必须能够应对这种多样性，让业务线能够在平台上实现各自的个性化需求，所以研发效能平台本身的技术架构设计必须考虑可扩展性和灵活性。 比如，我们可以Jenkins持续集成工具视为一个平台，在这个平台上支持安装各种插件，以增强平台功能，从而实现平台架构的灵活性。 1.6.7杜绝“掩耳盗铃” “掩耳盗铃”是我们在落地研发效能过程中经常会犯的错误。下面给出了一些研发效能的“*差实践”，读者可以在心里默默数一数被砸中几条。 ?代码质量门禁Sonar设而不卡。 ?单元测试只是执行，不写断言Assert。 ?代码覆盖率形同虚设。 ?PeerReview走过场。 ?代码递交过于随意。 ?监控超配，有报警但无人认领。 另一种掩耳盗铃的错误实践是普遍采用虚荣性指标来做度量效能，那么到底什么是虚荣性指标呢？虚荣性指标是指那些不能直接用来指导后续行动的指标，我们需要的是可以指导我们行动的可执行指标，可以参考以下内容。 ?“接入Sonar的工程数”就是虚荣性指标，与之对应的可执行指标是“Sonar问题的增长趋势”和“Sonar问题的修复时长”。 ?“系统用户数”就是虚荣性指标，与之对应的可执行指标是“DAU单日活跃用户数”和“MAU月活跃用户数”。 ?“接入研发效能平台的项目数”就是虚荣性指标，与之对应的可执行指标是“百分之多少的项目使用过研发效能平台来完成开发测试和发布流程”。 总而言之，我们需要的是雪中送炭，而不是锦上添花。 1.6.8吃自己的“狗粮” *后一点，吃自己的“狗粮”，意为“做自己研发效能平台的**个用户”，研发效能平台本身的研发流程必须通过自己的平台来执行，这样才能站在用户的角度看待自己的方案，才能和业务线用户“共情”。 如果我们作为效能工具平台的研发团队，自己都不用自己的工具平台来完成研发过程，就很难要求别人也来使用我们的研发效能平台。基于这项理念，我们始终践行的做法是，研发效能团队主持开发的产品和解决方案，自己必须是**个用户，同时我们自己必须认可其带来的价值，只有这样才能站在用户的视角来客观地评价我们的产品和方案，不至于出现“王婆卖瓜自卖自夸”的现象。
作者简介
吴骏龙 WishChinaQADirector，阿里本地生活前高级测试经理，毕业于中国科学技术大学，硕士学位。在软件质量体系、服务容量保障、服务稳定性建设、软件研发效能等领域深耕多年，善于通过创新手段解决质量和效能难题，拥有多项国内外专利。极客时间专栏作者，多次受邀于业界各技术大会发表演讲，传播先进理念和方法论，具备一定的行业影响力。 茹炳晟 业界知名实战派软件研发效能和软件质量双领域专家，硅谷先进研发效能理念在国内的技术布道者，腾讯Tech Lead，腾讯研究院特约研究员。腾讯云、阿里云和华为云Z具价值专家；中国商业联合会互联网应用技术委员会智库专家；多本技术畅销书作者，极客时间专栏作者；“研发效能度量规范”核心编写专家；国内外各大软件技术峰会的联席主席，技术委员会成员和出品人。
-
有限与无限的游戏:一个哲学家眼中的竞技世界
¥37.4¥68.0 -
全图解零基础word excel ppt 应用教程
¥12.0¥48.0 -
机器学习
¥59.4¥108.0 -
深度学习的数学
¥43.5¥69.0 -
智能硬件项目教程:基于ARDUINO(第2版)
¥37.7¥65.0 -
硅谷之火-人与计算机的未来
¥14.3¥39.8 -
元启发式算法与背包问题研究
¥38.2¥49.0 -
AI虚拟数字人:商业模式+形象创建+视频直播+案例应用
¥62.9¥89.8 -
UNIX环境高级编程(第3版)
¥164.9¥229.0 -
剪映AI
¥52.8¥88.0 -
深度学习高手笔记 卷2:经典应用
¥90.9¥129.8 -
纹样之美:中国传统经典纹样速查手册
¥77.4¥109.0 -
UG NX 12.0数控编程
¥24.8¥45.0 -
MATLAB计算机视觉与深度学习实战(第2版)
¥90.9¥128.0 -
界面交互设计理论研究
¥30.8¥56.0 -
UN NX 12.0多轴数控编程案例教程
¥25.8¥38.0 -
微机组装与系统维护技术教程(第二版)
¥37.8¥43.0 -
明解C语言:实践篇
¥62.9¥89.8 -
Linux服务器架设实战(Linux典藏大系)
¥84.5¥119.0 -
PREMIERE PRO 2023全面精通:视频剪辑+颜色调整+转场特效+字幕制作+案例实战
¥69.3¥99.0
