有关《大道至简》的几点讨论~
《移山之道》的作者邹欣先生,作了一篇读后,谈及了《大道至简》中的几个问题。相关的问题一些读
者也常问到,因此这里摘了给 邹先的回信,也算对一些共性问题的回复。
原文在《移山之道》的官方网站上:
http://yishan.cc/blogs/xin/archive/2007/09/15/693.aspx
==回信摘要====
Q2.a : 过程和工程是紧密联系的,RUP 和XP 这两种"过程"对于"工程"中的需求管理,过
程管理的要求很不一样,另外,"模型与模型语言"似乎更靠近"方法"。
========
EHM图是试图割离各个工程元素,而不是强调它们之间的复杂关系。因此它每个层次上所用的概
念名词是较为狭义的含义。例如过程中的模型,主要强调的是过程模型以及过程中为完成过程沟
通而用的模型语言。事实上,以更广泛的含义来看,过程、工程、组织等等都有各自的方法和方
法论,也有各自的模型或模型相关工具。而这种复杂的关系,是EHM图所不描述的。
关于这一点,第十章第一节是一个补述。事实上整个第十章都是查漏补缺,弥补一些此前章节中
因为偏激或专注于细部而忽略掉的、掩饰掉的问题。这也是这一章前的引语所表达的意思。
Q2.b 模型还是要有用处的,作者不妨讲讲不同的人应该能从模型中获得什么。
========
的确啊。但这本书对致以实用的种种方法,都没有加以细述。这个问题后面我再细加解释。
Q2.c 已做在勘误里了。谢谢指正。
Q3.第30页中的图:为什么"项目经理",属于开发团队,但是还有一个独立的"品质部门"?
我认为"品质部门"的项目参与人员应该属于开发团队。
========
独立的"品质部门"这种模型,是以项目产出为主要关注点的公司可能采用的模型。例如盛大
这种游戏公司,既有专门的产品测试部门,又有专门的用户体验测试部门。这些是面向客户的、
最终产品的。这种部门的建立,对于同类型的大批产品,由同一个部门负责,也由同一个主管
管理,反倒是更容易控制品质的。但是这种品质部门并不适于项目过程中的单元测试或模块测
试等。R模型是一个极简化的模型,并没有考虑项目内部的一些细节问题。它事实上更多的是用
于分清角色。
Q6.90页,图7-3:似乎"方法"应该在"工具"之上。方法有具体,抽象之分,这里讲的是一
个程序模块设计的方法,还是软件工程的方法论的方法?
========
这个图直接摘自《软件工程——实践者的研究方法》。我想它的意思是指:工具是方法的具体实
现;工具依赖于具体的方法理论。我刚查了一下原书,原文中说的是"工具对过程和方法提供自
动或半自动的支持"。
Q7. 94页,Boss 问题:谁是Boss?……
========
这个问题很有趣。我想您的意思是:客户是BOSS。这个答案也对。但在国内的很多公司里,第一
的问题并不是给客户提供服务,而是让公司生存下去。在这种境况里,Boss大概比客户还要急,
还要更可能对着程序大牛们咆哮。二者的问题其实是一致的:项目团队服务于谁。从项目角度上
看,服务于客户;从公司经营上看,服务于战略方向。我想对于国内的大多数团队,还是后者更
为紧迫的。
最后,则是关于这本书的定位的。
《大道至简》一书原本定位就不是一本可以即学即用的书。它讲方法,但没有哪一个方法能直接
应用于实践;它讲工具,但并不教读者亦步亦趋。我在书中所言讲的方法与工具,都是从批判的
角度来讨论它们的价值的。根本上来说,是两个观点:
-方法是可以被创造与再创造的,而不是拿来死用的;
-工具是有应用限制和应用理论的,不要迷信工具的强大。
这本书讨论方法从何来、工具的本质、工程、团队、角色等的关系。但是它没有任意一处是围绕
某种实用环境来讲述的。所以,邹先生希望这本书能讲某个具体东西的好处、用处或用法(例如
模型),而这正是本书不讲的。在这样一书只言思想的书中,任意一个确实的东西都会成为误导。
在这本书中,我回顾了我所知所见、所思所想的东西,把这些东西整理了清楚,放在了EHM图中。
这个图的价值,就是理清了工程角色、角色关系以及各自的关注点。