Changes between Initial Version and Version 1 of workflow


Ignore:
Timestamp:
09/25/2012 12:19:03 PM (14 years ago)
Author:
dingjianyong
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • workflow

    v1 v1  
     1== '''BBS项目中开发流程与测试上线流程的规范总结''' == 
     2 
     3= 1.开发流程规范总结 = 
     4 
     5* 需求的统一与检测[[BR]] 
     6    需求会议后,把需求列表放置上SVN上,在开发的过程中,开发人员需要对照需求列表,务必在实现功能的同时考虑此功能模块对应的所有需求点。[[BR]] 
     7    在功能实现的过程中,对应每一个需求点与用户方作出详细确认,如需修改需求列表的,修改后同步到SVN上,确保大家都能在SVN上拿到最新的需求列表。[[BR]] 
     8 
     9* 开发环境的连通[[BR]] 
     10    开发环境与其他系统有交互的,需求在开发的过程中确保与其他系统连通,并进行测试。[[BR]] 
     11 
     12* 新模块的开发[[BR]] 
     13    在做新模块新功能时,前期的讨论、准备和模块设计的时间充裕一些,把问题考虑周全,定出合理的模块实现方案。[[BR]] 
     14    在新模块的实现后,需要大家对新模块进行代码审核,让组员熟悉新模块的代码结构和实现方式,期间还可以提出优化方案,以便日后维护。[[BR]] 
     15 
     16* 代码规范[[BR]] 
     17    对于新接口和特殊逻辑的代码接口,必须加上注释。[[BR]] 
     18    避免在代码上或者页面上出现硬编码(如forumId=19)的方式,应该采取静态常量来表示。[[BR]] 
     19 
     20* 代码管理[[BR]] 
     21    对线上问题进行修复后,应该把主干上的代码及时合并到开发的分支上。[[BR]] 
     22    在开发提交SVN中,开发人员要写清楚提交代码对应的功能点或者对应修复的Bug ID。[[BR]] 
     23 
     24* 功能测试[[BR]] 
     25    对于多人合作完成的功能模块,应该有人负责整合这个功能,并对其进行测试。[[BR]] 
     26    开发人员对于自己实现的功能,在实现完成后必须对照需求列表进行自测。[[BR]] 
     27    开发人员之间可以根据需求列表进行交叉测试,保证模块功能的质量。[[BR]] 
     28 
     29* 项目时间管理[[BR]] 
     30    注重时间管理,提高对时间的敏感度,尽能力保证在承诺的时间内交付产品。[[BR]] 
     31    如果存在延迟的可能,应该及时地、尽早地提出,共同讨论原因,调动资源,重新确定解决方案。[[BR]] 
     32 
     33* 项目效率管理[[BR]] 
     34    注重工作过程中的效率,当用户方、测试方提出紧急问题时,应及时到第一现场,用最有效的沟通方式观察问题和解决问题。[[BR]] 
     35 
     36 
     37= 2.测试和上线流程规范总结 = 
     38 
     39* 测试包的更新[[BR]] 
     40    测试更新包应该由专门的开发人员统一负责打包并提交给测试人员。[[BR]] 
     41    考虑使用Hudson和脚本自动打包,由测试人员自己从SVN上拿到打好的测试包,更新到服务器。[[BR]] 
     42 
     43* 用户验收会议[[BR]] 
     44    在测试完成后,应该举行用户验收会议,让用户确认功能的完成。[[BR]] 
     45 
     46* 上线包的测试[[BR]] 
     47    使用上线包进行回归测试时,测试人员应该先把测试机上原来的代码全部清空,再使用上线包进行测试。[[BR]] 
     48    在测试人员进行回归测试的同时,开发人员也应该在测试环境上对本Sprint自己所做的功能进行检查。[[BR]] 
     49 
     50* 上线风险管理[[BR]] 
     51    定期进行对线上环境的检查,保证线上环境的正确性和可靠性。[[BR]] 
     52    以后对于项目上线都选择网上用户数量较少的时间(如早上),控制项目对用户影响的风险。[[BR]] 
     53    对上线的影响的风险进行评估,上线后优先检查重要模块和有风险的模块。[[BR]] 
     54    对于新功能新插件,上线时我们可以先屏蔽入口,待上线后详细检查功能后,再对用户开放入口。[[BR]] 
     55 
     56 
     57 
     58   
     59 
     60 
     61