有关《大道至简》的几点讨论～

《移山之道》的作者邹欣先生，作了一篇读后，谈及了《大道至简》中的几个问题。相关的问题一些读
者也常问到，因此这里摘了给邹先的回信，也算对一些共性问题的回复。

原文在《移山之道》的官方网站上：
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图中。
这个图的价值，就是理清了工程角色、角色关系以及各自的关注点。