保持编写项目总结的习惯

今天有朋友问我要项目总结文档模板, 俺在这 贴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. 其他。
¨ 以后要对整个开发过程发送的事情都进行记录，这样便于总结提高