5000字干货好文 | APP版本迭代流程&版本号命名规则(建议收藏)

编辑导读:面对X行业中激烈的竞争,让我们的开发liú程更完整、更有效率,产品才能拖颖而出。本篇文章总结整理的APP版本迭代liú程与规范,主要涉及到版本迭代过程中的规范liú程以及涉及到版本各个角sè的职责分工等内容,与大家分享。

本篇文章总结整理的APP版本迭代liú程与规范,主要涉及到版本迭代过程中的规范liú程以及涉及到版本各个角sè的职责分工等内容,分享给大家:

本文目录如下:

  1. 引言
  2. 需qiú汇总阶段liú程
  3. 需qiú评审阶段liú程
  4. 需qiú开发&测试阶段liú程
  5. 内测阶段liú程
  6. APP版本号命名规则

一、引言

1.1 目的

基于现在的开发liú程中缺少的环节进行补足,使得开发liú程更加的liú畅和正规化,以便以后的查阅与归档使用。面对X行业中激烈的竞争,让我们的开发liú程更完整、更有效率,产品才能拖颖而出。

1.2 范围

本文档适用于App产品的迭代研发,主要liú程包括:需qiú汇总、需qiú评审、技术&用例评审、开发&测试排期、开发&测试、内测体验等环节。以后的产品开发liú程也可以参考此文档的环节进行开发。

1.3 读者对象

本文档的目标读者对象主要包括:

产品经理:输出&收集汇总每个版本迭代的需qiú,同时对App迭代进行体验验收,需qiú汇总阶段、需qiú评审阶段、内测体验阶段的主要负责人。

交互设计师:根据相关需qiú文档,进行交互优化,输出优化原型图,提升产品整体用户体验。

视觉设计师:根据需qiú文档&交互原型图作为视觉设计的步骤和资源产出的依据。

项目经理:X发起需qiú评审,并跟进评审结果及输出开发测试排期,需qiú评审阶段、发布上线阶段的主要负责人。

开发:主导发起部分复杂需qiú的技术评审,根据需qiú文档编写代码,开发测试过程由版本经理主导推进,为迭代上线负责。

测试:根据需qiú文档设计相关测试用例,并主导发起用例评审,跟进测试阶段的Bug解决。

1.4 App迭代阶段liú程图

二、需qiú汇总阶段

阶段推进方:主要由产品主导推进与收尾

产品部门&版本主要产品经理:

  • 负责发起版本迭代
  • 输出相关App迭代需qiú
  • 收集其他需qiú方的App迭代需qiú
  • 汇总并进行需qiú的初步分类与优先级评定
  • 决策相关需qiú方案是否需要技术介入进行前期初评
  • 决策相关需qiú方案是否需要进行交互优化&视觉设计
  • 邮件发送需qiú汇总清单至相关责任人
  • 确认需qiú汇总完毕后发起需qiú评审
  • 汇总、整理、输出本阶段相关交付结果

阶段参与方&职责:

交互设计师:

  • 根据需qiú文档及需qiú原型图,进行交互层面优化,提升产品的用户体验
  • 自发发起用户体验提升相关的需qiú,并提交给产品经理汇总入版本迭代需qiú中
  • 输出交互优化稿后与产品经理进行评审确认

视觉设计师:

  • 根据需qiú文档及需qiú原型图或交互原型图,进行视觉设计
  • 输出效果稿进行视觉设计评审确认
  • 输出标注稿供客户端开发工程师对照开发
  • 输出相关测试用效果切图,供开发&测试过程直观查看效果用

项目经理:

  • 根据开发对需qiú提出的疑问点进行分类汇总
  • X安排评审X

开发:

  • 适时参与产品发起的需qiú方案初评
  • 查阅产品拟定的本版本迭代需qiú汇总,并初步提出相关疑问点

测试:

查阅产品拟定的本版本迭代需qiú汇总,并初步提出相关疑问点

阶段工作描述:

需qiú汇总阶段也是版本迭代的准备阶段,该阶段主要为需qiú的汇总及UED方面的设计输出,同时也为需qiú评审准备相应的材料与文档。

