软件项目版本管理二三事.docx

软件工程版本管理二三事什么是版本管理？版本管理，是对软件开发过程中特定功能的集合或特定代码构 建结果进行管理，主要包括版本编号的管理、版本的前期规划、版本开发时的需 求变更应对以及版本发布上线后的总结回顾等内容。在版本开发前：通过建立版本号标识，明确版本目标，制定好版本上线需求内容, 设计好发布策略，可以让产品功能和质量尽可能地符合用户的预期。在版本开发时：通过提升需求分析确实定性，提高需求方需求变更的本钱，降低 开发响应需求变更的本钱，从而帮助团队积极地应对需求变更。在版本发布后：通过对Bug和用户反应以及线上日志的收集分析，对版本进行 复盘，有助于及时应对版本问题，从而制定有针对性的版本优化。一、如何对版本进行规划对产品版本的规划，主要包括四局部内容：一是建立明确的版本号标识，二是确定版本的目标，三是制定版本内容,U!是设计发布的策略。1.建立明确的版本号标识为了使工作规范化、统一化，我们需要明确标识产品的版本编号。目前业界在软 件版本的命名上,通常会采用以下方式:原因二：需求变更的本钱建筑工程里面的需求变更，都很容易和本钱挂钩，因为这些东西已经是生活常识 了，而软件工程里需求的变更本钱比拟模糊不确定。举个例子：装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色, 那么他会很清楚，这涉及一系列本钱：需要重新购买涂料、需要找人重新粉刷。 但换成一个软件工程，客户想把界面的白色背景换成蓝色的，他会觉得这是很简 单也是理所当然的，甚至有时候产品经理也会这么想，就会对开发这么说：不 就是换个颜色吗？几行代码的事，客户让换就换了嘛但是实际上，软件工程 的需求变更，哪怕是换一个背景颜色，同样是要涉及本钱的：需要修改所有涉及 背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。问题二：如何缓解需求变更问题？在软件工程开发中，需求变更其实是不可防止的，找到合适的方案来改善并积极 拥抱合理的需求变化，减少不必要的需求变更，这是我们讨论如何缓解需求变更 问题的前提条件，也是共识的基础。1、提升需求确定性，把需求分析做好，减少需求变更例如：在了解完客户的需求后，不急于马上输出PRD文档让开发实现，而是自 己先用Axu re等原型设计工具，做一个简单的交互原型，给需求方演示。用户 会针对原型的效果提出一些修改意见，然后再快速地修改原型，这样反复确认, 等到用户没有什么修改意见后，再着手具体的文档编写和开发实现。2、规范变更流程，提升需求变更本钱例如：如果有条件，当业务需求发生变更时，可以根据实际情况，要求需求部门 需通过电子化管理平台中的需求管理流程进行需求变更，并提交需求变更 申请，经主管领导及工程经理审批后提交给技术负责人实施。需求变更申请 通过后，文档管理人应将工程需求规格说明书同步更新到最新版本。3、降低开发响应需求变更的本钱，积极应对需求变更例如技术上可以通过换皮肤的方式来定制界面，可以通过插件的方式增加功能, 以此来应对个性化的需求。三、版本发布后的工作当版本发布上线后，可能这才只是新的开始，因为还有两项重要的工作需要继续 跟进，一是问题跟踪，二是版本复盘。1 .问题跟踪用户在使用产品的时候，可能会遇到一些Bug或者是有一些建议，所以需要提 供用户反应问题的渠道，让用户可以有途径对于Bug或者功能去反应。除了被动地依靠用户反应问题，还需要主动的对发布的版本进行监控。比方说要 收集系统崩溃的日志、监控服务器资源占用情况、监控API出错的比例、监控 网页响应的速度等数据。当发现数据异常时彳艮可能说明发布的版本是有问题的, 需要及时的应对，回滚版本或者发布新的更新补丁。2 .版本复盘对版本进行复盘，就是通过分析和讨论实现版本过程中出现的问题，进而总结成 功经验，吸取失败教训，提升团队能力。版本复盘主要包括四个步骤。版本在最开始规划的时候都会确定该版本的目标，所以复盘的第一步，就是要回 顾最初的目标，方便对最终结果进行评估。做好版本目标回顾的前置条件，是准确和客观的目标描述。只有做到目标的准确 和客观，在后续才能对目标的完成情况进行准确地评估。2、评估版本结果好的结果：比方说版本上线后质量稳定，Bug比例低于上一次版本，没有出现需求遗漏，开发和测试能及时同步需求的变更。坏的结果：比方说开发过程中间有比拟多的需求变更；工程发生了延期等。3、分析原因 导致好结果的原因，比方：增加了自动化测试代，改进了开发流程，代码合并之 前有代码审核等；改进了工程流程，对于所有的需求细分后，基于任务跟踪系统 记录了起来，这样可以及时了解任务进程。导致坏结果的原因，比方：版本没有及时冻结需求，频繁增加新的需求，导致开 发节奏被打乱频繁等4、总结规律落实行动例如，需求变更是导致工程延期的主要源头，需要在后续工程中控制好需求的变 更，比方我们将缩短工程周期，采用快速迭代的开发模式，及时响应需求变更, 同时在一个迭代中，没有特殊情况，不做需求上的变更，有变更放到下一个迭代 中。或者，任务跟踪系统可以方便地跟踪需求的执行情况，也能保证工程成员能及时 同步需求的变更。那么就继续使用任务跟踪系统，对需求任务进行跟踪，并且可 以尝试对于一些临时性的任务也用任务跟踪系统跟踪起来。通过回顾目标、评估结果、分析原因和总结规律这四个步骤对版本进行复盘，有 助于我们发现做的好的地方和做的不好的地方，找出背后的原因，最终总结出来规律，落实成行动，做出积极的改变，把经验转化成能力。四.结语 版本管理工作是软件工程管理的重要内容，该工作贯穿版本开发前、版本开发时 和版本发布后的全生命周期。版本开发前，通过建立明确的版本号标识，明确版本目标，制定好版本上线需求 内容，设计好发布策略，尽可能地让产品版本功能和质量符合用户的预期；版本 开发时，通过提升需求分析确实定性，提高需求方需求变更的本钱，降低开发响 应需求变更的本钱，帮助团队积极地应对需求变更；版本发布后，通过对Bug 和用户反应以及线上日志的收集分析，对版本进行复盘，及时应对版本问题，从 而为下一步制定有针对性的版本优化做好准备。以上就是本人对于软件工程版本管理的一些思考和总结，希望对从事工程管理、 产品管理的同行有所帮助。主版本号,子版本号.修订版本号.构建版本号f.Revi版本号命名规那么例如：1.2.1, 2.0, 5.0.0 build-13124。其中，构建版本号通常由编译程序自动生成，对外不提供。1 .版本号更新规那么 主版本号更新规那么：产品功能发生全新的优化，包括页面、体验和技术上的全面更新优化。如下列图所示两个产品的版本号升级。 子版本号更新规那么：L产品新增了重要功能模块；2、在原来功能基础上作了重要更新；3、严重Bug的修复。 修订版本号更新规那么：L新增或优化一般的功能模块；2、一般Bug的修复。2 .版本号后缀版本号后面可以加入Alpha、Beta、Gamma、RC、Release等后缀，用来表示软件当前所处的阶段。 Alpha :内测版。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在开发者内部交流，或者提供给测试人员测试用，一般而言，该版本软件的Bug较 多，需要继续修改。 Beta :公测版。该版本相对于a版已有了很大的改进，消除了严重的问题，但还是 存在着一些缺陷，需要经过屡次测试来进一步消除，可以提供给一定的目标用户大 规模体验测试。 RC版：候选版本。是Release Candidate的缩写，意思是发布倒计时，该版本已 经相当成熟了，完成全部功能并清除大局部的Bug。 Release版：该版本意味最终版本。是经过前面版本的一系列测试之后，最终 交付给用户使用的一个版本。该版本有时也称为标准版。2 .确定版本目标版本规划的第二局部内容是关于版本目标确实定。在确定版本上线需求的时候，往往容易只考虑那些最紧急的、用户反应最多的、 所谓优先级最高的需求，然后将这些需求整合到下一次的版本发布计划中，但是 这么做无疑是捡了芝麻却丢了西瓜，因为忽视了对整个产品目标的实现。比方：需求A属于模块1 ,需求B属于模块2 ,需求C属于模块3 ,这些需求分 属于不同的业务，解决的是不同场景的需求，但同时实现这几个需求，并不能体 现出产品的目标和优势。一个版本，就好比一个产品，产品要有自己的优势，版 本也要有自己的目标和优势。基于海盗模型确定版本 海盗模型是一种以用户为中心的、着眼于转化率的漏斗模型。这个经典的数据模 型把目标整体分成了五个局部，即：获取用户(Acquisition )、激活用户(Activation )、提高留存(Retention )、获取收入(Revenue )和自传播(Referral)。1、获取用户即拉新，一般是用户的注册、下载、关注等行为。通常用新增用户数来作为考量。 任何一款产品上线之初都避不开这个环节，而且拉新是会持续的伴随整个产品生 命周期。一般在刚刚上线核心功能后，都会重点关注并优化用户的注册登录的路 径，甚至通过不断的埋点来获取数据，从而做数据分并优化需求。案例：最初新浪微博的注册流程，是需要用户在第一次注册时绑定手机号、身份 证、输入账号密码和保密邮箱等等非常多的内容，后来在后台的数据埋点中发现 由于注册流程繁琐，导致不少用户在注册了一半的情况下就跳出了页面。之后随 着版本的不断迭代，如今新浪微博的注册只需要输入账号和密码即可，只有在需 要用到核心功能时才会需要我们绑定手机号和身份证等相关信息。这样就大大降 低了用户的操作本钱，让获取用户变得更容易。2、激活用户即促活，一般会以用户的在线时长、与其他用户的互动频次等数据来做以考量。 初期用户的活跃度是至关重要的，甚至对产品以后的开展会有很长远的影响。案例：抖音在最初的版本上线的时候，通过各种渠道吸引了很多在校的大学生录 制作品，他们大多来自于音乐学院、表演系等颜值出众的年轻人。这些用户的积 极互动和推广为抖音在用户的心里留下了一个新潮时髦的印象，从而吸引更多人 参与到短视频的制作和互动中来。3、提高留存留存：指在经过一段时间后有多少用户留了下来，一般情况下会以月、周、日的 时间维度来作为数据考量，也就是我们常说的DAU、WAU和MAU0案例：在一些社区及游戏行业中留存是一个相当重要的指标，当一款产品的用户 留存越来越低，即使有新用户进来，也依然难以摆脱冷清的局面。例如，根据王 者荣耀的数据发现，在非长假期间用户的留存率会出现下降的情况，所以为了抢 占用户的时间，提高留存率，程序会经常发布一些诸如签到送皮肤和送钻石金币 等任务活动。4、获取收入即变现。不止是软件的开发方获得收入变现，用户也可以在这一步获得利益。案例：知乎为了更好的促进用户进行高质量内容创作，增加了付费问答等功能, 这些功能让用户有更强烈的动机去进行持续的内容输出，同时也为平台带来了部 分收益。5、自传播自传播：即用户可以自发的向身边用户推荐我们的产品。案例：拼多多采取了拼团模式让用户获取到折扣和优惠，同时进一步刺激了用户 提供给身边人，加强了产品本身的传播性。3 .制定版本内容版本的目标确定了，我们就需要从需求池中挑选需求了。需求很多，但是开发资 源紧张或存在其他一些客观因素，不能在一个版本中全部实现。那么我们怎么对 这些需求进行排序呢？基于KANO模型确定需求优先级KANO模型是东京理工大学教授狩野纪昭(Noriaki Kano )创造的对用户需求 分类和排序的工具。我们可以通过使用KANO模型，分析需求的优先级，完成 对版本上线内容的制定。具体就是：要尽量防止无差异型需求，不做反向型需求, 做好基本型需求和期望型需求，努力挖掘兴奋型需求。在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用 户满意度的因素分为五类：兴奋型需求、期望型需求、基本型需求、无差异型需 求、反向型需求。1、兴奋型需求兴奋型需求，就是哪些藏在暗处的、用户意想不到的，需要挖掘/洞察的需求。假设不实现此需求，用户满意度不会降低；假设实现此需求，用户满意度会有很大的 提升。当用户对一些产品或服务没有表达出明确的需求时，如果提供给用户一些 完全出乎意料的产品属性或服务行为，会使用户产生惊喜，提升用户满意度，从 而提高用户忠诚度。这类需求往往是代表着用户的潜在需求。例如网易云音乐的评论功能：网易云音乐刚推出时就摒弃了传统音乐APP 音 乐播放器”的普遍定位，以音乐社交为差异化切入点，让用户听音乐后投入 的情感以F发表评论的形式参与进来,让用户体验的不仅仅只有音乐,还有情感 的共鸣。2、期望型需求期望型需求，是处于成长期的需求，也是表达竞争能力的需求。实现此需求，用户满意度会提升；不实现此需求，用户满意度会降低。对于这类 需求，不仅要满足，还要保证质量。例如：电子书APP阅读方式的多样性，既支持文字阅读，又能支持语音听书。基本型需求，即痛点，对于用户而言，这些需求是理所当然必须满足的。 当不实现此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到 显著提升。这类需求是核心需求，也是产品必做的功能，所以应该不断地调查和 了解用户需求，并通过合适的方法在产品中表达。例如：电商购物类APP的支付和订单这两种需求。4、无差异型需求用户根本不在意的需求，对用户体验毫无影响，无论提供或不提供此需求，用户 满意度都不会有改变。对于这类需求，没有必要花大力气去实现。5、反向型需求用户根本都没有此需求，实现这类需求用户满意度反而下降。所以这类需求不能 去实现。4 .设计发布策略版本规划的第四个内容是设计发布策略。版本发布策略需要考虑的问题是：直接 发布给所有用户？还是先让一局部用户试用？比方说可以先让内部用户使用，内部用户对软件质量问题容忍度是很高的，还可 以帮助发现很多问题。还有就是采用灰度测试的发布策略，让一小局部用户先用 新功能，如果没发现什么问题，再继续扩大用户规模，如果有问题，也只是影响 少量用户。例如：苹果的iOS系统，用户也可以选择安装最新的Beta版本, 可以先体验新功能，但是必须忍受系统的不稳定。二、如何应对版本需求变更问题从版本的规划进入版本的实现阶段，业务需求的变更是无法防止的，所以需要考虑如何应对版本需求的变更问题。问题一：同样是工程，建筑工程也是有需求变更的,但却不会像软件工程这么频繁和失控。为什么呢?原因一：需求确实定性建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑工程里面，无论是 提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。然而，软件 需求那么经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形 后，才慢慢想清楚真正的需求是什么，从而导致需求变更。举个例子：客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件 给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成 蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候, 产品经理担忧客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜 色，客户还是不满意，问能不能把背景换成图片