| 编辑推荐: |
本文主要介绍了为什么要提升研发效能、什么是研发效能及如何提升研发效能。
本文来自于微信公账号DevOps时代 ，由火龙果软件Linda编辑，推荐。 |
|
研发效能是什么？为什么现在都在谈如何提高研发效能？研发效能对于一个企业到底有多重要？本文按照Why、What、How三步走沉淀梳理了研发效能相关的知识点。
一、为什么要提升研发效能
传统的职能部门组织架构带来的效率竖井问题
人力的增加没有让项目进度加快
长久加班导致团队士气低落，后续的效率降低
上线前加班、熬夜，压力大
上线后Bug、事故频发，实现效果与需求不匹配
各种重复低效工作，疲于应付业务
想要有限的人力做更多的产出
二、什么是研发效能
对于一个企业来说，追求的是企业效能的最大化，包括：利润、用户规模、客户满意度、运营效率等。而对于需要研发自有产品的互联网公司来说，研发效能则是服务于企业效能的至关重要的因素。
一个软件研发的完整流程如下图所示：
此流程交付期望产品的效率和能力，即研发效能。更进一步的《研发效率破局之道》中将研发效能定义为团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）
三个方面。其增加的可持续性指出研发效能应该着眼于长期效果。
一句话来讲，研发效能就是持续快速交付价值的能力。
三、如何提升研发效能
对应于第一部分中讲述的软件开发流程，如果想要提升研发效能，那么需要落实到研发流程（组织结构、项目管理、持续交付）、工程方法、个人效能以管理和文化的实践上。本文重点从研发流程、工程方法两方面来讲。
3.1 衡量指标
评估一个组织持续快速交付价值的能力，需要一组可量化的数据或参数，用来跟踪和评估开发过程的“健康”状况。
3.1.1 指标分类
持续发布能力
发布频率：单位时间内的有效发布次数
发布前置时间：从代码提交到功能上线花费的时间
需求响应周期
交付周期时间：从确认用户提出的需求开始，到需求上线经历的平均时长。
开发周期时间：从开发团队理解需求开始，到需求可以上线所经历的平均时长。
交付吞吐率
单位时间交付用户需求数量：单个团队的对比
交付过程质量：质量内建
缺陷创建和修复时间分布：缺陷能够持续和及时地被发现，并在发现后尽快修复。
缺陷库存：开发过程控制缺陷库存量，让产品始终处于接近可发布状态，是持续交付的基础
交付质量：系统的可用性
单位时间问题数目
线上问题解决时长
3.1.2 通用目标
2：2周交付周期。从想法提出并确认到上线的时间。【跨职能、组织的协调一致和紧密协作】
1：1周开发周期。从需求设计完成（对开发就绪）到达到可上线的时间。【需求的拆分和管理，开发团队的分工协作模式，持续交付实践】
1：1小时的发布前置时间。代码提交后可以在1小时内完成发布。【持续交付流水线】
3.1.3 选择优化指标
流程中总是有一个核心瓶颈。分析关键路径、定位瓶颈，针对优化
使用指标来发现问题而不是做绩效考核
使用指标来检验优化效果
使用价值流图/累积流程图发现全局瓶颈，从而确定需要提升的度量指标
3.2 组织结构&&项目管理
3.2.1 组织结构
避免“效率竖井”：采用以业务为单位的组织架构，保证业务线全栈配齐，目标一致。并从全局定位瓶颈进而进行优化工作。
3.2.2 项目管理
使用敏捷开发来提升研发效率
敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。
软件应该一直处于可工作状态
每个迭代都能将软件部署到一个类生产环境中，并向用户演示
迭代长度不超过两周
透明性、协作性、纪律性和持续改进
使用MVP，度量驱动开发
流程尽快流动：工程方法支撑
发现整个流程中的瓶颈，并解决：可视化工作流、事故复盘
避免“小瀑布”
价值排序
满足客户需要
需求拆分成能够独立测试的需求！！！
看板
从个人转变到关注价值流动：待开发->设计->开发->开发自测->代码评审->测试->完成
明确的“完成的定义”DoD，明确了状态迁移必须完成的活动
从实际出发、以终为始：以实用主义的态度，从原则出发，灵活优化流程
3.3 持续交付
持续交付指的是在短周期内完成软件产品，以保证软件保持在随时可以发布的状态。让每一个变更都经过一条自动化的检验流水线，来检查每一个变更的质量，通过就进入下一个阶段。其不是一种工具，而是一种实践！
不要阻塞开发人员
每个团队指定构建负责人或者发布工程师：优化交付流水线，提升交付效率
项目状态，应该对参与整个过程（包括构建、部署、测试和发布）的所有人都是可见的
迭代增量式交付是有效风险管理的关键
手工测试环境、试运行环境和生产环境总是需要严格的访问控制
让风险识别成为每日立会的一部分
审计
手工测试环境、试运行环境和生产环境总是需要严格的访问控制：指定谁能够访问“特权”环境。
要求每次部署都要进行审计，以确切知道到底修改了哪些内容。
文档自动化、自文档
具体可见：持续交付这点事
3.4 工程方法
3.4.1 技术债
在开发产品或者功能的过程中，没有使用最佳的实现方法而引入的技术问题。需要持续关注业务和技术债。对业务机会敏感，敢放手一搏大量借贷，也知道什么时候必须偿还技术债。
利用技术债的好处，必要时要大胆“举债前行”
控制技术债，在适当的时候偿还适当部分的技术债。
3.4.2 云计算
利用好云计算带来的服务化、自助化和弹性伸缩三大优势。初创公司在业务刚起步时，使用 SaaS 或者 PaaS
快速开发业务；业务成长到一定规模之后，再逐步转到 IaaS 以及私有云降低成本。
细节抽象得越多，云服务商负责的部分就越多，我们就越能够聚焦自己的业务，从而提高研发效能
使用云资源时，通过工具或者 API 调用来完成工作，减少人工参与，达到自动化
资源共享、弹性伸缩
容器：不可变基础设施；基于K8S建设PaaS
在使用云计算时，要妥善处理它带来的挑战，比如分布式系统带来的安全和控制方面的问题。
自治和集中管理相结合：信息可视化（系统整体的质量看板、调用链追踪）
错误处理
3.4.3 测试机制
上文持续交付一部分中最关键的其实就是测试部分，只有具有完善、可靠的测试机制，才能保证研发质量和交付效果，才能从根本上提高研发效能。
测试左移：质量内建，即持续交付中的测试机制。
按照功能的维度管理团队，让整个功能团队对产品负责；改变团队成员对测试工作的认知
把测试添加到开发和产品需求步骤中
频繁测试，快速测试：提升测试运行的速度，并行运行、提高构建速度、精准测试、分层测试、减少不必要的用例
测试右移
利用线上的真实环境测试：需要有完备的数据隔离机制
测试人员介入线上监控和预警，及时发现问题并跟进解决
混沌工程：即在真实环境中通过模拟各种不可预期的故障来验证系统稳定性
3.4.3 平台化
通过抽象共性组件、功能，达到代码、功能复用，从而减少重复开发，提高研发效能。
技术平台：技术设施的复用
数据中台：数据沉淀和输出能力
移动中台：前端组件、跨平台开发、插件化、热加载
业务中台
业务能力的复用
赋能业务
相关资料可见：中台简谈
3.5 个人效能
如何提高开发人员自身的开发效率，除了每个人自身的天赋能力外，也有一些可以刻意使用的高效工具和方法。
高效工作方法
抽象和分而治之
快速迭代
DRY
番茄工作法
高效开发工具
好的IDE
操作系统快捷键
思维导图软件
学习笔记软件
文档撰写工具
持续学习：不断地学习新的开发技能，从而提升自己的开发效率
此外，还可以通过技术管理从外部驱动个人效能的提升，这在下面的技术管理部分会讲。
3.6 管理和文化
3.6.1 技术管理
管理包括：看方向、管人、管事。做好技术管理是提高研发效能的关键部分。其中，3.4节个人效能部分的数字驱动也是技术管理的一部分。主要步骤包括：
制定目标：兼顾业务目标和技术目标
目标管理：使用OKR等目标管理方案
计划并执行去实现目标
此外，技术管理中一个很难的问题是如何进行考核。这里可以使用数字化的方式，以驱动个人效能的提升。
选择个人效能度量指标
根据代码提交日志自动生成工作日报和周报、个人贡献值
综合多维数据构建个人的数据画像
社会地位：用排名、榜单来实现；
工作本身：用复合型报告去综合评价，告知员工究竟做得好不好
自我改变：通过雷达图，进行多维度的数据分析，精准提炼员工的优点与不足，员工可以有针对性的取长补短。
需要说明的是，如果指标不能全方面的衡量，就不要做为考核指标，仅仅用于发现问题，解决问题！
一个可参考的技术管理标准动作模板见：技术管理标准模板
3.6.2 团队文化
团队文化是团队成员共同认可的价值观和行为准则，良好且有效的文化是保障团队高效产出的关键部分。很多互联网公司都是工程师文化主导的，包括Facebook、Google、百度等。他们也都具有自己独特的企业文化价值观，如百度的简单可依赖、谷歌的不作恶、Netflix的自由和责任。建立团队文化的步骤如下：
定义：总结、明确自己团队的文化，提炼出简单易记的文字。
主张：各种形式的传播。从我自己的经历来看，不断地念经是其中最有效的方式。
追求：在奖惩中体现出文化价值观的作用。如对于文化价值观贯彻优秀的同学给与公开的肯定与奖励。 |