阶段交付成果:

  • 版本迭代需qiú汇总
  • 产品需qiú文档
  • UE交互优化稿
  • UI视觉设计稿&标注稿
  • 需qiú初期疑问点汇总

三、需qiú评审阶段

3.1 需qiú评审

(X查看大图)

阶段推进方:主要由产品主导推进与收尾

  • 负责发起版本迭代需qiú评审
  • 配合项目经理X需qiú评审X
  • 在需qiú评审X中进行需qiú宣讲讲解
  • zhēn对汇总后的需qiú疑问点进行答疑与沟通
  • 需qiú的责任人需进行需qiú讨论记录并在X的最X行需qiú讨论记录的确认

阶段参与方&职责如下:

项目经理:

  • X安排评审X,召集相关人员
  • 汇总并与相关方确认最终的需qiú范围

开发:

  • 会前确认主liú程、主方向、主内容的认可
  • 非常细节的内容,不涉及主liú程环节可会后单独与产品经理讨论确认
  • 参与需qiú评审,并根据需qiú讲解情况,提出疑问点,进行讨论确认
  • 确认最终的需qiú范围及需qiú内容

测试:

  • 会前确认主liú程、主方向、主内容的认可
  • 非常细节的内容,不涉及主liú程环节可会后单独与产品经理讨论确认
  • 参与需qiú评审,并根据需qiú讲解情况,提出疑问点,进行讨论确认
  • 确认最终的需qiú范围及需qiú内容

阶段工作描述:

需qiú评审阶段是版本迭代的关键节点,该阶段主要需要对需qiú进行严格的审阅与传达,需要需qiú方与实现方进行完整全面的沟通。同时也是后续技术设计评审、测试用例评审的根基,力qiú将问题放在初期解决确认。

阶段交付成果:

  • 各个需qiú的需qiú讨论点记录
  • 需qiú评审总结与X纪要
  • 需qiú范围确认后的版本迭代需qiú汇总清单

3.2 技术/测试用例评审&排期

阶段推进方:主要由项目经理主导推进与收尾

  • 负责在确认需qiú范围后,发起开展技术设计评审、测试用例评审
  • 负责确认版本经理、测试负责人
  • 负责收集各个需qiú的开发/测试工作量评估
  • 负责输出版本迭代排期,并与各方最终确认排期情况

阶段参与方&职责如下:

产品经理:

  • 参与技术设计/测试用例的评审,并提出疑问并沟通确认
  • 确认技术设计/测试用例是否符合需qiú
  • 确认开发/测试的排期情况

开发:

  • 确认版本经理
  • 由版本经理评估相关需qiú是否需要进行技术设计评审并发起推进
  • 根据确认的技术设计方案or需qiú,进行开发工作量评估
  • 参与测试用例评审并确认一级用例范围
  • 确认转测条件

测试:

  • 确认测试负责人
  • 输出相关测试用例并分级,发起测试用例评审并推进
  • 参与技术设计方案评审
  • 根据确认的测试用例,进行测试工作量评估
  • 确认转测条件

阶段工作描述:

技术设计方案评审&测试用例评审及排期是版本迭代的重要节点,此阶段延续需qiú评审后对需qiú的理解,从开发/测试的角度出发,制定相关方案,为后续开发/测试工作X指导与依据。

阶段交付成果:

  • 技术设计概要
  • 技术设计概要评审X纪要
  • 测试用例
  • 测试用例评审X纪要
  • 版本迭X发&测试排期表

四、开发&测试阶段

阶段推进方:主要由版本经理主导推进与收尾

  • 对整体开发&测试过程主导推进并负责
  • 及时同步进度并进行风险预jǐng
  • 推进开发并同时跟进开发进度
  • 推进转测并同时跟进测试进度

阶段参与方&职责如下:

产品经理:

  • 参与进度同步,及时根据风险预jǐng进行调整
  • 参与代码开发阶段的讨论,确认细节点
  • 参与测试阶段的讨论,确认细节点
  • 决策是否需要在开发过程中进行需qiú变更

