文档

鲜丰水果:3个月夯实基建,85%的需求两周内发布上线

更新时间:

前言

鲜丰水果,创始于1997年,历经25年发展史的鲜丰水果,目前已成为一家集新零售、智慧冷链物流和供应链B2B平台的全球化企业,是全国知名水果连锁企业之一。目前全国门店数超2200家, 并拥有23个共计48万方的现代化冷链仓储中心。

随着外部环境的变化,2021年初鲜丰水果数字化转型再次加速,短短几个月时间,研发团队人员扩张2倍有余,一些问题开始暴露:

  • 研发基础设施不完善,也缺乏相关领域的专业人员,需投入的人力及时间成本很高,且见效慢。

  • 很多环节感觉有问题,但是不知道如何观测,也不知道比较好的实践是什么。随着公司在产研侧的投入越来越大,更快、更好地交付业务价值的诉求也愈发紧迫。

简单、快速地提升产研团队的交付质量和交付效率,成为了支持组织业务创新的必选项。让我们一起看看鲜丰究竟如何逐步破局。

一、梳理流程,发现问题

鲜丰水果研发负责人皮雪锋深知团队内部缺乏专业的研发转型人士,要想尽快推动转型落地,必须请外援。皮雪锋综合考虑成本、云产品集成性、功能全面性和易用性,最终选择了阿里云云效DevOps平台,也因此结识了阿里云云效最佳实践团队,邀请他们对鲜丰水果整个研发流程进行端到端调研,帮助明确团队各个环节中碰到的问题。

鲜丰水果办公室研发流程梳理的便签贴满了透明墙。

image

云效最佳实践团队和皮雪锋团队,经过梳理把问题归纳为两类。

1、端到端产研协作问题

  • 散装的产研协作工具带来的高协作成本和数据孤岛问题。

产品经理的PRD文档有的存在语雀、有的使用钉钉文档、有的则直接在本地,开发使用gitlab,测试却在xmind上维护用例和测试计划。

  • 缺乏统一、透明的协作流程导致的交付资源浪费、交付进展不清晰和交付质量差的问题。

产品无法及时了解需求的进展,研发是否遇到瓶颈,上线以后问题集中暴露,返工率极高。

2、工程交付能力和交付质量问题

先明确工程问题定义:把接受一个开发任务后,进行代码编写、联调、测试、集成,直到部署上线称为一次应用变更,整个变更过程中的问题均称为工程问题。

经过梳理分析,鲜丰的工程问题主要有3个:

  • 变更过程不顺畅,各个角色的等待、冲突多。

测试角色与开发角色关注在不同分支上,分支的管理依赖开发角色手工操作,由于双方的步调不一致,导致分支管理成本高,沟通成本高。

  • 交付质量严重依赖测试手工验证。

在当前的CI/CD流程中,没有内建的快速质量守护能力,必须依靠线下测试角色的手工验证,导致质量反馈滞后。

  • 云原生应用架构下的部署运维依赖少数专家。

鲜丰的应用架构已经全面转向无状态,基础设施全面转向云原生,但与此同时,对应用的部署和运维能力提出了新的要求,这些能力依赖少数几个专家。鲜丰希望能把这些实践经验沉淀下来,让每个研发都可以进行应用的部署和运维。

二、“三步走”解决问题

基于上述关键问题,鲜丰水果在阿里云云效最佳实践团队的建议下,实施了“三步走”的策略,明确了团队效能提升目标,并建立了相应的流程和机制,跑通以应用为核心的持续交付实践,实现了研发的“小步快跑”。

第一步,拉通跨职能团队达成目标-反馈闭环共识

由于工具链分散以及协同流程不透明带来的协同效率低、交付慢等问题,皮雪锋首先拉通了以业务目标为导向的跨职能团队,包含产品、设计、开发和测试在内,并明确每个跨职能团队的效能目标为提升交付效率和质量。为了让团队在执行落地的过程中更加清晰,做到“1+1>2”的合力效果,团队共识后皮雪锋给团队制定了两个阶段性目标:

  • 交付效率目标,主要指缩短需求开发周期,需求提交给开发后,85%的需要在两周内能上线

  • 交付质量目标,明确开发准入和开发进入提测的标准,持续降低缺陷和线上问题的数量下降20%

鲜丰在内部成立了的跨职能团队人员构成。

image

在明确了团队成员的组成后,进一步明确了需求的整体交付过程,尤其是从效能视角,需要建立交付效能反馈闭环的机制。

经过讨论,最终确立的机制如下:从对齐业务目标出发,定期进行业务规划,基于业务规划进行对应的需求评审和研发排期,团队通过双周迭代或单周迭代进行需求开发、测试和验收。在这个基础之上,还通过建立每月规划、每周排期和每日站会,对齐规划、计划和进度。

image

关于需求的交付周期和开发周期也做了明确的定义,如下图,需求交付周期从“已选择”到“已发布”,需求开发周期从“待开发”到“待发布”,在实际落地过程中,开发周期的终点会算到“已发布”,这样更能体现业务的视角。

image

第二步,基于共识确定流程和机制

