源码科技网
a 当前位置: 源码科技网 » 数码 » 正文

版本命名规范,验收规范,发版管理

 小狐 • 2020-06-29 19:24  来源:互联网  E76

版本命名规范,验收规范,发版管理(图1)

上一篇文章我们针对PRD文档撰写的why,what,how三个层面进行了分析,本篇文章,我将针对产品的版本命名,产品验收、版本发布三个方面谈一些想法。

01 产品版本命名规则 1.1 版本命名规范

版本命名规范,验收规范,发版管理(图2)

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

第一部分为主版本号。

第二部分为次版本号。

第三部分为修订版本号。

第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有五种,分别为base、alpha、beta 、RC 、 release。

1.2 版本号修改规则

1.3 版本阶段说明

Alpha :软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件者 内部交流,一般而言,该版本软件的Bug较多,需要继续修改,是版本。 人员提交Bug经人员修改确认之后,发布到网址让人员,此时可将软件版本标注为alpha版。

Beta :该版本相对于Alpha 版已经有了很大的进步,消除了严重错误,但还需要经过多次 来进一步消除,此版本主要的修改对象是软件的UI。修改的的Bug 经人 员确认后可发布到外网上,此时可将软件版本标注为 beta版。

RC :该版本已经相当成熟了,基本上不存在导致错误的Bug,与即将发行的正式版本相差无几。

Release:该版本意味“最终版本”在前面版本的一系列版之后,终归会有一个正式的版本,是最终交付用户使用的一个版本。该版本有时也称标准版。

1.4 版本发布周期

1非紧急情况:按照一般发包制度执行

2紧急情况:如果Bug比较紧急可跳过一般流程,由人员尽快修复Bug,及产品确认之后直接发布该版本。

1.5 版本号修改举例说明

如此时版本号为:1.0.0.0321_alpha ,此时为内部阶段

1人员修复了人员提交的bug并经人员验证关闭bug之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为:1.0.0.0321_beta ,如当前日期跟上一个版本号的日期不一样,版本号可改为:1.0.0.0322_beta。

2如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版,如1.0.1.0322_beta,日期为发布的当前日期。

3如果对软件进行了一些功能上的改进或增强,进行了一些局部变动的时候要修改次版本号,如:1.1.0.0322_beta上一级有变动时,下级要归零

4当功能模块有较大变动,增加模块或整体架构发生变化时要修改主版本号,如新增加了退款功能,则版本号要改为:2.0.0.0322_beta 。

02 产品验收流程 2.1 流程

版本命名规范,验收规范,发版管理(图3)

流程描述:

a、人员在确定所有bug修复之后交由产品进行验收,一部分公司中,产品也需要参与到中,特别在各项文档不是很齐备完善的情况下,产品可以在关键节点介入一下,防止研发出的功能与想要的功能差距较大。

b、产品功能验收—产品验收主要是验收功能,功能是否与设计一致,主流程是否通畅,交互是否顺畅,数据是否正常,是否有缺漏,异常流程是否考虑,各类提示及是否具备。一定要验收异常流程,很多时候正常流程可能没有问题,异常流程是很容易遗漏的,异常流程是否考虑完备的重要体现。

c、视觉设计验收—视觉验收产品也可以进行,但最好是让视觉设计师再进行一次验收,这样分工明确,也可以有所侧重,也形成多次验收,防止出现意识偏差。

2.2 产品验收报告标准

产品验收报告包含:

a、验收编号-表明所归属的项目及验收日期

b、产品版本、上线时间、发起人

c、验收清单项目—包括功能及视觉,检查清单项可以保证不遗漏,此功能验收还需要以prd文档辅助,以prd文档为基础,核对本次迭代中的功能、流程等。

d、签字确认项—明确验收,权责

版本命名规范,验收规范,发版管理(图4)

03 产品发版 3.1 目的

制定发包的相关制度是为了规范相关做事流程,明确相关交接文档,确定相关权责,让事情有据可依、有根可查、有人负责,从而提高团队做事效率。此处的发版说的是公司内部,不是针对外界的,外界可由或相关对于推广部门运作。

1产品新功能提需求,需要提交到禅道,按不同类型进行分类,归属到不同需求池,需求的提交按需求点方式提交,备注需求归属,是哪个,前端or后台、模块、功能、优先级等,并写明需求内容、规则。

2技术人员并通过本地后,交由人员进行。

3人员进行,参照原型等产品相关文档数据检查,页面核对,文字核对及其它。产生功能性等Bug,需向禅道提交bug,分配bug修改人并关联bug对应功能的研发人员。

版本命名规范,验收规范,发版管理(图5)

5《产品确认表》交给产品确认验收,产品查验功能与需求是否有出入,并进行验收。如果验收有bug,则由提交bug到禅道,关联相关研发人员。Bug修改完毕,先由研发、提交人员、人员无误提交产品。内部发布也需要走发布版本,需产品负责人及项目负责人签字确认。有必要的情况下组织会议商议对策,会议记录方式参考《会议纪要模板》

会议注意事项:

会前与参会人员沟通时间,会议议题事项。

开会围绕主题围绕事项,以解决事情为主,不要搞成茶话会

事事有负责人及截止时间点

会后有跟踪执行落实和反馈

版本命名规范,验收规范,发版管理(图6)

6产品验收完成签字,产品留一份签字确认纸制文档,并将电子文档给给研发负责人。由研发或再给正式发包运维人员并加此次已经签字完成的《产品确认表》电子文档。

7发布正式环境,无误后产品通过钉钉群方式发送发布版本公告。产品发公告的内容主要包括:

本次产品版本主要需求内容,需求提出方,对应UI、研发人员、产品、项目经理等关联人员。

版本号—版本号的规范参照《版本命名规则》执行。

发布时间(按实际发布时间)

8环境通过后发包至预发布环境或生产环境,再次进行验证,如此时发现有问题,也必须重新按照产品发包流程走,填写《产品确认表》环境完成才可在生产环境发包。

以上是关于产品版本命名、验收规范、发版相关内容,下一篇文章将是—项目。

本文相关词条概念解析:

版本

版本,最初指一种书籍经过多次传抄、刻印或以其他方式而形成的各种不同本子。随着时代的发展,版本也开始应用于影视、软件等事物上,形容对象相同但介绍方法等不同的两个事物。

验收

验收:按照一定标准进行检验而后收下或认可逐项验收。简要说明:项目可行性研究报告批复或计划任务书和核准单位及批准文号,批准的建设投资和工程概算(包括修正概算),规定的建设规模及生产能力,建设项目的包干协议主要内容。初验时间与初验的主要结论以及试运行情况(应附初验报告及试运转主要测试指标,试运转时间一般为3—6个月)。工程施工中的大事记载,各单项工程竣工资料、隐蔽工程随工验收资料、设计文件和图纸、监理文件、主要器材技术资料以及工程建设中的来往文件等整理归档的情况。

网友评论Translation