书评 -- 唯有优秀的团队，才有优秀的成绩

随着信息系统的规模扩大，触角深入每个环节。要完成一个信息系统真是千头万绪，若项目的各开发过程有辅助工具，以建立完整的开发架构，让信息团队所有的成员容易撷取各个开发流程所需要的进度评估数据。并有几本书描述各阶段性流程的精神，对应工具的操作方式就好了。

工欲善其事，必先利其器

微软在 2005 年推出了 Microsoft Visual Studio Team System(VSTS)，并搭配新版的 MSF(Microsoft Solution Framework) 4.0方法论。有别于先前的 MSF 3.0 版，4.0 版是以当下最流行的两套开发方法论：「敏捷(Agile)」和「软件能力成熟度整合模式(Capability Maturity Model Integration CMMI) Level 3」为本。期待提供大家整合开发流程的利器。

VSTS 以集中而共享的信息，让团队所有的工作者通透地了解任何一个开发环节的现状。并将抽象的方法论化为实际的模板档案和需要填入的窗体，并以专属的工具程序来完成各流程的需求，随后以报表呈现结果。而藉由此类工具，我们也比较能够发挥敏捷开发的精神，快速地走过各个阶段，让多个团队成员同时并进，一次次递归分析、设计、开发、测试、除错、部署等流程。

虽然整个 VSTS 架构的立意良善，但如此大部头的全套开发流程辅助工具在国内还算开风气之先，这不是一个项目经理熟悉项目建置、程序设计师学会程序技巧，或是 DBA 熟悉数据库架构就可以单兵作战。而是整个团队的学习与工作上的默契培养。向一个团队推广各成员角色独特的理论与技术，然后要成员们再凭着各自学到的新技术协同合作，这让学习与应用本身就是一件工程。

而笔者此次介绍的这本书「软件工程与 Microsoft Visual Studio Team System(原文书名为 Software Engineering with Microsoft Visual Studio Team System) 」，就是描述各开发流程重要的精神。作者 Sam Guckenheimer 是 VSTS 的产品规划师，代表我们各种软件开发人员对 VSTS 的需求。由他来解释 VSTS 的理念再适合不过了。

这是一本讨论 What 和 Why 而没有 How 的书，由于内容较形而上，且知识密度很高，所以并不好读。每每笔者读了一段后，总要停下来印证一下就自身实务上，是否可以此为准则，还是因为办公室政治与文化的差异，导致作者的立意虽好，但会在我们自身企业内水土不服。

增值的软件开发生命周期

相对于现实世界的工程特征(如建筑工程)：

l 重复前一个桥梁、道路或房舍的设计，以降低风险与成本。

l 设计成本较低，建置成本较高，建置过程中不太改需求。

l 采 work-down 工作流程，也就是仔细地将设计分解成多个实做的工作项目，分配资源，并在开工后逐一杠掉已完成的项目，以工作项目的完成度决定进度。

l 适合低风险、低变动以及需求明确的设计，若要以软件种类来模拟，可能企业资源规划(ERP)较为适合。

而软件世界的工作流程并非如此，它的特征如下：

l 若与其它已有的前一个设计近似，购买即可。要自行开发的，通常没有近似的经验，且有很深的企业营运逻辑。

l 需求时常更改，因为商业环境一直在变动。

l 需求明确时，适合 work-down，不确定时，适合 value-up。也就是在周期性的时间点量测客户价值的完成度，但认定需求输入是变动的，并非固定值。

本书强调反复与渐进(Iterative and Incremental I & I)的增值(value-up)式开发流程，希望能够同时整合迅速灵活与责任归属两个面向。

本书涵盖了软件开发大部分的生命周期，除了最后段的发行/上线/维护外，一般的项目管理、需求分析、架构设计、程序开发、测试除错都有专章涵盖。并伴随 MSF 4.0 的主要角色。若你在团队中，刚好身处该角色，可以先熟悉 MSF 所赋予的责任归属。再搭配一步步敎你 VSTS 操做的书，将概念实现出来。

本书在各章都有图解来辅助理论解说，并尽量以故事或实务经验来让论点鲜活。而部分章节以统计图为例证，说明相对的开发流程阶段之趋势分析，以讨论需求的满足、项目的进度、测试的周延、bug 的分布…等等，并描述图表的解读方式与潜藏的迷思。透过一目了然的图示，将让我们更能掌握项目的运作。

软件质量是我们普遍欠缺的，作者以增值思维贯穿全书，并约有一半章节对 bug 深入讨论，这是国内一般软件开发团队所忽视的。书中有趣的论点与作法俯拾皆是，例如他们在收集需求时，有易用性实验，也就是要受测着进入被监控的房间内操作软件，同时大声说出做每一动作的感想，而测试环境会录制使用者操作软件的方式，在检讨时，结合使用者的影像声音一起呈现。

