rails团队开发总结(二)

1. 红蓝事件机制

    红事件：无法按计划完成规定开发； 开发的功能存在严重问题造成版本打回。

    蓝事件： 新技术引进并对团队发展有利； 优化现有代码； 快速处理紧急疑难问题。

2. 版本打回机制

    1）研发对测试发布版本之后， 测试进行冒烟测试， 如果发现版本按照给定的RELEASENOTE部署， 但是部署之后不能运行， 则可以直接打回到研发；

    2）版本部署运行没有问题， 但是功能存在严重问题， 影响主流程， 测试可以直接打回。

    根据经验， 刚刚开始实行时， 版本打回的次数大于5次， 后期实行一定时间后， 次数可以控制在3次以内， 这样发到现场的版本基本可以保障。

3. 需求确认会议

    1） 会议提前一天通知， 并将相关文档给出；

    2） 会中对文档的功能进行讲解， 相关人员就有关功能进行讨论确认， 建议全部研发参与， 有助于新人的学习；

    3） 得出问题列表， 前方人员与甲方沟通确认；

    该会议必须， 因为经常出现甲方说：”这个不是我想要的东西“;  

    两点作用： 

          1） 培养新人分析讨论能力

          2） 需求理解保证甲方， 前方人员， 研发人员， 现场人员， 测试人员理解一致

4. 研发设计文档评审会议

    1） 会议提前一天通知， 并将相关文档给出；

    2） 研发对功能进行设计思路讲解， 测试以此为依据进行进行测试用例；

    3） 前方人员确认功能理解正确。

    两点作用： 

          1） 培养新人设计能力

          2） 需求理解保证前方人员， 研发人员， 现场人员， 测试人员理解一致       

5. 测试用例评审会议

    1）会议提前一天通知， 并将相关文档给出；如果时间紧急， 可以邮件通知研发进行REVIEW, 并提出疑问通知测试答疑即可。

    2）测试对测试用例讲解， 研发确认测试用例；

    两点作用： 

          1） 研发站在测试的角度思考问题， 测试站在甲方的角度思考问题

          2） 需求理解保证研发人员， 测试人员理解一致       

6. 现场SI参与机制

     1）现场SI负责收集功能， 对功能有整体理解；

     2） 有助于现场SI提高分析能力；

7. 责任制

    各阶段责任到人， 问题卡在什么地方， 由红蓝事件记录。

8. 定期代码REVIEW机制

    定期REVIEW代码， 有助提高整体CODE能力

9. 例会机制

   1） 日例会

ａ． 研发提供开发进度

ｂ． 疑难问题处理

   2） 周例会

ａ． 本周工作汇报汇总

ｂ． 下周计划

ｃ． 代码ＲＥＶＩＥＷ

ｄ． 技术学习共享