进步的起点

 

上篇《公司产品开发中遇到的一些问题？ 》对于工作的一些牢骚做了一些叙述，最近又认真思考了一番，觉得以目前我们公司的这种情况怎么实时求实的工作，使有所进步，改变的入口点在哪里？而不是好高骛远，一下子让公司的开发达到国际水准，太不现实了！

 

存在主要问题：

1.各种各样版本太多，没一个能完整的把整个流程跑通，拿不出一个演示版本？

2.代码混乱导致整合困难，需要增加一个公共功能时，发现有好几个版本的代码需要修改？

3.发布程序不稳定，经常是解决了某个bug却产生了其他的未知bug？

4.需求满天飞，都是各个模块开发人员自己获取自己的？

5.程序升级麻烦，开发员自己发自己程序出去，经常出现升级失败？

。。。

 

最近几天天气真的寒冷，坐在电脑前一天下来，脚冰凉的！刚好今天终于重见天日，呵呵~~ 中午出来透透气，在操场上晒太阳。看到清洁阿姨正在清扫操场的垃圾，她总是先把一块地方的垃圾扫到一起，再把另一块地方的垃圾扫在一起，形成一个个垃圾点，再用簸箕一个个移走就完了！为什么她不是把所有垃圾扫成一个点，再一次性移走不就行了吗？好像我们现在做的项目就是这样做的，一群人集中在一起的目标就是完成这个项目，是不是应该好好的想一下做项目的方法了！其实要说这些方法多得是，各种牛人、大机构都在吹嘘自己的某某管理方法是多么的科学，多么的跨先进，但你在操场开来一台垃圾清洁车，用吸尘器来打扫，觉得可能吗？所以我们需要自己动脑，分析这些问题来选择适合自己的方法，而不是生搬硬套某某开发过程。

解决问题的

第一步：

分配一个配置人员，把代码管理起来。所有开发人员需要修改代码，都要通过他的手，然后他再每天从开发员获取最新代码。由于开发员修改代码后，肯定会产生分支，所以每个月所以开发员一起做一次分支整合工作。配置员可以把从开发员收集到的代码用SVN管理起来，做一些持续集成等，就可以随时拿出一个版本进行演示。

现在我们已经解决了代码混乱与拿出一个版本，接着解决程序的稳定性！

第二步：

分配一些测试人员，对程序做系统的测试，目前主要集中在操作细节和异支流程上进行严格测试，建议使用bugfree做为bug管理工具，测试人员要达到程序在实施人员与客户手里的时候还出现低级错误，像点开一个菜单界面报“未将对象引用到实列”这种经典的错误！如果单个开发人员在现场开发的话，那实施人员就要成为主要的测试人员。

现在我们已经解决了程序的稳定性，但需求漫天飞的情况不改善的话，测试人员再多的话程序也难以稳定吧！还有现场测试的bug资料也都没有人管理，所以接下来解决需求与bug的问题。

第三步：

分配一个文档管理人员，所有实施人员从客户收集到的需求，都已标准格式提交到文档管理人员，再由他整理分类，过滤相同的需求，最后转发给各自开发人员。bug的管理也是同样做法！

但这种做法对于现场开发员的话，这种做法明细就不够灵活，这样走一个过场浪费的就不是一点时间，所以由开发人员自己先过滤，自己能解决的需求就先不提交上去，而是等自己修改完成后再一起提交！而文档管理人员也会根据需求的状态走另一个流程，不需要把它当成任务再分配给其他开发！

由于需求变化，所以程序操作肯定有所更改，对应的操作手册等都要按时更新，文档管理员必须定时发布新的操作手册等。

第四步：

由于开发员修改某个BUG或需求后，并不是说把整个程序版本或数据库发给实施人员，而只是某个修改后的文件、脚本等，而开发和测试的环境与实施使用的环境不同，所以导致这些文件在升级后反而出现其它更严重的错误。

这时就需要配置人员对这些修改的功能做一个完整的升级包，对应的升级文件、脚本规好类，还有升级步骤，修改了哪些问题说明。特别是某些脚本的执行顺序，一定要正确。

 

期望经过这些调整，开发过程能够慢慢走上正轨吧！