视觉设计:

  • 在测试阶段介入进行视觉还原
  • 跟进视觉还原的修复进度
  • 确认开发过程中的部分对视觉的问题点

开发:

  • Coding
  • 参与转测演示,并对转测演示结果负责
  • 在测试阶段及时清理相关Bug与问题
  • 与产品积极沟通相关细节点

测试:

  • 根据转测演示结果,决策是否转测成功
  • 发起测试阶段,并根据测试用例进行数轮测试
  • 跟进提出的Bug的解决进度
  • 与产品积极沟通相关细节点

阶段工作描述:

开发&测试阶段是版本迭代的实现阶段,本过程持续时间长,且过程需要大量持续的沟通与工作,需要各方进行紧密的配合。

阶段交付成果:

  • 相关接口协议文档
  • 测试版本App
  • 版本迭代节点通知
  • 曰常进度信息
  • 测试验收报告

五、内测体验阶段

阶段推进方:主要由产品主导推进与收尾

  • 推动App迭代内测正常进行,组建内测X,拉内测员
  • 整理版本主要更新点并发布内测邀请
  • 收集汇总内测员的问题反馈并记录相关反馈人
  • 反馈问题的定性与分类,确认是需qiúorBug,同时进行后续分配与确认
  • 判定需qiú是否采纳,采纳则纳入需qiú池,酌情安排迭代,不采纳则将原因描述反馈归档
  • 归档全部的问题及问题认定后,进行问题反馈分级
  • 根据问题反馈分级,对反馈内测员发送对应奖励

阶段参与方&职责如下:

测试:

  • 确认预发布验证X,准备内测包并发起内测liú程
  • 配合产品一起完成对反馈的问题的定性分类分级
  • 对分类为Bug的问题反馈,进行确认与复现,同时确认Bug的优先级
  • 高优先级Bug,当前版本需解决,录入系统跟进本版本内解决
  • 低优先级Bug,可延后解决,录入系统Bug池延后版本解决

开发:

  • 确认需发布内容的Checklist
  • 对X进行逐一发布
  • 内测包的打包与准备

内测员:

  • 内测员一般由内部员工或灰度员工参与
  • 下载并安装内测包,进行体验
  • 重点体验本版本的更新点相关liú程
  • 轻度体验App的常规常用liú程
  • 发现问题并在内测X内反馈问题,配合产品完成问题的确定与归集

项目经理:

  • 跟进版本迭代的生产环境发布
  • 推动最终对外上线发布

阶段工作描述:

内测阶段是上线前最后一个阶段,在这个阶段需要从常规用户的角度来最终体验,以防存在有未覆盖的点存在问题。

阶段交付成果:

  • 生产环境App
  • 内测体验报告

六、APP版本号命名规则

作为移动端产品经理,经常会做APP版本迭代规划,所以不可避免的需要给APP版本确定版号的工作,大多数情况下可能都是拍脑袋确定的版本号。有些X可能会有专门的项目经理负责版本管理和版本号的命名,但是绝大多数小X可能都是产品经理来做这项工作。

6.1 为什么要规范APP版本号的命名?

首先需要说明的是哪些人员需要用到APP版本号,第一是产品经理,第二是开发人员,第三是项目经理,第四是用户。

对于产品经理,APP版本迭代基本都是由产品经理发起的,因此很X况下都是产品经理在进行需qiú管理和版本规划的时候就大体上划分了版本号,版本号对于产品经理来说可以更好更清晰的筛选和确定每个版本的需qiú;

对于开发人员,版本号是直接和代码相关的,很多时候不同版本交X发,同一时间可能在开发不同版本,为了X代码的规范和清晰,避免不同版本出现交叉混乱,版本号是极其重要的一环;

对于项目经理来说,版本号是需qiú管理中唯一标识符,需要根据版本号去管理和分配下发工作,同时也为了在软件产品生命周期中更好的沟通和标记;

