存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况,项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可"左"可"右"。"左"时按领导下达的"期限"进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。"右"时则项目工期无休止地延期。对我们软件工程来说,总的特点是先"左"后"右"。在领导面前表现"左",在用户面前表现"右"。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。
存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个"地主"，编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了"私有财产"，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免, 进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。 开发大量重复, 留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y 的研发支持下运转效益很好，但是三个月之前，开发人员 Y因为待遇问题和公司领导谈判失败，提出辞职。项目D仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助，因为没有文档记录，Y忙于新公司的工作也不能解决修改。
存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。但开发人员的一句名口号是:"叫我干什么都可以,但别叫我看别人的程序"。当然,开发人员的工作态度要转变,但客观上有一个很重要的原因是:前人留下的程序既无像样的文档(即使留下了文档 ,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。
存在问题五、测试工作不规范。仍然停留在"小姑娘做测试"的底水平上，传统的开发方式中,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走一走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。
存在问题六、虽然项目施工时间不长，但软件版本更新周期过短,几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。由于应用软件的特点,各个不同的施工点有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。
2.2 建立配置管理系统,规范项目管理流程，建立知识库的同时节约项目费用
针对以上问题, 利用自己在Beijing Precom Inc, 普天润汇等公司积累的经验，建立配置管理系统CVS, CVS 的全称是Current Version Control. CVS是一种GNU 软件包.由Intersolv公司开发，它明确的将源文件的存储和用户的工作空间独立开来, 并使其有利与并行开发.这个工具属于Open Source， ,CVS可以在int.net 上很方便的得到. 它的源码在ftp://202.113.29.4/pub1/unix/cvs 它的说明文档在ftp://202.113.29.4/doc/cvs.任何人可以很方便的下载.目前他的最新版本是2..10.8。 不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略,取得了很好的成效。
文章来源于领测软件测试网 https://www.ltesting.net/