1、通过对团队现状的调研,明确团队协作过程中的问题后,有针对性地设计出需求的流转状态和流转机制,并与团队成员达成共识。共识的背后是为了建立统一的认知和沟通语言。

image

2、拉通和可视化端到端的业务价值流

在明确需求流转状态和流转机制后,需要把机制和共识在云效上进行落地。

用户价值驱动:各团队基于需求进行协作,每个需求都需要关注用户价值,一方面需要明确用户是谁,目标是什么,另一方需求需要被拆分到小颗粒度(一个需求开发测试完成要在两周内),当然对于小需求需要达到可测可发布。

前后职能拉通:在需求的整个流转机制中,需要关注需求阶段、开发阶段、测试阶段和发布阶段,需要全流程打通,拉齐各个阶段的角色一起协作,让整个协作过程顺畅和高效。

左右模块对齐:在开发中,需求会被拆分为开发任务。往往一个需求会被拆分为前端的开发任务和后端的开发任务,有时,后端的开发任务还会拆分到各个不同的模块。此时,需求下的各个开发任务,需要对齐接口,对齐联调和测试时间。

业务价值流在云效产品上的落地。

image

3、明确各阶段准入规则,形成内建质量机制

需求的工作流明确后,接下来是需要明确需求流入各个状态的准入规则,不但要让需求能顺畅流转,更需要高质量的流转。同时从内建质量的视角出发,需求的质量不是靠最后环节的把关,而是需要从源头上就明确质量要求,让各个环节的质量都能达到明确的要求,直到最后高质量地交付。

我们会明确定义各阶段的流转规则,尤其是需求准入开发和准出开发的规则,因为这两个是产品、开发和测试这三个角色的需求抛接过程,而需求的抛接过程是最容易出问题的。

image

4、明确需求优先级机制

明确需求优先级机制在团队共识环节特别重要,因为需求优先级的高低代表价值的高低,价值的高低是直接和目标强相关的。在实时落地中,发现团队排入迭代的需求优先级都是紧急的,而没有明确排出优先级的顺序来。

咱们需要有一个按照绝对优先级排序的需求列表,最高优先级的需求要能被最先交付,同时还方便团队对需求的优先级进行积极的挑战,最终形成最合理的需求优先级列表。

image

5、明确进入开发后的需求责任人

进入开发中的需求,需求Owner需要负责协调把需求拆分成任务,并需协调至需求开发完成到提测,测试和发布完成为止。一方面让进入开发的需求有专人负责,另一方面也培养团队成员的责任感。

image

6、形成月规划、周排期和日站会的节奏

建立整体的节奏,形成月规划、周排期和日站会的节奏,同时各个是和需求的状态有紧密的集合的。

通过规划后的需求,需求状态会更新到“已选择”。通过排期后的需求,需求状态会更到“待开发”。通过站会后需求,需求的状态会更新到最新。

image

第三步,实践以应用为核心的持续交付

在工程方面,基于当前鲜丰水果的现状,皮雪锋决定全面拥抱以云原生应用为核心的工程实践方法,具体来讲,主要有两点:

1. 制定基于特性分支的研发模式,并落地到应用的变更流程中。

为了保证变更过程中各角色的协同效率,结合团队实际情况,鲜丰决定去除测试分支,采用类似特性分支的研发模式,只保留一条长期分支,其分支模式类似下图:

image

基于该分支模式,鲜丰将master分支设置为保护分支,通过应用维度的云效流水线定义和串联整个流程,避免手工的部署和分支管理操作,保证所发即所测。其应用流水线模板如下:

image

上述流程按应用落地到云效AppStack的发布流水线中,类似下图:

image

2. 以云原生应用为核心聚合编排、环境、监控和研发流程。

鲜丰从前两年开始进行云原生应用架构的转型,研发团队中只有很少的SRE(Site Reliability Engineer),负责制定整体的研发和运维规则,应用的部署运维都由一线研发负责,但之前一直缺乏一个研发视角的工具平台,将应用研发相关的资源和操作都聚合起来。而这刚好是云效AppStack应用交付平台的设计初衷。为此,AppStack开启公测后,鲜丰便第一时间开始了试用,并逐渐把所有应用都搬了上来。

image

从上图可以看出,研发团队不直接操作云资源,对资源的操作都可以通过操作AppStack的应用环境进行,一方面更符合云原生研发的习惯,另一方面也更为安全。

当然,工具只是云原生转型的一部分,鲜丰的云原生转型包含了技术架构、部署架构和工程实践3个方面。

技术架构上,做到每个应用可以独立地部署、验证和运维,并充分利用云原生基础设施提升弹性和韧性。

image

鲜丰的研发基础设施全面上云,基于云资源和开放标准来构建应用,主要采用了以下云产品:

  • 阿里云ACK:完全兼容K8s且免运维,无论生产还是测试环境的应用容器都承载在其上

  • 阿里云RDS等数据库产品:遵循开源协议标准(如MySQL),可以无缝迁移,方便运维,且性能更好

  • MSE NacOS:开源的配置中心NacOS的商业版本

  • 阿里云ARMS:一站式的可观测性平台,主要采用其中的K8s监控和应用监控,也可以集成RDS等的监控,对Java应用无侵入

