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

前言

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

敏捷宣言及原则

宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个体和互动 高于 流程和工具
  
• 工作的软件 高于 详尽的文档
  
• 客户合作 高于 合同谈判
  
• 响应变化 高于 遵循计划
  
  也就是说，尽管右项有其价值，我们更重视左项的价值。

原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

需求阶段

• 开发、QA、用户一起讨论需求

• 确定需求的边界和测试边界

• 引导用户确认需求

• 需求在sprint中不能变更

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

设计阶段

• 数据库和代码设计方案及时共享

• 评估前要先想好自己的方案

• 在脑海中自己过一遍实现方案

• 不要过度设计

• 使用UML统一描述功能【李剑文】

开发阶段

• 遵循代码规范，确保代码可读性【秦鸿源】

• 建立代码沟通和审查机制【丁健勇】

• 重复的工作建立自动化脚本

• 功能完成演示

• 以前的bug分类总结

• 每天思考占时最长和最短的需求

• 建立应用相关的信息文档【待定】

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

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

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

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

自测阶段

• 重视单元测试【待定】

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

• 代码提交SVN前跑测试

• 自动化回归测试【陈阳】

• 送测前成果展示，并预留修改时间

QA测试阶段

• 与QA一起搭建测试环境

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

• 按照优先级修复bug，不能只看自己的bug

• 仔细确认是否真正的是bug，合并重复的bug

• 测试完后将bug进行分类总结

• 用户验收会议
  在大版本测试完成后，应该举行用户验收会议，让用户确认功能的完成。
  

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

上线阶段

• 严格按照上线计划执行

• 更新包必须经过测试

• 大版本要有预上线

• 上线比告知用户的时间提前，预留充足的异常处理时间

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

报障处理

• 固定时间处理报障，辨别优先级

• 丰富线上故障查找信息

• 提高报障处理效率（小工具、Q&A、用户接口人）

其他

• 按优先级处理事情，有效利用时间做重要的事

• 遇到问题多与有相关经验的同事交流

• 休息好，保持积极心态

• 不仅要把事情做完，更要做好

• 避免被打扰，与经常沟通的同事约定要时间

• 团队成员有统一的思想

• 持续反馈结果，不管是好是坏，勇于面对现实

• 加强组内沟通

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

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