试着跳出大师们的身影，再仔细地看一下那些所谓的 “经典”过程，不过是在瀑布模型上的一再变形。瀑布模 型描述了开发的主要环节，于是一群人把这些环节拧来扭去或者反复迭加，就成了 RAD、螺旋、RUP，以及未知 的、还没有被扭出来或者堆叠出来的 X、Y、Z。 2002 年前后，我在 CSDN 论坛中看到一个漂洋过海 东渡扶桑的取经人，贴出了一个被称为“日本 IT 工业发 展史的活字典”牛人指点的，足以令人震聋发馈的“V 字 型模型”。 这个模型是这样： 要求定义 ------> 运用测试(验收测试) / 系统设计 ------> 系统测试 / 机能设计 ------> 结合测试(集成测试) / 详细设计 ------> 单体测试(单元测试) / CODING 我看后就很不以为然。 为什么呢？你看，你把 V 模型拉直了，还不就是瀑 布模型吗？ 要求定义 系统设计 机能设计 详细设计 CODING 测试 工程不是做的，是组织的 我们总是在说“做工程”，好象工程就是面包馒头一 样，有个模子，拿来照着一堆面按上一按，放在笼屉上蒸 上一蒸，就可以“做”出来了。 经历过工程的人都知道，我们没有那个模子，而工程 中的人员也不是那一堆面。 所以我们当然不能“做”工程，而是要“组织”工程。 项目经理的工作，就是要去组织这个工程中的各个角色， 使得分工明确，步调一致，共同地完成这个项目。
相对于瀑布模型，V 模型有改变了什么吗？是的。源 于实际的需要，它把测试(和评审)阶段抽取出来，于是就 成了 V 模型。 那么，如果需要，为什么不能把瀑布模型变成 W 模 型，或者 M 模型呢？为什么就一定要跟随那个以迭代为 基础的 RUP 模型呢？ 更进一步想，如果瀑布可以变成 V、W 和 M，为什 么它不能更关注于其中某个具体的环节(例如实现和设计 环节)？如果在这些环节上引入 RUP 的思想，哈哈，你看 看，是不是出现了勋章模型和烟斗模型？ 然而你要知道，过程模型是在既有工程中总结出来 的。也就是说，在某个模型有了名字之前就它已经存在了， 就已经被一些团队或者公司创生并使用了。 那么，为什么我们不是创生那些新的工程方法和软件 过程理论的团队或者公司呢？
感受：
跳出大师的身影，我们也可以做出一些东西的，v模型就是瀑布模型的改进。这两年的编程，我自己的代码可能并不多，都是瞻仰大佬的博客。久而久之，养成了一个坏毛病，遇事先找博客，我可能也有实力去自己完成目标，但就是怕麻烦。我应该怎么做？答：我应该客服自己的臭毛病，管好自己的大脑，不走便利路。