实际过程
了解 RUP(rational　unified　process)　的朋友，知道软件开发过程并不是我们想象的
如此简单。它告诉我们在同一个时间内所有的开发阶段是有可能共存的。也是说整个开
发过程可以是多个迭代同时进行。
让我们回顾一下日常的开发过程：
1.　得知有一个项目需要开发。有可能是老板告诉你的，也可能是业务部门告诉你的，
总之我们要为它而工作了，同时确信老板同意开始这个项目
2.　对这个项目涉及的人员及其需求进行调查。这里的需求包括了所有项目的需求，比
如老板对这个项目的要求及期望，用户对这个项目的期望，开发人员对这个项目的期
望。这时，我们很快会发现，调查所有人是不可能的，调查所有需求也是不可能的。因
此，
1)　我们会先找几个关键人物，了解他们的期望，确定系统的边界（或叫轮廓，
XP(Extreme　Programming)中把它叫系统隐喻）；
2)　再把系统划分为几个部分，确定先做哪个部分后做哪个部分；
3)　再一个一个部分对需求进行调查
当我们在调查的时候，常常会发现新的部分之间的关联，这使我们不得不对这两个部
分的内容进行检查，加的加，改的改，删的删。
3.　基于调查的结果进行设计。这个时间，我们经过对这些需求的分析、归类，设计一个
开发的模型以支持这些需求。设计时也免不了会发现需求不对的地方，对需求进行加的
加，改的改，删的删。
4.　基于设计的结果进行编码、集成。也免不了会发现设计、需求不对的地方，对需求进
行加的加，改的改，删的删。
5.　基于编码的结果进行测试，以验证软件是否达到了需求。我们常常发现这时的需求
与设计之前的需求已有了很大的变化。
6.　发布（部署）产品，进行项目收尾。
如果某一时间，客户要知道项目进行到哪了，我们告诉他设计已完成，正进行编码工
作。当有需求变更时，相关的需求、设计又要来过。客户能不怀疑我们的回答么？
做过软件开发的人就会知道，上面的过程描述中有很大的问题。我们的做过程并没有错
一个一个需求，一个一个功能的实现，有变更时就一个一个变更的实现，大家都这样
做，也只有这样做。对于一个应用软件项目来讲，而不太可能真正的按软件书上写的过
程一个一个过程的做下去，集中 10 天做完所有的需求，集中 20 天内做完所有设计。
做的过程没有错，把过程描述出来，为什么就错了？原因很简单：我们在描述时，总
喜欢套用一些"模式"，一些书写的"方法"，而不是按实际的过程描述。如果我们不套用
任何模式，将会如何呢？我们再来描述一遍上面的过程：
1.　了解软件项目的故事（story）。开始一个软件应用项目，了解关键人物都有哪些？
他们要求是一个什么样的系统？把这些要求描述成一个一个的故事，如果稍稍规范一
点。就会象这样：
1)　这个系统的目标是为了谁解决什么问题
2)　第一步做什么，系统反馈什么