12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061 |
- 一配云项目版本管理流程
-
- 文档编号:1pei/IS 2018-0003
- 修改历史:
- V0.2, 2018.02.XX, XXXX
- V0.1, 2018.01.16, 初稿
- 1. 简介
- 项目、版本迭代式前进,牵引整个公司不断前行。
-
- 2. 项目任务来源
- 用户的每一项功能和需求,可能来源与用户、竞争对手、我们自己分析,都会汇总到产品部门,由产品经理来归纳,总结,分析梳理,安排设计UI,最后形成系统化的需求与概要设计文档。
- 这些需求文档还需要经过多轮次的评审,修订,再评审。
- 定稿后的需求文档将引领整个公司不断前行。
- 通常需要比开发提前1-3个月来安排设计。
- 3. 版本不断迭代进化
- 项目采用版本方式来迭代进化,例如2017.07.01 服务器端版本2.5.0版本上线后,就开启新一轮2.6.0版本的开发。
- 通常每个版本的进度如下:2周开发,1周测试周六上线B站,B站运行一周后上线A站,大致一个月一个版本。
- 遇到遗留BUG很多的情况下,会安排一个版本专门来清理BUG,这种版本通常整体不超过2周。
- 4. 项目需求/任务评审机制
- 每个模块最重要的两次评审:需求评审+接口评审
- 4.1 需求评审
- 开发+UI+产品经理+测试
- 4.2 接口评审
- 开发+产品经理
- 5. 白天项目/晚上BUG开发二重奏
- 一方面,项目必须不断前行,开发新的功能,开发与老牌进销存厂家(思锐、怀远等)差异化的功能来满足用户不断增长的新需求。
- 另外一方面,源源不断的用户问题类与需求类BUG也需要不断解决。
- 为此,基于之前的经验,我们采用白天做项目,晚上解BUG这样两不耽误,两个都快速前行的开发二重奏!
-
- 谨记:我们再做5年在进销存方面也无法超越有13年经验的思锐!
- 但稳固能够满足绝大多数用户的进销存是我们拓展其他业务的前提!
- 6. 版本阿里云B站上线倒计时通知
- 在B站上线的那一周,从周一开始就要
- "2.X.0版本B站上线倒计时7天",
- "2.X.0版本B站上线倒计时6天",
- "2.X.0版本B站上线倒计时5天",...
- 这样,每一天及时发布遗留BUG和项目进展进度, 督促大家在上线前及时处理掉相关问题,确保项目进度正常。
- 7. BUG上线测试确认流程
- 对比较严重的BUG采用分开测试:
- (1) 苏立平先内部测试。
- (2) 典型场景最小集合测试:
- 使用100059家的大量产品、库存来实际测试,做一个XS与CG单据导入200条产品来创建单据,保存单据、出库/入库、打印、结算,审核一整套流程。
- 每一个步骤都必须要流畅,如果超过2秒以上,就说明出现了严重的性能问题,需要解决完成后才可以上线。
- (3) 最小集合测试通过后,由张思宇上线到B站,然后雅靖来测试确认;
- (4) B站上线后可能暴露出多个问题,问题解决3天之后再上线到A站。
- 这样可以将问题的风险降到最低。
- 8. 上线升级时间强制要求
- 2018-01-11上午有7分钟左右无法上线: 可能是合并代码出错。
- 以后白天不论再怎么样紧急,用户问题白天不再升级,只能在晚上23:00之后升级。
|