由于该项目使用新的技术框架开发，为更为准确的收集信息，分别采样了两个模块，一个是初次开发需熟悉开发框架的模块，另外一个是已基本熟悉使用技术框架二次开发的模块。
统计信息如下表所示：
（见http://space.itpub.net/6906/spacelist-image）
表-1 信息统计表
从上表的数据可以看出，一个由高级程序、中级程序员、初中级程序员和初级程序员组成的4人开发团队，每人开发2个模块，在首次开发的开发效率约为40小时/模块，二次开发的开发效率约为32小时/模块，也就是说每个模块需耗费4-5天左右，效率较低。
下面从环境搭建和熟悉技术框架、熟悉业务需求和设计、编码、返工和等待等阶段分别说明开发过程中出现的问题。
1. 工程比较快搭建好了，但辅助类的配置（如菜单、按钮等）初始化花了较长时间；
2. 熟悉整个开发流程比较快，但是实际开发过程中因为框架的一些弊端影响效率：
a) 程序报错，被框架catch掉，无法知道错误在哪，无法Debug到程序中；
b) 框架没有完善的api，比如使用一些已经集成的功能只能靠猜。比如后台填充到前台的数据，使用list数据集填充不了，就猜测是不是要用map；
3. 没有在该框架上开发过，只能仿造其他人的做法和一边做一边问或者自己一点一点的去猜；
1. 文档太简单，没有界面、没有说明，只有界面原型，相关的数据库表亦不清楚；没有文档，只能根据原型和设计人员的口头描述来理解设计；
1. 调用存储过程不停的出错，由于存储过程不是由本人自己编写，沟通存在问题，在很多地方浪费时间，比如结果不正确，但是过程没报错，执行成功等等。诸如此类的问题影响判断和思路。
1. 业务问题：原型设计有问题，比如复核页面本应跟经办差不多，风格却完全不同，导致返工；
2. 技术问题：
a) 业务逻辑通过存储过程还是Java实现、是否采用工作流等技术问题在开发时才确定；
b) 调试的时候缓存的存在给调试带来麻烦，并且开始没有认识到；
3. 版本发布问题：由于时间比较仓促，单元测试较少，很多bug来不及修复，多半在系统发布测试时才来得及修复；单元测试是开发人员手工构造的数据，很多中文代码字段没有准确写入，导致部分页面的bug；
4. 需求管理问题：
a) 业务需求开始不太明确，变更较大，返工较多；
b) 初期需求未定好，设计文档也不完善，从最开始理解的两个界面改变到后来的四个界面；
5. 项目管理问题：
a) 任务目标不清：如任务分派时是A模块，以为打印也是A模块，后来才发现打印要做的是B模块的打印；
b) 沟通交流不充分：由于是分模块做，以为是各人完成自己的模块，所以取数逻辑是按A来做，报表样式也是按A来做，后来改为打印B模块，导致返工较多；
1. 等待系统分析员解释业务；
2. 基础开发平台启动不了，开发一直在等待；
3. 在遇到问题问其他人的时候，其他人由于也有要做的模块，不能即时回复，影响进度；
1. 优化和完善安装脚本。后台sql脚本应该进一步完善，和智能化，不应该让用户自个去创建用户然后再运行相应的脚本，可以考虑直接进入一个dba用户直接运行一个脚本，简单方便；
2. 充分调动成员积极性。大家互相帮助，团结奋进，做事负责任，严格控制自己的进度，如负责的模块是别人工作的基础，能尽量加快进度，不要影响到其他同事的进度；
3. 分工明确。比如做维护的就做维护，规范化一点，不要东做一点西做一点，等修改完那边程序回来后发现理清的思路忘记了，又得从头来，浪费时间；
1. 编写设计文档。设计文档还是需要有，特别是要说明数据表有哪些，业务较难复杂或难理解的地方，要说明设计思路；
2. 完善和确认界面原型。原型设计要尽量做到准确，否则，会导致一定的返工量；
3. 加强沟通和交流。希望能加强开发人员和设计人员的联系，就算时间紧，开发人员也应该再交流清楚，使自己的思路也得到设计人员肯定后再做，也希望设计人员将思路考虑充分，双方共同来避免快做才完发现不对需要大规模返工的情况出现。
1. 重构架构。将后台管理和系统框架分离，至少要分离在不同的模块中；
2. 框架开发人员合理分工。对于框架、公共部分的开发人员，在项目开发中能不能将其任务分配的稍微少一点，或者更灵活的对待这类开发人员的任务，以方便其对项目中的特殊需求优先进行框架的优化修改，从而提高其他同时的开发效率。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-626102/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/6906/viewspace-626102/
762
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
