Changes between Version 21 and Version 22 of workflow

Timestamp:

09/17/2013 05:53:07 PM (13 years ago)

Author:

lifeng

Comment:

--

workflow

@@ -46 +46 @@
 - 建立应用相关的信息文档【待定】
 
+- 新模块的开发[[BR]]
+  在做新模块新功能时，前期的讨论、准备和模块设计的时间充裕一些，把问题考虑周全，定出合理的模块实现方案。[[BR]]
+  在新模块的实现后，需要大家对新模块进行代码审核，让组员熟悉新模块的代码结构和实现方式，期间还可以提出优化方案，以便日后维护。[[BR]]
+
+- 代码规范[[BR]]
+    对于新接口和特殊逻辑的代码接口，必须加上注释。[[BR]]
+    避免在代码上或者页面上出现硬编码（如forumId=19）的方式，应该采取静态常量来表示。[[BR]]
+
+- 代码管理[[BR]]
+    对线上问题进行修复后，应该把主干上的代码及时合并到开发的分支上。[[BR]]
+    在开发提交SVN中，开发人员要写清楚提交代码对应的功能点或者对应修复的Bug ID。[[BR]]
+
+- 功能测试[[BR]]
+    对于多人合作完成的功能模块，应该有人负责整合这个功能，并对其进行测试。[[BR]]
+    开发人员对于自己实现的功能，在实现完成后必须对照需求列表进行自测。[[BR]]
+    开发人员之间可以根据需求列表进行交叉测试，保证模块功能的质量。[[BR]]
+
 = 自测阶段 =
 
 - 重视单元测试【待定】
+
+- 开发环境与其他系统有交互的，需求在开发的过程中确保与其他系统连通，并进行测试
 
 - 代码提交SVN前跑测试
@@ -60 +79 @@
 - 与QA一起搭建测试环境
 
+- 测试包的更新[[BR]]
+    测试更新包应该由专门的开发人员统一负责打包并提交给测试人员。[[BR]]
+    更新打包时需要对主干上的代码进行对比，看是否还存在没有从主干上合并到分支的代码，如果有的话，需要先从主干合并到分支上。[[BR]]
+    考虑使用Hudson和脚本自动打包，由测试人员自己从SVN上拿到打好的测试包，更新到服务器。[[BR]]
+
 - 按照优先级修复bug，不能只看自己的bug
 
@@ -65 +89 @@
 
 - 测试完后将bug进行分类总结
+
+- 用户验收会议[[BR]]
+    在大版本测试完成后，应该举行用户验收会议，让用户确认功能的完成。[[BR]]
+
+- 回归测试[[BR]]
+    把测试包更新到测试环境的同时，需要列出本次更新有增加或者删除的jar包，配置文件，SQL语句，将来用于上线。[[BR]]
+    使用测试包进行回归测试时，测试人员应该先把测试机上原来的代码全部清空，再使用上线包进行测试。[[BR]]
+    把修改过的配置文件也打包在测试包上，测试人员与开发人员进行沟通，对比增加的内容并修改。[[BR]]
+    在测试人员进行回归测试的同时，开发人员也应该在测试环境上对本Sprint自己所做的功能进行检查。[[BR]]
 
 = 上线阶段 =
@@ -76 +109 @@
 - 上线比告知用户的时间提前，预留充足的异常处理时间
 
+- 上线风险管理[[BR]]
+    定期进行对线上环境的检查，保证线上环境的正确性和可靠性。[[BR]]
+    以后对于项目上线都选择网上用户数量较少的时间（如早上），控制项目对用户影响的风险。[[BR]]
+    对于上线时需要运行的SQL语句，需要明确是在代码更新前运行还是代码更新后才运行，以免数据更新和代码更新的时间差内出血影响应用的状况。[[BR]]
+    对于新功能新插件，上线时我们可以先屏蔽入口，待上线后详细检查功能后，再对用户开放入口。[[BR]]
+
 = 报障处理 =
 