在选型的时候,鲜丰充分考虑了标准的开放性,保证应用可以无修改地承载在不同的云服务商上。

部署架构上,做到每个应用一套编排作用于多套环境,环境差异通过变量来体现,做到镜像与配置分离。

鲜丰对部署架构的期望是:一个应用定义一个部署架构,不同的环境的差异通过变量区分,一个镜像可以部署到多个环境中,镜像内部不保留环境相关配置。为此,鲜丰基于AppStack采用了如下的实践方式。

SRE定义企业的编排模板(如包含一个Service、一个Deployment)

image

在每个应用中,应用负责人选择该模板定义自己的部署编排,环境间有差异的地方定义变量来解决。

image

应用负责人定义不同的变量组以适应不同的环境。

image

应用负责人将变量组绑定环境。

image

研发团队直接在环境上进行部署和运维操作。

image

工程实践上,做到研发自发布、自运维,但SRE又能在全局上进行权限和策略的配置和管控。

鲜丰将研发角色分为应用负责人、开发、测试3类,以及一个企业级的SRE角色,SRE为其他每个角色配置对应的权限。

image

SRE为每个角色定义不同环境的操作权限,开发和测试角色可以部署和运维开发测试环境,但不能操作生产环境;只有应用负责人可以执行生产环境的部署和运维。

三、效能提升效果

开发周期缩短

经过三个月的落地,鲜丰水果的产研团队已经能够实现85%的需求两周内发布上线。

在这个指标制定/实现的过程中,也有一些小插曲。

一开始我们把开发周期的“85线”定为两周的时候,有产研同学会问,需求的交付时长不是和需求的大小强相关吗?是的,我们跟产研团队会先达成一个共识,即什么是一个需求?我们定义需求的标准是可独立交付和验收测试,在此基础上,颗粒度越小越好。

下图是鲜丰水果转型三个月之后的开发周期的统计图表,通过下面这个图表,我们不难看到,该试点团队在二月份交付的需求中,已经有85%的需求开发周期在13天以内,达到了我们预设的两个周的目标。

另外通过这个图表,我们也能看到一些其他的问题,比如还是出现了需求批量交付的情况,没有做到单需求持续发布。

image

相对理想的需求交付周期图:

image

平均交付周期:10天(两周以内)

期望的散点分布:

  • 纵向上向下集中----响应能力及可预测性提升;

  • 散点密度提高----提升交付效率;

  • 横向上更均匀分布----持续交付。

交付质量提升

经过三个月的落地,鲜丰水果的产研团队的线上问题数下降20% ,并且研发模式有根本性的变更。

image

前期,鲜丰水果的产研团队采用类似小瀑布的开发模式。团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。越到后期发现的缺陷,修复难度大幅提升,修复成本大幅增加。

经过对现状问题的分析,团队开始向持续交付模式演进。在整个迭代过程中,通过上面的“三步走”策略,基本实现了“单应用部署,单需求交付”,团队以小粒度的需求为单位开发,持续地集成和测试它们,即时发现和解决问题。缺陷库存得到控制,系统始终处于接近可发布状态。这一模式更接近持续发布状态,团队对外的响应能力随之增强。

四、传统企业研发转型建议

经过三个月的实践落地,鲜丰水果的产研团队实现了研发流程的数字化转型,达到了预期的研发效率提升的目标。但是仍然有一些问题需要团队持续改进、提升,如从业务需求开始的整个业务监控的闭环建设,以及测试自动化能力的提升等等。

鲜丰水果作为“传统行业”研发转型“数字化”的新零售代表,其在转型中碰到的一些问题也是很多类似企业,已经遇到或者将要遇到的,这里我们做一个简单的小结,希望能够给有相似问题的企业以帮助:

  • 团队共识很重要。在鲜丰水果整个落地过程中,不管是一开始指标的确立,还是后续诸如流程、规范等的设定,让整个团队能够共识,达成理解一致是非常重要的一环。譬如我们为什么要看这个指标,什么是需求,需求完成的定义又是什么等等,只有团队真正共识,才能确保后续整个流程的顺畅。

  • 业务驱动是根本。研发的目的是为了业务价值的实现,所以通过业务需求拉通端到端的交付过程,对齐各个功能开发的工作,才能保证我们是以“用户”为目标在工作,最后的产出才是有价值的。

  • 拥抱云原生。云原生的技术栈已经成熟,同时随着业务的快速发展,不管从资源利用率、人力成本、可用性还是响应速度上,传统的基础设施构建方式已经很难满足企业发展的诉求,适时的“拥抱云原生” ,提高业务的灵活性以及快速响应的能力也变得愈发重要。

对鲜丰水果落地实践感兴趣,也想要落地阿里研发最佳实践的企业,请联系云效最佳实践团队

重要

本文内容非阿里云官方提供,如您发现本文档存在侵权内容或其他问题,请提供相应证明材料并在本页面内提交反馈信息,阿里云会协调或通知相关作者进行处理。

  • 本页导读 (0)
文档反馈