吴春雷
819543772
绝大多数软件公司走的都是由项目到产品的模式,也就是从做项目起家,积累经验,慢慢从做项目逐渐转型过渡到做产品.对于开发者来说能够一开始就加入到软件产品开发团队的幸运儿不多,绝大多也都像我一样整天围绕着项目在转.本人从参加工作到现在,除了参与过一个科研性质的项目(姑且称之为)以外,绝大多数时间都花在了工作量在60个工作日/人以下的小项目上.这些项目看起来并不复杂,但是却几乎毫无例外的全部延期了,除了工作量评估有误以外,究竟是什么导致了项目的延期,这是一个需要探讨的问题.
在探讨这个问题以前,有必要对小软件项目做一个定义,究竟什么是小软件项目?小软件项目有什么特点?所谓小软件项目,我认为应该是指针对某一具体客户,功能需求相对较少,业务逻辑相对简单,开发周期短,资源占用较少,实施价格较低,资源投入获利比相对较高的软件产品.从定义中可以看出,小软件项目的本质是软件产品,因此这类项目拥有软件开发过程的所有特点,同时也存在软件工程中提到的所有问题.另外,该类项目还有一个重要的特点,那就是开发和实施周期短,由于项目价格相对较低,因此公司不可能投入较大的人力和物力成本,也不可能在这样的项目上花费太多时间.个人认为上述两个特点是小软件项目延期的重要原因.除了上述特点以外,该类软件产品一般自始至终都会由某个人负责设计和开发,因此在软件设计的过程中主观性过强,同时由于程序员业务素养以及开发时间紧迫等原因,往往很少考虑对已经存在的软件模块进行复用,也很少重视对软件复用能力的设计.缺乏可复用的软件模块和代码库也是软件项目无法按时的完成的原因之一.
我认为导致项目延期的原因主要有以下几点,先做简要介绍有机会再在以后的文章中针对这些问题展开讨论.
1.忽视需求分析的重要性.需求该由谁来做不明确?
众所周知,需求分析是整个软件开发过程中的重中之重,需求的变动可谓牵一发而动全身,需求是否明确是软件是否成功的重要原因之一.一般来说,在软件产品的开发过程中,需求分析的过程要占到整个软件开发过程的40%,并且要在详细设计前反复迭代使需求最终明确,然后才能进入到后面的过程.但很明显,小型软件项目由于开发周期短,貌似没有这么久的时间进行必要的需求分析,很多公司领导人员更是认为,小项目的需求简单,搞明白个大概就行了,不明白的地方可以在开发过程中进一步明确.为了节省时间,想当然的弱化了需求分析过程,但殊不知,由于需求的不明确,开发后期必然会出现大幅度的改动,"拆东墙补西墙""东拼西凑"的情况更是屡见不鲜,最终的结果就是程序结构混乱,稳定性差,Bug到处都是,再往后,恐怕就是任何一位程序员都不愿意看到的噩梦了.很明显,开发后期需求变化所花费的时间是导致项目延期的重中之重.
了解了需求的重要性,那么在小型项目中,需求分析究竟该由谁去做呢?相信绝大多数公司都会认为,项目由谁负责开发,需求分析理所当然应该由谁去做.但是我认为,这种看似合理的做法实际上最不可取的.首先,一个优秀的软件开发工程师很可能没有很强的沟通能力,去诱导用户说出自己的需求,因此如果由他来做需求分析,必然会为日后留下巨大的隐患.其次,术业有专攻,优秀的软件开发工程师可能对需求分析技术并不了解,即便有很强的沟通能力也无法明确的提取出用户的表达中究竟那些是需求,那些是随便说说.最后,作为一名软件工程师,面对某个复杂的问题有着天生好胜心,因此,软件工程师在面对客户提出的复杂的技术需求时,只会考虑是否能够实现,而不会考虑实现这个需求所花费的时间和成本,因此,由软件工程师确定的需求,很可能在技术上会较预期复杂的多,这也是项目延期的重要原因.因此,我认为,需求分析应该由拥有开发经验同时又有很强的需求分析能力的专人负责,而不是负责该项目的软件工程师.
2.小型软件项目中忽略软件结构的架构
软件的架构实际上是对软件整体结构和运行模式的描述,大型软件产品的最核心问题是设计一个可靠性高,运行稳定,容易扩展的软件结构.那么对于小软件项目,软件结构的架构化究竟还有没有必要呢?我认为,答案是肯定的.首先,拥有一个稳定的应用程序框架可以节省大量的开发和设计时间,同时由于该框架已经被充分使用,因此不会有太多的Bug,无形中节省了整体开发时间,这也是软件复用的一种方式.另外,应用框架的高扩展性是保证日后软件快速升级的基础.由于小型项目的特殊性,后期对功能上的升级频繁发生,在设计初期确定日后所有需求显然是不现实的,即便能够确定日后的升级需求,为了一个可能在很久以后才会用到的功能而投入人力和时间显然是不经济的.而高扩展性的框架显然是解决这一问题的最好方法.最后,公司搞项目的最终目的是软件的产品化,任何一个产品都有一个高可用的框架作为基础,设计一个高可用的框架也是公司由项目到产品转型的需要.
3.整个项目所有开发过程由专人负责还是采用流水线的方式,各司其职?
以软件为主的公司,一般都会配备技术总监,需求分析人员,软件设计师,程序员,软件测试人员,实施人员等.而小型软件项目所涉及到的人员应该会有需求分析专员,软件设计师,软件测试专员,实施人员.但是,很多公司,只有需求分析专员和软件设计师,需求分析人员只在初期参与,一旦需求明确就会直接甩手给软件工程师,由软件工程师完成设计,编码,测试,甚至实施等过程.这里显然有很大的资源浪费,软件的编码和单元测试所花费的时间实际上要远小于功能测试和现场实施的时间.而软件工程师的成本相对于黑盒测试人员和实施人员来说相对较高,因此,如果舍软件工程师的长处不用而去让他们参与实施过程,会增加软件人员的抵触情绪,而在实施过程中所浪费掉的时间实质上是延误了下一个项目的进行.因此,我认为虽然项目较小,也应该采用流水线的方式,各司其职.这种方式的缺点是,流水线上的人员沟通不够,可能也会延误一定的时间,但是,只要在管理上协调好,增加流水线上各点的沟通机会,应该是一种比较经济和有效的方式.这种流水线的方式的前提条件是需求相对明确,软件质量有一定的保证.
4.忽略该类软件的概要设计的重要性,采用何种开发模式?(SD方式,OO方式,还是XP方式)
概要设计是对软件整体结构的把握,但是由于项目的特殊性,概要设计在小型软件项目中一般会被忽略,或者干脆不做,或者融入到详细设计和编码的过程中,正是这种看似"节省"时间的方式,却给程序的高耦合和低内聚创造了条件,最后的结果是软件结构混乱,对需求变动的适应性差,哪怕需求只有微小的调整,程序也有较大的改动.同时软件模块几乎没有可重用性,导致每个项目中相同的某块都需要重写一遍,严重降低了开发效率.
虽然所有应用软件开发的公司都在使用支持面向对象的开发语言,但是用到OO思想,并且尝到甜头的企业并不多,而真正在开发过程中用到OO思想的开发者恐怕也是少数.熟练使用OO思想可以提高软件的开发效率和复用性这一点毋庸置疑,但是在使用的过程中也发现了很多的问题,前面说过,小型软件项目的一个特点是软件工程过程不完善,需求分析过程没有得到足够的重视,因此,在开发过程中会有很多变动.采用OO思想设计程序的时候,虽然会有很高的扩展性和开发效率,但是面对需求变动所产生的程序变动似乎不够灵活.XP是最近才开始展露头角的开发思想,其核心的思想用7个字就可以概括"一红,一绿,扫扫地",具体来说就是先写测试代码,此时测试代码不能通过,此为"一红",程序代码写完,且通过测试,此为"一绿",程序代码运行正确以后,对代码进行重构,此为"扫扫地".实际上,本质是以测试来驱动开发过程.由于该模式紧扣敏捷思想,因此貌似与小软件项目周期短的特点相吻合,但在具体使用时还是有些问题需要探讨.比如,由于开发时间短,因此,小软件项目中详细设计过程很不明确,一般开始写代码前都没有详细设计文档,这样在使用XP方法的时候就无法根据文档设计有一定覆盖率测试用例,测试代码基本成了摆设.还有一个问题是,由于测试代码本身也是程序,那么如何保证测试代码的正确性似乎就成了歌德尔不完备性的问题.
5.保证该类软件产品的质量重要性?
软件产品质量的保证一直以来都是非常重要的课题,而在小软件项目中更是非常重要.可以说软件测试工作做的如何,直接影响软件项目是否能够正常完成.试想一个在实施过程中到处都是Bug的程序,实施人员该怎么去部署.不停的修改Bug也浪费了软工大量的时间.另外,软件质量不过关还会带来一个非常重要的问题,那就是软件实施后仍然会牵扯软件工程师的精力,由于用户在使用的过程中发现了这样或那样的BUG,软件工程师既要忙手头的工作,又要疲于奔命的解决在使用过程中出现的问题,时间长了项目多了以后,软件工程师将不能集中精力工作,效率低下任务不能按时完成将直接导致当前正在进行的项目的延期.
6."需求地狱"如何避免?在出现"需求地狱"的时候该由谁来踩刹车?
所谓"需求地狱",可以理解为在软件开发过程中,用户的需求永远是没有止境的,他们会不停地提出这样或者那样的改进建议,希望软件人员能够满足他们的要求.而在修改这些需求和问题的时候,会导致另一些功能发生异常,而这些发生一场的功能模块又可能影响更多的模块.对于"需求地狱"的避免,我认为需要先从问题的种类着手.在开发后期,用户所提出的需求(或需要改进的地方)可以大概分为3类,第一类是影响业务流程的进行,且用变通的方式无法解决的问题.第二类是不影响业务流程的进行,但是会降低客户工作效率的问题.第三类是为了让软件使用更加方便,也就是说锦上添花的问题.毫无疑问,第一类问题的修改是非常必要的,必须及时修改.第二类问题要看对客户工作效率的影响程度,然后在决定是否进行修改.第三类问题,我认为暂时无需进行修改,因为在如此短的时间里,所做的项目不可能面面俱到,存在不完善的地方在所难免,考虑到成本和时间这类问题和第二类中决定不修改的问题应该统计出来,留在以后的升级版本中在行修改.
当"需求地狱"出现时,如何与客户有效沟通,告诉客户那些问题不该修改,为什么不修改,这项工作究竟该由谁来完成,也是需要探讨的问题之一.软件工程师交流能力以及对客户关系的把握不一定很强,对于问题可能会更多的从技术上分析,而客户大多数不懂得技术,因此,往往解释了半天,客户还是认为我们在推脱.所以我认为,这项工作应该交给沟通能力强,且有一定技术基础的支持人员完成.
总结一下,在小项目开发的过程中可能导致项目延期的主要原因有如下几个:
1.需求分析力度不够,这一点首当其冲
2.软件设计不充分,结构混乱,当遇到需求变动时修改过大.
3.软件复用性重视不够,由于时间不够无法进行复用性设计,每次都重新写相同的代码导致时间的浪费,陷入恶性循环
4.软件测试不充分,需要修改的Bug太多,除了直接导致项目拖延以外,托住软件工程师的精力,间接导致后面的项目延期.
5.如何避免和解决"需求地狱"问题.
通过上述分析,看起来小软件项目延期的问题已经找出来了,但是解决起来却是困难重重,关键问题是项目实施时间太短.因此,公司在接这类项目的时候一定要谨慎.
