团队软件开发管理

团队软件开发管理

摘自www.dbwin.com论坛中的发言

前几天在互联网上看到关于印度软件开发的一个连续报道(中国软件业的劣根性)，对印度和我国的软件行业进行了全方位的对比。作为专业软件开发人员，对我们目前团体软件开发的现状也有很多感触，于是就形成了这篇文章，以下是笔者的管见，文章内容仅代表个人观点，不适之处欢迎讨论，以此促进中国软件开发的发展。

一.开发队伍与龙虫问题有关吗？

看看目前团体软件开发的现状，大家自然想到一个中国人是条龙，三个中国人是条虫的说法，我认为大家只看到了软件开发人员的协作程度不够，而没有看到开发队伍的综合素质。可以指出的是，在中国现有的程序开发环境下，大家看到的只是程序员之间谁也不服谁，难道就没有人看到，因为这样一种情况，每个人的基础都很扎实吗？中国需要发展符合自己国情的东西，包括程序开发环境。在这样的环境下，我相信一定会有能够河纳百川的人物出现。

一个出色的中国人才是一条龙(仅从软件开发角度，指能单独开发出一个与众不同的软件产品)，而只有龙与龙合作才有可能不是条虫。毕竟优秀的软件开发人员是进行团体软件开发的基础，相信大家所处的软件开发团体的开发人员有良莠不齐的现象，结果软件的质量如何呢？不用问，很难达到预期的设计目标。开发人员除了有良好的技术素质以外，还要有团队精神，多为总体着想，有不同的想法及时和负责人或其他人沟通，尽量避免开发思想不统一，开发步调不一致。

印度直接照班西方的模式，从来没问为什么。这种方式确实在短时期内在商业利润上带来相当大的增长。除了这个以外，还有一些什么价值存在？印度因为发展晚，所以老老实实的先照办西方的方法，难道中国也要这样做吗？请看看日本，学习西方的新技术新科技，确实也发展的比西方好，但是日本有过自己的创新吗？没有！！！！

我觉得我们的（软件开发水平的）发展是不足，但是不要因为这个就先自卑起来了。和印度想比，我觉得我们的劣势是，大家的想法很多很杂乱，没有一个统一的规划。

我们的优势是，我们尝试了很多种不同的方法，就象是春秋战国时期，诸子百家。在统一了思想以后所爆发出来的力量是将会是无比强大的。中国国内好的优秀的管理人才有几个？软件开发水平低和程序员又有什么相关呢？

二.开发规范 无规矩不成方圆

软件开发要有软件开发的规范，目前的情况是，开发前大家信誓旦旦，要按照软件开发规范来做，实际开发过程中可能就有很多人开小差了，我行我素，置开发规范于不顾。开发规范包括文件对象的命名规范，菜单图片的大小，变量定义的规则，代码的书写风格，总之要使软件从外到内要有统一的风格，界面的一致性给用户的是感觉是你的软件上手快，让用户在不同的程序模块中适应不同的操作风格，恐怕他们要叫苦连天；而代码风格的一致性，则给项目组长或其他人员阅读修改方便，当然注释写的要尽量详细。这样，起码不会一个人员跳槽，此人负责的部分要重新写的尴尬局面。还有大家要注意软件和程序的区别，程序就是代码，可以运行并完成既定的功能，而软件还要有详细的文档说明。

程序员在这个方面缺乏自觉性，管理的水平方法也都不是很好。前面所说的开发规范其实是大家都应该知道的，我觉得问题出在对做这些事认识不足上，甚至有些公司上下都因为是软件公司而自觉高人一等，从来都没有从用户和公司本身发展的角度去考虑

三.开发工具  工欲善其事，必先利其器

