移山之道—VSTS软件开发指南 (2009 年度畅销榜NO.1475 )

发现《移山之道》还有个官方讨论区，http://yishan.cc，作者在上面很活跃啊，可以去问问题:)

发现《移山之道》还有个官方讨论区，http://yishan.cc，作者在上面很活跃啊，可以去问问题:)

按：这是邹欣老师的一个学生写的一篇关于《移山之道 -VSTS软件开发指南》书评。从学生和普通软件开发者的视角出发，重新解读了隐藏在文字背后的作者想要传达的关于软件开发的理念。

邹老师写了一本书，名字叫做《移山之道 -VSTS软件开发指南》(在线支持和社区)。
在n久以前，我和几个同学曾经经历一个失败的项目，结局很简单，在经历了两周的设计之后，投资方因为没有见到可运行的代码而停止了项目。现在想来，那个时候的项目从运作上来讲有太多不成熟之处，而即便是学软件出身的我们，也更多的、过早的、不合时宜的陷入了种种细节，缺乏适当的控制。最尴尬的情况是，在项目组所有成员几乎全部定位为程序员（dev）的情况下，两周短短的时间我们陷入了UML的设计，和各种出错机制、接口的讨论，而负责投资的Fujian老板，期望的却是一个可以运行的快速原型系统。那个时候，我清晰认识到，虽然每一个人心里都有一个共同的目标，就是可以真正run起来的软件，但是在真实的环境中，要达到这个目标，需要的工作还有很多。绝对不是几个会照着书，写几行sample code，欣欣然的软件小子可以搞定的。
MS2是一次珍贵的经历，原因也很简单，一个完整的软件开发流程，一套完备的角色分担和项目控制，一个可以运行和评估的软件系统。难怪在MS2的总结汇报会上，我们的院长，开发过国内CAD大型系统，写过一本厚厚的《计算机图形学》，国家自然科学基金副主任的孙家广院士，会潸然泪下。是的，没有比团队合作，团队成长以及团队的成果，更让人激动不已的事情了。
软件开发，真正的“玄机”在于合作、机制和管理；语言和工具倒是相对中立的部分。很多人看了C或c++的教科书，觉得编程很容易，觉得做程序员很容易。是的，没错，那是教科书的责任，将复杂的东西浅显易懂，但是敲几行sample code和开发软件产品的差别，就像是在游泳池里学习蹬腿，和成为海岸警卫队的水下救生员一样，差别巨大。在一个软件开发的过程中，如果你之前没有解决过类似的问题（换句话说，就是没有经验），最常见的疑问就是“现在这样，我该怎么做？”“我的项目现在的问题是什么？”“我的团队现在问题是什么？”“为什么现在的进度比预想的要落后很多？”“这个决定该怎么做？”“我应该做到什么样的程度，才算是做好了工作？”“别人（同事）需要我的什么工作来支持？”……等等。我并不要将软件开发上升为玄学（所以我加了引号），或者其它什么神秘的事情，相反，如果懂得适当的方法，包括合作、机制和管理，它是相当简单的过程。工程性强的一个特点，就是其本身的复杂性，无法用形式化的方式概括，从而抽象化为理论，依靠n维的输入矩阵，就能计算出最后的to do or not to do（哇噻！好多o），它更多的是依靠经验。不可能每一个人都需要花十年的时间去获得相类似的经验。现实中有很多人，他们努力将自己的经验和盘托出，著作成书，为了让他人更容易、迅速的获得经验。Xin就是其中的一位，《移山之道》也正是这么一本书。
邹欣老师在他的新书中，以一个虚构小说为框架，介绍了一个完整软件开发的故事，其中以微软的MSF软件开发流程为基本，辅以微软的软件开发管理工具VSTS。这样的风格，在以往的软件工程相关的书中都很罕见。一些正规的软件工程教材，虽然有很多实际的经验介绍，以及漂亮的彩图，但是还是会在课堂上引起我很多的瞌睡。如果你正遇到上述的一些问题，而没有办法解答时，何不来尝试在本书中找到答案。Xin在书中的第一部分介绍了Visual Studio中VSTS套件工具，如果你的团队以MSF的软件开发过程模型作为指导（其它的模型也无所谓，也可以成功，甚至没有模型也可以成功），那么VSTS正是契合的工具，它们都来自微软的开发团队，他们的实际需要、经验和工具。它是帮助团队管理项目进展以及日程工作安排的好工具。第二部分主要是提高个人能力，和尝试最佳合作。每一个团队成员（特别是新手，或者孜孜不倦的人）都应该清醒的认识到这一点。第三部分详细介绍了，项目在不同阶段，主要的任务，可能的问题以及解决。
当然，全书的关键词着落在：角色、流程、管理、工具和合作，如果你没有看出来这些隐藏在文字背后的关键字，可能是你还没有适当的软件开发经验，或者带着实际的问题来看本书。有经验的团队成员，无论是PM，还是dev，或者test，从目录中就可以嗅出对应内容的概要和价值；如果其中的一些内容正好和你现实中遇到的问题相似，那么你也一定会跳起来的。本书人物的性格以及对话，相信都是Xin在实际经验中的积累，或许曾经就有某些人，表达过类似的看法和观点，被Xin收录其中。这些问题，如果你现在正带领某一个团队进行开发，都可以被拿出来重新讨论，或者验证。
我是一个普通的程序开发人员，以前是一个学生，做过程序开发人员、测试人员，现在是团队的QA兼SDET。读这样的书，会找到共鸣（知道的），学到经验（不知道的），相信随着工作的深入，这样的机会会更多。很多人都认同这样一个观点，中国现在缺乏软件的管理人才，以

