精华内容
下载资源
问答
  • 产品版本迭代管理
    2019-09-11 17:51:25

    场景描述:一个软件产品,一个用户(一个部署)。随着用户的需求,不断的迭代更新。

    我整理了一下版本迭代的过程。

    https://www.processon.com/view/link/5d78b7c2e4b0b018f3ee054f

    更多相关内容
  • 所以,理清楚产品的整个规划的流程就非常重要,这套流程能够帮助自己理清思绪,让你知道你现阶段应该做什么,接下来要做些什么,这样才能让自己的工作非常有条理,也会让产品迭代更有节奏。需求管理是做产品的人最...
  • Git版本管理与项目迭代发布 Git强大的版本管理能力让我们在项目中可以灵活的创建、合并分支,不过灵活总是伴随着复杂,比如,当项目团队越来越大时,创建的分支可能非常多,每个人都可能创建几个,如果不及时提交...

    Git版本管理与项目迭代发布

    Git强大的版本管理能力让我们在项目中可以灵活的创建、合并分支,不过灵活总是伴随着复杂,比如,当项目团队越来越大时,创建的分支可能非常多,每个人都可能创建几个,如果不及时提交代码、合并删除没用的分支,并且做好分支命名规范,可能搞的混乱不堪。

    在实战项目中,我们往往有多套环境,比如开发环境、测试环境、生产环境,有的还有灰度环境、UAT环境,或预发布环境等,一般情况下,测试环境和生产环境是必须要有的。

    在小规模团队中,Git和SVN一样,提供代码提交、合并的功能,即使迭代开发,两三个工程师定期合并下代码发布即可,但在大型团队中,问题就暴露出来了,比如,一个大型团队可能分好几个组,每个组负责若干模块的开发,每个组之间的开发是不同步的,如果共用一套代码,就会出现问题。比如A,B,C,D四个项目组,有的要本周三发版,有的要下周一发版,代码要是一个project就麻烦了。

    比如我们的项目,就是一套代码,为了规范,规定每周三晚上发版,其他项目均按此计划执行,但由于只有一个project,假设A项目完成开发测试本周三发布,B项目也提交了一些代码,但还没开发完成,本周三不能发布,这在SVN做管理时就很难实现,而Git提供了强大的版本管理功能,各项目组完全可以在不同分支上进行开发,就提供了解决此问题的方案。

    功能发布不同步的问题

    一开始,我们只有一个master分支,但由于master分支是默认分支,且对权限要求较高,我们创建了一个dev分支,所有工程师都把代码提交到dev分支中,用来发布测试和生产,大家可以自建分支,但只要代码提交到dev,就能保证dev分支中包含所有开发出来的代码,每周三发布后(一般是周四早上),我会把dev中的代码合并入master,以保证master中包含所有上线的代码。

    此时的过程是这样的:
    在这里插入图片描述

    但问题来了,我们同时有两个功能在开发:

    • 功能1:本周上线
    • 功能2:下周上线,本周和下周开发测试

    此时dev中即有功能1的提交,也有功能2的提交,如果本周三把dev编译上线,则功能2中的未完成代码也会上线,我们的确这么干了,也的确出问题了。

    用户气乎乎地问功能已经上线了吗?测试则则要把我们大卸八块。

    为了避免这种问题,有人提出了创建一个test分支,只有测试完成的代码才可以上线,为了防止上线时出现什么幺蛾子,我们在周三晚上并不是先把test的代码合并到master再发布,而是把test中代码发布到正式,验证无误后,第二天早晨再把test合并到master。

    然而,把test分支代码发到生产环境,这听起来似乎不太友好,怎么办?我们不如再建一个release分支,此分支中保存所有验证通过的代码,其实release就是test,只不过等test中的代码测试通过了才把test合进release。
    在这里插入图片描述

    此时的方案是这样的:

    1、日常开发中可以把代码全部提交到dev,dev分支是所有开发工程师代码的最新合并。
    2、dev分支只的内容可以发布到【开发环境】进行验证,验证完后,把代码合并到test分支中,发布测试;
    3、测试完成后,把测试完成的代码合并到release代码中;
    4、每周三把release的代码发布到正式环境,验证完误后第二天清晨把release中的代码合并到master中。

    我们把dev定义为【所有开发中的代码】,把test定义为【所有测试中的代码】,release定义为【所有代发布的代码】,master定义为【所有已上线的代码】,这样的定义是非常清晰的,但问题是【所有测试中的代码】即包括本周三要上线的代码,也包含下周三要上线的代码,如何把需要的代码提出来转到release中?
    更为麻烦的是,工程师即要把代码提交到dev,也要把需测试的代码提交到test,这可不好操作。

    我们再详细探讨一下这个问题:
    假设:
    工程师D负责功能一的开发,需要本周内完成开发测试,发布生产;
    工程师D、G共同负责功能二开发,在下周完成测试发生产。
    方案:

    1、为防止冲突,工程师D在功能一开发完后不能参与功能二的开发,否则,会造成功能一和功能二的代码混在一起提交到测试,影响本周的发布;
    2、工程师D在功能一开发完成后,合并到dev分支,发布到开发环境验证(工程师D自验证);
    3、如果没有问题,可以把提交到dev的那次commit,再发到test分支上去(工程师D在开发完成前不要提交dev,开发完后一次性提交!);
    4、工程师G可以同时开发功能二,并提交代码到dev,但不能提交到test分支;
    5、等功能一完成上线后,工程师D与G一起完成功能二,然后在提交到dev并发布到开发环境自验证;
    6、验证成功后,D和G把提交到dev上的commit再提交到test上合并,发布测试环境上测试。
    7、如果没有分批上线的情况,要及时合并dev到test上,以防止两者差别过大。

    git将代码同时提交到另一个分支

    1. 先在当前分支提交代码
    2. git log 查看刚才提交的 commit id
    3. 切换分支
    4. git cherry-pick commitId
    5. git pull
    6. git push
    

    问题:
    工程师D在dev上的验证可能会有问题,再反复修改,多次提交,要把这几次提交的id都记下来,将来全部转到test分支,操作起来相当麻烦;
    在功能一开发过程中,G的代码也会阶段性提交到dev,可能与工程师D的代码冲突,或影响功能;

    为了解决功能不同时上线的问题,对分支的操作很多,要花费大量的时间合并,如果出现误操作,要花更多时间去解决,保证test分支上是本次要发布的纯净代码,付出的代价非常大,得不偿失。

    如果不要dev分支呢?
    如果不要dev分支,那么当前git库中就没有一个分支是当前最全的代码;并且,每个工程师都想到开发环境验证问题怎么办?每个人的代码都与别人不同,你发一版,我过会也发一版,我把你发布的覆盖,再过会我的也被人覆盖了,更没法玩了。

    敏捷迭代与临时分支

    上面我们考虑的test分支是固定的,其实我们的敏捷开发是迭代进行的,每一轮测试也是迭代的,不如我们每轮迭代创建一个test分支,本轮迭代完成就合并删除它,再建一个新的。
    在这里插入图片描述

    方案

    1、把需要本次迭代的代码提交到当前测试分支 test-v4.5.1
    2、如果D即要开发 test-v4.5.1 功能,也要开发下轮迭代 test-v4.5.2 功能,则优先开发本轮迭代,发布后再做下一迭代功能。或者保证把本轮迭代的代码发到 test-v4.5.1 ,下轮迭代的代码提交到dev分支。
    3、test-v4.5.1测试通过后合并到本轮release-v4.5.1分支,删除test-v4.5.1
    4、release-v4.5.1发布生产验证后,合并到master,删除release-v4.5.1
    5、创建下个迭代test-v4.5.2release-v4.5.2分支,合并dev的代码到。
    6、需要开发next sprint的工程师切换到test-v4.5.2,其他工程师切换到dev。

    总结一句话:本轮迭代的代码提交到current sprint中,下轮代码的代码提交到dev中,再往后的才发布的代码自建独立分支。

    这种方案中,dev中不一定是最全的代码,因为当前迭代中有些代码是直接提交到test中的(避免代码同时要提交到两个分支),但是没关系,我们只要保证需要的代码上线即可。在当前迭代中,test确定是当前所有测试的代码,而release也确实是测试通过后合并进来的代码,我们仍然在周三晚上发布release中的代码,在周四早晨把release中的代码合并入master。

    问题:
    1、如果有功能三,要下个月发生产,H可能已经往dev中提交了一部分代码,此时,从dev创建next sprint的代码就会把H的代码也复制到next sprint中,这就不合理了。
    而若从master创建next sprint分支,则功能二开发的部分代码又不在next sprint中。
    在这里插入图片描述

    所以,对于非current sprint,也不是next sprint的代码,建议一开始就从master建一个分支独立开发,开发完后再合并到current sprint中,而新建的next sprint则要合并master与dev的代码。

    2、如果我们把test中代码测试通过了,test->release后也把test给删除了,周三晚上,我们把release中代码编译发布到生产环境,结果发现个bug(你知道测试往往做不到充分,总会有什么事发生),怎么办?

    此时已经没有test分支了,一般如果bug影响严重,需要用master分支(上一版)来覆盖,如果不太严重,可能要修改少量代码,这里可以切换到release分支上,改完后,把release编译发到测试环境验证,没问题再用release发生产。

    最终方案

    实际上release分支的确没什么卵用,它只是test的最终快照,测试完成时,一般就到了上线时间,所以直接拿test完成的结果发生产没有问题,操作上还能简化一些,因为我们下个迭代只用创建一个新的test,把dev中代码合并进来即可,要不然还要再维护一个release,还得保证这两个分支的初始状态是一样的。
    release只不过是掩人耳目的test,作为直耿且追求无尚简化的程序员,怎么能不“懒”一点呢?

    在这里插入图片描述

    实施规则

    1. 本次迭代连接test分支开发;
    2. 下次迭代连接dev分支开发;
    3. 更远的发布或不确定日期的任务,从master新建独立分支开发;
    4. dev只能发布【开发环境】,test用来发布【测试环境】。
    5. 在上线前夕,test必须经过测试通过才可发布到【生产环境】。
    6. 上线后,test合并到master,然后test合并当前dev中的代码,开始下轮迭代。

    注意

    1、保证dev中是下轮迭代要发布的代码,test是本轮迭代要发布的代码,其他长期功能另建分支开发,如果不确定是否是在本轮或下轮能完成的功能,也要另建分支,等确定后再合并到dev或test中。

    2、注意代码提交的位置,如果不小心把要test的代码发到dev,则自行把相关代码重新发到test;如果把要发dev的代码发到test,则要撤回。

    3、另外,在test合并到master后要合并dev的内容,记住:每次切换分支后,先pull request,把远程代码拉取一下,以保证合并时有完整的代码。

    远期分支的命名规范:

    feature-[模块标识]-[帐号]
    

    临时分支(用来做某个功能、改个某个bug)命名规范:

    temp-[dev/test]-[帐号]
    fix-[dev/test]-[帐号]
    [功能]-[dev/test]-[帐号]
    

    版本号命名规范:

    x.x.x #[大版本].[小版本].[迭代号:当前自然周]
    

    Git规范改进版

    经过一段时期的试运行,发现以上规则有一些问题:
    1、大部分工作都在test分支上进行开发,只有极少量的工作在dev分支上做,造成dev分支形同虚设;

    因为大部分项目/任务都是要近期上线的,没有谁愿意说自己的工作不着急,团队的敏捷实践并不完美,很多时候只会规划本期要上线的东西。远期的需求不确定什么时间能上线。

    2、每次发版要把test合并到master,之后要把dev合并到test,但这样就会出现问题,首先,因为有些代码只提交到了test,在dev中是没有的,在下次迭代时,dev中因为缺少了一些代码而无法在开发环境验证;其次,在dev与test合并的过程中常常有大量的冲突出现,解决冲突需要很多沟通成本,而且容易出错;再者,如要保持迭代后dev与test相同,则需互相合并,或者dev合到test后再重建dev,这样dev和test实质上可以看做一个分支。

    为了解决上面两个问题,我们采用两个主分支,test和master,去掉恒定的dev,如果有下次迭代的内容,可以从master新建临时的dev分支,这种dev分支是临时的,开发时只在本地验证即可,开发环境服务器一般不用发布,所以不同人可以有不同的dev临时分支。

    分支规范示意图:

    分支命名规范

    #远期分支的命名规范
    feature-[模块标识]-[帐号]
    #开发分支
    dev-[帐号]
    # 修复bug用的分支
    fix-[bug号]-[帐号] 
    #紧急发版的临时版本
    fix-master-[帐号],从master建一个分支,修复验证后发版
    

    版本号命名规范:

    x.x.x #[大版本].[小版本].[迭代号:当前自然周]
    
    展开全文
  • 全网都在用的项目迭代管理工具,在Projex中支持利用迭代按照既定周期交付需求。项目管理员,通过「项目设置」-「导航服务」开启迭代服务,即可使用迭代管理项目。

    全网都在用的项目迭代管理工具,在Projex中支持利用迭代按照既定周期交付需求。项目管理员,通过「项目设置」-「导航服务」开启迭代服务,即可使用迭代管理项目。

    立即体验

    迭代管理

    在Projex中支持利用迭代按照既定周期交付需求。项目管理员,通过「项目设置」-「导航服务」开启迭代服务,即可使用迭代管理项目。

    新建迭代:填写迭代的名称、开始及截至时间以及迭代描述,提交完成迭代的创建。

    在这里插入图片描述
    迭代创建完成后,进入迭代规划页面进行迭代事项规划。
    在这里插入图片描述
    在迭代规划完成后可开始迭代。
    在这里插入图片描述
    在迭代进行中,可查看概览数据进行迭代进度跟踪。

    1.基本信息、类型分布、动态

    基本信息包含当前迭代的完成情况及基本信息字段;工作项类型展现三种类型的分布及各自的完成情况;迭代动态展现迭代的创建、工作项变更等信息,按照动态发生时间由近及远。

    工作类型分布:查看每种类型任务在迭代中的占比,该指标可反映团队在当前迭代中开发新特性的工作占比,也能够间接体现项目当前的交付质量和技术债情况。

    2.燃尽

    数量燃尽:展示随着迭代进展,迭代中未完成的任务数变化情况。在具有良好敏捷实践的团队中,留存任务数应当在期望数据线的上下浮动。若实际留存任务数偏离期望线较远,则可能预示着进入迭代的任务量过大或开发进度未及时更新。同时还提供了任务按照人员维度的统计作为数量燃尽的辅助信息。按任务的当前指派人查看所有任务的分布情况,能够直观展现团队成员的工作量分配,用于识别流动瓶颈和团队负载情况。
    在这里插入图片描述

    迭代锁定

    在敏捷交付场景中,团队会组织迭代排期会确定迭代交付内容。一旦确定后,迭代的内容不会轻易变更。如需变更需要经过迭代相关参与方的确认后方可进行。基于以上的场景,需要迭代具备锁定交付内容的能力。

    在迭代列表、规划页面、迭代详情页面均提供了迭代锁定入口。可操作人员包含迭代负责人、项目管理员、企业管理员。
    在这里插入图片描述
    在这里插入图片描述
    迭代规划页面列表入口当迭代锁定后,不再允许随意变动迭代内的需求(包含移入、移出)。

    锁定用户范围:除有迭代管理权限的用户。具备管理权限的用户(如迭代负责人、项目管理员)可不受锁定影响。

    锁定后影响:用户在变更锁定迭代的需求移入/移除时,提示且无法进行后续操作。

    可进行迭代解除锁定,当解除后将不做规划限定。

    通过云效Projex进行迭代管理提高团队开发效率。迭代开发是敏捷开发的概念,迭代开发是有开始和结束时间的轻量级计划,用来明确规划在开始和结束时间之间需要实现的需求、需要修复的缺陷和需要完成的任务。一个典型迭代开发的周期从1到6周不等,团队可根据自己的节奏或业务的需要来确定迭代开发周期也能够提高开发效率。

    立即体验

    关于我们

    了解更多关于云效DevOps的最新动态,可微信搜索关注【云效】公众号;

    福利:公众号后台回复【指南】,可获得《阿里巴巴DevOps实践指南》&《10倍研发效能提升案例集》;

    看完觉得对您有所帮助别忘记点赞、收藏和关注呦;

    展开全文
  • 项目版本迭代管理总结

    千次阅读 2020-02-13 18:34:20
    困难 信息孤岛 需求理解 片面 有可能是错误的 新团队:并没有经过培训,...自发的 规则由下而上 规则提效 : ui-测试-产品-技术 等等 各种类型问题处理 一套固定流程。 过程资产 提效: 在这么高强度的工作后, 之...

    在这里插入图片描述

    困难

    1. 信息孤岛
    2. 需求理解 片面 有可能是错误的
    3. 新团队:并没有经过培训,面对复杂高强度业务的 团队协作及能力并没有那么强

    收获

    1. 脱敏: 每种业务异常 都有 专人处理,不像以前是 应激性反应患者:其他部门提个问题处理就手忙脚乱的去处理

    2. 自发的 规则由下而上 规则提效 : ui-测试-产品-技术 等等 各种类型问题处理 一套固定流程。

    3. 过程资产 提效: 在这么高强度的工作后, 之后 工作流程规范基本形成,本来 团队天花板最高是10,现在日常也是10,大大提高工作效率

    4. 采用的是 tapd+yapi+腾讯工蜂 项目管理工具

    5. 文章是在内部分享会做的笔记

    展开全文
  • 版本迭代规划的几大关键步骤

    千次阅读 2019-08-22 14:37:37
    产品经理对于如何做版本迭代规划,有时总会产生无力感,要么是计划难以确定下来,要么是制定好的计划无法执行下去,这个问题的原因很复杂。在项目初期,我们缺少对产品的全局概念和整体把握,内部意见很难统一;再者...
  • 版本迭代

    千次阅读 2019-12-19 15:16:50
    可以一个迭代发一个版本,也可以多个迭代发一个版本,也有一个迭代发多个版本的情况。迭代版本没有关联,实际使用中测试提bug是针对版本的。做测试也是基于某个版本测试找bug。 划分迭代版本 按“主次”划分 ...
  • 基于个人TOB大数据产品研发的工作经历,总结产品需求迭代流程图,客户-需求-设计-开发-数据-测试-运维各组人员分工职责如下。 先上图吧,以后有时间补充个文字版的,把一些踩过的坑列列,呃 希望拖延症不会太严重=_...
  • 项目迭代管理流程

    千次阅读 2021-04-15 10:25:09
    为规范产品迭代流程,提升团队成员产品迭代参与度,更好的衡量团队成员贡献度,量化产出,明确各成员角色的责任及义务,特制定此流程。 发版周期 两周一个迭代 概念描述 使用Jira管理自定义字段的描述如下: ...
  • 软件迭代开发计划模板,项目管理文档参考用
  • 如何进行高效的版本管理版本管理的方法。云效Projects版本管理为不同的产品线、模块建立版本,对集成版本进行相关活动的管理。在Projects版本管理中规划发布内容,可以关联需求、任务、缺陷。
  • 记录版本迭代_20180709

    千次阅读 2018-07-09 10:01:39
    记录这个千疮百孔的项目迭代过程!!!!   乐店云通用版v1.5   1、店铺管理文案修改:“店铺管理/店铺装修”文字改为“店铺管理/微站装修”; 2、装修菜单层级关系优化:目前的版块命名和提示,导致层级关系很...
  • 一路走来 从做项目,到做产品迭代,从做研发,到架构设计,再到团队管理,总结了一些经验。 这也年底了,总结 总结 与csdn上的大牛门 探讨 探讨。 技术 架构 方面的 总结,会陆续发出来,今天先说说 ...
  • Git如何持续迭代

    2021-06-16 09:53:20
    开发时, 手上七八项任务,如何从容迭代? 团队中,大版本控制如何从容迭代? 产品中,持续升级如何从容迭代?
  • Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum ofScrums....
  • 以下是版本迭代的个人总结,总结不算精辟,没有很专业...... 算是自己成长的历程...... 但是对于软件自动化测试,最好的学习方法不是听课,也不是看视频, 而是在有经验的专业人士指导下进行项目实战、...
  • MVP产品迭代流程

    千次阅读 2019-06-11 21:38:20
    关注公众号【程序职场】,专注于 Spring Boot+微服务,小程序,...怎么让产品快速迭代? 怎么让客户尽快体验产品? 这些问题一直困扰着创业公司?创业公司人员,资源有限,为了更好的抓住时机,需要快速的做好一个...
  • 需求管理迭代需求功能方案PRD.doc
  • 这块流程走下去不是很顺畅,需要优化一下以上场景作为PM再熟悉不过,作为一名产品经理,经常会受到来自各个方面的各种需求,而产品不可能大而全的满足所有需求,此外为了确保快速迭代,每一版本在有限时间内只能完成...
  • 转载 简书:https://www.jianshu.com/p/d917139304eb一、前言本文用实例来讲解Git的分支管理产品快速迭代开发过程中解决实际问题的详细方案,面向的是对Git有一定了解的朋友(多图预警)。二、背景最近接手了一个...
  • 敏捷产品管理之发布、迭代计划

    千次阅读 2019-10-18 12:06:59
    上篇我带你从理解产品 Backlog 最好的形式 Story 开始,经过建模、搜集、编写、估算这四个步骤,编写出有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致。让“一张卡片”发挥出它的洪荒之力,快速挖掘...
  • 两大明星产品到底哪个做迭代管理更胜一筹呢? 在正式开始对比之前,我们先来复习一些关于敏捷开发、迭代和 Scrum 的知识点。 一、基本概念 什么是敏捷开发? 敏捷开发是一种以人为核心、迭代、循序渐进的开发...
  • ONES 敏捷项目管理迭代流程图文演示

    千次阅读 2020-09-07 08:34:33
    ONES 敏捷项目管理迭代计划流程图文演示
  • 如何做好迭代规划

    千次阅读 2018-12-14 14:37:25
    互联网产品迭代速度越来越快,大家都想抢占市场,那么怎样才是正确的打开方式呢? 确定迭代节奏 如果产品已经进入维护阶段,即无论搞什么都不会造成利润大幅变动,那大家可以轻松点,每个需求都不限时,做完为止。...
  • 8个步骤,一次完整的产品迭代

    千次阅读 2020-02-25 07:21:08
    一、需求管理 1. 需求获取 需求获取也称为需求收集,该过程,产品经理要面对各种角色(需求方)提的形形色色的需求,需求质量也参差不齐,一般来源于以下渠道: 自己挖掘的需求; BOSS、合作商、甲方; 团队...
  • App版本迭代时间安排(思路重要)

    万次阅读 2016-05-08 23:39:29
    App 2周版本迭代时间安排 对于移动互联网产品来说,迭代的速度就是生命。 我创业时做移动App时是一周一版,而现在是2周1版。 相比起小公司,大公司迭代时间虽长,却更为不易,因为大公司流程更多,...
  • 好的产品总是保持着快速更新迭代的过程,抖音约10天更新一次,拼多多平均每周更新一次的速度更是让人惊叹。可以看到,一款APP要长久生存下去,必须让用户保持新鲜感。通过产品迭代优化产品设计、增加新功能新玩法等...
  • 迭代需求文档规范(模板)

    千次阅读 2020-08-18 23:04:50
    不适合新的产品或大的需求。 消费分期迭代需求 详细设计说明书 XX集团有限公司 2020年8月 声明 文档控制 更改记录 日期 修改人 版本 更改参考 8月18日 XXX V1.0 输出详细设计 审阅 姓名 职位 签字 分发人员 部门 ...
  • Lucene的版本迭代

    千次阅读 2017-12-25 23:01:04
    Lucene在之前的版本迭代中,不断尝试新的设计思想,不断引入新的与时俱进的功能。这也导致Lucene的大版本不兼容,在我之前的项目中,从Lucene2升级到Lucene4,再升级到Lucene6,都不能平滑过渡,需要修改项目中使用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 70,504
精华内容 28,201
关键字:

产品版本迭代管理