研发效能的涉猎面是很广的，软件研发的每个阶段都有研发效能需要关注的问题，以需求价值和研发工作为维度，整理“研发效能双流模型”用于呈现研发效能整体过程。双流模型从软件研发的各个阶段提出了研发效能提升的各种工程实践，并且倡导需求价值流和研发工程流的自动联动。

研发生命周期管理

在整个研发过程中，需要从需求卡片开始贯穿整个研发生命线，设计评审、开发测试、生产运维都是以需求卡片为核心点分阶段实施执行的。

以需求为入口贯穿研发周期

在一个需求卡片下可以查看到对应该需求的设计文档、测试用例等一些文档沉淀，同时卡片状态在扭转过程中的变化也要关联呈现，做到实时跟踪，全流程透明。此处需要理解对研发数据打通的正确认知，不是为了单纯的留痕记账，而是为了实时跟踪进度、透明化工作量、及时捕获风险，反哺项目管理与积累知识沉淀。

划分责任边界

    为了提高研发效能和保证工程质量，在整个研发生命周期中需要明确各阶段的责任边界，避免由于责任所属不清导致问题无法跟进落实的情况。对于BRD、PRD和技术设计方案均由各产出方对其质量负责，研发过程中发现任何由于设计产出异常导致研发成本升高的问题，均需要对应的产出方负责。虚拟架构组持续收集线上线下问题，迭代跟踪，分类研究制定最终解决方案。

    这里还需注重说明，尤其是开发和测试要划分好明确的责任边界，生产故障不应由开发和测试共同背负，提测阶段所有测试出来的BUG均由开发承担，一旦测试通过发布到生产后的问题均由测试承担。

    只有划分清楚责任边界，才能在每一个子环节中保证其产出的质量。

                                     （问题处理流程）

DevSecOps

    我们知道，DevOps 不仅仅涉及开发和运维团队。而如果想充分发挥出 DevOps 的敏捷性和响应力，就必须将IT 安全防护融入应用的整个生命周期中 。随着近年来行业对安全重要意识的觉醒，系统安全已经是一个必要的考量因素，采用 DevOps 可以有效推进快速频繁的开发周期（有时全程只有数周或数天），但是过时的安全措施则可能会拖累整个流程，即使最高效的 DevOps 计划也可能会放慢速度。

    在 DevOps 协作框架下，安全防护是整个 IT 团队的共同责任，需要贯穿至整个生命周期的每一个环节。这个理念非常重要，因此催生出了“DevSecOps”一词，强调必须为 DevOps 计划打下扎实的安全基础。

    DevSecOps 意味着从一开始就要考虑应用和基础架构的安全性；同时还要让某些安全网关实现自动化，以防止 DevOps 工作流程变慢。选择合适的工具来持续集成安全防护（比如在集成开发环境（IDE）中集成安全防护功能）有助于实现这些目标。但是高效的 DevOps 安防需要的不仅是新工具。它更需要整个公司实现 DevOps 文化变革，从而尽早集成安全团队的工作。

在我们日常工作中安全其实是无处不在的，比如：

• 技术设计阶段就需要考虑安全架构部分，产品研发过程中要考虑敏感数据的传输和保存、代码安全漏洞扫描等问题；

• 对外交互过程中需要考虑相关秘钥管理和算法问题；

• 生产环境部署时，部署拓扑结构需要分为DMZ区、业务核心区、数据存储区等安全区域划分以及部署服务器安装蜜罐、HIDS、WAF等安全软件问题；

• 日常运维过程中需要考虑访问权限控制和生产数据留存操作等问题。

DevSecOps 强调，在 DevOps 计划刚启动时就要邀请安全团队来确保信息的安全性，并制定自动安全防护计划，实现持续 IT 防护。它还强调，要帮助开发人员从代码层面确保安全性；在这个过程中，安全团队需要针对已知的威胁共享掌握的全局信息、提供反馈并进行智能分析。由于 DevSecOps 并非始终着眼于较为传统的应用开发模式，所以这可能还包括为开发人员提供新的安全培训。

可参考：

1、https://www.redhat.com/zh/topics/devops/what-is-devsecops

2、https://netsecurity.51cto.com/art/202101/639217.htm

敏捷迭代

通过引入敏捷迭代开发模式应对需求优先级管理混乱，牺牲代码质量承接紧急需求上线等问题，同时敏捷迭代开发可以有效的提高研发团队的产出节奏，合理控制输入输出。

