某店铺收银系统开发总结

 

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

 

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

 

 

l合作开发问题

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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