“FreeNeb product reiteration process”版本间的差异

来自cslt Wiki
跳转至: 导航搜索
(以“==关于产品版本迭代更新的指导原则== 1. 由CTO确定产品项目的设立,指定攻关小组长,总体目标和时间点。小组长选择优秀组...”为内容创建页面)
 
第1行: 第1行:
 
==关于产品版本迭代更新的指导原则==
 
==关于产品版本迭代更新的指导原则==
 
+
<pre>
 
1. 由CTO确定产品项目的设立,指定攻关小组长,总体目标和时间点。小组长选择优秀组员参与项目,设计具体目标和时间节点。
 
1. 由CTO确定产品项目的设立,指定攻关小组长,总体目标和时间点。小组长选择优秀组员参与项目,设计具体目标和时间节点。
 
2. 小组长对项目进度全面负责,组织人力,总结进度,提示风险。
 
2. 小组长对项目进度全面负责,组织人力,总结进度,提示风险。
第14行: 第14行:
 
6. 每个版本发布以后,该版本将被deliver给项目组,由项目组负责掌握、集成测试和客户支持。同时,项目组反馈问题,为下一版本迭代提供基础。
 
6. 每个版本发布以后,该版本将被deliver给项目组,由项目组负责掌握、集成测试和客户支持。同时,项目组反馈问题,为下一版本迭代提供基础。
 
7. 内部版本一般不直接部署给客户,除非fatal bug,此时应在稳定版本基础上给临时patch,待下一个稳定版本后再统一迭代。
 
7. 内部版本一般不直接部署给客户,除非fatal bug,此时应在稳定版本基础上给临时patch,待下一个稳定版本后再统一迭代。
 +
 +
</pre>

2019年5月24日 (五) 01:13的版本

关于产品版本迭代更新的指导原则

1. 由CTO确定产品项目的设立,指定攻关小组长,总体目标和时间点。小组长选择优秀组员参与项目,设计具体目标和时间节点。
2. 小组长对项目进度全面负责,组织人力,总结进度,提示风险。
3. 每个版本的迭代应从design spec开始,到Release NOTE结束。Design spec着重说明目标、预期方案、风险提示,Release NOTE着重说明安装与重现方法,与上一版本的主要改动,已知问题提示。
4. Release是最重要的一步,check list如下:
(1)bugdb中相应的bug是否都解决完成,或取得CTO的同意,流转到新版本
(2)Test是否完成完整的Test报告
(3)是否完成Design Spec的更新
(4)是否完成Release NOTE
(5)是否完成合理归档和github tag
(5)是否完成wiki log
5. 版本1.0属基础版本,保证基础功能;1.x版本为改进型版本,主要功能为fix bug,补全文档,清洁代码。
6. 每个版本发布以后,该版本将被deliver给项目组,由项目组负责掌握、集成测试和客户支持。同时,项目组反馈问题,为下一版本迭代提供基础。
7. 内部版本一般不直接部署给客户,除非fatal bug,此时应在稳定版本基础上给临时patch,待下一个稳定版本后再统一迭代。