一个软件项目从开始到结束,由于资源、人员、管理、方法学等等各方面的因素,往往不可避免的会存在一些问题,如需求不明确、项目管理失败、沟通问题等等,今天无意中看到老外写的关于这方面的一篇文章,总结的比较全面,翻译过来结合自己的一些经验做了点补充和修改,存档以备时常可以告诫一下自己。
1、不能很好的理解用户的需求,缺少与用户之间的沟通 -----让客户明白自己在项目中的作用,做好调研需求,和沟通计划并严格按计划办理 2、错误的预估项目的大小和难易度。 ----不断积累经验,丰富知识和时实践 3、没有计划就匆匆开始编码。 ---- 做完善的计划 4、没有在项目初期就开始做测试,一直拖到项目后期才做,或者根本不做什么测试。 ---测试是一本艺术。要按单元、以不同身份测试。 5、选择时下最cool的技术还是已经被团队使用比较成熟的技术,往往不能做出很正确的选择。 --- 选择成熟的,关注新技术,适当采用 6、不采用任何软件过程或者方法学。 --- 学问大了,不赘述 7、没有一个真正的项目经理,让开发人员无计划的主导项目。 ---- 项目经理,要懂项目管理、IT技术、业务流程和需求 8、拖延计划,把进度压力留在后期。 9、不做版本控制,混乱的代码库和开发环境。 ---这是我要加强的 10、在项目过程中随意的更换开发工具和环境。 11、客户的任何需求都答应下来,需求会永无止境,记得学会说“不”。 --“不“ 12、只有一个大的计划,没有把计划分割成一个个更小的任务,要知道,大的计划如果不分割成任务很难落实和具体实施 -- 尽可能详细的 wbs 13、对开发团队的管理不足。 ---计划好 职责、管理流程、沟通计划 14、在项目后期增加人员来加快开发速度,很多时候往往适得其反。 ---软件开发,人越多,沟通成本就越高。效率越低 15、开发人员不做单元测试。 ---单元测试,呵 16、一旦项目中遇到问题,就把压力抛给开发人员。 ---项目经理,应该给技术人员指导。设计人员 施工队的关系。 17、不关注软件实际的运营环境和硬件条件。 --- 要考虑到以后的运营模式 18、没有命名规范和代码规范。 ---不说了 19、到处都用全局变量。 ---不懂 20、遇到问题的时候往往不请教别人,而是一个人闷头搞,到最后还是不得以还是通过别人来解决。 21、没有写代码注释的习惯。 ---喂,编程的兄弟,过来看看 22、对输入输出的数据不做验证。 ---建议看书 测试的艺 23、不做压力测试,到实际环境中往往就会出现更多的跟环境和性能相关的问题。 --同上 24、项目内部沟通不畅,每个成员只是埋头做自己的事情。 --按沟通计划沟通 25、没有很好的bug管理规范和系统,往往用word、email、excel等文本方式来跟踪bug,将会导致整个项目的bug管理陷入混沌。 ---不用这些,用什么来沟通?
[此贴子已经被作者于2007-8-31 13:26:47编辑过] |