莱芜网站优化招聘网,网站注册备案查询,网站建设常用六大布局,wordpress wp 缺点简介#xff1a;3个月夯实基建#xff0c;鲜丰水果这样实现研发数字化。简单、快速地提升产研团队的交付质量和交付效率#xff0c;成为了支持组织业务创新的必选项。让我们一起看看鲜丰究竟如何逐步破局。
鲜丰水果#xff0c;创始于1997年#xff0c;历经25年发展史的鲜…简介3个月夯实基建鲜丰水果这样实现研发数字化。简单、快速地提升产研团队的交付质量和交付效率成为了支持组织业务创新的必选项。让我们一起看看鲜丰究竟如何逐步破局。
鲜丰水果创始于1997年历经25年发展史的鲜丰水果目前已成为一家集新零售、智慧冷链物流和供应链B2B平台的全球化企业是全国知名水果连锁企业之一。目前全国门店数超2200家 并拥有23个共计48万方的现代化冷链仓储中心。 随着外部环境的变化2021年初鲜丰水果数字化转型再次加速短短几个月时间研发团队人员扩张2倍有余一些问题开始暴露
研发基础设施不完善也缺乏相关领域的专业人员需投入的人力及时间成本很高且见效慢。很多环节感觉有问题但是不知道如何观测也不知道比较好的实践是什么。随着公司在产研侧的投入越来越大更快、更好地交付业务价值的诉求也愈发紧迫。
简单、快速地提升产研团队的交付质量和交付效率成为了支持组织业务创新的必选项。让我们一起看看鲜丰究竟如何逐步破局。
一、梳理流程发现问题
解决问题前提得知道问题在哪儿。
鲜丰水果研发负责人皮雪锋深知团队内部缺乏专业的研发转型人士要想尽快推动转型落地必须请外援。皮雪锋综合考虑成本、云产品集成性、功能全面性和易用性最终选择了阿里云云效DevOps平台也因此结识了由业内资深研发转型专家何勉带领的阿里云云效最佳实践团队邀请他们对鲜丰水果整个研发流程进行端到端调研帮助明确团队各个环节中碰到的问题。 鲜丰水果办公室研发流程梳理的便签贴满了透明墙
云效最佳实践团队和皮雪锋团队经过梳理把问题归纳为两类。
1、端到端产研协作问题
散装的产研协作工具带来的高协作成本和数据孤岛问题。
产品经理的PRD文档有的存在语雀、有的使用钉钉文档、有的则直接在本地开发使用gitlab测试却在xmind上维护用例和测试计划。
缺乏统一、透明的协作流程导致的交付资源浪费、交付进展不清晰和交付质量差的问题。
产品无法无法及时了解需求的进展研发是否遇到瓶颈上线以后问题集中暴露返工率极高。
2、工程交付能力和交付质量问题
先明确工程问题定义把接受一个开发任务后进行代码编写、联调、测试、集成直到部署上线称为一次应用变更整个变更过程中的问题均称为工程问题。
经过梳理分析鲜丰的工程问题主要有3个
变更过程不顺畅各个角色的等待、冲突多。
测试角色与开发角色关注在不同分支上分支的管理依赖开发角色手工操作由于双方的步调不一致导致分支管理成本高沟通成本高。
交付质量严重依赖测试手工验证。
在当前的CI/CD流程中没有内建的快速质量守护能力必须依靠线下测试角色的手工验证导致质量反馈滞后。
云原生应用架构下的部署运维依赖少数专家。
鲜丰的应用架构已经全面转向无状态基础设施全面转向云原生但与此同时对应用的部署和运维能力提出了新的要求这些能力依赖少数几个专家。鲜丰希望能把这些实践经验沉淀下来让每个研发都可以进行应用的部署和运维。
二、“三步走”解决问题
基于上述关键问题鲜丰水果在阿里云云效最佳实践团队的建议下实施了“三步走”的策略明确了团队效能提升目标并建立了相应的流程和机制跑通以应用为核心的持续交付实践实现了研发的“小步快跑”。
第一步拉通跨职能团队达成目标-反馈闭环共识
由于工具链分散以及协同流程不透明带来的协同效率低、交付慢等问题皮雪锋首先拉通了以业务目标为导向的跨职能团队包含产品、设计、开发和测试在内并明确每个跨职能团队的效能目标为提升交付效率和质量。为了让团队在执行落地的过程中更加清晰做到“112”的合力效果团队共识后皮雪锋给团队制定了两个阶段性目标
交付效率目标主要指缩短需求开发周期需求提交给开发后85%的需要在两周内能上线交付质量目标明确开发准入和开发进入提测的标准持续降低缺陷和线上问题的数量下降20%。鲜丰在内部成立了的跨职能团队人员构成
在明确了团队成员的组成后进一步明确了需求的整体交付过程尤其是从效能视角需要建立交付效能反馈闭环的机制。
经过讨论最终确立的机制如下从对齐业务目标出发定期进行业务规划基于业务规划进行对应的需求评审和研发排期团队通过双周迭代或单周迭代进行需求开发、测试和验收。在这个基础之上还通过建立每月规划、每周排期和每日站会对齐规划、计划和进度。 整体交付流程
关于需求的交付周期和开发周期也做了明确的定义如下图需求交付周期从“已选择”到“已发布”需求开发周期从“待开发”到“待发布”在实际落地过程中开发周期的终点会算到“已发布”这样更能体现业务的视角。 第二步基于共识确定流程和机制
1、需求流转机制和状态共识
通过对团队现状的调研明确团队协作过程中的问题后有针对性地设计出需求的流转状态和流转机制并与团队成员达成共识。共识的背后是为了建议统一的认知和沟通语言。 2、拉通和可视化端到端的业务价值流
在明确需求流转状态和流转机制后需要把机制和共识在云效上进行落地。用户价值驱动各团队基于需求进行协作每个需求都需要关注用户价值一方面需要明确用户是谁目标是什么另一方需求需要被拆分到小颗粒度一个需求开发测试完成要在两周内当然对于小需求需要达到可测可发布。
前后职能拉通在需求的整个流转机制中需要关注需求阶段、开发阶段、测试阶段和发布阶段需要全流程打通拉齐各个阶段的角色一起协作让整个协作过程顺畅和高效。
左右模块对齐在开发中需求会被拆分为开发任务。往往一个需求会被拆分为前端的开发任务和后端的开发任务有时后端的开发任务还是拆分到各个不同的模块。此时需求下的各个开发任务需要对齐接口对齐联调和测试时间。 业务价值流在云效产品上的落地
3、明确各阶段准入规则形成内建质量机制
需求的工作流明确后接下来是需要明确需求流入各个状态的准入规则不但要让需求能顺畅流转更需要高质量的流转。同时从内建质量的视角出发需求的质量不是靠最后环节的把关而是需要从源头上就明确质量要求让各个环节的质量都能达到明确的要求直到最后高质量地交付。
我们会明确定义各阶段的流转规则尤其是需求准入开发和准出开发的规则因为这两个是产品、开发和测试这三个角色的需求抛接过程而需求的抛接过程是最容易出问题的。 4、明确需求优先级机制
明确需求优先级机制在团队共识环节特别重要因为需求优先级的高低代表价值的高低价值的高低是直接和目标强相关的。在实时落地中发现团队排入迭代的需求优先级都是紧急的而没有明确排出优先级的顺序来。
咱们需要有一个按照绝对优先级排序的需求列表最高优先级的需求要能被最先交付同时还方便团队对需求的优先级进行积极的挑战最终形成最合理的需求优先级列表。 5、明确进入开发后的需求责任人
进入开发中的需求需求Owner需要负责协调把需求拆分成任务并需协调至需求开发完成到提测测试和发布完成为止。一方面让进入开发的需求有专人负责另一方面也培养团队成员的责任感。 6、形成月规划、周排期和日站会的节奏
建立整体的节奏形成月规划、周排期和日站会的节奏同时各个是和需求的状态有紧密的集合的。
通过规划后的需求需求状态会更新到“已选择”。通过排期后的需求需求状态会更到“待开发”。通过站会后需求需求的状态会更新到最新。 第三步实践以应用为核心的持续交付
在工程方面基于当前鲜丰水果的现状皮雪锋决定全面拥抱以云原生应用为核心的工程实践方法具体来讲主要有两点
1. 制定基于特性分支的研发模式并落地到应用的变更流程中
为了保证变更过程中各角色的协同效率结合团队实际情况鲜丰决定去除测试分支采用类似特性分支的研发模式只保留一条长期分支其分支模式类似下图 基于该分支模式鲜丰将master分支设置为保护分支通过应用维度的云效流水线定义和串联整个流程避免手工的部署和分支管理操作保证所发即所测。其应用流水线模板如下 上述流程按应用落地到云效AppStack的发布流水线中类似下图 2. 以云原生应用为核心聚合编排、环境、监控和研发流程
鲜丰从前两年开始进行云原生应用架构的转型研发团队中只有很少的SREsite reliability engineer负责制定整体的研发和运维规则应用的部署运维都由一线研发负责但之前一直缺乏一个研发视角的工具平台将应用研发相关的资源和操作都聚合起来。而这刚好是云效AppStack应用交付平台的设计初衷。为此AppStack开启公测后鲜丰便第一时间开始了试用并逐渐把所有应用都搬了上来。 从上图可以看出研发团队不直接操作云资源对资源的操作都可以通过操作AppStack的应用环境进行一方面更符合云原生研发的习惯另一方面也更为安全。
当然工具只是云原生转型的一部分鲜丰的云原生转型包含了技术架构、部署架构和工程实践3个方面。
2.1 在技术架构上做到每个应用可以独立地部署、验证和运维并充分利用云原生基础设施提升弹性和韧性。 鲜丰的研发基础设施全面上云基于云资源和开放标准来构建应用主要采用了以下云产品
阿里云ACK完全兼容K8S且免运维无论生产还是测试环境的应用容器都承载在其上阿里云RDS等数据库产品遵循开源协议标准如MySQL可以无缝迁移方便运维且性能更好MSE NacOS开源的配置中心NacOS的商业版本阿里云ARMS一站式的可观测性平台主要采用其中的k8s监控和应用监控也可以集成RDS等的监控对Java应用无侵入
在选型的时候鲜丰充分考虑了标准的开放性保证应用可以无修改地承载在不同的云服务商上。
2.2 在部署架构上做到每个应用一套编排作用于多套环境环境差异通过变量来体现做到镜像与配置分离。
鲜丰对部署架构的期望是一个应用定义一个部署架构不同的环境的差异通过变量区分一个镜像可以部署到多个环境中镜像内部不保留环境相关配置。为此鲜丰基于AppStack采用了如下的实践方式。
首先SRE定义企业的编排模板如包含一个Service、一个Deployment。 其次在每个应用中应用负责人选择该模板定义自己的部署编排解决环境间有差异的地方定义变量来解决。 第三应用负责人定义不同的变量组以适应不同的环境。 第四应用负责人将变量组绑定环境。 最后研发团队直接在环境上进行部署和运维操作。 2.3 在工程实践上做到研发自发布、自运维但SRE又能在全局上进行权限和策略的配置和管控。
鲜丰将研发角色分为应用负责人、开发、测试3类以及一个企业级的SRE角色SRE为其他每个角色配置对应的权限。 SRE为每个角色定义不同环境的操作权限开发和测试角色可以部署和运维开发测试环境但不能操作生产环境只有应用负责人可以执行生产环境的部署和运维。
三、效能提升效果
开发周期缩短
经过三个月的落地鲜丰水果的产研团队已经能够实现85%的需求两周内发布上线。
在这个指标制定/实现的过程中也有一些小插曲。
一开始我们把开发周期的“85线”定为两周的时候有产研同学会问需求的交付时长不是和需求的大小强相关吗是的我们跟产研团队会先达成一个共识即什么是一个需求我们定义需求的标准是可独立交付和验收测试在此基础上颗粒度越小越好。
下图是鲜丰水果转型三个月之后的开发周期的统计图表通过下面这个图表我们不难看到该试点团队在二月份交付的需求中已经有85%的需求开发周期在13天以内达到了我们预设的两个周的目标。
另外通过这个图表我们也能看到一些其他的问题比如还是出现了需求批量交付的情况没有做到单需求持续发布。 相对理想的需求交付周期图 平均交付周期10天两周以内
期望的散点分布
纵向上向下集中----响应能力及可预测性提升散点密度提高----提升交付效率横向上更均匀分布----持续交付
交付质量提升
经过三个月的落地鲜丰水果的产研团队的线上问题数下降20% 并且研发模式有根本性的变更。 前期鲜丰水果的产研团队采用类似小瀑布的开发模式。团队集中设计、编码引入缺陷但并未即时地集成和验证。缺陷一直掩藏在系统中直到项目后期团队才开始集成和测试缺陷集中爆发。越到后期发现的缺陷修复难度大幅提升修复成本大幅增加。
经过对现状问题的分析团队开始向持续交付模式演进。在整个迭代过程中通过上面的“三步走”策略基本实现了“单应用部署单需求交付”团队以小粒度的需求为单位开发持续地集成和测试它们即时发现和解决问题。缺陷库存得到控制系统始终处于接近可发布状态。这一模式更接近持续发布状态团队对外的响应能力随之增强。
四、传统企业研发转型建议
经过三个月的实践落地鲜丰水果的产研团队实现了研发流程的数字化转型达到了预期的研发效率提升的目标。但是仍然有一些问题需要团队持续改进、提升如从业务需求开始的整个业务监控的闭环建设以及测试自动化能力的提升等等。
鲜丰水果作为“传统行业”研发转型“数字化”的新零售代表其在转型中碰到的一些问题也是很多类似企业已经遇到或者将要遇到的这里我们做一个简单的小结希望能够给有相似问题的企业以帮助
团队共识很重要。在鲜丰水果整个落地过程中不管是一开始指标的确立还是后续诸如流程、规范等的设定让整个团队能够共识达成理解一致是非常重要的一环。譬如我们为什么要看这个指标什么是需求需求完成的定义又是什么等等只有团队真正共识才能确保后续整个流程的顺畅。业务驱动是根本。研发的目的是为了业务价值的实现所以通过业务需求拉通端到端的交付过程对齐各个功能开发的工作才能保证我们是以“用户”为目标在工作最后的产出才是有价值的。拥抱云原生。云原生的技术栈已经成熟同时随着业务的快速发展不管从资源利用率、人力成本、可用性还是响应速度上传统的基础设施构建方式已经很难满足企业发展的诉求适时的“拥抱云原生” 提高业务的灵活性以及快速响应的能力也变得愈发重要。
原文链接
本文为阿里云原创内容未经允许不得转载。