引子
===============

大概是因为列在博文的作译者清单里的缘故罢，我常常能在第一时间得到有关新书的消息。这本《移山之道》的消息在《大道至简》出版前我就知道了。当时也是心中忐忑，因为同样是一本言“道”的书，同样以愚公移山为背景，同样讲软件工程……邹欣先生在博客中说这“车”撞得他眼冒金星，其实我又何尝不是如此？哈哈～于是当时便想着：等《移山之道》出版了一定得好好看看，是不是好书不论，评论的心态要先调整好。。。。

还没想好怎么个调整法子，书就到了手上；还没看到第一页，书就被同事抢去了。有些事往往如此，来也没个准备，去也没个准备。不过这被同事抢走的事实，让我知道：无论如何，这一定是一本受欢迎的书。

　
　
一、VSTS之源：MSF
===============

一本书，最怕写到糊里糊涂，自己说不明白别人也读不懂。我写书，所以便常常这样提醒自己。今天读到邹欣先生的《移山之道》，第一篇便说到这样一句话：

---------------
问渠哪得清如许，为有源头活水来。
---------------

书的开篇便解了我久久以来的疑惑：如何把一本书写清楚。这句话摘自朱熹的《观书有感》，所以说的是读书者如何“看书的‘清如许’”。同样一句话，简略下来就是“有源则清”。

书名“移山之道”并不是哲学的“道”，简言之就是“法子”。所以本书原本就是在讲“移山的法子”。作者将软件工程（的具体实施）寓作移山之艰，在这万千艰难中，作者给了的“法子”是两个东西：MSF和VSTS。前者，是思想理念，后者则是方法工具。

注１：我向来不直接讨论一个方法、思想的好或坏，因为这种讨论总是宥于某种具体的背景或范围的。所以我这里也不对MSF和VSTS直言好恶，我们这里只说书。


说实话，在读邹先生这本书之前，我与书中的“果冻”一样，面对MSDN上的“官方绕口令”大感困扰。基本上来讲，我除了知道“MSF/MSA是微软的工程理论”之外，没有从那些绕口令中得到任何有价值的信息。而这样的知识到了《移山之道》里，变成了“白话MSF”。一句话：就是微软推荐的做软件的方法。

再简而言之：一种方法。如同敏捷方法一样，MSF方法也有几个“基本原则”——好象从敏捷之后，工程理论都是先谈“原则”的。《移山之道》一书除了讲述这些原则之外，也讲述了他们在VSTS中的映射——一些具体的功能。

这大概就是前８章的内容了。其中前４章是我推荐阅读的部分。

　
　
二、移山之道，源出务实
===============
第二个该读的部分，则是１２章之后的内容。这本书构建了一个虚拟的项目，并且围绕一个完整的项目过程“导演”了一出实战的大戏。我们可以清晰地看到每一个工程角色在这个戏目中的表演、心态，甚至神情（因为有很漂亮的插图）。

我们常读到一些讲工程实施的书籍，大概都是讲某种工程方法、工具或过程理论的条条框框或者（界面）操作指南。读者看完，大抵是既不见得能懂，也不见得会用的。凡是这些，都必须要放在具体的工程环境中，读者才会发现问题。而一发现问题，读者要么畏难而弃，要么以大无畏的精神一通乱撞。工程中不能活用的，大概都是这样的状况了。而《移山之道》则是切切实实的讲工程场景的，讲具体场景下的应用方法的。所以，你会看到类似这样的语句：
---------------
同学：对！我们要用全（敏捷开发模式的）５个工作项类型。
……
阿超：当敏捷模式变成强迫，那还能敏捷到哪儿去呢？
---------------

又或者一些应时应事的实战法门：
---------------
……
同学：你说得在理，但是老师让我们用全套敏捷模式，我们怎么办？
阿超：你们可以回去告诉老师说这是最新的“移山精简开发模式”，填补了国内外空白，（大牛、超人和理论家们都一致说——这是我加的^.^）很好用。
---------------

这样的段落看了是非常过瘾的。如果遇到这种连具体工程是什么都不知道，就要求“用全套ＸＸ方法、ＸＸ模式、ＸＸ过程”的那些工程角色时，这常常是可以派上用场的。

　
　
三、怎么读这本书
===============

这本书的内容可以分成好几个部分：
　１、VSTS与MSF基础
　２、团队角色的基础素质
　３、工程实战的细节与处理方法
　４、阿超的故事
　５、用好VSTS

一般的读者，大概可以把本书当成VSTS的快速指南，所以可以用它来学学VSTS以及MSF。毕竟如宣传所言这是“第一本由微软VSTS一线开发人员所写的原创精品”。同样的道理，对于一个工程团队来说，也不妨用这本书作为团队成员的一般性读物。另外，如果你的团队的“个人技术和协作精神及技巧”尚有待启蒙（在我看来许多人有此需求），不妨看看本书的第二篇（９～１１章）的内容。

但如果这样读这本书，大概是暴殄天物。因为这些大概是１、２、５三个部分的内容，只是书中所述的末节，远非精要。

我读这本书，看完前四章，全书的思想基础与行事原则就已经了解了。接下来，我大概都是在看书中以阿超、大牛、果冻等虚拟角色之间的对话，我称之为“阿超的故事

这里有一个书评

http://www.ms2.cn/blogs/alex2006/archive/2007/08/27/9566.aspx

既讲了原理也讲了具体使用,由浅入深,对初学者很有帮助

在 www.yishan.cc 有更多的内容。读者可以通过这里或yishan.cc 的评论渠道提供反馈。谢谢。