软件项目开发过程中的几点体会
软件项目开发过程中的几点体会
在从事开发时，往往思考的是具体开发问题，如何提高代码质量，如何加快开发过程，将采用什么新技术等等，偶尔也会以开发的角度思考项目管理中该如何如何；等到从事项目管理时，考虑的主要问题是如何按工期、高质量、快捷、低风险的完成项目开发，围绕此主题，结合项目情况和以前的经验，制订出各种项目管理的策略和计划；下面，结合项目开发谈谈体会。
筹备阶段
召开项目誓师大会，讨论形成一致共识；
在下达项目开发任务后，组织团队成员召开讨论会；通过介绍项目任务，引导大家一起讨论项目改如何进行，畅所欲言，倾听意见和建议，最终形成一致共识；这样做的目的：一是让团队提前进入项目状态；二是调动团队对项目的积极性；三是达成项目过程中一些基本原则，比如严格服从开发管理、所有问题都是团队的问题等等。
对团队成员的性格有个基本了解；
对成员性格了解后，有利于彼此交流，有利于开展工作，可减少交流中的冲突点。
项目经理要向团队阐述自己的做事方式方法；
比如，开发中遇到重大问题，要提出来大家一起商量解决。
对团队成员的技术水平有个基本的把握；
这点非常重要，项目开发过程中采用技术含量高低，就来源于这里，比如
Hibernate
技术，如果团队成员有
1/2
熟练运用，且项目经理包括在内，就完全可以采用此技术；另外，通过对技术水平的了解，在项目开发时可以有个侧重点，对技术水平低的多些关注，技术高的也可以帮助解决问题。
明确要求的事必须不折不扣的执行；
在项目开发过程中，会要求团队执行各种标准、开发要求等，这些都必须得到彻底执行，才能最大限度提高软件的质量。
需求阶段
开会整体介绍、讨论需求，分配开发模块；
各自阅读需求文档，列出疑问点；开会讨论，列出剩余疑问，提交业主或需求人员；
以上是本人理解需求的基本思路，屡试不爽。
此阶段测试人员必须介入；
测试人员提前理解需求，对测试工作非常有帮助，尽快制订测试用例，编写测试计划，提高测试质量；另外，如果现在不介入，等到提交功能测试时，再理解需求，就影响项目进度，而且费时费力。
需求阶段必须实现对需求至少
60%
的理解度；
通过
6
、
7
两种方式，实现这个目标问题不大。
设计阶段
要求开发人员书写部分详细设计文档
,
包括程序结构图
、 IPO 图 ( 输入、处理、输出 ) 、算法、数据流程图、操作流程图、系统页面设计等等；
这样可以进一步加深对业务的理解，需求理解度达到 80% 以上；从开发的角度，思考软件的实现方式，明确业务流程等等，这样在开发阶段就可以专著于具体代码书写。
整理
准备所有的
Cell
报表
,
要求加入输入限制
、
公式等；
要用陌生技术的开发人员
,
要及时阅读相关资料
,
做好技术准备；
开发过程中，有时需要用到陌生技术，这时要给予相关人员一定时间来阅读学习。
原则上统一设计数据库模型；
这样做目的是规范数据库的设计，统一标准，统一模型，统一部署；如果数据库设计量较大，可以允许开发人员单独设计，但要严格遵循设计规范，设计完交数据库工程师（或项目经理），确认方可部署到库里；经验证明这样做可以避免很多问题，比如数据库设计混乱，数据库版本混乱。
此阶段需要开发人员做许多工作，要加强监督检查，以保质保量的完成工作；
对于工作内容安排
,
开发人员必须绝对的支持和执行
,
不能打折扣或者跳跃工作内容
,
让做这个他做那个。
开发
/
测试阶段
在开发前期统一开发工具；
开发工具统一非常重要，可避免很多潜在的问题，比如由于
JDK
版本不同，导致整合版本后无法正常运行，
Tomcat
版本不同也会如此；开发工具统一如下“
JDK1.4+Eclipse3.1+MyEclipse4.1+Tomcat5.0+SQL Server
2000
”
。
商讨将要运用那些开发技术
(
如
Struts
、 Ajax 、 Hibernate 、 Spring 等
);
采用技术的原则是团队必须
1/2
成员会用。
参考行业标准和实际要求，制订详细的代码书写规范和代码结构要求；
通过规范要求可相对的提高代码质量，使项目更接近一个人开发出来的，增强代码的可读性，最重要的是增加代码的可维护性，长期来看降低了项目的风险性，从公司发展上看，有利于技术的沉淀积累。
先开发部分程序
,
然后一起阅读部分代码
,
检查代码规范执行的情况
,
包括类和
JSP
等
;
同时
,
也看看代码的书写思路是否有问题
,
特别是书写的结构是否规范等
,
现场解释解决问题
,
最终完善出一套具体的代码书写规范
,
以及程序书写的结构思路规范出来
,
列如下
:
a
．类及方法都要有注释
;
b
．方法中的变量和程序块
,
要有注释
;
c
．页面也要有注释
,
比如页面所属
、 JS 方法注释等等 ;
d
．每次页面动作只能创建一次数据库连接并用完及时关掉
;
e
．数据库连接取得
、
使用
、
关闭的程序块
,
得按照制订的模式书写
;
f
．对数据库进行添加
、修改、删除操作时 , 一定要运用事务机制 ( 系统底层已经封装 , 注意调用就可以实现 );
g.
在构架每次页面动作的业务类时 , 要严格按照 MVC 的结构书写 , 同时完全运用 Struct 思想 ;
h.
对于异常的报出 , 调用公共类 , 输出相应 ” 类名、方法、说明 ”;
i.
页面上不允许做任何的访问数据库或业务操作 , 只可以显示、获取数据 ;
注意调用一些公共类 , 可以减少工作量 , 也使程序模块化 , 比如 ” 项目列表 ” 、 ” 标段列表 ” 、 ” 编制范围 ” 的生成程序等等。
与测试组交流
,
商讨项目测试目标
,
了解测试报告和测试用例准备情况；
部分模块开发完成，马上提交同步测试，对测试问题及时进行修改；
注意对测试问题的累加
、
分类，及时进行复测；
定期开会一起讨论测试问题，找出问题出现的原因，及时调整开发方式，加强工作细心态度，争取类似的问题不再出现；这样可有效的降低
BUG
出现率；
积极协调开发进度，协调好开发与测试的关系；
在软件开发中，开发与测试是最容易产生矛盾的双方，但是他们协调工作的效果高低，直接影响项目软件的质量；项目经理要营造一个良好的工作气氛，当出现矛盾时，及时的协调化解，推动测试进度。
开发人员遇到难解问题时，要及时帮助解决，困难的开会商讨，千万不能积压问题，因为这往往是关键点问题，不解决会极大的影响开发进度；
每周都要开会了解开发进度情况，及时把握项目进度，做到心中有数；
要多协调
、
多商议
、
多交流，充分调动大家的积极性；
发布阶段
书写详细发布说明文档；
团队建设
考虑问题以成员为出发点
,
维护他们的基本利益
,
帮助做好辅助工作；
可以不定期的组织茶话会，聊聊天，释放工作压力；
与成员一起寻找利益的共同点，建立共同的价值观，才能最大限度的凝聚力量，发挥主观能动性；
对成员要求不能急于求成，要循序渐进，共同进步；在不断的历练中，提高团队的工作效率；
采取民主集中的原则，用集体的力量解决问题；
以上就是本人在项目过程中一些体会，对于一般公司项目经理往往需要身兼数职，比如构架、设计、管理、协调等，所以项目涉及的方面比较复杂；如果简单的从项目出发，关注点是如何保质保量、低风险的完成项目任务；但是经过数个项目后，才发现项目不是最重要的，重要的是团队建设和公司产品技术的积淀，在项目开发过程中形成一支高效的团队，经过几个项目的磨合，团队的开发效率将得到极大的提高，公司产品技术得到有效累积，这时项目只是团队工作过程中的积淀的产物而已；不过有个问题，往往公司的开发人员是随机组合的，对此可采取相对稳定团队，保持团队的基本构架不变即可。