3个月夯实基建，鲜丰水果这样实现研发数字化

Posted 2022-04-05 阿里云云栖号

简介：3个月夯实基建，鲜丰水果这样实现研发数字化。简单、快速地提升产研团队的交付质量和交付效率，成为了支持组织业务创新的必选项。让我们一起看看鲜丰究竟如何逐步破局。

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

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

• 研发基础设施不完善，也缺乏相关领域的专业人员，需投入的人力及时间成本很高，且见效慢。
• 很多环节感觉有问题，但是不知道如何观测，也不知道比较好的实践是什么。随着公司在产研侧的投入越来越大，更快、更好地交付业务价值的诉求也愈发紧迫。

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

一、梳理流程，发现问题

解决问题，前提得知道问题在哪儿。

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

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

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

1、端到端产研协作问题

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

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

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

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

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

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

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

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

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

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

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

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

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

二、“三步走”解决问题

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

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

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

• 交付效率目标，主要指缩短需求开发周期，需求提交给开发后，85%的需要在两周内能上线；
• 交付质量目标，明确开发准入和开发进入提测的标准，持续降低缺陷和线上问题的数量下降20%。

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

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

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

整体交付流程

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

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

1、需求流转机制和状态共识

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

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

在明确需求流转状态和流转机制后，需要把机制和共识在云效上进行落地。用户价值驱动：各团队基于需求进行协作，每个需求都需要关注用户价值，一方面需要明确用户是谁，目标是什么，另一方需求需要被拆分到小颗粒度（一个需求开发测试完成要在两周内），当然对于小需求需要达到可测可发布。

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

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

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

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

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

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

4、明确需求优先级机制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

鲜丰从前两年开始进行云原生应用架构的转型，研发团队中只有很少的SRE（site 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% ，并且研发模式有根本性的变更。

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

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

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

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

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

• 团队共识很重要。在鲜丰水果整个落地过程中，不管是一开始指标的确立，还是后续诸如流程、规范等的设定，让整个团队能够共识，达成理解一致是非常重要的一环。譬如我们为什么要看这个指标，什么是需求，需求完成的定义又是什么等等，只有团队真正共识，才能确保后续整个流程的顺畅。
• 业务驱动是根本。研发的目的是为了业务价值的实现，所以通过业务需求拉通端到端的交付过程，对齐各个功能开发的工作，才能保证我们是以“用户”为目标在工作，最后的产出才是有价值的。
• 拥抱云原生。云原生的技术栈已经成熟，同时随着业务的快速发展，不管从资源利用率、人力成本、可用性还是响应速度上，传统的基础设施构建方式已经很难满足企业发展的诉求，适时的“拥抱云原生” ，提高业务的灵活性以及快速响应的能力也变得愈发重要。

原文链接

本文为阿里云原创内容，未经允许不得转载。