项目接近尾声，需求也逐渐收敛。面对需求变化频繁、迭代版本周期较短的客观情况，传统模式已不能在此生搬硬套。虽现有的开发过程谈不上正规敏捷，也算接近小步快跑的节奏。下面分‘需求开发&代码开发、版本控制、版本发布、增量升级’几个部分，记录一些体会，欢迎指正：
  （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、升级包验证（远程商用环境）：需求人员牵头、测试人员参与，在商用环境做结对测试。