理想中的研发团队应当具有以下特征：
- 总是工作在最高优先级的事项上
理想的研发团队能够识别并始终集中精力在当前最紧迫和最有价值的任务上。这需要团队具备出色的项目管理能力和决策能力，以便能够正确评估优先级，做出合理的工作分配，并快速适应项目需求的变化。
- 各个角色既能专注于自身的专业工作，又能彼此高效协同
每个团队成员都应当是各自领域的专家，并且全身心投入到他们擅长和负责的工作当中。然而，这并不意味着他们仅限于个体工作。一个理想的研发团队鼓励跨学科合作，通过敏捷的沟通机制和共享的工具，确保信息能够顺畅地在团队成员之间流通。团队中的设计师、工程师、产品经理和其他角色之间应当存在协同工作的文化，这样的多元化合作能够促进创新思维，并最终导致更高质量的产品开发。
- 团队和个体的技术和工程能力能持续改进
理想研发团队不仅在现有技术上精通，而且持续追求技术和专业技能的提升。这意味着个人和团队都应该鼓励创新和实验，并且能做到快速试错、快速反馈。同时，团队应该有制度鼓励个人在工作中尝试新方法和技术，这种文化不仅有助于团队的长期成长，也有助于吸引和保留那些富有好奇心和热情于学习新事物的人才。
一个拥有如上特质的研发团队更有可能成功地完成复杂的项目，创造创新的产品，并在竞争激烈的市场环境中获得成功。
1. 团队工程交付的常见问题
要成为上面所述的优秀研发团队确实需要付出巨大的努力和持续的改进。在追求理想状态的过程中，以下三个问题经常成为阻碍团队达到理想特质的障碍：
1）信息传递失真：团队内部成员来自不同的专业背景，使用的术语和概念也各不相同。例如，开发说发布一个应用，运维说对一个服务做变更，但他俩说的其实是同一件事情。在日常协作中，需要将这些信息从一个领域转换到另一个领域，并确保信息不丢失、不扭曲。如果处理不当，就会导致团队成员对项目的理解出现偏差，从而影响决策和执行。为了解决这个问题，可以通过建立统一的概念模型、使用共享的术语库、提供跨部门交流培训和使用相同的工具平台等方式来减少信息传递过程中的失真。
2）流程没有连接：尽管每个研发阶段内部可能已经实现了自动化和高效的运作，但是当一个项目或需求从一个阶段转移到另一个阶段时，往往缺乏流畅的衔接。举个例子，有的企业开发人员和测试人员属于不同的职能团队，开发人员提交代码后，自动会触发代码的构建、静态检查、单元测试等环节，但到了功能测试阶段，开发人员需要手动填写提测单，在提测单里写上代码版本、单测结果、静态检查结果、部署方式等，由测试人员线下确认后，再流转到功能测试阶段。这种阶段间的断层通常需要依赖于团队成员之间的线下沟通和非正式协议，这容易造成流程上的混乱和效率低下。要打破这些障碍，团队可以尝试引入端到端的研发管理工具和流程，确保流程的透明化和自动化，从而形成一个无缝连接的、整体的研发流程。
3）无法识别重点：当团队同时处理多个项目和需求时，工程活动可能会分散在不同的工具和平台上。这种分散导致团队成员很难追踪整体的进展，也难以判断哪些任务是当前的重点。信息的碎片化使得团队难以集中注意力在最紧迫的需求上。解决这个问题的关键在于建立统一的研发管理系统，按研发任务聚合工程活动，实时展示各个任务的状态和优先级。此外，定期的回顾会议和优先事项的重新评估也是确保团队能够集中精力在最有价值的工作上的重要做法。
总结来说，成为一个优秀的研发团队不仅需要专业技能的不断提升，而且还需要针对信息流通、流程衔接和重点识别等方面的问题进行系统的解决方案设计和实施。通过持续的努力，优秀的团队可以逐步克服这些拦路虎，走向成熟和效能的最高标准。
因此，改进的第一步是要能看见工程活动和研发模式，进而识别其中存在的问题。
2. 统一工程交付的概念模型
为了有效解决信息传递失真、流程不连贯等问题，确保信息的流畅传递和流程的无缝连接是至关重要的。这就要求从根本上统一工程交付的概念模型，使所有参与者——无论是开发人员、测试人员、产品经理还是任何其他相关方——都拥有共同的理解框架。
在解决这些问题的过程中，云效联合产学研各界于 2022 年发布了 BizDevOps白皮书，该白皮书提出了 BizDevOps 完整的概念模型，通过该模型，可以更清晰地界定和管理研发生命周期中的各个环节。
具体到模型本身，它将业务需求、产品需求、变更请求定义为时标对象，这些时标对象在时间轴上代表了需求的生成和变更的发生。每一个变更请求都与特定的应用相关联，而应用就是变更请求所属的空间或上下文。这样，工程交付的核心概念就被简化为两个主要元素：应用和变更请求。此外，还包括了应用的一些重要附属属性，例如变更内容、环境、部署编排和研发变更流程等。这些属性共同描述了从需求提出到最终部署的完整过程。
通过应用这个核心概念，工程侧能够高效地聚合研发资产和研发流程，形成一个集中的管理点。这有助于优化资源分配，提高研发效率，同时也有助于跟踪和度量研发过程中的关键指标。
另一方面，变更请求作为时标对象，承担了连接不同研发活动和项目协作的关键角色。通过对变更请求的跟踪和管理，团队可以确保所有的活动都围绕着实现具体的业务目标进行，同时使得整个工程交付过程更加透明和可控。
综上所述，这个模型不仅为团队成员之间的沟通提供了共同的语言，还为整个研发周期的管理提供了一套清晰的指南，从而使得各个环节能够紧密协作，确保研发活动能够高效、有序地进行。
3. 定义应用交付的模式
拥有了统一的概念模型后，我们得以实现对研发资产和流程的系统化规范和高效管理。具体来看：
1）基于应用将研发资产和研发流程有效地规范和管理起来：我们为此构建了一套标准化模板，旨在帮助团队对应用的研发资产和流程进行全面梳理。这个模板涵盖的内容包括但不限于：
a. 应用相关角色及其权限：定义每个涉及应用开发的角色（如开发人员、测试工程师、产品经理等）以及它们相对于应用的权限，确保权限的分配既满足安全要求又促进工作效率。
b. 应用的代码和制品：明确代码库管理和制品库的使用，以及不同角色在代码提交、审核、制品生成和存储过程中的职责和权限。
c. 应用的分支模式：规定了源代码管理中各种分支的使用场景和规范，以及不同分支对应角色的职责，确保代码的版本管理既清晰又高效。
d. 应用端到端的研发流程：详细描述了从开发任务的启动到产品的最终上线，涉及的所有阶段和流水线，包括每个阶段的具体任务、责任分配、准入和准出标准，以及阶段间的衔接方法。
e. 应用的环境及其与角色的对应关系：梳理各种环境（如开发环境、测试环境、生产环境）的配置和用途，以及各个环境中不同角色的责任和权限。
2）基于变更请求将产品需求和开发任务端到端地连接起来：与上面的静态资产和流程管理相比较，这里更侧重于需求到上线这一动态的研发流程。
a. 创建变更请求：这一流程的第一步通常是将产品需求转化为技术任务，即变更请求，这些变更请求直接属于相应的应用。
b. 指定变更范围：变更请求的创建过程中，会指定其变更范围，通常指定为某个代码库的特性分支。开发人员在此分支上进行代码提交，触发应用的研发流程。
c. 执行研发流程：随着研发流程的展开，变更请求会逐渐通过各个阶段，特性分支也可能会被合并到集成分支或发布分支。每个阶段的执行频率可能不同，一般情况下，越接近流程的末端，执行的次数就越少。
d. 完成变更：当变更请求成功通过最后一个阶段，它就被视为完成。同理，一个产品需求所对应的所有变更请求一旦全部完成，那么这个产品需求也就可以宣布完成或者发布上线。
4. 基于云效平台的落地方法
我们强烈建议在落地工程交付实践之前，先把需求协作实践梳理清楚，关于这一块内容，推荐参考：如何制定科学有效的需求流程规范。
接下来，我们会借助云效平台，按照前面章节的示例，定义应用的交付模式，并按照该交付模式完成一个产品需求交付的完整流程。
4.1 通过应用模板定义应用交付模式
我们通过应用模板来承载团队的工程交付模式，这里我们以前面提到过的基于 feature 的持续交付模式为例。
该交付模式的特点是开发、测试均基于特性分支，集成发布均基于主干分支，属于快速开始，快速集成，快速交付，推崇单个特性的独立开发、独立测试、独立集成于独立交付。首先，在云效 appstack 上创建一个名为“特性驱动的持续交付模板”的应用模板。
在该模板上开启“变更 + 研发流程”服务。
按照 feature/master 两阶段的研发流程，为这两个阶段分别定义变量组，在变量组中使用不同的 k8s namespace，以及指定不同的副本数。
接下来通过模板来规范应用的部署方式，云效推崇多套环境一套编排模板的实践，差异性的部分通过变量组来定义。
然后，我们规定每个应用都有两套环境，分别为用于 feature 开发验证的“特性验证环境”，和用于集成发布的“生产部署环境”。这两套环境与对应的变量组、部署编排和集群资源（可选）关联。
我们已经确定了应用的环境和部署策略，接下来我们规范应用的研发交付流程。
我们要求应用从开始开发到完成交付，需要经过特性验证和生产部署两个阶段的验证，且只有经过特性验证阶段的 feature，才能进行生产部署。为了做到这一点，我们创建了一个两阶段的研发流程，分别为特性验证阶段和生产部署阶段。
在特性验证阶段，我们定义了一条包含 4 个步骤的流水线，分别为代码检视、构建、部署和测试，且规定分支为自由选择方式（可在流水线配置名称前缀为 feature- 的分支有新的代码提交自动触发）。
在生产部署阶段，我们配置了一条有 5 个步骤的流水线，分别为代码检视、构建、审核、部署和完成变更。同时限制流水线运行分支为 master，且执行时相关 feature 在特性验证阶段的执行结果为成功（云效会自动计算流水线执行时所涉及到的 feature 分支，并判断其前序阶段的执行成功与否）。
至此，我们完成了应用模板的定义，现在，让我们基于该模板来创建一个应用，并完成一个特性的交付。
通过应用模板创建好应用后，还需要设置好应用所关联的代码仓库和相关成员。
4.2 分析产品需求，拆解变更请求
假设我们接到一个产品需求，需要将查询服务接入风控，避免爬虫攻击。为此，我们为 risk-control-srv 拆解了一个变更请求，并关联到该产品需求上。
4.3 在变更分支上提交代码，进行持续验证
由于设置了代码提交至 feature 分支自动触发特性验证阶段的执行，每次在 feature 上 push 代码后，都会自动进行验证并给出反馈。
4.4 通过代码评审合并变更分支，进入生产部署
当代码评审通过并合并入 master 分支后，会自动触发生产部署阶段的执行。
4.5 完成变更，进而完成产品需求
生产部署阶段执行完成后，变更请求会变为已完成状态，同时其对应的产品需求也会自动进入已完成状态。
5. 后记
本文从统一工程交付的概念模型开始，介绍了如何将应用交付的模式显式地定义出来，并通过工具平台落地。但需注意，团队的工程交付实践往往不存在标准解，我们都是在寻求当前场景下的最优解。在具体的场景下，团队的工程交付受到协作机制和技术水平的双重制约，因此需要我们把视角从工程交付本身跳出来，结合协作、技术一起来看，并持续优化和改进，才能找到适合我们自身团队的最佳实践模式。
作者：张裕、雅纯