走自己的路

最近总是在想项目流程上的一些东西，我们必定是存在很多问题，以使：
１．交付客户的产品总是不令人满意
２．实现的产品总是偏离系统最初的设计
３．实际的工作量比计划的工作量多了很多
４．个别技术问题造成项目或者任务的延期

是着手改进的时候了，谈不上改进，是一个从无到有的过程。
这个过程就记录在这里吧，各位大拿也给献计献策，也给小弟上上课～～

HEAD-------------------------------------------------------
Document Status: Draft
Version: 0.0.1
Modification Log:
2008-03-09 deadcode Initial Document (Flow of mass)

START------------------------------------------------------
I. Flow of mass
1. 客户需求说明书
早上打开foxmail,收到了客户的邮件,粗略的看了一下需求文档,估计需要三个兄弟,看看整个team的进度情况,安排一个比较又能力的兄弟和两个能力一般的兄弟抽空去看新的需求文档.

2. 需求分析
收集求中的疑问,在小组会议的时候讨论,不能解决的mail给客户.
客户要求con-call,安排小组参加con-call.基本扫除了需求疑问.
从客户需求中分析出功能点,对功能点进行大致的分工,出项目计划.

3. 简单设计
出一个比较简单的Solution,只需描述一下采用何种技术,大致的业务流程,让客户知道我们的需求理解没有偏差就OK了.

4. 开发过程
搭建好项目框架,建立好配置库之后,大伙开始闷头开发自己的功能点.

5. 过于乐观的团队
某天小A发现某个功能点不好实现,闷头鼓捣了一下午毫无头绪,无奈晚上加班,终于想出一个"小技巧"解决了难题.
过了两天,小A发现前几天实现的小技巧有点小问题,改了多个相关的类,总算修正了这个小问题.
项目时间推移,这样的小技巧和小问题越来越多.项目组终于发现,简单设计过于乐观了.系统细节被无情的忽略了,残酷的梦魇又一次开始了.
我无奈的告诉客户,项目延期了,并且多了许多加班的时间...

6. 测试
经过了N天的奋斗,项目组精疲力竭,终于发布测试啦.项目组成员逐渐恢复了生气,但这仅持续到发布测试后的一个小时.项目组成员不得不面对msntis的一路飘红.

7. 部署
在延期了N天之后,mantis终于绿了,此时不发布,更待何时?
客户现场一部署,客户:"非常感谢你们的工作,但我觉得这个流程上我们还要改进一下.",项目组成员当场立扑....

8. Restart Flow of mass...
---------------------------------------------------------


开发需求说明书 - 项目计划 - 任务
系统DEMO - 界面测试脚本
数据库设计（数据结构设计） - 数据结构测试用例
系统设计说明书 - 业务逻辑测试用例

项目原型 - 系统初始化脚本，构建脚本，系统原型快照
项目开发（迭代） - 单元测试脚本
持续集成 - 集成脚本、集成测试脚本、集成测试快照
部署 - 部署脚本（完整部署、补丁发布） 、部署快照