保持编写项目总结的习惯

    今天有朋友问我要项目总结文档模板,   俺在这 贴2篇以前写的项目总结文档, 如果您觉得有用可以参考一下:)

 

                                                                          项目一个人工作总结

1. 基本信息

总结人：黄云辉

总结耗时：1小时

总结日期：2004年3月24日

总结目标：积累经验，总结教训，为以后的工作提供指导

2. 主要工作

n           设计和编码

n           XXX框架的详细设计、编码，

n           访问控制的编码，

n           规则引擎的设计和编码.

 

n           规范的讨论和文档的编写

n           编写XXX20基础版-DB框架使用说明.doc

n           编写XXX20基础版-JNDI名字命名规范.doc

n           编写XXX20基础版-XXX相关配置文件配置说明.doc

n           编写XXX20基础版多框架使用规范.doc

n           编写XXX20基础版开发部署规范 .doc

n           编写XXX20基础版-权限控制说明文档.doc

 

n           其它工作

n           搭建struts架构，确定开发部署模式

n           主要的工作

设计，编码，文档编写

n           满意度

比较满意，完成预计的目标

n           期望的工作

参与更多的设计工作

3. 经验总结

n           引用成熟开源项目，缩短项目开发周期，提高产品质量
CAS，规则引擎是在开源项目的基础上开发的，这2块能够很好的运行

n           藐视问题但不轻视问题
碰到问题不用慌张，冷静分析，一定可以找到解决办法。没有做不成的事情，只有
做不成事情的人。
这一点王工做的很好

 

n           团结就是力量
碰到难题时，开个小会，大家讨论一下，很多问题都可以迎韧而解。切忌回避问题

 

n           引入新技术要格外小心，尤其是那种没有源代码的东西。

引入pmi是本项目的一个失误

 

n           一定要做界面原型

项目初期，XXX项目没有界面原型（这是失误）

项目原型的好处是可以激发讨论，明确需求，帮助大家更好的理解系统设计.

 

n           项目初期解决主要问题
项目初期要能识别出项目中存在的重大风险，并尽早确定相应的处理策略，尽早
解决高风险问题.

n           对于复杂逻辑的编码，先理顺思路，不要急着动手编码
我在写权限控制代码的时候吃了这样一个亏，当时在思路不是很顺畅的情况下
编写代码，结果bug N多，反复修改了N次.

 

n           项目进度的估计不能过于乐观

在项目的实施阶段总会碰到一些你意想不到的问题.

XXX项目的进度评估过于乐观，预计是2个星期设计2个星期编码.结果在整个项目组连续加班1个多月的情况下，还是消耗了将近2*6人/月.的编码时间.

 

n           分工明确,降低沟通成本

这次开发在分工这快做的很好，还有就是项目组相关人员最好做在一块这样可以降低沟通成本.

 

                                              项目二个人工作总结

1. 基本信息

总结人：黄云辉

总结耗时：2小时

总结日期：2004年9月6日

总结目标：积累经验，总结教训，为以后的工作提供指导

2. 主要工作

n           设计

Ø           数据库设计

Ø           类设计

n           项目管理和沟通

Ø           制定开发计划和计划进度跟踪

Ø           工作流和采购网项目组的工作协调沟通

Ø           技术选型

n           编码

Ø           工作流接口实现和相关文档编写

Ø           采购网接口实现和相关文档提交

Ø           样例维护，email发送等工具类，权限控制，组织机构管理等模块的编码（没有写jsp页面）

n           其它工作

Ø           搭建系统开发环境

n           主要的工作

Ø           设计，协调沟通

Ø           对外接口

n           满意度

Ø           比较满意，完成预计的目标

n           期望的工作

Ø           希望以后自己能做的更好.

3. 经验总结

n           技术选型
JSTL + Struts + DBUtil,这次技术选型算是比较成功，基本上没有遇到技术难题.
总结：技术不一定要使用最先进的，自己能够驾驰的住的才是最合适的.

n           第3方资源使用

¨           xtree
使用方式：直接使用

¨           spring的email发送组件
使用方式：直接使用，只做简单包装,提供异步邮件发送功能

¨           随机数生成类
使用方式：把他们的类直接copy过来

 总结：

Ø           使用开源最好不要去修改代码，因为这样可以和开源项目同步升级.

Ø           有的时候 你也可以从开源项目copy某些东西放到自己的项目包下,这样
        就不再依赖第3方包了。

 

n           技术决策

一开始计划采用struts-menu组件来构造WebTree,后来处于技术可控性的考虑，选择了Xtree.

理由

Ø           Xtree成熟稳定，而且简单

Ø           struts-menu比较复杂，不好控制.

总结：技术选择的基本原则

Ø           简单，构用

Ø           资料丰富

 

n           文档提交

u           按计划提交文档，如果提交不了，需要说明理由

 

           

 

n           分工

 原则

Ø           让合适的人做合适的事情

Ø           能者多劳

Ø           软件经理的工作计划不要排的太紧，因为有很多驱动型事情要做.

 

n           设计需要内部评审

Ø           我缺乏数据库设计经验，有的设计太理想化，实现起来比较困难。不过这种设计有部分及时调整过来，对编码造成的影响不大.

Ø           标志字段缺乏详细说明，导致编码时沟通成本过高

 

n           系统集成测试

Ø           保证提交版本是正确可用的，没次提交版本都需要打个label

Ø           在每次提交新版本的时候，同时对新版本与旧版本的更新进行简单说明，只需要描述解决了哪几个问题，有什么变化。这样更容易让承包方了解情况。

Ø           版本提交时间应该固定，如没每天的早上

n           设计交流

设计人员花1到2天时间向开发人员讲述设计思路

好处：

Ø           检验设计

Ø           开发人员理解设计

Ø           团队提高

 

n           对外接口

Ø           应设定固定的人对外交流，重要事情应以邮件沟通，要记录

 

n           样板代码

Ø           典型应用示例

Ø           尽量简单

Ø           需要进行评审

 

n           核心数据的删除处理方式

Ø           设定删除标志，还是级联删除，或者是有引用就不删除

n           代码审查

 这次一开始计划做代码审查，但后来因为时间太紧就没有做。

下次项目一定要做起来，而且是要先建立代码审查标准，由大家评审通过。

定时进行代码审查。

n           单元测试

 struts unit下次考虑引入.

 

n           沟通

需要加强主动和项目经理的沟通意识，想让“项目经理站在你这一边思考”的前提首先是让项目经理了解你

 

n           碰到的技术难题

Ø           xtree的cookie问题，导致session无故丢失.

解决办法：将usePersistence 的缺省属性改为 false

　　

 

4. 其他。

¨           以后要对整个开发过程发送的事情都进行记录，这样便于总结提高