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

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个方面。

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

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

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

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

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

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

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

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

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

SRE定义企业的编排模板（如包含一个Service、一个Deployment）。

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

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

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

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

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

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

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

开发周期缩短

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

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

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

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

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

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

平均交付周期：10天（两周以内）

期望的散点分布：

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

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

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

交付质量提升

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

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

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