4)工匠、工艺隐喻
说到工程隐喻,现在大家自然会想到最近出来的《软件工艺》这本书。如果工程的隐喻有问题,那么工艺怎么样?如果工程师的隐喻有问题,那么工匠怎么样?按照软件工艺的说法:“如果项目中的成员不具备执行项目过程所必备的技能,那么纵有世界上最好的过程,也无法挽救项目失败的命运;与此相反,真正优秀的开发者,能够让任何过程,发挥最大的作用。”真的就这么简单吗?
工匠与工艺的隐喻,与工程相对,但是这样的对立,并非如《软件工艺》所理解的那样,是由于不同的复杂程度而做出的不同的选择。如果2000个人年的项目,我们应该采用工程的隐喻,5个人年的项目,我们应该采用工艺的隐喻,那么50个人年呢?500个人年呢?我们是不是有可能将两种不同的隐喻像调鸡尾酒一样,选取适合的比例,然后调制起来呢?这样具有的“颠覆性”的理论,我想作者也没有考虑过如何与工程隐喻相调和吧?
在工艺隐喻中,还有几个特点,质量、培训、高手。
工艺隐喻,意味着工匠(程序员)会在自己的作品上签名,并终生为之负责(这与XP是有区别的)这样就能保证质量。但是我们知道,手工制作就意味着质量无法保证,第一次与第二次不同,第二次与第三次不同,现代工业比起手工业来最大的进步,就是能够保证一个始终如一的质量水平。所谓为自己的作品负责的荣誉感,最多只能保证我能够在“事发之后”找到人来修补,却不能保证我免受这样的损失。软件质量更多的取决于一个开发团队的能力,而不是他们愿意为之负责的决心与荣誉感。如果真的那么简单,中国男足立了那么多次军令状了?早就该有成效了吧?
培训开发人员,当然是非常重要的,但是现在软件开发中较多使用的“新手”,并非“工程隐喻”的罪过。作者设想的学徒的过程,也并不与软件工程相矛盾,这在日本的软件工程实践中,可以得到证实。不客气的说,这样的浮躁,不是软件工程的责任,而是文化的问题。可悲的是,中国的软件产业,较之美国,更为浮躁。
高手是宝贵的,但同样也是稀缺的。一个公司或者一个项目团队,不可能全由高手组成,再者,对于一个项目来说,所有的活都让高手来干,也同样是浪费。在这里还要指出作者的自相矛盾之处。一方面,作者强调“师—徒”式的培训,另一方面,又想把低手从公司里赶出去。那么究竟该怎么做呢?如果一个项目内,低手比高手还要多(这是几乎是必然的)。这样的项目应该如何组织呢?任务如何划分呢?作者没有告诉我们。因为在工艺里面,学徒做的可能是毫不重要的,甚至是重复的劳动,只是为了学习。但是在软件企业,谁来为这样的学徒买单呢?
工艺的隐喻,新则新已,好就未必。这本书,就是那种“用隐喻来思考的产物”。真要照做,只怕危险。
5)敏捷的场景
敏捷开发与其它模式不同,它似乎没有隐喻,但是,还记得我们是如何定义隐喻的吗?一个隐喻是一个完整的场景,这个场景中有很多相互交织的“概念要素”。 当这个场景中多出了与软件开发无关的要素时,就会误导我们。敏捷开发是一个逼真的场景,这个场景不是像软件开发,它就是软件开发,它没有多出任何东西,因此,这样就完美了吗?不,它却少了很多要素。当一个逼真的场景,向你描述了一个成功的,但是却却少了很多要素的软件开发项目时,这样的场景同样会产生误导,会使你认为其他的要素,都是不重要的,至少是可以在大型项目中才需要考虑的。我说的要素,并非CMM的KPA,或者RUP里的关键活动,然后通过剪裁就能得到XP那样的要素。而是指关键的概念,缺少关键概念,故事就会显得虚假,那么在敏捷项目中,缺少了什么呢?时间概念,成本概念以及分工概念。
在一个又一个的迭代周期中,什么时候,项目算是完成呢?这个完成,由谁来决定呢?似乎敏捷开发面对的是一个User Story集合,多一些,少一些,都没关系的。如果用户给定时间,功能的多少,就得由开发人员决定。反之,如果用户要求必须数量的功能,开发时间的多少就得由开发人员决定。这样的项目,可以说简直没有压力,这是咱们梦寐以求的项目,但是这可能吗?
再说成本概念,同样的道理,合同是在开发开始之前签订的,但是按照敏捷开发的场景,能开发出多少东西,需要多少时间,都是不一定的。那么成本如何确定?如果成本无法确定,这个合同可能就会有一方要吃亏,这样的合同,谁去签呢?
再说分工概念,敏捷开发是程序员提出的,而且完全是从程序员的角色出发,在他们的故事里,除了用户,就只剩下了程序员,你也许会说,还有项目经理呢!但是,那只不过是一个名称而已,他不过就是一堆程序员里最有权威的那个。那么其他角色呢?你在敏捷开发的故事里,看不到界面设计人员,看不到独立的、专职的测试人员,看不到数据库管理人员(随着设计的浮现,也许项目进行到40%时,程序员中会有一个人,转而承担较多的数据库管理的职责,但是这并不一定)看不到产品经理,看不到用户手册的编写人员,看不到客户培训人员(XP认为客户会和程序员一起工作,但是那些没来的可能谁去培训呢?)也许XP的支持者会说,“嗨,我们又不是要开发巨型项目。”但是我要说的是:“不管有多大的项目,一定会有不需要、也不应该程序员做的事情。”作为一个软件开发的方法论,就必须包含对这些工作的探讨,一个完全从程序员本位出发的,不考虑其他工作的方法论,不是一个完整的方法论,这样的场景如果被普遍模仿的话,也是相当危险的。
6)银弹隐喻
《没有银弹》如此著名,以至于无论它的赞同者还是反对者,都无法回避它的存在。但是银弹究竟是什么呢?“没有银弹”究竟意味着什么呢?
首先,“银弹”是一个隐喻,它的本意是能够杀死人狼(一种怪兽)的武器。用在软件开发里,银弹是什么,用通过追问“什么是软件开发中的人狼”来得到答案。在一个项目中(在一个村庄里),出现了一个困难(出现了一头人狼),如果任由困难存在,项目就会失败(如果没有办法赶走人狼,村民就会受害),一种方法出现了,解决了这个困难,项目成功了(银弹出现了,打死了人狼,村民获救了)。所以我们可以这样理解:银弹就是能够保证项目成功的方法。但是,如果Brooks真的这样简单的推出自己的结论,那么大家都会说;“废话,谁不知道,没有一种方法能够保证项目的成功?”Brooks的水平当然远不止此。但是很多人对《没有银弹》的理解,却事实上到此为止了,然后他们就拿着这个结论,四处“传道”开来。
Brooks更进了一步(或者说退了一步),他将保证项目成功的目的,弱化为提高项目效率的目的,并且给出了一个看起来能够量化的标准“单一技术,十年之内,提高十倍以上的效率。”(可靠性和简洁性根本无法量化,咱们先不讨论)
但是,我们知道,如果一个论断无法证实,又无法证伪,这个论断就毫无意义。那么我们如何能够检验他的这个论断呢?首先我们要能够明确,什么是单一技术?软件工程算单一技术吗?CMM体系算吗?CMM里的一个KPA呢?UML算吗?设计模式呢?XP呢?还是XP中的结对编程呢?怎么才算单一?没有界定!也无法界定,包括Brooks,也不能告诉我们,什么算单一技术?
然后我们还要确定,如何比较开发效率,如何量化?严格的说,必须证实两组能力,知识水平,人数,了解的信息都完全相同的人马,在互不交流的情况下,同时开发一个项目,都达到了一组项目的目标(即不是不够,也不是超过),然后两组人的开发时间,是否相差十倍。
再者,当我们要证明单一技术的功效时,必须保证这两组人马只在这一项技术上有区别,其他都一样。
最后,当我们要证明十年之内的差别时,还要保证十年后的这组人马,与十年前的那组人马使用相同的软件、硬件设备。(十年前是什么操作系统?WIN32?CPU呢?486?)这样的研究,才能够算是精确的验证。但是这样的验证,没有,也不可能有人去进行,自然这样的论断也就毫无意义!
可笑的是,居然有人,当真去寻找银弹的证据,并且兴奋的宣称找到了,最近还有一家著名的公司,出版了一本的著名的杂志,名字就叫《银弹》!但是,最可笑的还在于,Brooks居然还写了一篇《再论没有银弹》,宣称自己的论断,已经基本上成立了。
如果事情到此为止,那么Brooks也不过就是跟大家开了个玩笑罢了。但是Brooks更进一步指出:“软件开发分为根本问题与次要问题,根本问题占软件开发的90%的比重。而且很难被很好的解决。”一方面,我们要说:“这样的认识很有必要”,另一方面,我们也要说:“这样的论断,毫无疑义。”因为它既不能被证实,又不能被证伪。90%从何而来?如何证实?我们无法得知。我相信,10年,10倍,根本就是他随口说出的一个数字,同样的,90%也不过是一个“印象”。当不得真,作不得数,也无法用来指导我们的实践,更无益于我们提高软件开发水平。这样的玩笑文字,竟然风行世界,备受瞩目,的确是软件开发的方法论,还处于蒙昧的“隐喻时代”的最好证明!
(未完待续)