posts - 188,comments - 176,trackbacks - 0

    项目接近尾声,需求也逐渐收敛。面对需求变化频繁、迭代版本周期较短的客观情况,传统模式已不能在此生搬硬套。虽现有的开发过程谈不上正规敏捷,也算接近小步快跑的节奏。下面分‘需求开发&代码开发、版本控制、版本发布、增量升级’几个部分,记录一些体会,欢迎指正:
  (1)需求沟通&代码开发:
        1、针对有可以复用的现有模块时,和开发人员沟通主体思路,由开发人员着手开发,开发人员在开发期间与需求人员充分沟通,碰到疑问及时澄清、解决。
        2、针对没有可复用的模块且涉及较复杂的业务流程时,需求人员画原型图(紧急情况手绘草画),开发人员按原型图或草图着手开发。
        3、需求人员记录开发过程中和开发人员、客户沟通的需求变化点。
        4、功能开发完成、客户验收后,及时补充到《需求规格说明书》。
  (2)版本控制:
        1、代码提交前做比较再合入版本库(严禁合入非自己修改的文件)。
        2、合入代码需填写修改信息,新版本开发只填写修改信息,优化修改还需在BUG管理系统自提单,以做BUG管理。
        3、在试商用、商用环境上升级,必须由升级接口人闸口执行并得到负责人同意。非特殊情况,严禁开发人员在试商用、商用环境上自行修改代码(修改后要到开发环境上做代码同步提交)。
  (3)版本发布:
        1、需求人员输出《需求规格说明书》,用于研发指导、市场支持。
        2、测试人员做全量回归测试,输出《测试用例》、《测试报告》,用于测试维护、说明测试结论。
        3、开发组长将正式版本打包、封存。输出《版本安装手册》,用于版本安装过程的指导。
        4、需求、测试人员整理《数据配置手册》,用于版本安装的初始化配置。  
  (4)增量升级:
        1、升级列表:需求人员牵头、测试人员参与,整理本轮版本升级的功能列表(含新功能、上一轮的遗留问题)。
        2、代码提交(本地开发环境):开发组长约定当天所有开发人员提交代码的时间点。
        3、升级包制作(本地测试环境):当天所有代码提交SVN后,升级包制作人(开发组长或测试组长)制作升级包T01。
         制作说明:
             1.升级前关注开发过程中模块的关联影响,如:表结构变动涉及第三方工具的代码调整,表结构变动涉及平台内关联模块的代码调整。 
             2.升级前,开发人员提交代码的时间必须由开发组长统一安排,如:什么时间点之前必须完成代码提交并给组长回执确认、哪些代码还没开发完此轮版本不做提交,避免测试人员制作升级包后,开发人员又要提交代码、导致测试人员又要重新制作升级包。
             3.集成开发环境中记录代码的提交时间,测试人员用文件比较工具按照时间段(如早上8:00~下午18:00)将有变动的代码文件搜索出来,形成此轮的升级文件。
             4.数据库客户端开发工具,针对测试库和开发库进行数据库脚本(表结构、视图、存储过程、触发器等)比较、自动生成升级脚本。
             5.将升级文件、升级脚本打包成增量升级包,在本地测试环境(连接远程数据库)上做升级包验证。
        4、升级包验证(本地测试环境):测试人员将升级包T01在本地测试环境做部署、测试,迭代3轮(发现的问题知悉开发人员修改代码重新提交、测试人员重新从SVN上取代码制作升级包在本地测试环境验证),发布升级包。
        5、升级包部署(远程试商用环境):将发布的升级包部署到试商用环境。
        6、升级包验证(远程试商用环境):需求人员牵头、测试人员参与,在试商用环境做结对测试(发现的问题知悉开发人员修改代码重新提交、测试人员重新从SVN上取代码制作升级包在本地测试环境验证)。
        7、升级包部署(远程商用环境):试商用环境升级、验证通过后,同步升级到商用环境。
        8、升级包验证(远程商用环境):需求人员牵头、测试人员参与,在商用环境做结对测试。

posted on 2013-12-27 20:47 cheng 阅读(1216) 评论(0)  编辑  收藏 所属分类: 通信&政企产品

只有注册用户登录后才能发表评论。


网站导航: