某店铺收银系统开发总结

 

我们的某店铺收银系统(包括前台pos机销售应用、后台信息管理)已经基本结束了,最近大家都忙专业考试,不得已将开发工作搁置了一段时间,现在基本上闲下来了,就剩下系统部署、发布,进行最后测试了。

 

这次合作开发实练,我忝为组长,感触颇多,说实话,现场有点混乱。

 

 

l合作开发问题

 

多人合作开发,是鉴于五期两个师哥苦苦做了78个月的ERP项目的失败而从我们六期开始进行的一个新举措,也算是一种公司项目研发的仿真。

 

  说来,这次某店铺收银系统的合作开发是我们接触合作开发以来的第三次,针对合作开发这块儿我们没有成熟的经验指导,暂时也只是摸索阶段。

 

  摸索,在摸索中磕磕绊绊,错误屡犯。

 

  现在我们的合作开发模型,就是由组长管理负责整体业务理解、拿大主意,组员主要进行编码、测试。

 

  我是第一次作为组长投入到合作开发过程中的,管理经验、模块分配、进度规划等等都为零。第一次合作开发机房收费系统的时候,我处理界面层,那时候感觉自己责任单一化,需要考虑的就是如何把自己这层做的更完善,更优秀,其他的一概不管,这样或许就是一个优秀的程序员的特点吧。

 

  但是这次的收银系统,由我来“主刀”一组的开发工作。上两次的开发经验(开发过程中的注意事项、准备工作等)都是通过口头传承过来的,精简为进度规划、模块分配、各模块编码规范说明、模型改动记录。

 

  与之前的合作开发经历不同的是,这次的需求有好多不定因素在里面,直接从坤哥那里拿到的就是设计好的模型和数据库,还有就是不太确定的需求。

 

这样对组长的要求更加严格一点,而我做的不好。

 

1、在此系统开发的十多天时间里,我倒也忙忙碌碌地像个小蜜蜂,基本上没怎么参与到编码过程中,而是跑来跑去确定需求,理解需求,改动模型。

 

2、没有直接和客户获取需求信息,从而导致有些需求信息延迟。

 

3、部分组员对需求理解不到位(这是很严重的问题,虽说每人负责好自己模块即可,然而负责重要模块的成员的却没有全面理解需求,从而导致一部分代码返工,同样出现亡羊补牢的问题。)、盲目性(主要是体现在一些需求理解问题的实现上,缺少主见,某种程度上也是缺少自信的表现)比较严重。

 

4、对相关管理经验了解过少。

 

你可能感兴趣的:(工作,数据库,测试)