@@ -83 +122 @@
 
 - 提高报障处理效率（小工具、Q&A、用户接口人）
+
+
 
 = 其他 =
@@ -102 +143 @@
 - 加强组内沟通 
 
-
-= 1.开发流程规范总结 =
-
-
-- 开发环境的连通[[BR]]
-    开发环境与其他系统有交互的，需求在开发的过程中确保与其他系统连通，并进行测试。[[BR]]
-
-- 新模块的开发[[BR]]
-    在做新模块新功能时，前期的讨论、准备和模块设计的时间充裕一些，把问题考虑周全，定出合理的模块实现方案。[[BR]]
-    在新模块的实现后，需要大家对新模块进行代码审核，让组员熟悉新模块的代码结构和实现方式，期间还可以提出优化方案，以便日后维护。[[BR]]
-
-- 代码规范[[BR]]
-    对于新接口和特殊逻辑的代码接口，必须加上注释。[[BR]]
-    避免在代码上或者页面上出现硬编码（如forumId=19）的方式，应该采取静态常量来表示。[[BR]]
-
-- 代码管理[[BR]]
-    对线上问题进行修复后，应该把主干上的代码及时合并到开发的分支上。[[BR]]
-    在开发提交SVN中，开发人员要写清楚提交代码对应的功能点或者对应修复的Bug ID。[[BR]]
-
-- 功能测试[[BR]]
-    对于多人合作完成的功能模块，应该有人负责整合这个功能，并对其进行测试。[[BR]]
-    开发人员对于自己实现的功能，在实现完成后必须对照需求列表进行自测。[[BR]]
-    开发人员之间可以根据需求列表进行交叉测试，保证模块功能的质量。[[BR]]
-
 - 项目时间管理[[BR]]
     注重时间管理，提高对时间的敏感度，尽能力保证在承诺的时间内交付产品。[[BR]]
@@ -132 +149 @@
 - 项目效率管理[[BR]]
     注重工作过程中的效率，当用户方、测试方提出紧急问题时，应及时到第一现场，用最有效的沟通方式观察问题和解决问题。[[BR]]
-
-[[BR]]
-
-= 2.测试和上线流程规范总结 =
-
-- 测试包的更新[[BR]]
-    测试更新包应该由专门的开发人员统一负责打包并提交给测试人员。[[BR]]
-    更新打包时需要对主干上的代码进行对比，看是否还存在没有从主干上合并到分支的代码，如果有的话，需要先从主干合并到分支上。[[BR]]
-    考虑使用Hudson和脚本自动打包，由测试人员自己从SVN上拿到打好的测试包，更新到服务器。[[BR]]
-
-- 用户验收会议[[BR]]
-    在测试完成后，应该举行用户验收会议，让用户确认功能的完成。[[BR]]
-
-- 回归测试[[BR]]
-    把测试包更新到测试环境的同时，需要列出本次更新有增加或者删除的jar包，配置文件，SQL语句，将来用于上线。[[BR]]
-    使用测试包进行回归测试时，测试人员应该先把测试机上原来的代码全部清空，再使用上线包进行测试。[[BR]]
-    把修改过的配置文件也打包在测试包上，测试人员与开发人员进行沟通，对比增加的内容并修改。[[BR]]
-    在测试人员进行回归测试的同时，开发人员也应该在测试环境上对本Sprint自己所做的功能进行检查。[[BR]]
-
-- 上线风险管理[[BR]]
-    定期进行对线上环境的检查，保证线上环境的正确性和可靠性。[[BR]]
-    以后对于项目上线都选择网上用户数量较少的时间（如早上），控制项目对用户影响的风险。[[BR]]
-    对于上线时需要运行的SQL语句，需要明确是在代码更新前运行还是代码更新后才运行，以免数据更新和代码更新的时间差内出血影响应用的状况。[[BR]]
-    对于新功能新插件，上线时我们可以先屏蔽入口，待上线后详细检查功能后，再对用户开放入口。[[BR]]
-
-
-
-  
-
-
-