您的位置:首页 > 其它

好的开始就是成功的一半--JD项目总结之一

2008-01-15 18:50 447 查看
到JD项目已有半年,马上要结项了,之后应该总结下该项目的经验和教训.所以今天先着重总结下有关需求方面的问题.因为在这个项目中,作为开发人员,感到很累.当然作为新手,刚接触BizTalk,开始确实觉得有点难.但是过了一段时间,技术方面已经基本掌握够用了,却还是觉得很累.很多原因都是需求变化引起的.毕竟好的开始就是成功的一半,需求如果没有弄清楚,就不清楚自己做的东西有没有价值.

首先说个故事.

谁的医术才是最高

有兄弟三个都行医,其中,以老三的名气最大,病人最多,门庭若市,许多病人抬着来,走着回去;老二的名气略次,门庭也没有老三这样热闹;老大的门庭是最冷落的,找他看病的也不是什么重病人.

有一天,一个人在老三那里看完病后,就问:"你家兄弟,谁的医术最高明?"

老三就答:"老大的医术最高明,然后是老二,最后才是我."

那人问:"那为什么最出名的是你呢? "

老三说:"老大医术最高,病在潜伏期的时候,已经治好了,病人认为本来就没什么大问题,治好小病也就不算什么了,所以老大不出名;

老二往往是病在初期,就把病人的病给治好了,所以稍有名气;

而我,找我的人总是病重的时候才来,我治好了他们的病,他们认为我能把顽疾治好,于是就认为我的医术最高."

能够将病情防范于未然,才是真正的医术高超!软件开发也是一样,只有充分把需求和设计确定并做好了,下面一系列的开发才能良好地有序进行!

需求为什么总会变化

遇到的需求问题,对于开发人员,需求只有一个,一旦变化,程序就会有一连串的变化.所以,开发人员最怕的不是技术问题,而是需求的不确定性!在JD项目中,我把遇到的需求变化的问题和原因归结为:

无法预料的问题
客户给了我们一个数据库,但是客户真正实施的数据库我们是没有的.由于客户的业务系统要求,导致一些正式数据库的表结构变化(表字段增加修改等).做JD项目就是为了不同数据库间的数据交换,数据库表结构是不能随便改的,否则这个项目就没意义了.这些问题,负责和我们交流的客户人员也不知道,在程序实施到正式数据库的时候才发现,再一查有十几个表发生变化,导致相关的流程全部要修改,从头再来一遍.

产品要求的功能变化
后期,一些主要的流程,客户要求功能增加,致使某些表需要增加字段,这又不可避免的修正程序了.

而一百多个流程里面,目前只挑了几十个对于客户很重要的在测试.当催促他们尽快把其他流程也测试并确认时,却答复不知道其他流程有什么用,暂时不管了.至今这些流程还放在那里,我也不知道有什么用,看来这样详细设计人员清楚了.我一直怀疑是不是做了无用功.

详细设计书不够详细
开发过程中,经常要跑过去跟需求设计人员确认发现的问题,这些问题有比较大的问题,比如需求跟客户不一致,结果是需求再改,程序再次从头开始做一遍.更多的是小问题,比如字段映射错误,表名写错,等等.

如何避免这些问题

软件开发过程中,作为一个工程,从源头开始将问题考虑到,对后面一系列的问题都有很好的效果.总结的解决方法如下:

加强沟通
加强客户与开发人员的沟通,重要的改动,肯定要通知对方,并且要衡量下改动是否必须,有无更好的替代办法.晓之以理,动之以情!可惜的是,貌似项目的价格已经签署到合同里了,否则这样改动大的设计,肯定是要加钱的.涉及到钱才可能会让客户感到问题严重,否则客户只会不断的要求自己想要的功能,想法接连不断,导致开发人员苦不堪言!

多次确认
详细设计人员对于定下来的东西,告诉客户程序出来的结果到底会是什么样子的,并要求客户确认.对于客户可能还需要的功能,最好能够提前帮客户想到,并提出多个解决方法,供客户选择.一旦需求确定下来了,马上形成文档,客户和设计人员都确认过了,才算最终文档!这一点我觉得设计人员没有做好,最后成了开发人员跟客户在确认了.

评审设计
以前在苏州高达的时候,需求,详细设计,设计评审这些编码前期工作,开发人员都会稍微参与,尤其是设计书评审阶段,但是在JD项目,详细设计书全做好了的情况下,我才加入该项目的,并且详细设计书居然没人评审过.这次的需求文档,在多次去跟设计人员确认一些问题后,他说:"这些问题你知道就改下吧,几天就做好一百多个流程的设计文档,肯定是有很多问题的."我听后感到十分的吃惊,当然并不是惊叹他的效率,而是最后一句话,"肯定是有很多问题的".

既然知道设计有很多问题,为什么不在程序开发之前仔细评审一下,却发布给开发人员,当然各个公司的软件工程管理不一样,我也不好怎么提出建议.所以作为开发人员,拿到详细设计书的时候,不能埋头照着就做,应该先仔细查看一遍是否会有问题,尽量将能发现的问题扼杀在程序开发之前!

最后总结

好比中国出现矿难时,某某领导高度重视,亲自下达全力抢救的指示,亲自赶往现场,等等.这些都不能改变灾难发生的事实,只能让人看出官员的虚伪!软件开发也相似,如果把问题杜绝在萌芽状态,就不会有较多不该产生的问题.据说软件开发过程中,前期没有修正的错误,后期要花费三倍的时间精力来更正!

最后再附一个故事,十年前听来的,江西九八年发大水的时候,ZHURONGJI总理达到后视察,严厉批评江西的官员没有做好防护工作,决定撤职;而随后来的JIANGZEMING主席,看到的是江西各地官员全力抗灾抢险,救助被困百姓,于是决定提拔.至今记忆犹新!偶是小民,不做评论!

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: