wiki:workflow

Version 21 (modified by lifeng, 13 years ago) (diff)

--

论坛互动团队工作流程规范总结

前言

本流程规范由论坛互动组成员总结而成,在日后的工作中将根据项目开发流程的情况不断总结,更新此规范,务求提高开发的效率和项目的质量。

需求阶段

  • 开发、QA、用户一起讨论需求
  • 确定需求的边界和测试边界
  • 引导用户确认需求
  • 需求在sprint中不能变更
  • 需求的统一与检测

需求会议后,把需求列表放置上SVN上,在开发的过程中,开发人员需要对照需求列表,务必在实现功能的同时考虑此功能模块对应的所有需求点。
在功能实现的过程中,对应每一个需求点与用户方作出详细确认,如需修改需求列表的,修改后同步到SVN上,确保大家都能在SVN上拿到最新的需求列表。

设计阶段

  • 数据库和代码设计方案及时共享
  • 评估前要先想好自己的方案
  • 在脑海中自己过一遍实现方案
  • 不要过度设计
  • 使用UML统一描述功能【王安宁】

开发阶段

  • 遵循代码规范,确保代码可读性【待定】
  • 建立代码沟通和审查机制【丁健勇】
  • 重复的工作建立自动化脚本
  • 功能完成演示
  • 以前的bug分类总结
  • 每天思考占时最长和最短的需求
  • 建立应用相关的信息文档【待定】

自测阶段

  • 重视单元测试【待定】
  • 代码提交SVN前跑测试
  • 自动化回归测试【待定】
  • 送测前成果展示,并预留修改时间

QA测试阶段

  • 与QA一起搭建测试环境
  • 按照优先级修复bug,不能只看自己的bug
  • 仔细确认是否真正的是bug,合并重复的bug
  • 测试完后将bug进行分类总结

上线阶段

  • 严格按照上线计划执行
  • 更新包必须经过测试
  • 大版本要有预上线
  • 上线比告知用户的时间提前,预留充足的异常处理时间

报障处理

  • 固定时间处理报障,辨别优先级
  • 丰富线上故障查找信息
  • 提高报障处理效率(小工具、Q&A、用户接口人)

其他

  • 按优先级处理事情,有效利用时间做重要的事
  • 遇到问题多与有相关经验的同事交流
  • 休息好,保持积极心态
  • 不仅要把事情做完,更要做好
  • 避免被打扰,与经常沟通的同事约定要时间
  • 团队成员有统一的思想
  • 持续反馈结果,不管是好是坏,勇于面对现实
  • 加强组内沟通

1.开发流程规范总结

  • 开发环境的连通

开发环境与其他系统有交互的,需求在开发的过程中确保与其他系统连通,并进行测试。

  • 新模块的开发

在做新模块新功能时,前期的讨论、准备和模块设计的时间充裕一些,把问题考虑周全,定出合理的模块实现方案。
在新模块的实现后,需要大家对新模块进行代码审核,让组员熟悉新模块的代码结构和实现方式,期间还可以提出优化方案,以便日后维护。

  • 代码规范

对于新接口和特殊逻辑的代码接口,必须加上注释。
避免在代码上或者页面上出现硬编码(如forumId=19)的方式,应该采取静态常量来表示。

  • 代码管理

对线上问题进行修复后,应该把主干上的代码及时合并到开发的分支上。
在开发提交SVN中,开发人员要写清楚提交代码对应的功能点或者对应修复的Bug ID。

  • 功能测试

对于多人合作完成的功能模块,应该有人负责整合这个功能,并对其进行测试。
开发人员对于自己实现的功能,在实现完成后必须对照需求列表进行自测。
开发人员之间可以根据需求列表进行交叉测试,保证模块功能的质量。

  • 项目时间管理

注重时间管理,提高对时间的敏感度,尽能力保证在承诺的时间内交付产品。
如果存在延迟的可能,应该及时地、尽早地提出,共同讨论原因,调动资源,重新确定解决方案。

  • 项目效率管理

注重工作过程中的效率,当用户方、测试方提出紧急问题时,应及时到第一现场,用最有效的沟通方式观察问题和解决问题。


2.测试和上线流程规范总结

  • 测试包的更新

测试更新包应该由专门的开发人员统一负责打包并提交给测试人员。
更新打包时需要对主干上的代码进行对比,看是否还存在没有从主干上合并到分支的代码,如果有的话,需要先从主干合并到分支上。
考虑使用Hudson和脚本自动打包,由测试人员自己从SVN上拿到打好的测试包,更新到服务器。

  • 用户验收会议

在测试完成后,应该举行用户验收会议,让用户确认功能的完成。

  • 回归测试

把测试包更新到测试环境的同时,需要列出本次更新有增加或者删除的jar包,配置文件,SQL语句,将来用于上线。
使用测试包进行回归测试时,测试人员应该先把测试机上原来的代码全部清空,再使用上线包进行测试。
把修改过的配置文件也打包在测试包上,测试人员与开发人员进行沟通,对比增加的内容并修改。
在测试人员进行回归测试的同时,开发人员也应该在测试环境上对本Sprint自己所做的功能进行检查。

  • 上线风险管理

定期进行对线上环境的检查,保证线上环境的正确性和可靠性。
以后对于项目上线都选择网上用户数量较少的时间(如早上),控制项目对用户影响的风险。
对于上线时需要运行的SQL语句,需要明确是在代码更新前运行还是代码更新后才运行,以免数据更新和代码更新的时间差内出血影响应用的状况。
对于新功能新插件,上线时我们可以先屏蔽入口,待上线后详细检查功能后,再对用户开放入口。