微网站开发方案模板,惠州seo建站,怎么查询网站备案服务商是哪个,男女做暖暖的免费观看网站简介#xff1a;研发效能提升不知从何下手、一头雾水#xff1f;阿里资深技术专家一文为你揭秘研发效能提升的系统方法。 注#xff1a;本文是对云栖大会何勉分享内容的整理 这几年“研发效能”一直是热词#xff0c;很多组织都会启动研发效能提升专项。我与其中的很多有过…简介研发效能提升不知从何下手、一头雾水阿里资深技术专家一文为你揭秘研发效能提升的系统方法。 注本文是对云栖大会何勉分享内容的整理 这几年“研发效能”一直是热词很多组织都会启动研发效能提升专项。我与其中的很多有过深入的交流他们中达成最终目标的并不多经常是高调开始草草收尾。为什么什会这样呢 提升研发效能首先要弄清楚要解决的问题是什么然后才是落地解决问题的实践方法。否则问题没定义清楚就很难有好的结果。 那提升研发效能究竟要解决什么问题 我将提升效能要解决的问题归纳为3个效能不等式。 三个不等式揭秘研发效能的本质 第一个不等式局部效率不等于高效交付 这一点大家应该会感同身受。当我们去问各个部门或者个人时都觉得他们很忙效率很高。但是我们去问业务部门或用户却是另外一回事他们会抱怨产品研发响应慢、交付迟、质量也不好。 这就是组织内部视角的局部效率并不等于用户视角的高效交付。这个是提升研发效能要面对的首要问题。解决它需要更有效的组织协同、更合理的交付模式和更好的过程质量。 接下来的问题是高效交付就够了吗这就引出了第二个效能不等式。 第二不等式高效交付能不等于持续高效 有的时候为了高效的交付我们可以采取临时动作比如把一群人关在一起成立一个临时项目这样沟通协作会更便捷这可能会达成一时的高效。但是如果缺乏长期质量思维当我们在做下一个项目往往会发现问题之前的代码和设计存在各种问题比如可修改、可复用性很差它们成为后续项目的负债而不是资产长期的效率无法维持。 如何从高效交付转变成持续的高效这是研发效能要解决的第2个问题。它对我们的工程和技术能力和实践都提出了要求。 第三个不等式高效交付不等于业务成功 产品交付的目的是支持业务发展和业务创新。我们必须保证交付的东西能解决用户问题并构建可持续的商业模式否则交付再多也没有意义。 今天市场和用户的不确定持续增加破解这一问题不容易。它需要整个组织能够聚焦用户问题快速交付和试错并形成有效反馈调整的闭环。做到这三点才能让高效交付转化为业务成功这是提升研发效能要解决的第三个核心问题。 我们认为研发效能提升的本质就是要解化解上面的三个不等式从而把组织内的局部效率转化为用户可感知的高效交付并保障持续的高效和带来业务的成功。最终实现“持续地顺畅高质量交付有效的价值”。这是效能提升的根本目标。 研发效能提升实践体系 明确问题是开始解决它们需要系统的实践方法。接下来我们分享这些实践方法它是我们对过去的实践的提炼和总结并概括为这个图。 整个图分为三个模块 左侧是协作和需求实践。左上方我们称之为业务驱动需求的协作模式和产品导向的交互模式下边是以终为始的需求分析和设计。左侧这部分实践解决的是局部效率如何带来高效的交付。 右侧是工程与技术实践。右上方我们称为领域驱动的架构和实现中间是标准化的工程基础设施下面是应用为中心的持续交付这部分实践解决的问题是如何让我们高效交付带来持续。 中间这部分是创新实践。它包含如何高效探索业务、如何持续快速地完成业务交付并形成有效的反馈和调整的闭环。创新实践要解决的问题就是高效交付如何带来业务的成功。 接下来我们一步步展开看一下各部分的关键效能提升实践。 协作和需求实践 首先我们来看协作需求实践。 在介绍协作之前我们需要弄清楚协作的上下文——也就是当我们谈协作时我们在谈什么。 让我们先从梳理需求交付的内在结构开始。 首先产品交付都是源于目标有可能是用户目标如更高效的完成某项工作也有可能是业务目标如实现业务的增长提高用户的黏性等。我们基于用户目标和业务目标规划业务需求。除了业务目标外客户的具体诉求也会转化为业务需求。 业务需求的实现需要落地到产品中它会被分解为一个个的产品需求。产品需求会进一步被分解为技术任务通过实现技术任务来交付产品需求最终实现对应的业务需求。 当然产品需求并不一定都直接来自业务需求产品也会做出自己的规划包括架构的升级和技术重构或者面向未来的前瞻性技术布局如AI算法、区块链平台等。这部分产品需求虽然不来自当下的业务需求但它同样服务于业务目标只不过是长期和未来的业务目标。 了解了产品交付的结构之后接下来我们看在这样的结构下如何实现团队的高效协同。 业务驱动的协作模式 首先我们协同的结构应该和前面的产品交付需求层次结构一致。业务需求、产品需求和技术任务由不同的职能的人来负责例如业务人员负责创建业务需求业务人员和产品经理一起把业务需求规划分解为产品需求。 业务需求、产品需求、技术任务这是交付需求过程中的基本价值单元。而文档、代码、测试、数据等都是为它们服务的与应该向它们关联并沉淀为资产。 业务需要被收集、管理、规划和交付完成这些工作需要有独立的空间,它对应研发协同工具中的“业务空间”。在业务空间中还要能看到业务需求是如何拆分为产品需求的。我们称之为管一层也要向下看一层这样才能保证业务需求交付。 业务需求交付是一个动态的过程需要清晰的工作流它定义了业务需求从提出、接收、规划直到发布、验收的整个过程。顺畅高质量地交付就是要让这个工作流更加顺畅减少过程中的阻碍和等待。 与业务需求一样产品需求也需要被收集、管理、规划和交付研发管理工具同样要为产品人员提供专属的产品交付空间并定义产品交付的工作流。技术开发者也需要对他们友好的工作台。在这里他们接受、管理、计划和完成技术工作。 更重要的是我们需要让这三个层次三者变成有机的整体让大家真正的协同起来顺畅的交付业务需求。这三个层次的工作流是相互关联业务需求规划后被拆分为产品需求产品需求会被进一步拆分为任务这些是自上而下的。 再看自下而上的下层的工作完成后它的状态要能够被自动卷积上去比如产品需求下所有的任务完成后对应的产品需求进入待测试状态。业务需求所有产品需求完成后业务需求的状态也需要自动变更。 这三个层次的联动和透明让问题和阻碍更容易被识别比如业务需求交付延期或者出现问题时能清晰的看到是哪一个产品造成的应该在哪里采取动作。 我们把这称为业务驱动的协作模式。组织中不同的职能和团队必须相互协同完成业务交付达成用户或者业务的目标业务驱动的协作模式让这一过程更加透明和高效。 产品导向的交付模式 前面讲的是协作模式企业的业务需求最终还是要到落实到产品交付团队中交付的。以前我们更多把IT交付团队看成成本中心先确定需求范围再确定时间然后分配资源、成立项目、完成交付这也被称为项目导向的交付模式。 项目导向的交付本质是把人作为资源分配到事情上。其背后的假设是未来是确定的在确定的时间内交付确定的内容。它强调计划和执行追求交付的确定性。 确定性今天已经越来越不现实组织必须学会与变化共舞。另外项目导向的交付导致短期思维缺乏工程、技术长期改进意识。同时因为团队的临时性也无法持续团队的交付效能。 数字化时代我们需要从项目导向的交付模式向产品导向的交付模式迁移。产品导向的交付模式本质是把事情交给跨功能的特性团队由相对稳定的特性团队持续的接受并完成需求的交付。 特性团队对产品的迭代负责他们拥抱业务的不确定性并为此不断演进产品。特性团队要维护产品必须建立长期思维注重代码资产和工程资产并持续改进团队交付能力和交付流程提升交付效能。 但这还不够因为如果各个产品各自为政任何特性团队的需求过载都会让它成为整个业务瓶颈解决办法是同一业务领域的多个特性团队共享同一需求列表。这就让一个团队出现资源瓶颈时需求可以分配到另一个团队这与今天很多服务行业中实行的“一个队列多个服务窗”的本质是一致的。 以终为始的需求分析和设计 前面我们讲了企业的协同模式应该是业务驱动的团队的交付模式应该是产品导向的它们解决协同流程的问题但光有流程是不够的我们还必须保证输入的质量。 IT行业有一句著名的话“输入的是垃圾输出的也会是垃圾“ 。需求的输入是交付过程是源头也是最关键的部分。如果输入的有问题交付的中间过程也不可能顺畅。那我们应该怎么做呢 “输入垃圾输出垃圾”的反面是以终为始——也就是在需求输入的时候团队要知道最终要做成什么样子并在业务、产品和技术之间达成一致。 那么怎样才叫以终为始呢以终为始分为3个方面 第一对于业务需求要有明确的业务目标并基于目标定义清晰的业务流程确保业务流程可以支持业务目标的实现这是业务分析要完成的工作。 第二对于产品需求它要能支持业务流程的实现为此我们要基于业务流程明确定义产品的功能对于每一个产品功能首先要明确用户使用的交互流程并在交互流程的基础上明确验收标准。 第三明确业务需求、产品需求之间的结构也就是业务需求和产品需求之间的层级关系。这对后面的团队协作都很重要我们协作交付的目标不是产品需求而是业务需求只有结构清晰协作的时才知道这些产品需求如何协同向业务对齐完成快速交付业务需求。 总结一下业务分析和产品设计分是一个金字塔的结构 需求永远源自业务目标基于业务目标分析业务流程基于业务流程分解产品需求并对产品需求进行设计。 金字塔的上面两层是业务分析关注的。我们引入了“事件驱动的分析”方法——基于目标和业务事件分析业务流程并基于业务流程拆分定义产品需求并划分最小可行产品MVP。 金字塔的下面两层是产品设计所关注的。在业务流程设计的基础上分解出产品需求并对产品需求进行澄清。澄清和设计需求最好的方式是以用户使用实例来说明操作流程、验收规则是什么样也就是用户在什么情况下做什么操作将得到什么结果。我们引入了“实例化需求”分析方法来支持这一过程。 通过系统的业务分析和产品设计方法在需求上从GIGO转变为以终为始这是局部效率转化为高效交付的重要一环。 下面让我们在从另一维度解释一下协作和需求实践以上图的产品截图为例总结一下我们在协作部分要做到的三点 第一点我们要看到并且要管理端到端的业务需求的交付过程我们称之为前后职能拉通。这些职能可能是业务、产品、开发、测试部署和运维。我们要拉通这些职能让他们更高效的配合让业务需求从左到右顺畅的流动和交付。 第二点左右模块对齐。一个业务需求可能会分解到不同的产品里面每个产品都有自己的工作流产品的交付要向业务的交付对齐。     我们的目标不是让某一个产品忙起来而是让业务需求的交付更顺畅。所以各个产品都要向业务需求的交付对齐。研发管理工具上也要能实现这一点包括规划上对齐产品和业务需求以及在执行过程中对齐产品和业务并即时发现因无法对齐带来的阻碍和等待。 第三点内建过程质量。需求在每个阶段应该有明确的质量标准并执行到位例如需求输入的质量要做到以终为始需求测试的质量、测试转发布等都应该有明确的标准。质量应该建立在每个需求的每个阶段之上而不是成批的依赖于最后的检测阶段。 我们要做到前后职能拉通左右模块对齐内建过程质量。最终形成这样下图所示的协作模式。 图中每个节点都是一个具体活动这些活动有它的节奏、负责人、输入输出以及实践方法的支持如前面提到的事件驱动的业务分析和实例化需求等这样才能让业务、产品、技术真正形成一个整体做到这样顺畅和高质量的交付业务需求。 技术和工程实践 技术和工程部分我们究竟要解决什么问题呢我们先看一幅图。 上图横轴是时间纵轴是生产效率。我们希望效率是沿着绿色线一路向上的但是现实中可能随着时间的推移、产品变得复杂、团队规模变大而效率反而降低。 区分这两条线的核心就是在工程和技术实践上它决定我们积累的到底是资产还是债务也最终决定了长期的效率。 领域驱动的架构和实现 在技术方面我们要持续积累并维护好领域资产让它易于理解、扩展、维护和复用今天业界普遍都认识到领域驱动设计的重要性也愿意投入精力。然而领域驱动设计要发挥作用并不容易。 领域驱动设计不仅仅是设计的问题它是涉及需求、架构和实现的系统工程。需求和业务是源头架构是枢纽而他们都需要落地到现实当中。最重要的是如何把需求、架构和实践真正连接起来连接他们的是领域模型。 如上图所示我们从业务需求开始去分析业务流程基于业务流程分解和设计产品需求通过实例化需求定义验收测试澄清和细化产品需求。更重要的是在整个的需求分析的阶段中我们要不断地提取和精化领域模型。因为对领域的认识和抽象来自于每个具体的业务、具体的需求所以被称为“业务引领的领域建模”。 领域模型应该成为应用架构设计的基础。我们基于领域模型去划分子域设定子域的上下文基于领域模型去定义接口的设计契约划分子域和限界上下文并约束微服务的边界让微服务成为可复用的领域资产。限界上下文和服务契约最终保障领域资产的可复用。所以我们称为“领域引领的微服务架构”。 在实现上领域模型、验收测试、服务设计契约都是高质量代码的约束和指导。我们的代码要体现领域模型与架构和接口契约一致并符合相关验收标准。 同时测试先行的方式让我们有更靠谱的自动化测试而自动化测试会让我们的重构更有保障。持续的重构又保证代码资产不会快速腐化维持系统健康。 今天分享的更多还停留在概念层面但是我希望能在思考规划上给大家带来启发。除非你认为你可以牺牲长期的质量你不需要积累一个长期可重复的资产那么上述这些都是不可或缺的。 标准化的工程基础设施 接下来我们看工程部分。今天比较幸运的是我们看到工程部分的技术趋势正在收敛。 我们看到基于容器管理和分发制品基于k8s编排环境资源,这一部分已成为了一个事实大家都不再考虑要不要做而是什么时间做或者怎么做的问题。这个方向大概率不会改变。但问题是我们讲容器更多还是站在资源的视角去看即站在运维的视角但是在开发视角看到的是代码代码对应的是应用。如果仅做到这一点开发和运维之间还是有隔阂他们所面对的对象就不同。 今天我们看到另外一个趋势是基于OAM的标准去做应用管理。OAM的标准是阿里和微软共同提出的叫做开放应用模型基于OAM可以管理应用的开发、编排和运维。OAM是一个标准基于这个标准开发可以声明式地编排应用运维也可以基于已有的声明进行自动化的运维。 OAM 面向应用的部署和运维的终态统一了应用开发和运维的基本模型。它首先提出了应用描述的基本模型包括应用的拓扑、资源依赖、部署方式、运维方式等然后定义声明式的应用编排、部署和运维方式。OAM基于应用统一了开发和运维的基本语言让应用成为开发和运维共同的关注和操作的基本对象解决了技术基础实施的问题让真正的DevOps 成为可能。 但是这个离真正的DevOps还差一点我们刚才讲的只是我们有了DevOps的基础我们从部署这个阶段基于这样的标准但是我们还没有定义我们的应用是怎么交付的。如果把应用和交付这一部分也包含进去就会实现真正的DevOps。 我们看这样一幅图如下图所示我们这样定义应用的变更流程 首先我们要解耦部署和发布部署是技术行为发布是业务行为。我们希望每一个应用可以单独部署所以我们要解耦部署发布以应用为单元持续的集成和部署。 但是这还不够应用的变更从哪里来应用来自于业务需求业务需求拆解为产品需求产品需求对应一系列应用的变更。 每个应用的变更都有自己的流程。当这个业务需求对应所有的应用变更部署完成之后这个业务需求也应该能够完成发布。 我们的工具、流程、操作要能够连接起这些应用的变更和产品需求直至业务需求。这样我们就能够做到以业务需求为单位发布——当一个业务需求下所有的变更都部署完成后业务需求可以随时发布。 我们认为持续交付的最佳形态是以单应用为单位变更部署以单需求为单位需要的时候就去发布在此基础上我们就有机会建立起最快速的业务闭环。 以上是我们看到云原生持续交付的形态也就是以应用为单位的持续部署业务为需求单元的持续发布前提是我们以应用统一了开发和运维的基本单元。 总结一下我们认为云原生下的BizDevOps的形态是什么有三点 面向终态基于开放应用模型OAM形成运维和开发底层模型的一致化和标准化。  以应用为核心连通应用的开发、集成过程和部署运维过程实现云原生时代的DevOps。  连接并对齐业务需求与应用变更并完善反馈闭环实现真正意义上的BizDevOps 。总结 效能提升必须从清晰定义问题开始。 我将提升研发效能要解决的根本问题总结为三个效能不等式。化解这三个效能不等式需要系统的实践。 第一让局部效率转化为高效的交付。为此我们需要落地业务驱动的协作模式和产品导向的交付同时在需求上要做到真正的以终为始。 第二让高效交付可以持续为此在技术上要做到领域驱动的架构和实现不断积累和优化领域技术资产。在工程上要建设云原生的标准化基础设施并以应用中心打通开发运维和连接业务的需求最终实现以应用中心的持续部署和以业务需求为中心的持续发布。 第三让高效交付带来业务成功。为此需要建立业务探索和持续交付之间的快速执行和反馈的闭环。 以上3点的共性是它们都以业务为起点。比如以业务需求驱动组织中各个环节和部门的高效协同从业务目标开始分析业务流程并分解设计产品连接业务需求和产品应用变更实现业务需求的持续发布建立业务探索和持续交付之间的快速闭环。 落地这些实践必须打通业务 Biz、开发Dev和运维Ops让他们成为一个高效运作的整体建设BizDevOps实践体系赋能数字化时代的组织加速业务发展和创新。 原文链接 本文为阿里云原创内容未经允许不得转载。