第3批定制需求开发中，教训总结

第3批定制需求，有几点做的不好，在此总结一下：

1、有几个需求，因为当时觉得比较简单，涉及面也比较小，所以就没有很在意。整个开发过程中，将主要的精力和时间投入到别的几个大需求里，对这几个小需求关注不够。

结果转测试过程中，这几个需求就出了比较多纰漏，甚至出现了阻塞业务的BUG。比较关注的大需求，反而没有出现问题

总结：

对整个开发过程进行跟踪管理的时候，需要对开发人员自身的素质（包括编码能力、责任心、细致等）有一个评估。对于自身素质比较高的开发人员负责的模块，可以相对放松一点；对于自身素质一般的开发人员负责的模块，应该要重点关注

开发人员自身的素质，只是考虑的一个方面。此外还要综合考虑模块的复杂性、重要程度等

无论需求是大是小，开发过程中都有可能引入新BUG，甚至会造成基本功能的阻塞。所以不能仅仅根据需求的大小，来确定是否投入主要的精力，要如上所说，综合考虑

2、制作升级包效果不好，转测试过程中发现了很多问题

排除代码变更多，时间紧的客观原因。主观原因是制作升级包的经验不足，以及平时对代码变更的跟踪不到位。这2者都缺失的时候，制作升级包就很难保证质量，关于制作升级包的总结，见另一篇博客http://kyfxbl.iteye.com/blog/1565159

3、负责环境的人员变更频繁，环境没有得到很好的保障

由于这个项目本身的一个特点：环境比较复杂，并且缺乏有效的集成部署手段。环境的部署主要依赖人工操作，所以对负责环境的人员就提出了比较高的要求。

而我们做这批需求的时候，临时替换了负责环境的人，因此整个过程中，对环境的保障就比较不到位。