对于用户来说,尽管版本号对于用户来说只是一串数字,但是版本号给用户的感知是不断更新的数字,可以X版本号来判断自己的APP是不是最新的。

6.2 APP版本号的组成与规范

目前很X况下,版本号可能只遵循了两个原则和规范,即版本号是唯一的,且是一串数字这个基本原则。在介绍APP版本号的命名规范和原则之前,我们首先需要了解一些APP版本号的组成是怎样的。

软件版本号有四部分组成:

<主版本号.><子版本号>.<阶段版本号>.<曰期版本号加希腊字母版本号>。希腊字母版本号共有5种:base、alpha、beta、RC、Release。例如:2.1.0.181209_Release。下面对希腊字母版号进行简述:

Alpha版:也叫α版(开发环境),此版本主要是以实现软件功能为主,通常只在软件开发者内部交liú

Beta版:此版本相对于α版已经有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI。

RC版:此版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发行的正式版相差无几,测试人员基本X的版本。

Release版:此版本意味着“最终版本”、“上线版本”,,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的是符号(R)。

而对于绝大多数APP来说,一般采用的基本都是GNU风格的版本号管理策略,APP完全版本号的组成包括三组数字<主版本号.><子版本号>.<阶段版本号>,也即X.Y.Z,其中X、Y、Z都为正整数。

6.3 APP版本号的命名修改规则

6.3.1 主版本号

  • 当App的多个主要模块有较大的变动,一般情况下比方说APP新增一个TAB,整个产品结构都改变了,或者新增了新的功能或X。比方说微信上线钱包,抖音上线直播
  • 主版本号起始值为0或者1,具体需要由产品经理来决定是否需要修改主版本号(PS:大多数可能需要老板拍板)

6.3.2 子版本号

  • 子版本号初始值为0
  • 当APP的较少主要模块发生较大的变动或新增模块(涉及主逻辑变更的)、较多个分支模块发生较大的变动或新增,相对于主版本号而言仅是jú部的变动,比方说某个功能上的UI重构,某个页面的优化等,其中较少模块和较多模块需要去定义,一般我们认为较少为小于3个,较多认为是超过3个;
  • 子版本号的最大值需要确定,不同的X可能有最大的值,比方说最大为9,如果超过9,则需要主版本号进1,也有些X可能不存在最大值,只会在主版本号+1的情况下才会将子版本号归0。这里没有确定的原则和规范,可以由产品经理自己定规则

6.3.3 阶段版本号

  • 阶段版本号初始值为0
  • 什么时候修改阶段版本号,一般是Bug修复、较少个分支模块的变动,比方说视觉、样式、交互、文案等修改的情况。
  • 一般情况下,如果只是修复bug,则阶段版本号+1即可;如果既涉及到bug修复,又涉及到较少分支模块的修改,则阶段版号+2;如果超过3个分支模块的修改,则建议直接子版本号+1。

尽管说版本号只是一串数字,但是对于产品经理、开发人员以及用户来说,都是X义的一串数字,既能规范版本的生命周期,也能方便内部人员的沟通和工作,拍脑袋的去命名版本号是一个不严谨和规范的,而产品经理是需要去追qiú完美的,希望以上的APP版本的命名规范能够给大家一些参考。

以上,就是APP版本迭代涉及到的各阶段liú程整理,以及各个X涉及到的各角sè的职责以及每个阶段需要输出什么交付物,每个X每个产品涉及到的liú程可能都会不一样,但是大体上来说应该有会包hán上述环节,大家可以根据自己的实际情况进行调整。

#专栏作家#

Harryli,微信X号:Harry李先生笔记,人人都是产品经理专栏作家。3年产品经验,主要关注互金、新零shòu等领域,以及行业热点相关产品、运营内容。

本文原创发布于人人都是产品经理,未经许可,jìn止转载

题图来自Pexels,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 5000字干货好文 | APP版本迭代流程&版本号命名规则(建议收藏) https://www.xiongfawang.com/750.html

常见问题

相关文章

5000字干货好文 | APP版本迭代流程&版本号命名规则(建议收藏)-海报

分享本文封面