　　关于开发工具的讨论经常见于各程序员论坛，结果针锋相对，争论不休，可见大家对开发工具的选择还是比较迷惘，我的个人观点是，其实语言只是实现特定功能的工具，选择哪种语言要根据实际需要和个人的熟练程度而定，并没有说哪种语言一定比另外一种语言好，正如，锤子就是比斧子好用，你听着是不是很荒唐。有人说“VB只是帮助你入门的，还是学VC吧”，这观点显然过于偏激。由于各种开发工具采用的数据库引擎不同，对某种数据库的存取效率也有差别，有时甚至比较明显，可以给大家举个这方面的一点经验，例如一个省的参加医疗保险人员的数据信息量很大，而且数据还要实时传输，应该算一个大型的MIS系统，我们选的是Sybase数据库，假设时间很紧。如果用VB做开发工具，可能性能会差一些，显然用PB做前台开发可以体现速度上的优势，而实时传输数据的部分可以用DELPHI来完成比较合适。做一些中小型的MIS系统呢，例如餐饮店的管理，采取VB,DELPHI等开发工具都是可以的，尤其是VB和DELPHI现在采用的ADO引擎，提高了数据库访问的速度，加上界面和其他功能上的优势，做MIS程序也越来越方便了。归根到底，预计模块对数据库的要求而定义出用什么语言最合适。

四.开发步骤

关于MIS软件开发的步骤我认为比较合理的是(其他团体开发软件的工程类似)：

1.初期业务调研

　　主要了解业务内容和业务流程，主要为做投标方案和无数据演示版软件打基础，这也是与开发产品软件不同的地方，产品软件往往仅实现特定功能，只需要很少的调研或根本不需要调研。

2.研究同类软件

　　毕竟个人的思路是有限的，要集思广益，可以相互讨论，但找一些同类软件来拓宽自己的开发思路是很重要的，当然，也不能局限于别人的软件的界面和思路，跳不出别人的圈子。

3.做投标方案和无数据演示版

　　因为很快可能要参与投标，不妨把参与投标比喻成招亲，你的演示界面好比人员的外包装，界面漂亮，人家对你的第一印象就好，相信大家做菜单和窗口这些界面是很内行的，可以加一些图片和小动画，给人以清爽的感觉，无疑，花点时间做软件的演示会给自己在竞争的实力上加个砝码，而你的标书相当于你的谈吐，是实力和能力的体现。

　　如果中标，无数据演示版软件还有另外一个作用，就是让一些领导视察提意见建议时给领导演示，因为是无数据演示，一般不会出现程序的错误。

4.详细业务调研

　　这不同于初期业务调研的是要和用户进行共同研究业务流程，写出需求分析说明，一方面让开发人员有个分析问题的过程，另一方面可以让用户确认需要那些功能，以免等开发出来后，用户说哪些功能应该有，怎么没有，到底用户当时有没有提出此要求，口说无凭，拿给他需求分析说明书看就行了。

5.总体设计

　　这当然是重中之重，直接关系到软件的开发周期，开发效率和开发质量，所以要多花些时间，最好大家一起参与，仁者见仁，智者见智，以防疏一漏百，到时候再改，大家肯定都有类似教训，总体设计做不好，结果数据结构重新调整时，大家很多汗水就白流了。行成统一的开发字典，人手一份，有改动时同时通知每个开发成员。另外要有一个尽量详细的开发计划，做到软件开发有条不紊的进行。确定开发工具，详细设计数据库，文档当然必不可少了。

6.系统开发

　　进行系统开发时，应该注意符合软件的开发规范，鉴于文档的重要性，写程序同时应该把帮助文件的内容一起写出来，因为此时考虑到很多处理方法，考虑的比较详细，不要等软件完成以后，再想如何写帮助文件，茫然不知帮助该写些什么，另外写一些详细的文档可以防止自己以后看自己写的程序时，自己都搞不清如何处理的，哪些地方该做修改的尴尬局面。写的过程中要主要功能调试，不要以为我这样写代码应该没有问题，程序的隐患往往在不经意间发生。写程序的过程中可根据实际情况，对开发计划和系统设计做一些调整。

7.有数据测试并试运行

　　在拿给用户之前，一定要进行系统的全面测试，可以到某相关单位进行测试，出现问题及时修正。保证拿给用户的是确实能用的软件，就一切OK了（后期维护的路其实还很长的:) ）。

　　行胜于言，团体软件开发的成功会给我们带来愉悦和帮助我们提高开发水平，这样我国整体的软件开发水平才能逐步提高，反之，留给我们的永远是遗憾。

原文转自：http://www.ltesting.net