实际上,在开发过程中,我们不由的都喜欢看项目的一些缺点,今天埋怨需求的变更管理做的不好，明天吵闹说RD与QA配合的不好,好象项目一无是处:(,实际上静下心来想象,一个比较复杂的项目(接近22万行代码),开发能够在将近一个月内完成,算人天实际上是150人/天,而且在五个开发人员中有四个是新人,不能说成功的项目,但也应该有可圈可点的地方,现在把我认为几个比较好的地方列举出来,欢迎大家拍砖:
1.抛弃式的用户界面原型
由于需求上的一些问题,我们在开发前做了两版的原型,项目进展到现在可以说能够很清晰的看出这两版原型对项目后期开发起了相当大的作用,我们现在开发出的系统与原型的几乎没有什么差别.在一些细小的由于原型考虑不周的地方,开发时所用的讨论与修改时间远远大于了修改原型的时间.所以从这一点可以看出,一个准确的,让RD\QA\PM达成共识的原型对项目开发的重要性.
2.迭代式交付,用户的参与
我们做RD的,可能刚开始都有一种想法就是自己干活不希望有人监督,也不希望有别人打扰.所以对于用户的参与,以及迭代式的交付可能都存在抵触情绪,所以"晕死,把功能全部实现再给你,急啥子呀","我们工作你们能不能不打扰啊,这很影响我们的进度啊"之类的话就是常听到的了,我们这个项目由于客户很强势,公司把这个客户看的很重,所以在开发中我们逼不得已的不断提交版本(半个月一版),而且接受到不断的反馈(来自客户的真实使用),开始觉得这样很变态,但是现在项目快结束了,细细体会一下,才真正感觉到了客户参与的重要性!试想如果当初我们一直那样做下去.................
3.不同阶段的评审
无论是PM的需求评审,RD的设计评审还有QA的测试用例评审,这一切在当时看错是浪费时间的烦人的会议到后来却发挥了很大的作用,将项目的风险可以说降到了最低.
,所以这三个主要的工件产生流程中做好每次评审,把好每个关口都是至关重要的.当然在这里也说一个自己认为不好的地方,就是在RD的设计评审的时候,PM由于对设计不太熟悉,QA也不会太用心看设计文档,而迫于项目的压力RD内部又不会强行的去让设计评审不通过(这当中当然有因为大家太熟悉,不好意思的缘故).这样就导致了一些隐患大家没有发现,由于这个我们也在后期开发中吃了不少亏!所以教训就是"要不就不要做评审,要做就要做到六亲不认
"
今天先写到这里,其实有待改进的地方还很多，等有时间了,再思考思考吧!
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