流转开发规则 : DoR-Definition of Ready

流转测试&发布规则 : DoD-Definition of Done
DoR + DoD = 其本质是对整个研发过程的质量要求

推荐敏捷沟通群：

沟通阶段

    业务方在提交需求时需要有详细的BRD，根据BRD内容进行需求评审，如果是迭代已有业务需求，在需求评审阶段产品可以准备PRD草稿配合评审，避免空对空的场景。

    有时也存在需求倒置的情况，即已完成开发测试甚至是已投产的需求，再拿到需求评审会上进行讨论，只起到了信息同步的作用，丧失了需求管理的本意。

    该阶段在明确受理需求后，各技术团队应提供具体的工作排期，项目经理或产品经理需完成对应需求卡片的录入维护工作。

怎么做好需求评审：

    在做需求分析时一定要了解业务方提出需求的背后意图，通常就是一句询问的过程。比如，业务方说需要增加一个支付工具调用量的查询接口，单从需求角度来说是需要满足业务方的，但是此时我们可以深入询问一下『为什么需要我们增加这支接口啊？』，业务方可能会和你说：我们想通过支付工具的交易量来决定对于接入渠道的成本做评估预算，其实这可能就涉及到了支付交易路由的需求，我们可以根据业务方的预算去调整我们的支付渠道排序，选择最佳成本的支付渠道。

设计阶段

无论需求大小，理论上都应该有BRD和PRD，可参考集团统一规范。对应的设计产出要有相关评审，参与评审人员根据具体需求而定，但建议尽量将相关方聚齐，避免由于信息不对称或统一问题重复说明等场景。同时，评审相关会议由于涉及人员角度尽量控制会议时间和核心议题，会议前要提前同步评审文档；会议评审过程要抓住评审重点，避免无限发散；会议后要有详细的会议纪要，并将其最终确认的产出物上传到需求卡片进行关联。

• BRD参考模板：

• PRD参考模板：

• 技术方案参考模板：
  

使用说明：

根据模板定义，编写系统的设计方案。可以根据实际情况使用该模板。

对于必填项目需要完整填写，否则可能影响方案评审。

方案基本信息：

项目发起人	项目负责人	版本号	备注
ZZZ	SSS	yyyy年mm月dd日_小版本号	...

方案内容项：

1. 项目背景（必填）

   这里简要描述需求内容。如果是产品发起的，请把prd链接贴在这里。

2. 项目目标（必填）

   实施项目预期的效果说明。比如 实现项目的故障AI识别和自动告警等。

3. 对现有架构影响（必填）

   描述对当前项目相关的其他项目的影响。

4. 总体系统架构图（必填）

   这里描述项目的整体架构设计，最好直接贴上简洁明了的架构图

5. 功能组件设计

   这里描述项目具体功能组件的 架构图，流程图，时序图等。

6. 系统部署图

   如果新项目，需要完整描述部署的架构图。

7. 投产方案

   包含切量方案，资源需求，相关配置等信息。

8. 验证方案

   验证方案可行的方式说明。

9. 兜底方案

   描述项目覆盖的需求场景下，如何收敛故障和异常导致的问题。

10. 运维方案

    运维相关的方案和描述

11. 风险（必填）

    如果方案实施的范围不能全场景覆盖，需要说明不适用此方案的情况可能发生的问题。

12. 安全性（必填）

    项目自身的安全性以及对于依赖项目造成的安全性问题描述。

13. 任务拆分及排期（必填）

任务说明	开发时间	联调时间	提测时间	上线时间	备注
任务A
任务B

超过3天的需求鼓励提交至少两份设计方案，方案中需包含API设计和基本类图，评审通过才能开始开发。此方法可以避免研发小伙伴在接到需求产出技术设计方案时，完全按照自身的了解和习惯产出最终的所谓"潜意识方案"。多出一套方案就会对一些思考，技术方案设计环节我们要不断的告诫自己，我们究竟是要做『一锤子买卖』还是要做一个『百年老字号』的系统。如果是前者，那大可以想到哪里代码就写到哪里；但如果是后者，则需要我们综合考虑多个方案，选择更能可持续反战的方案，尤其是现在BPaaS输出又是我们的重点目标。

技术方案的价值有时是需要长周期的验证才能体现出来，更多时候是需要在短期收益和长期价值中进行取舍，这一环节应该控制在固定的工作量范围内，在能够满足本次业务迭代的前提下尽可能的提升系统架构的长期价值。