随着中国加入WTO后,外界对中国的软件业带来了机遇和挑战;为新新的软件行业注入新的活力。但细细一想,其实所带来的更多的是挑战。我所说的挑战不单只是个人开发中的水平问题,更多的是我国软件项目管理的问题。下面我几个方面来谈谈。
一、开发人员问题:
1、你开发中按软件工程做了吗?
软件工程,这对软件开发员来说是多么熟悉的字眼,但其中的内涵你又知道多少? 再进一步说,在开发中按软件工程来做的又有多少? 大家常在网上听到一些程序员在抱怨说:“我加班加点地写了10万行的代码,所以老板把我给开除了。”这话扎听有点好笑,但细细一想这是他的悲哀。他写的代码虽多,可是关键的又有多少。如果里面的代码只要有80%的是关键的,我想老板是决对不会开除他的。问题出在10万行代码中有多少是关键的。先不说写这10万行代码所花的时间了,说以后的维护问题,要是你到一个公司,老板首先要求你看完这10万行代码。我想你第一想到是走人,第二想到的还是走人。因为对于一个没有按软件工程来进行开发的程序,不要说是这么多的代码;那怕是几十行、几百行,读起来也是很难受的事。记得我刚到深圳找工作,老板让我接手另一个程序员所开发的一个小系统。这样理所当然的是看设计文档,可是没有,这样只有看源程序;当我打开源程序时,我呆了。看了代码,我决定走人。当我向BOOS提出时,老板给我做思想工作。当然加薪也是少不了的,这也打破加薪的记录了。所以我留下了。之后我开始看代码。在我看代码的同时真不知道把写这程序的程序员骂了不知道多少次。这让我更加增强了对软件工程的认识。为了不让以后继我的程序员不骂或少骂我。所以得好好按规定《软件工程》办事。说这些只是想让大家静下来想想,你在开发中按软件工程做了吗?
2、你是先写文档再写程序的吗?
一个好的程序是先写好设计文档再进行编程的,在设计文档的指导下,才能写出安全的代码。在文档的指导下,这样写出来的程序至少不会出现写了10万的代码还被老板开除的情况。如果你不写文档,一开始写程序,这样你不会按已设计好的路线走,而是想到哪写到哪。小功能还好说,要是大功能,你想想等你写下一个时,回过头来看原来写的,你早不知所云了,那时你觉得好像在云里雾里乱走,修改的代码也更不安全了。我所说写文档不是说很正规的,那怕你只用一张搞纸划上几画也要画点出来(这是对小功能来说的)。对于大的程序来说,你必须正规的写了。因为这样才能详细的记下你的设计思想,如果开发一段时间后,感觉须要对一些功能进行修改或变态时,记住别删除原来的,而是在下面进行变更说明。这样再次看文档时你会更清楚为什么要这么做的原因。一看明白不是多好。总比你去再想以前的设计花的时间要少,如果删除原来的设计思想,当你再次看修改或变动的功能时,你可能会对其不理解。这是多么可怕的事呀!我想作为程序员应该知道文档的重要性。可是在一些小公司,先写文档后写程序的开发员又有多少。要成为一个好的程序员大家想想自己该怎么做的吧!
二、软件项目管理问题:
1、现代的软件开发,技术不是关键:
随着日益增长的软件需求和软件系统功能的增强,过去一个人开发的历史已不复存在。现在单枪匹马写程序也只是一种娱乐。我们一般开发的系统都是一个小组才能完成的。所以管理才是开发出好的软件的前提条件,没有管理一定出不来好的软件,当然有管理也不一定出软件的。一个成功的软件不一定是好的技术,但在它背后一定有一个好的管理。所以现在的软件开发已不像从前把技术放在第一,而是该把管理放在第一位。我在网上看到一篇关于中国软件和印度软件的比较。我现在记的不是太多,但对我影响深的是他们会去权衡技术和开发效率问题。如现在开发一个软件,用户要求在三个月内完成,你在做系统分析时也认为在三个月能完成。但你没有考虑到一些细节,你写完系统的总体设计,在进行详细设计时碰到要建一张不是太大的路由表。这时大多数国内的设计人员会想用什么算法,去花很多时间去设计研究新的算法和技术,而人家首先考虑的是系统的运行环境,而这个软件设计了是在(CPU:1.1G,内存:512M)中运行,用户也没特意提出其运行效率要求。所以人家在内存中开一个大数组来对这个路由表进行操作。从这点看,人家注重的是软件的整体,而不像国内大多数据设计员那样,把个体放在首位。其实这方面我觉得我们的开发员应当多向共产党学习(本人不是共产党员,团员也因没交团费被Cancel掉了)。把软件设计的整体放在首位,而不去花太多的时间在不一定成功的技术上。如果花太多的时间在技术上去,这将对系统的按时完成带来影响。我也不是说不该研究技术,我只是说开发中应当以全局为重。如果要加入新的技术,必须在分析时预算其所需要的时间,并设置技术风险管理。如果风险太大应当取消用这项技术,改用其它的已成功的技术代替。风险管理这是近来才提出的软件管理方法。它对我们的软件项目有着很好的控制作用。对于一些中、大型系统,它是一把走进成功之门的钥匙。这里不谈了,我将在下面进行说明。
2、好的管理才能开发出好的软件(小系统除外):
大家都知道,软件开发中有太多的不可预知性。但这种不可预知是对总体来说的,当软件进行到一点程度时,不可预知的东西会变成可预知的东西。以往的做法是不去管理它,这样所带来的是项目的失败。要是有好的管理方法可以控制这些不可预知的东西,软件项目会一步步随着你的设计思路起向成功。现在和大家一起讨论一些常用的软件管理方法。
1)错误管理:
小时候当我做错事的时候,我父亲总是把我叫到他身边,对我说:“没事,只要下次不做相同的错事行了。”这话也许很多家长都对自己的小孩这么讲过。小时还不觉得,慢慢长大后,会发觉其中深刻的道理。这是说从错误中吸取经验教训。软件项目开发中的错误也是一样。软件开发是一项复杂的活动。一个典型的软件开发项目可能会给我们提供很多的机会去从错误中吸取经验教训。一般的软件项目也会提供少量的错误给我们学习。学过开车的人都知道,教练老是会这么讲:“我希望你们从我身上学习我和前人的的经验,这些经验你们不要再去试了。如果要试你也许会赔上钱甚至于生命。”虽然软件项目开发不会赔上生命,但是失败的软件项目是一定会赔钱的。所是在软件开发中少不了要对错误进行管理。在项目的错误管理中我一般是这么做的,现在和大家讨论一下:
a、 列出典型错误:
典型错误中有人员方面的。如:对有问题的员工失控、挫伤积极性、人员素质低、英雄主义、项目后期加入人员、开发人员与客户之间发生摩擦、不现实的预期、缺乏有效的项目支持、缺乏各种角色的齐心协力、政治高于物质、充满想象等…
典型错误中有过程方面的。如:过于乐观的计划、缺乏足够的风险管理、缺乏计划、在压力下放弃计划、在模糊的项目前期浪费时间、前期活动不合要求、缺少管理控制、缺少质量保证措施、鲁莽编码等…
典型错误中有技术方面的。如:过高估计了新技术或方法带来的节省量、项目中间切换工具、缺乏自动的源代码控制手段等…
b、 列出自己的差实践:
注意典型错误,建立自己的差实践列表,可以避免在以后的项目中犯同样的错误。
c、 列出项目中的差实践:
组织机构和其他项目组总结经验,学习他们的错误中得到的经验。和其他组同事交流项目开发中的磨难,学习他们的经验。列出潜在的错误,看到它我们会尽量避免今后犯同样的错误。
打个适当的比喻,典型错误好比我们学车时教练讲的经验,自己的差实践像我们在实际开车当中出的问题,而项目中的差实践是我们学车前的笔试的书。