RAILS团队开发总结（三）

补充一些细节

1. 导师制度

   1） 导师， 主要是答疑， 指导方向性问题， 分析问题的培养等作用； 但导师仅仅指明方向， 具体的需要新人自己的学习。例如： 指明需要学习技术， 但是导师仅仅指明需要学习某技术， 具体的需要新人自己去查询学习。

   2） 在开发当中， 导师分析问题， 编写文档， 具体的code由新人编写， 新人code时， 导师考虑异常及研发测试CODE， 最后review新人的代码。

   3）  到了后期， 导师的工作仅仅是分析， REVIEW设计文档， 疑难问题答疑。 

    在公司中经常遇到这种问题， 就是导师经常在处理一些简单的问题， 造成导师的能力不能充分的利用，重复性的工作。 采用以上方式可以减缓这种事态， 两人都可以提高能力。 好像这种也是大多数公司采用的方式， 具体没有了解过其他的公司，不清楚。

2. 研发内测试机制

     因为采用了红蓝事件机制和测试版本打回机制， 所以研发提供的版本质量就得过关， 否则就会被处理。

     研发内部有专人负责功能测试， 针对主要流程的冒烟测试， 当然前提是研发在开发完毕后， 自己有完整的测试过，其实就是研发内部需要一个简单的集成测试， 保证整体流程的完整性。 曾经也实施过研发互测机制， 也会有一定的效果， 但是效果不是很明显， 可能实施的不是很好吧！！

3. 版本号规则

     公司内部制定了一套版本号的规范， 但是这里不太方便透露。 大概的意思就是在软件开发的每一个点上， 都有一个专门给的术语， 另外版本号的制定也有一定的规范， 比如：项目_xxx_xxx_xxx； 类似于这种，而且实施起来还不错。

4. 问题疑问

   1） 以上方法对于独立项目比较适用

         一个团队的成熟度是要有一定的制度的， 而且还要看作为团队的LEADER， 有没有想法想把团队打造成一个什么样子的团队； 也就是需要问Leader的一个问题：“你想要一个什么样子的团队？”， 但是对于具体的团队来说还是有区别， 有的团队比较稳定， 就可以采用以上的部分方法；有的团队在建设当中， 那么采用以上方法， 可能效果会更加明显一些。 而且方法也要看具体的实施情况， 没有最好的， 只有最适合的。

   2） 项目太紧的情况下实施

        在项目太紧的情况下如何实施， 这个也是国内大多数IT的通病， 就是每个项目时间都很紧， 搞得最后交付的质量大有问题， 而且后期基本上都在补丁， 照死里打补丁， 最后搞得都很郁闷， 而且后面的研发看到前面研发写的CODE， 真的是想破口大骂， 貌似这个是通病。离题了， 其实也不是说完全按照以上的方式处理， 具体的实施是要看项目的， 也可以去掉或者减弱某一个环节。 例如： 测试用例评审不用会议， 直接由测试找研发单独沟通等， 都是可以减弱某一个环节；具体的操作要看实施人员。