按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
第 5 章 失败的过程也是过程
例如 RAD（快速应用开发）模型、螺旋模型和现在常被提及
的 RUP 模型。
模型就是“样子”。人家拿出一个东西来说：这是模
型。其言下之意就是要你按照这个样子来做。然而正如下
在这张图所展示的：
按照模型的这个“样子”，做完过程的每一个阶段，
并不等于做工程。或者说，工程并不是这样就可以做成功
的。
换而言之，无论是用 RAD 模型还是 RUP 模型来做工
程，即使是亦步亦趋，也做不好工程。
如果工程可以那样做成的话，只需要有瀑布模型就足
够了。因此做过程并不是做工程的精义。
也不是目的。
…60
…………………………………………………………Page 65……………………………………………………………
『大道至简』
2。 做过场
为什么会存在这样的问题呢？
四川有句地方话叫“做过场”，也有说成“走过场”
的。“过场”是舞台术语，意思是角色从舞台一端出场，
再走到另一端进场的一个过程。过场角色一般没有唱腔或
道白，即便是有，也是没有什么实质内容的。
前面那张图就是一个过场。尽管那是一张用来描述
“沟通问题”的经典图例，然而你应该注意到，每一个角
色都把自己的环节当成一个“过场”。如同演戏一样，从
A 做到 Z ，就一切都完成了。当然，按照 RUP 的思想，
是要从 A 到 Z 一遍又一遍地做下去的。然而，如果每一
遍（或者用 RUP 的那个术语“迭代”）都只是“过场”的话，
项目将是一场无休止的演出而已。
最终呢？观众受不了了，就交钱走人；演员受不了了，
就下台散伙。戏目和项目的结局，竟如此地相似。
3。 实现，才是目的
很多人把问题的本质给忘掉了。从最开始，从我们编
程开始，我们的目的就是实现一个东西。无论这个东西是
小到一个称手的工具，还是一个大到千万的工程，我们的
…61
…………………………………………………………Page 66……………………………………………………………
第 5 章 失败的过程也是过程
目标，都是要“实现”它。
工程只是一种实现的途径。最初做开发的前辈们，不
用什么工程或者过程，也一样编出了程序，也一样解决了
问题，也一样实现了目的。而现如今，我们讲工程了，讲
过程了，讲方法了，却什么都再也做不出来了。
不奇怪么？
工程被当成了借口，掩盖了我们做事的真正目的：“实
现”。因此，我们在一个项目中常常听到说“工程要这样
做”，或者“工程要那样做”，而绝少听到“项目要求这样
做”或者“客户的本意是那样的”。
这样的结果是：我们做完了工程（ 的每一个过程） ，却
没有完成项目（ 的每一个“实现目标”） 。
为工程而工程的人，都迷失在项目中了。就象开发人
员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD
之间的区别的人，可以把每一个过程的流程图都画出来，
却也被这每一个流程给捆绑得死死的，再也没有挣扎一下
的力气。
4。 过程不是死模型
试着跳出大师们的身影，再仔细地看一下那些所谓的
“经典”过程，不过是在瀑布模型上的一再变形。瀑布模
型描述了开发的主要环节，于是一群人把这些环节拧来扭
…62
…………………………………………………………Page 67……………………………………………………………
『大道至简』
去或者反复迭加，就成了 RAD 、螺旋、RUP ，以及未知
的、还没有被扭出来或者堆叠出来的 X 、Y 、Z 。
2002 年前后，我在 CSDN 论坛中看到一个漂洋过海
东渡扶桑的取经人，贴出了一个被称为“日本 IT 工业发
展史的活字典”牛人指点的，足以令人震聋发馈的“V 字
型模型”。
这个模型是这样：
要求定义 ………………》 运用测试（验收测试）
/
系统设计 ………………》 系统测试
/
机能设计 ………………》 结合测试（集成测试）
/
详细设计 ………………》 单体测试（单元测试）
/
CODING
我看后就很不以为然。
为什么呢？你看，你把 V 模型拉直了，还不就是瀑
布模型吗？
要求定义
系统设计
机能设计
详细设计
CODING
测试
…63
…………………………………………………………Page 68……………………………………………………………
第 5 章 失败的过程也是过程
如果仅仅是这样看问题，那还只是知其表理。
《韩非子·外储说左上》记载了“买椟还珠”的故事：
“楚人有卖其珠于郑者，为木兰之柜，熏以桂椒，缀以珠
玉，饰以玫瑰，辑以羽翠。郑人买其椟而还其珠。”
郑人就只看到了事物的表面，而忽略了实质的东西。
如果我们只是把 V 模型当成折弯了的瀑布，那便是犯了
相同的错误。
因此，我们应该去思考由瀑布模型到 V 模型这种变
化的真实意图。
V 模型在每一个环节中都强调了测试（并提供了测试
的依据） ，同时又在每一个环节都对实现者和测试者的分
离。由于测试者相对于实现者是一种监督、考察和评审的
关系，因此它相当于在不断地做回顾和确认。
这有什么意义呢？你把它放在一个工程外包的背景
里去考虑就明白了。由于日本近年来老龄化严重，因此劳
动力短缺导致的劳工输入和项目外包，直接影了它的组织
管理模式。无论是在本国雇佣外来劳工，还是将项目直接
外包给国外的开发团队，项目成果的阶段性考察都是他们
的第一要务，这直接决定了何时、如何，以及由谁来进入
下一个环节。
因此 V 模型变得比其它模型更为实用。模型的左端
是外包给的团队或者公司，而右端则是日本软件企业中有
丰富经验的工程人员。这样既节省人力，又可以保障工程
…64
…………………………………………………………Page 69……………………………………………………………
『大道至简』
质量。事实上，即使左端外包方是由多个团队同时承接，
右边的工程人员也不需要更多的投入。
相对于瀑布模型，V 模型有改变了什么吗？是的。源
于实际的需要，它把测试（和评审） 阶段抽取出来，于是就
成了 V 模型。
那么，如果需要，为什么不能把瀑布模型