需求、项目版本与BUG关系

文档编号：1pei/IS 2017-0002

修改历史：
   V0.1, 2017.07.04, 初稿
   V0.2, 2017.09.24, 紧急BUG和严重BUG增加用户感受   				  

1. 用户需求/产品部门引领版本
   用户的每一项需求都会汇总到产品部门，由产品经理来归纳，总结，分析梳理，安排设计UI，最后形成系统化的需求与概要设计文档。
   这些需求文档还需要经过多轮次的评审，修订，再评审。
   定稿后的需求文档将引领整个公司不断前行。
   通常需要比开发提前1-3个月来安排设计。

2. 版本不断迭代进化
   现在项目采用版本方式来迭代进化，例如2017.07.01 服务器端版本2.5.0版本上线后，就开启新一轮2.6.0版本的开发。
   通常每个版本的进度如下：2周开发，1周测试周六上线B站，B站运行一周后上线A站，大致一个月一个版本。

   遇到遗留BUG很多的情况下，会安排一个版本专门来清理BUG，这种版本通常整体不超过2周。

3. 用户BUG优先级管理
   随着用户群的不断增加，新上线的用户总会发现这里或那里不顺手，然后提交问题和需求，最后都会以新BUG单来展现。
   因此，BUG可以分为问题类BUG和需求类BUG。

3.1 问题类BUG
   问题类BUG需要首先经过产品经理的筛选，分严重性和优先等级，我们使用紧急、严重、一般三个优先级：
   
   紧急：BUG影响到用户业务的正常进行，不解决用户无法继续开单或使用；
         金额或库存数量错误的，影响到用户利润计算或造成用户销售开低价造成损失的。
		 用户感受：用户会骂街，会不信任一配云，会不再向其他意向用户推荐。
         例如：销售界面中搜索不到产品无法开单、
               BUG[3532]|提交订单时出现白屏，服务器SQL报错
               BUG[3517]|采购单据修改保存后都变为同一个产品

         影响范围广，可能每一个用户正常操作都会遇到。
         需要立刻，1小时之内，或在问题发现当天解决；不能超过一天，否则影响范围会波及很大，无法善后。
         这种问题一天解决不完的，第二天继续解决，直到解决完成为止。其他内部开发项目，其他BUG都需要为该问题让路。

   严重：在一些特定条件下出现，可以有其他手段来处理，不至于影响到用户业务开单；
         例如：快速点击+按键出现双模态框
               销售单据详情页面无法打印但是销售首页可以打印

         用户感受：用户会皱眉。

         影响范围大，可能有类似操作习惯的用户都会遇到。
         可以在一周之内优先解决，作为严重BUG安排到项目中穿插解决。

   一般：页面错位、字体、样式等不一致，不影响用户开单的非紧急和严重级别BUG。
         例如：页面文件信息不恰当，样式错位等等。

         影响范围小，一般用户不会注意到这些细节，除非是一些细心用户。
         放低优先级来解决，作为一般BUG安排到项目中穿插解决。
   
3.2 需求类BUG
    需求类BUG通常需要修改设计界面，对需求类需要谨守之前发生的多个教训：
    (1) 不允许由产品经理在UI设计完成后，未经过多方评审，就直接找开发人员处理。
        开发人员有权拒绝此类问题修改。

    (2) 这些UI在设计完成后，至少需要经过需求管理委员会（建勇、思宇）、产品经理、测试代表、开发人员达成一致意见后，再安排到项目中来实现。
        谨记：磨刀不误砍柴工！

4. 白天项目/晚上BUG开发二重奏
   一方面，项目必须不断前行，开发新的功能，开发与老牌进销存厂家（思锐、怀远等）差异化的功能来满足用户不断增长的新需求。
   另外一方面，源源不断的用户问题类与需求类BUG也需要不断解决。

   为此，基于之前的经验，我们采用白天做项目，晚上解BUG这样两不耽误，两个都快速前行的开发二重奏!
   
   谨记：我们再做5年在进销存方面也无法超越有13年经验的思锐！
         但稳固能够满足绝大多数用户的进销存是我们拓展其他业务的前提！

5. 评审机制
   每个模块最重要的两次评审：需求评审+接口评审

5.1 需求评审
    开发+UI+产品经理+测试

5.2 接口评审   
    开发+产品经理

5.3 BUG单修改审核机制
   每个BUG单除了自己修改以外，必须经由另外一位同行人员评审，这位同行可以同样是前端，也可以是本小组组长，评审通过后再转给测试检验。
   测试人员看到BUG单如无评审记录，可打回要求增加评审。

6. 版本阿里云B站上线倒计时通知
   在B站上线的那一周，从周一开始就要
   "2.X.0版本B站上线倒计时7天"，
   "2.X.0版本B站上线倒计时6天"，
   "2.X.0版本B站上线倒计时5天"，...
   这样，每一天及时发布遗留BUG和项目进展进度, 督促大家在上线前及时处理掉相关问题，确保项目进度正常。

7. BUG上线测试确认流程
   对比较严重的BUG采用分开测试：
   (1) 苏立平先内部测试。
   (2) 内部测试通过后由张思宇上线到B站，然后雅靖来测试确认；
   (3) B站确认通过后再上线到A站。
   这样可以将问题的风险降到最低。
   
   2018-01-11上午有7分钟左右无法上线: 可能是合并代码出错。
   以后白天不论再怎么样紧急，用户问题白天不再升级，只能在晚上23:00之后升级。