又如管理项目时，使用描述性的，而非规范性的度量。规范性的度量是明白指出达成目标的条件，例如程序设计师撰写的程序代码行数，测试工程师发现的 bug 数，或是程序开发者解决 bug 的数量，这种单一的简单度量长时间施行后，只是鼓励员工钻漏洞，打击做事者的士气。例如宁愿重复复制程序代码，而不撰写成可重用的函数或对象。或是故意埋入 bug 后，再发现并解决。

为了预防上述的弊端，作者强调在周期性开发，逐次达交的模式下，量测的重点应是已完成、有质量、可交付的工作，参照多个量测数据才推测合理的结果，且评比的对象是团队而非个人，不以单一数据而以客户满意度为奖惩依据。

译者的心路历程

本书的译者<personname w:st="on" productid="蔡焕麟">蔡焕麟</personname>先生曾经与笔者在恒逸信息教育中心共事，是位功力扎实的讲师与工程师，本书由他译来，文笔流畅外，更因处处的「译注」，让读者更能了解作者所言的来龙去脉。如他所言：「尽管这是一本写给开发团队所有成员阅读的书籍，但其内容深度对一般开发人员来说，恐怕还是有些过于艰涩、不易阅读，这是我在翻译时经常担心的。作者没有用太多文字向读者解释什么是 Extreme Programming、Agile、CMMI、Scrum...等术语，而是假设读者对它们已经有基础的认识，或者应该自行去阅读相关的书籍、文章。但从软件工程相关书籍的种类与数量，以及各大讨论区、论坛网站的主题大都围绕在程序设计方面的问题来看，台湾的软件开发人员在这方面似乎仍偏重于程序设计的技术面议题，如 ASP.NET、ADO.NET...等。在这种情况下，有些读者或许仍欠缺一些必要的背景知识，再加上 VSTS 又是一项新产品，因此他们在阅读这本书时，可能无法平顺地前进。虽然作者适时地在每章后面加上注释，让读者能够找到相关的信息或参考出处。但是对大多数忙碌的读者来说，恐怕也考验着他们的耐心。因此，我在书中加了一些译注，期望能降低阅读门坎，让读者阅读时会比较平顺些。」

由于 VSTS 是新产品，而以往在微软领域理也少有软件工程论述译作，相信在翻译此书时，名词的选择、陌生领域的术语意义都需揣摩推敲。译者严谨的做事风格让译本如实表达了作者的意念，如他所说：「flow（心流），这个名词出自《快乐，从心开始》。当初为了翻译这个名词，我跑了好几家书店，却都买不到这本书，原来早已绝版，最后总算在图书馆借到。另外，为了顾及翻译的正确性，也尽量查找书中引用到的一些术语的参考文献，如：《戴明的新经济观》、《跨越鸿沟》、《人月神话》、《Extreme Programming Explained》...等等。这样一路翻译下来，让我觉得本书作者真是博学多闻。而当初为了翻译一句话而去买一本书，本来颇觉费事，但也发现自己的视野更加开阔。」

另外，本书的图片也都经由译者中文化了，足见他架起 Team Foundation Server，建立范例项目的数据，以抓取 VSTS 中文版的操作画面。顺著作者的思绪走访一遍 VSTS 的各项功能，定让他更贴切地译出文字，同时也让习于中文环境的使用者在阅读本书时，没有障碍。

阅读建议

本书的第一、二、九、十章是综合的概论，而中间的章节比较偏向软件团队中，不同职称的人所负责的工作。你可以先阅读概论后，接着跳到属于自己工作角色的章节，而后再扩散到邻近工作项目，相信对于整个软件开发生命周期会有更深一层的认识。

在书籍一开始有来自各界一长串对本书的溢美言词(其中还包含了对象导向的巨擘 Ivar Jacobson)，从不同面向褒扬此书，倒也呈现不少软件工程理论、业界认知、VSTS 定位三者间的关系。

相关阅读

最后，本书中，每章都有注释，主要是详列引言的出处，但都可以当作你的延伸阅读。你可以将本书当成建构现代化信息系统的入门指引，而后藉由注释提供的联结，进一步深入各领域。

由于本书仅着重在精神的描述，并未介绍实际的操作，或许你可以搭配一本与 VSTS 逐步使用指引有关的书，例如 Microsoft Press 所出的「Working with Microsoft Visual Studio 2005 Team System」，并辅之以试用 VSTS，将更有收获。

而本书译者的网志有提供该书的试阅与讨论，也不妨去瞧瞧：http://huanlin.dyndns.org/CS/blogs/huan-lins_blog/archive/2006/09/08/sevsts_5F00_freepdf.aspx

译者在以下网址也提供了一些心得和书籍的勘误：http://huanlin.dyndns.org/CS/tags/Books/default.aspx