论瀑布模型、Rup是否适用于一般的国内软件公司。（一）

记得第一次对软件的开发方法第一次感兴趣是在大学的时候，那个时候开始学习瀑布模型。从那个时候开始，我知道我之前写的一些东西只能叫做“一段代码”，远远不是软件。也开始对软件的开发方法感到迷惑、兴奋、感慨，软件开发原来是这样一个复杂的过程。那个时候我觉得瀑布模型解决了我心底一个长久的疑问：这些庞大的软件是怎么开发出来的。同时，也觉得自己增长了不少的见识。看到或者听到多少多少项目失败，心里总在想：肯定是没有采用科学的开发方法，要是让我来管理，我就采用科学的管理方法，规范文档、接口，就不会出现这样的问题了。现在看来以前的想法是多么天真，不过谁不是从天真走过来的呢！

后来工作了，开始我热爱的程序员工作。随着紧张、兴奋的心情逐渐平静，我从代码堆中挣扎出来，开始审视自己参与的项目，也跟我的那些同学们讨论每个公司的不同开发过程。发现瀑布模型那一套，在现实中，是很少有贯彻的。

一般的开发过程都是这样：首先是立项，这个立项可能是个外包，有可能是接到的一个单子，可能是公司领导要开发的一个产品；然后成立项目小组，指定项目经理，领导一般都会给出时间的期限；然后项目经理把项目进行瓜分，某某模块张三负责，某某模块李四负责；然后开发，各人搞定自己的一亩三分地；最后集成在一起进行测试，修改一堆的Bug。最终Release出去的东西一般都是不满足要求的，怎么办，项目延期，各人负责修改自己的部分。直到项目完成。

所以，我们从上面这个管理的过程中看到我们的项目管理是人员管理，有点象车间式的管理。每个人都是搞定自己这一块的需求、数据库设计、类定义、接口定义、代码编写、文档工作、测试。每个人都是全能的。最终出来的产品可以想象。从这种管理方式中，我们看到了现在我们痛恨的各种问题：一个人写的代码自己他自己明白（没有文档、有也不懂）、每个人都搞了一个自己的CStroke类、集成的时候问题一大堆等等。

我开始反思：为什么大家不用瀑布模型呢？有什么更好的方法可以解决这种问题呢？

我和我的同学也一起讨论瀑布模型，大家都觉得瀑布模型只是一个理论，没有具体的可操作性。我觉得这个道理很对，知道道理并不表示知道怎么做。大家继续讨论，觉得瀑布模型中有一些东西在现实中实施也很困难，最明显的就是文档。首先，咱得承认中国的程序员表述很成问题，很多东西写得象天书，没有人看得懂（我是深有体会）；其次要求这些平时写作文都是抄袭的程序员写文档很费力气，没有人愿意写，要写的也要花巨长的时间。