也谈瀑布模型与敏捷开发

 

 

    最近在敏捷中国发起了一场关于瀑布vs敏捷的讨论，论者纷纭。虽然争得热闹，但我个人认为，这样一个题目对于瀑布模型而言，本身就是不公平的。这样的一种比较，就好像拿现在的好莱坞大片去与上个世纪六七十年代的电影比电影特效，显然，现在的中等水平的电影特效，就完全能够超过《星球大战》的巅峰水平了。瀑布方式本身就是软件工程理论还处于草创阶段的产物，如何能与糅合了大量实践与工程理论的敏捷方式相比呢？

 

    我很赞同O6Z的方式，采取追本溯源的方式，先找到各自的源头，所谓“正本清源”，在了解各自产生的背景和目的后，方谈得上对这两者之间的客观比价。不弄清楚这些，就先争论谁是谁非，结局只会造成敏捷的粉丝们与反对者两大阵营的“掐架”了。

 

    说道瀑布模型的来源，O6Z说瀑布模型不是首先被作为一种正面模型被提出的，而是是作为一种失败的模型被提出的，这倒是让我这个瀑布模型的无知者有些惊诧了。不管正确与否，我们必须承认的一个事实是，瀑布模型在过去的数十年曾经风光无限，按说，存在即是真理，我不认为能一棍子打死，因为出现了例如螺旋型、 RUP以及敏捷，就使得瀑布一无是处了，这不是科学的方法。

 

    实际上，O6Z提到的几点认识非常好的概括了瀑布模型的适用场景。事实必须承认，瀑布模型已经逐渐离开历史舞台，但谁都不能否认瀑布模型其实开创了软件工程的一个时代，科学合理地将软件开发划分为需求、设计、编码和测试等多个阶段，解决了工程化的问题。尤其是目前采用的一些重型开发模式，例如RUP，实际上仍然可以看作是演化版的瀑布模型。

 

    坦白说，我是敏捷方法的支持者，但我始终认为，无论哪种方法，都没有绝对的好和绝对的坏，而必须因地制宜，因人而异。瀑布模型由于其过程的不可回溯性，自然决定了它无法应对需求的变化，对软件开发过程无法及时反馈与修改，或者说对于应对变化的成本较大。然而，如果对于一个团队，假设团队成员都是一些顺从、忠诚与诚恳地人，他们具有非常强的编码能力，习惯按照标准与规范作事，但他们却缺乏天马行空般的想象能力，以及那种独立与自组织的意识与能力，那么你认为在这样的团队推行敏捷还会有好的结果吗？或许说，这种团队是否过于假象化了，有这样的团队吗？事实上，这样的团队不仅有，而且太多，甚至完全超过了那种敏捷团队的数量。尤其是在软件外包领域，那种软件工厂培养的代码工人，实际上很难按照敏捷的方式做事。这个时候，采用瀑布模型可能会是比敏捷更好的模式（不过，像这样的团队，我更倾向于将快速原型法和RUP结合。）

 

    这就引出我一直在思考的问题，那就是传统的软件模型（不仅是瀑布模型，也包括螺旋和RUP），他们的组织架构可以认为是基于角色化的层次组织架构。在这样的团队中，各种角色各司其职，处理技术与管理的任务，例如PM、SA、BC、SE、CM、QA等。这样的团队更像是一台机器，各个零部件能够有条不紊的协作，他们共同遵守一些标准、流程。每个人都明确自己的职责，但如果要求他们独立为自己分配任务，或者跨角色执行工作，就有些勉为其难了。诚然，这已经是一种相对较为落后的组织方式，或者是一种僵化的运作模式。但现实是这样的团队仍然存在，如果不能从根底里改变软件人才的培养模式，仍然会有许多所谓的“代码工人”出现，这样的一些人总是处于金字塔的塔基，人数众多，生产力受到的约束也最大。这一角色天生是与敏捷开发水土不服的。

 

    至于敏捷团队，我认为它就是一种去角色化的扁平组织架构，虽然它也有类似于PM之类的角色，但更倾向于团队成员之间的平等。例如在Scrum中，就将团队定义为一个角色，在这样的一个角色里，成员既是设计师，又是编程人员；既是UI设计者，又是测试人员和数据库专家。同时，他们能够自组织自己的团队，分析需求的实现，了解并安排进度。他们之中，即不允许墨守陈规，做老老实实的“遵循者”，也不允许那些总是突发奇想，不切实际的“牛仔程序员”。

 

    假定已经存在这样的两个团队，如果让他们的开发模式互换，会得到怎样的结果？大家可以想象。

 

    所以我的意见是，即使你是一个狂热的敏捷支持者，或者执着的敏捷布道者，在你推行敏捷方法的时候，还需要认真分析你要面对的团队，以及团队的人。很多时候，人才是最重要的。就像之前提到的电影比较，如果比较特技，自然是现在的电影水平更胜一筹，但为何许多翻拍电影却会遭遇票房滑铁卢呢？除了源于人们的一种怀旧情愫之外，恐怕演员的演技是其中最重要的。须知，《罗马假日》或许是可以复制的，但世界上却只有一个奥黛丽·赫本，她才是独一无二，无可替代的。软件工程何尝不是如此呢？

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13770856/viewspace-237874/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13770856/viewspace-237874/