我们是软件工程的实践者，而不是高高在上的布道者

我们信奉的理念是：大道无形，有效的才是最好的

大道无形——有效软件工程初探
（暨“有效软件工程实践（网）”揭幕告白）

http://www.effective-swe.com/

一个学生和N个老师——关于过程的困惑

    当今的软件过程领域可以说是热闹非凡，SW-CMM在咨询公司的大力鼓吹和政府的扶持下在大江南北遍地开花，让那些够格和不够格的咨询公司们忙了个不亦乐乎，即使SEI推出了最新的CMMI，由于其一脉相承的血统，丝毫没有减弱业界对其的热情。虽然其在国内的实施效果已经越来越多的受到各方的质疑，但作为一种重量级的过程模型依然在业界保持着绝对的权威地位。
    
    2001年的春天，一群软件拥有相同理念的过程专家们齐聚一堂成立了所谓的敏捷联盟（Agile Alliance），这些人中为首的便是Kent Beck，其在5年前（1996年）就提出了一种轻量级的软件过程——极限编程(XP)。无论是作为一种理念的敏捷编程，还是作为一种可操作的软件过程的极限编程，自从其被引入中国那一刻起，就以其自由的风格和饱满的热情深深的打动不少软件从业人员，尤其是基层的程序员和中小项目的管理者。
    
    Rational 统一过程（简称RUP）作为一种用例驱动、以构架为中心、迭代和增量的开发过程，随着UML的推广和普及也渐渐成为一种主流的开发过程，前段时间其开山鼻祖之一的Ivar Jackbson高举着Smart的大旗来到中国传播其“主动软件”的理念，又令业界一时间陷入了 关于“隐性知识”和“显性知识”的热烈讨论中。
    
    从业界的大师们到咨询公司的咨询师们再到这些理论的忠实拥护者们，几乎每个人都万分诚恳的对你循循善诱的摆出一大堆充分或不怎么充分的理由，往往同时还都能列出一个能够有力证明某个模型优越无比的对比列表。所有人的目的只有一个：那就是告诉你唯有他所推荐的模型才是最适合你的。于是乎我们陷入了深深地困惑：到底什么样的过程才是最适合我们的呢？而且，在大多数情况下，当我们满怀崇敬的遵循大师们为我们指引的过程小心翼翼的前行，却发现其终点却远非其描绘的那么的美妙。于是乎，这种困惑变成了一种痛苦。
    
    当然，大师们总是高高在上且充满智慧的，但当他们给我们指引的道路变成一种痛苦的时候，我们就有理由来反思一下我们走上这条道路的理由是不是那么的充分和必要。

把书翻过来——看看文字背后的内容

    当年鲁迅先生从满纸的道德文章后面看到了“吃人”二字，从此让我们学会了原来念书是可以这样念的，今天我们不妨用鲁迅先生传授我们的方法看看这些深奥的过程背后到底是些什么....
    
    首先，有一点是显而易见的，那就是软件开发的管理对任何人来说都是一个绝对的挑战。在这个领域里面，人似乎都是无比的弱智，虽说是条条大路通罗马，但我们似乎永远不能一开始就找到通往罗马最快捷的道路，一没人指点，我们就要在南北极无谓的打N个来回，所以我们必须学习前人们通过无数失败总结出来的成果。虽然前辈大师们给我们指点的通向罗马的道路也分为各门各派...

    然后我们沮丧的看到一个事实：人是不可靠的，正因为人是不可靠的，我们需要用各种各样的方式来验证我们的工作成果，以尽可能的发现缺陷，并及时的修复，其实大师们说的都是一件事情——验证。虽然承认自己的无能是令人沮丧的，有一定是肯定的，那就是：我们需要有效的验证自己的工作——无论是行为还是结果，至于形式是次要的。

    再看下去，我们会发现软件开发在绝大多数情况下应该是个群体行为。所以我们需要沟通和传承，无论是CMM过程中庞杂的文档还是XP中颇为极端的“结对编程”其出发点都是为了沟通和传承，虽然无论是无休无止的编写文档还是两个人坐在同一台电脑前的吵吵闹闹听起来似乎都不能令人心情愉快，但不管怎样，有一定是肯定的，那就是：我们需要有效的沟通和传承，至于形式是次要的。

    接着往下看，我们会发现，人是健忘且判断能力低下的，所以我们要量化的记录我们的所作所为，这不但可以有效的展现我们的工作业绩，更是让我们避免多次掉入同一个坑里。 但不管怎样，有一定是肯定的，那就是：我们需要有效的用量化的数据来度量我们的工作，至于形式是次要的。

    继续往下看，我们会感觉些许的不安，那就是我们会发现这个世界的万事万物是不断变化的，而且其变化的迅捷常常让我们疲于奔命且晕头转向。关于这一点，大师们给我们指点的无非是我们老祖宗——大禹及其前任们治水的那两招：“堵”和“通”，这里的“堵”并不是指完全的拒绝变化——这是不可能的，而是指将所有的变化处于完全受控的状态，CMM应该是这种方式的代表，其通过建立一套复杂而庞大的控制机制使所有的变更都处于受控状态，然而这个美好的愿望却时常因为其笨重的身形和高昂的成本令人不堪重负而无法有效的执行。相对而言XP提出的“拥抱变化”采取的是“通”的策略，这听起来颇为令人兴奋，至少和繁杂的过程以及成堆的文档告别是一件让人心情愉快的事情，但实际操作起来往往并不那么容易，除非你是“大禹”那样的绝顶高手，否则弄不好就会溃堤决口、水漫金山。虽然上述两条路听起来都不怎么美妙，但非常遗憾我们目前还没有第三种选择，个人认为最有效的方式也许应该是首先看清楚是一条什么样的河流，然后再判断哪种方式更为合适，而在某些情况下，将“堵”和“通”结合使用会有意想不到的结果。但不管是采用什么方法，有一点是肯定的，那就是：我们必须找到有效的方法来应对变化，至于形式是次要的。

    所谓“仁者见仁，智者见智”，我相信不同的人遵循着这个方法可以看到更多的东西，但有一个结论是肯定的，那就是我们行为的最终目的是要达成我们的目标，至于确定采取何种行为的标准应该是该行为针对某个特定目标的有效性，而不是它的形式，更不是因为它曾经出自于某个大师。

小结

    时下有一个非常时髦的名词——“驱动”,诸如目标驱动、用例驱动、过程驱动、方面驱动、测试驱动、业务驱动......一时间好像所有人都被这个或者那个驱动得团团转。其实我们在满怀崇敬的拜读大师们的理论和方法的时候，不妨深究一下“驱动”这些理论和方法的东西是什么。任何理论的产生都有其特定的背景和环境，正如“南橘与北枳”的故事一样，一味的照搬别人的东西往往并不是通往理想彼岸的最佳途径，所以我们不光要知其然，而且还要知其所以然，只有这样才能有效的找到真正适合自己的有效的方法。

    也许我们都曾经或多或少的受缚于某位大家的理论或某个权威的模型，但这并不妨碍我们用自己的智慧来探询真正有效的解决方案，相反，没有曾经的作茧之缚，也就没有破茧之后蝴蝶的美丽和灿烂......

行者无疆
Nov. 29 2005

mail: TheWalker@effective-swe.com
MSN: just_a_walker@hotmail.com