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