小型软件团队过程改进方法 (一)

小型软件团队过程改进方法

一、从方法到编码

软件管理与软件开发是截然区分的吗？

关于项目经理来说，其职责是软件项目的管理，而关于架构师、

编码人员来说，其职责是软件设计与开发。尽管在一些小型的团队中，

这两种职责有的时侯候是同一个人担任的，但两种角色的区分是必要

的。从事过软件开发的人都能或者多或者少的感受到软件管理与软件

开发之间客观存在的沟壑。

我常常听到来自两个方面的声音。一边埋怨说设计师、编程人员

阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边埋怨

软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。

现代的方法学理论与相应的过程实践为我们奠定了软件开发科

学管理的基础，个中的翘楚包含RUP与XP,纵观这些方法、过程，

都非常强调过程的流畅、生命周期的连续c而在实际的应用中，我们

却常常能够看见对它们的不恰当的懂得，不正确的使用。特别是那些

希望在自己的软件团体中引入新型的方法过程新手们。关于他们来

说，最容易犯的一个错误就是忽视了如何利用一个软件过程来制造一

个成功的软件。

关于如何建立一个软件过程的资料很多，但是这些资料并没有把

为什么需要过程，过程的目的是什么之类的问题说清晰。而这些资料

的读者们，往往需要花费大量的时间，亲自进行实践之后，才能获得

这些问题的答案，而付出的代价是教训与挫折。同样的，我与我的伙

伴们也经历了这样一个过程。因此，我希望把我在过程应用、过程改

造中涉及到的问题例举出来（使用过程模式的方式）。假如大家能够

利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，

本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设

计、编码等方面的内容。但是本文中所讨论的内容都能够对以上的活

动起到部分的指导作用。

敏捷？敏捷！

从开始研究软件工程，我就对敏捷过程的概念情有独衷，但是随

着学习的深入（所犯错误的增多），我发现敏捷是无处不在的，她是

一种尺度，一种处于"混乱〃与“死板”之间的平衡艺术。有句俏皮话说

的是"一放就乱，一管就死”，这句话很好的点出了软件过程的一种无

奈性。假如没有严格的规定，软件开发就陷入一种混乱、无序的状态,

但是假如制定了过于严格的规定，软件人员的思路又受到极大的约

束，管理成本也随之上升。敏捷正是一种处于两个极端之间微妙平衡

的艺术。这种艺术难以完全表述，但是能够通过一些指导，来帮助大

家达到这种境地。

因此，我们能够推想的到，敏捷是见仁见智的。每一个软件团体

都有自身的特性，其敏捷过程必定都不尽相同。如何设计出成功的敏

捷过程，来保证软件团体的成功呢？本文通过一些过程模式的讨论，

掀开了问题的一角C关于过程设计的完整的讨论，大家能够参考敏捷

软件开发［AlistairCockburn］一书(该书近来将有中文版面世)，

该书全面的描述了过程设计的来龙去脉，与如何根据组织的特点来选

择适当的过程。

因此，尽管本文中并没有特别提到敏捷的字眼，但是所讨论的内

容无不在敏捷思维的范围之内。

MDA推动软件可重用框架的建立

我有一个梦想，希望有一天能够不用在诸多的平台之间摇来摆

去。虽说Java语言的口号就是跨平台。但事实上，我们还是无法完

全摆脱平台的束缚C

在UML2.0的规范中，提到了一个MDA(ModelDriven

Architecture)的概念。在众多的软件平台中不知该如何选择，已经

演变为当今软件开发的要紧难题。MDA的存在目的就是为熟悉决这个

问题。通过MDA技术，一个UML的模型能够是平台无关的，称之PIM

(Platform-IndependentModel),也能够是与特定平台有关的，称

之PSM(Platform-SpecificModel)o利用平台技术的软件商，能

够专注于自己的领域，集中描述业务功能，业务规则，而无须考虑特

定的技术，构建出一个PIM,然后，通过支持MDA的工具，将PIM转

换(通过不一致Profile进行映射)为一个或者多个PSM。这时候的

模型仍然是UML的c但是，这个转换过程尽管有工具的辅助，但仍然

需要外力的介入.接下来，开发工具将会从PSM中产生可执行代码°

这就是MDA的思路，它把以往以程序为中心的开发模式转变为以设计

为中心的开发模式C

Finance

以往的重用，往往是基于代码的，比如算法的重用、界面组件的

重用，却往往没有将重用提升到设计的层次上。MDA为我们建立可重

用的框架提供了一个很好的指导。注意上面的这副图，最外面的两层

就表达了MDA能够用于设计重用的基本理念。倒数第二层的含义是利

用MDA来进行通用软件（比如事务、目录服务）的模型设计，倒数第

一层则表示MDA能够用于特定业务领域的设计建模。能够想象，今后

软件公司中的最有价值的资产，就是这些设计模型。

本文并不打算全面讨论MDA,除了简单的介绍MDA的思路之外，

更重要的一点是企业可重用框架的建立。软件企业的核心在于知识，

如何有效的将人脑中的知识存储起来，并不断的使用与进展，是软件

企业成功的关键.本文提到的可重用框架，指的就是将软件开发有关

知识存储起来的框架。这个思路是本文的一个核心思路。在本文看来,

可重用框架不但包含了设计模型，还包含了过程与方法。软件开发是

在这个框架之内运作的，同时反过来影响着框架的完善与改进。

过程塑造模式语言

下述的模式都是从软件开发过程中，围绕着可重用框架的建立

整理出来的一些经验，之因此整理为模式的形式，是由于这种方式

有利于类似情况的鉴别与对其进行必要的扩展。在软件开发中会遇

到各类各样的问题，以上模式中讨论到的问题都是我们在实践中，

或者是与其他开发团队沟通中反复遇到的。因此坚定了我们将之整

理为模式的信心。目前我们得到的模式并不多，但是随着经验的增

力口，我们会得到更多的积存。

本文介绍的模式都比较注重权衡的艺术。我们认为这是敏捷思维

的必定结果。世界上并没有什么绝对的情况，特别是目前多变的社会

中，昨天的标准并不适合于今天的环境。因此，我们的平衡点也在不

断的变化。

•将实现与接口分离，即把如何做隐藏起来，而把做什么展示给

客户。

•继承与多态使得我们能够在一个抽象的层次上（基类与接口）

思考问题，并能够根据现实的需求进行灵活的调整（子类与实

现）。

•通过设计模式与设计技巧的应用，能够有效的降低系统的不一

致部分之间的耦合度。特别是简化客户端的代码。

在使用与比较过几种开发语言与开发环境之后，我们发现，事实

上最关键的并不是使用什么样的面向对象语言（或者环境），关键的

是你运用面向对象思维的能力，或者者说对现实世界的懂得、抽象、

映射的能力。这种能力决定了你的开发水平的高低，而语言与环境只

是一种重要的实现手段与工具而已。而这种思维能力，尽管能够通过

例子与讨论来进行介绍，但更关键的还是在实践中进行练习。在本文

讨论的模式中，我们会夹带的对这些内容进行讨论。由于我们认为，

开发思想与开发过程是无法区分的，否则，你的开发过程就没有灵魂。

这也是我们的主题所要强调的：从方法到编码，铸造起一个敏捷的、

流畅的过程，才能够保证开发过程的成功，开发软件的成功。

此外，本篇是总论性文章，在撰写此文时，该篇事实上是最后完

工的，因此，建议大家在看过全文之后，假如还有耐心，能够重看此

篇，相信会有另外一番收获。

现在请大家进入我们的模式之旅。

在软件过程中，我们如何保证信息能够得到正确的传递呢？我们

用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中

处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保

证投入的最小化呢？

1、意图

软件开发过程是知识传递、知识转换的过程。注重知识转换中的

完整性，保证知识通过各个阶段与活动，顺利的转换为软件是极为重

要的。

2、示例

元朗公司是国内某银行的下属企业。从年初开始，公司就投入了

大量的人力为银行开发新版本的国际收支系统。考虑到这是一个非常

庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人

员有些来自于其它的项目组，有些人员来自别的公司。为了保证开发

的顺利进行，项目经理引入了软件过程。但是从一开始，烦恼的情况

就出现了。项目组中的技术人员与银行的领域专家之间不断出现意见

相左的情况。要紧的问题是后加入的员工对目标领域不熟悉，难以配

合领域专家的工作°最糟糕的是，某些领域专家身处异地，因此在需

求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，

进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已

定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析

阶段不得不在原先的基础上延长了50%的时间。在进入设计与编码阶

段之后，问题少了许多。但在设计到编码的过程中仍是出了一些烦恼,

原因是新加入的人员不熟悉开发团队的设计风格。通过一番周折，问

题基本解决了。可等到项目进入到测试阶段，矛盾一下子就凸现出来

了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定

性为无法满足需求的严重错误。通过对错误的复审，排除了其中1796

的严重错误。通过分析，发现其中70%的错误都是发生在后加入人员

负责的模块中。而产生大量错误的一个要紧原因是在编码阶段，由于

银行启用了新的会计制度，导致大量模块被修改，由于时间紧迫，因

此没有进行正规的需求调研。现在看来，领域专家与技术专家对同一

个问题的懂得并不相同。最后，项目的开发周期延长了40%。

3、分析

软件过程每经历一个阶段，就会发生一次知识转换的情况。这种

转换是由人来完成的，这就是像是接力一样，一个人把脑中的知识以

某种方式传递给另一个人，再有另一个人传递下去，直至编码人员把

这些知识固化在最终的软件中。在软件成型之前，知识的要紧载体是

文档与模型。我们称它们为工件(Artifact)o比如，需求阶段时，

领域专家在技术专家的帮助下，将自己脑中对领域的认识传递给技术

人员，并最终形成需求规格书或者是用例模型。而在分析设计阶段，

技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分

析模型、设计模型、数据模型等工件。最后，在编码阶段，编码人员

把这些工件中隐藏的知识转化为软件的形式。通过测试与部署，软件

将会交付到用户手中。这是非常典型的软件开发过程，再简单的软件

开发也需要经历上述的这些阶段。

能够看到，在上述的软件开发过程中，知识形式发生了两次的重

要转换，知识所属角色也改变了两次。知识完成第一次的形式转换之

后，将成为需求规格书（或者同类工件）的形式，知识从领域专家的

脑中转换到技术专家的脑中。然后，知识开始了第二次的形式转换，

形成设计模型（与同类工件）。随着知识从技术专家转移到编码人员，

知识转换为其最终的软件形式。在这些转换的过程中，最容易出现信

息遗漏、信息失确实情况。保证转换过程中知识的完整性与正确性，

对软件开发具有重要的意义。

4、问题

假如保证转换时知识的完整性与正确性？

5、方法

知识转换的主体是人，因此我们要紧的计策也是针对人来展开

的。我们明白，软件过程的特点就是：越早埋下祸根对项目的杀伤力

越大。因此我们首先需要重点防范的对象应该是在初始需求分析阶

段。需求分析阶段涉及的知识非常的多，大家假如有兴趣能够参看我

的文章一需求的实践。但这里我们重点的任务是找出需求分析阶段中

发生知识转移的关键点。

领域专家与技术专家是需求阶段中最重要的两种人，不论你的项

目与团队规模属于哪一种层次，一定都包含这两种角色。假如你的团

队中领域专家与技术专家是同一种人，那么恭喜你，你能够不用阅读

这一段的内容了。惋惜在强调分工协作与软件规模不断扩大的今天，

这种人已经非常难找了。领域专家是知识的最初持有者，其职责是为

项目提供准确的、完整的需求信息c技术专家的职责则是帮助领域专

家完成这一项工作c因此，首先请保证领域专家与技术专家是能够沟

通的，示例中的项目的第一个问题就是团队的新成员与领域专家之间

存在沟通壁垒。在我们的经验中，就发生过一位优秀的技术人员与一

位资深的领域专家争吵的情况。剖析原因之后，我们发现，最要紧的

原因是他们两个人都太优秀了，技术人员有一定的领域经验，领域专

家有一定的开发经验，这导致了双方在讨论中的强硬立场。因此，假

如遇到类似的情况，请对你的组织进行岗位调整。但在执行这项工作

之前，请小心你的说辞，不要伤害到任何一个人。”我们的某个小组

有烦恼，那边非常需要你的经验与能力”会是一句不错的说辞。其次,

技术专家不应该提出任何可能影响领域专家的问题。只有领域专家才

能够提出需求，技术专家起到的只是辅助作用。因此请杜绝这种情况。

再次，假如你的领域专家不只一个人，那么你需要考虑领域专家之间

可能出现的不一致。为领域团队指定一位领导者是一种不错的做法。

在我们的一个项目中，就曾邀请对方公司的财务总监担任这一角色。

理由有二：1、财务总监具有权威性；2、财务总监熟悉公司的全部运

作。此外，假如领域专家分布在不一致地点的话，你需要在该阶段的

某个时期，安排需求讨论会，并考虑一种能够沟通的方式，以便随时

能够熟悉身处异地的领域专家的意见。这种情况关于那些拥有分公司

的公司（比如银行、证券、保险、销售公司等等）而言非常的普遍。

因此，我们在需求分析阶段，首先要处理好领域专家与技术专家之间

的关系。应该说，这里提到的内容不仅仅适用于需求阶段，在整个的

开发过程中都有用处。

需求不是实现C需求表示的是有什么(What),并不关心如何做

(How)o假如在需求分析阶段把精力分散到了如何实现需求上，那

么需求分析的效果就会受到影响。这表达在需求的完整性与正确性两

个方面。领域专家与技术专家都可能犯类似的错误。领域专家往往只

能够针对自己的工作来描述需求，而他会很容易的把自己关于需求实

现看法参杂到需求描述中。从项目的整体范围来看，这种需求描述有

的时候候是有问题的。假如你开发的是一个定制应用，那问题还不大,

假如你开发的是一个产品，那么问题就很严重了。领域专家描述的需

求一定是你需要的内容吗？比如，你打算开发一个配送的管理应用，

但是领域专家把大量的精力花在了他在原先的公司中如何实现配送

的流程上，这个过程可能适合于他的公司，但是关于产品而言，可能

就不合适，由于并非所有的配送公司都使用这种流程的。好吧，你想

要的内容与你不想要的内容混合在一起，这使得你不得不花费精力对

需求进行进一步的整理。因此，好的做法是，一开始就明确领域专家

应该提供什么，而且，尽可能的提供需求，而不是需求实现。多问一

些诸如"假如环境发生变化，你该如何做”之类的问题，否则你会发现,

用户的需求变化将会对你的软件造成很大的影响。再说技术专家，技

术专家常常犯的毛病是把分析参杂到需求调研中来，从需求描述中精

练出一些业务实体(或者进行CRC讨论)是能够的，但是过早的考虑

实现方式将会限制你的思维。因此，请确保需求只是需求，这样才能

够尽可能保证需求的完整性与正确性。

需求复审是非常重要的检查点。请确保你正确的使用它。需求复

审需要领域专家与技术专家、与管理者的参与。需求复审是保证需求

完整性与正确性的最后一道防线。在很多的文章（包含我的需求的实

践一文）、过程都对需求复审进行了论述，我们这里就不赘述了c在

实践过程中，我们发现，需求复审还有一个好的方式，为了能够通过

需求复审，需求分析人员（包含领域专家与技术专家）会非常努力的

找出需求中的问题。因此，在你的过程中加入这个检查点是非常有必

要的。

好的，假如这一切都进行顺利的话，最后的需求规格书应该是比

较完美的，而技术专家也已经从领域专家那里熟悉到了足够的信息，

能够开始下一阶段的开发了。这里，我们再花一些笔墨来讨论迭代过

程中，我们如何处理需求。实践中，我们认为迭代次数并不是越多越

好，应该根据项目规模与团队特点进行区分，每一次的迭代都可能有

自己的目标。比如首次迭代的周期可能比较短，其要紧的目标定为提

供软件原型、验证要紧设计思路等。第二次的迭代的周期能够长一些,

目标能够定位为实现要紧功能。假如软件规模比较大，也能够为每次

迭代设定需求范围（或者要紧场景），这样就能够防止需求扩散的情

况。这已经超出了本文的范围，因此我们这里只是简单的提一下。

很难严格的区分分析阶段与设计阶段，至少我是这么觉得的。他

们的差别仅仅是在分析的全面程度上（有点类似于以往的概要设计与

全面设计）。在实践中，我们发现，并没有必要严格的区分它们，但

是你需要保证模型已经完整的描述了需求。这里能够设置检查点来验

证，也能够在设计模型出来之后再进行检查，这取决于具体的项目。

因此，我们在分析阶段与设计阶段结束之前需要进行设计复审。

从MartinFowler提出分析模式的概念之后（现在他的第二本分

析模式正在写作中），它就成为分析建模的有利助手之-----对领域

概念进行分析与建模，并描述它们之间的关系（我在点空间上的一篇

读书笔记反应了需求与分析之间的关系）,但是请千万注意，不要误

用与滥用分析模式,由于任何分析模式的提出，都是基于某个上下文

环境中的需求的，假如上下文环境不一致，那么模式就需要改进或者

改造。因此，分析模式是一个好的开始，但需要你针对实际需求具体

分析。在应用模式方面，FrankBuschmann的ApplyingPatterns是

一篇不错的参考文章，其中文版公布在点空间上。

在软件过程中设立反馈活动，能够有效的减少项目的偏差。就像

我们骑自行车，很少能够走一条直线，通常我们是根据对目标的偏差

进行忽左忽右的调整。这就是反馈的机理。原型法是一种不错的反馈

机制，根据我们的经验，视觉刺激对用户是最为关键的，因此不论你

的需求文档做的如何的优秀，仍然比不上一个能够看得见的软件原型

有效。这一实践很多的软件工程资料中都有叙述，我们就不深入熟悉

To另一种反馈机制是渐进交付。把软件产品分为多个迭代周期，每

个周期交付一个可运行的软件，在获得用户的反馈意见之后，在下一

个迭代周期进行改进，最后一个迭代周期交付的就是完整的软件了。

6、对可重用框架的改进

在找到了适合软件企业自身的知识接力方法之后，应当将其作为

规范或者指导意见，加入到现有的软件过程中。比如，在需求分析完

成之后强制要求进行需求评审。加入到过程中的方法，小心不要流于

形式。这样，既付出了成本，又收不到应用的效果。使用工具也是保

持知识顺利交接的重要方法。比如，使用自动产生源代码的工具，模

型设计工具、帮助产生工具、对象-关系映射工具等等。假如这些工

具对你的过程起到了润滑的作用，请规范与普及工具的使用。

7、小结

.请确保领域专家与技术专家之间的顺畅沟通。

.完整、准确的描述需求。

•进行需求复审与设计复审。

•保证分析模型（设计模型）能够完整的描述需求。

•保持需求信息到设计信息到代码注释的一致。

.使用反馈机制。

过程的最终目的是代码，开发过程中的所有活动都围绕着这一目

的而展开。假如没有最后的用于交付的代码，软件就无法成为软件。

因此，务必保证过程能够产出代码，而且是优秀的代码。

1、意图

不管哪一种过程，其最终目的都是为了产生出可执行、同时可用

的软件。因此软件过程中的各类活动应该围绕着快速、准确的实现这

一目的而展开的。

2、示例

维力亚软件公司是一家合资公司，由于有外资背景，公司内部很

早就引入了软件工程，并严格的对人员角色进行分工。包含领域建模

人员、架构设计师、高级程序员、程序员、界面设计师等等多种角色。

每个人各司其职，充分发挥出了分工的特点。但是随着公司开发项目

的逐步增多，这种方式也显露出其弊端来。每个人的要紧目标都是为

了通过评审，而有的时候候，就算是通过评审的工件，依然可能存在

问题。但这时候扯皮就出现了。项目中存在的一些中空地带。与交错

地带，常常发生无人问津的情况。开发过程的效率开始下降，开发成

本开始上升。问题尽管不是一下子出现的，但是已经逐步变得严重起

来了。

3、分析

我们在进行过程设计，或者引入一个过程理论的时候，是否具有

思考过该过程的每一个阶段、每一个活动的目的是什么，它们对生成

最后的软件有什么样的帮助，这些帮助关于我们所在的组织有意义

吗。很多情况下，我们并没有这么做，或者者随着软件过程的定型，

就不再思考这类的问题。一开始并没有什么了不起的，但是当软件过

程演变成了一种政治体系的时候，那么问题就会慢慢严重起来。

4、问题

如何让过程围绕着产出软件的核心目标而不断演进？

5、方法

从上一篇介绍的内容中，我们明白软件过程的每一个阶段都是知

识转换的过程，知识转换的终点就是软件C问题在于，我们如何保证

这种转换的效率呢？

现代软件的进展的趋势是重用。我们开发一个软件已经很少会从

最底层开始编写了。我们使用各类各样的技术与平台。包含数据库、

分布式体系、UI机制、业务元素等等。因此现在的软件编写往往都

是站在巨人的肩膀上开始的。不一致的软件组织，肩膀的高低也不一

样。比如有的软件组织使用J2EE平台，有的软件组织则使用.NET平

台。但是能够确信的一点是，每个软件组织都或者多或者少的拥有自

己的平台体系开发经验。这些经验的表现形式也不尽相同，可能是储

存在某些高级技术人员的脑中，也可能是储存为文档、模型或者代码

的形式。

关于单个的项目而言，其过程一定是从需求开始，以部署（与后

续保护）为终结的。但是关于长时间存在的软件组织而言，更重要的

是项目经验、技术经验、管理经验的积存。这样说可能过于抽象，我

们举一个具体的例子。在完成了一个库存管理项目之后，我们把库存

管理的领域知识制作为商业组件的形式，而把项目中学习到的一些编

码的技巧整理为模式的形式，并把项目过程中积存的过程方法添加到

现有的软件过程中c这些经验的堆积就是在一开始我们提出的可重用

框架。对一个软件团队的来说，它的所有软件项目都应该是围绕着这

一个可重用框架而展开的。

迄今为止，我们见过的大多数的可重用框架表现形式都能够总结

为：以开发平台为基础，积存自己的商业组件，并以此为中心订立开

发活动。这种形式是不是最好并没有定论，但我们是抱着学习的态度

来研究它的。

以开发平台为基础的意思是软件组织务必有自己所熟悉的开发

平台，其大部分的项目都是在此基础上进行的。目前最流行的两种软

件开发平台是J2EE与.NET,但是就算是同一个平台，不一致的软件

组织对平台内部的侧重也是不一致的（同样关于J2EE技术，有的软

件组织可能把JSP与Servlet作为核心选择，而另一些软件组织则把

重点放在EJB上）。选择一种广泛应用的、具有生命力的平台技术是

非常重要的。由于你的框架将会以此为基础进行，而框架的转移戌本

是非常之高的。尽管我们在一开始介绍的MDA思路为我们绘制了一副

平台无关设计的美好愿景，但是在目前阶段，我们仍然要面对不一致

软件平台造成的严重隔阂。

务必指出的是，我们上面提到的开发平台指的是在操作系统这个

层次之上的平台，也就是俗称的中间件平台。但是从中间件到最终的

产品之间是否具有过渡的平台呢。事实上可重用框架就扮演了这一角

色。软件市场上已经出现了商业化的可重用框架了。IBM的

SanFrancisco框架就是这种概念的代表。

平台技术仅仅只是提供了一个技术，而软件组织要生存与进展，

还需要积存与进展自己的商业组件。并将商业组件进展成为可重用框

架。商业组件的好坏，直接与软件组织的能力、经验，与平台技术有

关。商业组件可能直接表现为代码的形式（Bean.类、COM组件等），

也可能只是描述性的记录（文档）。商业纽件是经验积存而成的,请

注意，商业组件的设计并不完全等同于面向对象开发，由于面向对象

只是一种技术手段，但是商业组件设计的优劣，更重要的是对业务的

懂得程度。举一个最浅显的例子，一个熟知面向对象开发、面向组件

开发的设计师，让他介入他完全不熟悉的行业组件设计，他的表现将

会大打折扣。

到目前为之，大家所认识的框架仍然是技术型的框架。但事实并

非如此，框架还包含了外延的一系列软件活动。这才是一个完整的框

架。结合之前我们讨论的软件交付为开发目标。我们把这种开发方式

称之以可重用框架为核心，以交付为目标的软件开发。这事实上并不

是什么了不起的概念，大部分的软件组织都已经这么做了，只是没有

意识到自己的方式而已。熟悉这一点，能够帮助软件组织有效的改进

自身的构架。

平台技术与组件开发并不是本文的重点，因此我们在确信了两者

的重要性之后，把精力转移到软件活动上。

在拥有一个框架核心（平台与商业组件）之后，框架需要包含这

样的活动（或者活动集）：收集项目需求，并将需求映射到核心构架

上来。这事实上就是需求阶段到设计阶段要做的情况。但是由于我们

的活动是以软件交付为目标的，因此我们需要明确的指出活动中的注

意事项。

•为映射工作设计需求描述规格。需求并不是一件容易的事。最

难的莫过于尺度的把握了，比如需求要多全面。使用现成的技

术来定义需求描述规格，并根据核心框架的特点进行必要的扩

展。比如，我们使用成熟的用例技术来描述需求，同时我们要

求需求按照不一致类的商业组件进行分类索引。用例技术的推

荐读物是AlistairCockburn的WritingEffectiveUseCases

一书，该书目前已有英文影印版。

原型方法能够有效的帮助最终软件的成功。所谓原型方法，就是

选取系统的某个部分（最直接或者风险最高的部分，通常是界面原

型），实现并呈现给用户，以获得反馈，为后续的活动提供指导。

原型方法最大的好处是能够帮助用户认识软件，消除用户的疑虑，并

发掘潜藏的需求。围绕着是否抛弃原型这一根本问题，原型方法能够

分为渐进原型方法与舍弃型原型方法。前者是在一个软件原型的基础

上不断的演进，并最终进展为可用的软件，后者则是在开发出原型之

后就将它舍弃。渐进原型方法充分利用了原型，但是由于缺乏前期设

计，可能会导致最终产品存在性能或者设计问题。舍弃型原型克服了

这个问题，但是它浪费了原型开发的那段时间。不论使用何种方法，

最重要的是在项目一开始就决定使用哪一种原型方法。模棱两可的使

用两种方法是兵家大忌。最终你无法利用任何一种方法的优点，而所

有的缺点都将降临到你身上。相较而言，渐进型原型方法更适合于应

用在小型项目上，由于项目并不复杂的话，设计的改进比较容易。关

于一个拥有构架的团队而言，把原型方法纳入构架之中是很有意义

的。假如构架足够成数，迅速开发出一个原型并不是什么很困难的情

况。这样就能够在投入最小化的情况下获得原型方法的优势。假如情

况是这样的话，舍弃型原型方法大概更适合一些。

.从需求模型中生成同意测试。该活动把需求映射到测试上。在

这个活动中，不但要注意功能性需求（如完成的功能），还需

要注意非功能性需求（性能要求）。同样的，同意测试也需要

同意复审。能够按照需求的组织方式来组织同意测试。

•设计模型完成之后，同意测试已经细化到模型的各个元素上了

（比如包、类）。该项活动与将需求映射到设计的活动是同步

进行的。由于它们处理的信息是非常类似的。与同意测试一样,

这两个活动都需要由团队来保证。

•在进入编码阶段之后，开发人员根据同意测试与设计模型，将

会为自己负责的部分设计编写单元测试。单元测试的编写顺序

是否优先于编码，这取决于各人的看法。关于这方面的讨论，

能够参看XP的单元测试实践。从我个人的经验来看，先写单元

测试，再写代码不失为一个很好的办法，另一种做法是，让两

个紧密合作的开发人员相互为对方编写单元测试。

其次，我们需要保证测试的最小单元一单元测试的成功。所谓皮

之不存，毛将焉附。单元测试没有组织好，最后的软件是不可能戌功

的：

•需要注意单元测试的覆盖率。这里的覆盖率指的是是否能够完

全检测出错误所在。比如边界条件的测试等。开发团队中的架

构师之类的角色需要为此负责，假如无法检查所有的单元测试,

那么能够进行抽查与代码复审会议的形式。后者是一种很优秀

的做法。从代码中抽取出一段，开发人员一起分析单元测试存

在什么问题，会使得大家编写单元测试的功力不断的增长。

.单元测试一定要是自动化的。Junit就是一个不错的自动化测

试框架。保证单元测试的自动化，同时避免单元测试与特定环

境有关，这样就能够顺利的进行回归测试。这关于迭代式的软

件开发是非常必要的。同时，我们也应该认识到，单元测试的

稳固性取决于设计的稳固性。我们能够想象，假如测试的类方

法的参数、命名都发生改变，那么测试是确信需要重新组织的。

因此，面向对象的抽象思维关于现代软件开发而言是费产重要

的。为了做到测试的自动化，尽量避免将逻辑硬编码在界面中，

并小心的处理数据库。能够尝试着建立测试数据库。

•假如测试的内容需要并入核心构架，那么这部分的测试工作需

要增加，并对构架可能的修改进行测试。因此，学习开源软件

的做法，将构架的稳固版本与开发版本相区分是比较保险的。

让测试活动随着软件开发的进行而进行，让测试活动贯穿整个开

发周期。这有点类似于全面质量管理的思想。由于软件开发过程的失

败并不是突然而至的，而是在平常的不经意间一点一点的积存起来

的。使用测试活动来消除这种微小的不稳固性，能够大幅度的提高最

终软件的质量。但是，在一个团队中引入正规的。频繁的测试活动是

需要耐心的。能够先从单元测试着手，慢受的普及这种做法。

测试活动能够衍生为日创建与冒烟测试。关于有复数的开发人员

参与的软件项目，就无法避免正视集成测试的局面。有过类似经验的

人都能够想象的到这种集成测试的难度。专门有一句话是描述这种局

面的：”我们已经花了90%的时间来完成90%的软件，但我们还需要

90%的时间来完成剩下的10%\现代的软件往往都包含成百上千的文

件，这些文件的编译链接的过程是很复杂的。而日创建的思想就是每

天进行一次这样的过程，形成一个可执行文件°但这只是日创建第一

部分内容。日创建还需要对软件进行冒烟测试，测试的要紧内容就是

单元测试中所编写的内容，保证软件能够通过所有的测试。

日创建需要留下一些调试的时间，特别是在软件开发初期，不一

致开发人员的代码整合在一起出现问题的可能性极大。随着对这项实

践的熟悉程度，问题会逐步减少°日创建能够很明显的提高产品质量,

与提升团队的士气c尽管日创建活动需要付出额外的一些成本，但是

相关于集成测试的不可控，这些成本还是值得的。

6、小结

•投资于框架能够保证软件开发的成功。

•应用有效的实践活动来完善框架。

•将需求映射到核心框架上来。

•使用原型法。

•注意测试活动。

•假如可能，使用日创建，并进行冒烟测试。

规则不一致于指南。规则是目标受众所务必遵守的，而指南是建议目

标受众遵守的。

一致性原则是软件开发中重要原则，也是最令人困惑的原则。做

到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各

类各样的问题。能够想到，这又是一个需要权衡的问题°

1、意图

软件过程中的大部分工件都需要保持其相互之间的一致性。但

是，工件越多，保持一致性的开销也就越大。我们需要在一致性与成

本之间保持平衡。

2、示例

天利软件公司的项目经理正在为开发过程中出现的大量的不一致

问题头疼不已。从软件过程一开始的需求阶段，版本问题就一直困扰

着项目组的成员。项目组的成员并非没有经验，只是这一次的项目规

模超过了以往的项目，因此公司决定使用严格的过程，以保证软件质

量。开发过程中每个活动都务必产出文档。第一次的不一致发生在需

求调研中期的一次研讨会上，当时的会议上发现了三种不一致版本的

需求规格书。之后情况越来越糟，文档的数量不断增多，由于所有的

开发人员都需要编写文档、使用文档，因此发生了各类原先没有料到

的情况，包含新文档被覆盖；设计人员手中的需求规格书不是最新的

版本；设计书变更之后，代码却没有相应的变更；代码中的方法说明

与设计模型中的方法说明不一致。为了对文档进行操纵，公司不得不

从项目组中抽调了两名开发人员来操纵文档，并加强了文档的管理。

但是随之而来的是开发周期的延长。

3、分析

一致性包含两个方面：一是不一致工件之间的一致性，二是使

用同样的方法来处理问题。

软件过程的每个阶段都需要产出不一致的工件。典型的比如需求

分析阶段将产出需求规格书、用例模型、非功能需求等，设计阶段产

出设计模型、类图。而在软件开发中，我们常常会遇到需求的变更的

情况，因此我们需要依次对我们的需求模型、分析模型、设计模型、

代码进行修改，以保持它们之间的一致性。假如项目处于前期阶段，

这种修改量并不大，由于工件较少，假如项目进行到后期。需求的改

变将会涉及到大量的工件。关于期限比较紧张的项目而言（这大概是

所有项目共同的特征），这种成本几乎是无法同意的。

另一方面，在同一个软件组织中，解决同样的问题有着不一致的

办法。不一致的人有着不一致的编码习惯、不一致的目录组织方式、

不一致的类库、不一致的框架。尽管我们并不反对同一问题的不一致

解法，但是当这种情况对项目的进展起到负面的效果的时候，我们就

有必要来思考这个问题了。

4、问题

我们如何在一致性与一致性带来的成本之间做好平衡？我们如何

保证不一致工件之间的一致性，又该如何保证项目中解决方法的一致

性。

5、方法

首先，我们应该确信，一致性这个问题并没有标准的答案。不一

致的项目对一致性有着不一致的要求。关于要求严格、规模庞大、涉

及到一些重要领域的项目来说，一致性的要求是极为严格的。而关于

一个小型的、较为无关紧要的项目来说，一致性的要求就低了许多。

因此，与前面介绍的模式类似的，一致性的正确的答案只能够从读者

自己的项目中去寻找。而这里提供的，是寻找该项标准的建议。

我们先从后者一解决方法一致性入手。

在项目一开始的时候，不要过分注意工件的修饰。比如，我们选

择的用例模板要求每一个用例都需要包含6种元素，包含要紧角色、

级别、前置条件、要紧流程、备选流程、优先级。并规定引用其它用

例的地方需要做出链接。但是在一开始需求调研的时候就按照这种标

准完善用例将会提高成本，由于需求尚未稳固，我们要紧的工作是尽

可能完整的收集用例，而不是把时间花费在修饰用例上。因此一开始

任何形式的用例描述都是同意的。你能够使用几句话来描述用例（事

实上，利用自然语言来描述用例有着图形无法比拟的优势），并用着

重号标记出其中可能与其它用例有关联的词汇。这样就已经足够了，

修饰的工作能够等到下一步来做。其它的工件也是一样的。这时候的

一致性的要求并不十分严格。

因此，我们应该根据项目进行的不一致时期来保证工件的一致

性。比如，在实现阶段的初期，设计尚未定性，花费大量的时间在设

计文档上就没有什么必要，只需要准备一份草稿，在设计的时候随手

记录下设计思路就能够了。注意，不要不做任何记录，人的经历是最

不可靠的，过目不忘只出现在小说中。而当项目逐步成数的时候，我

们就能够为其中成熟的设计进行文档化的工作了。这些能够根据需要

公布给用户，也能够整合到构架中。

再来看第一个问题，如何保证不一致工件之间的一致性。

同时保护3个工件的工作量,要比同时保护10个工件的工作量

小的多。因此，我们应该尽可能的减少在每个关键点中需要保证一致

性的工件数量。同时，我们需要区分，哪一些工件属于务必保持一致

性的工件，什么属于不需要随时更新的工件。比如，我们在需求分析

中使用了CRC卡片，但是它的要紧目的是为了顺利的进行沟通，并得

到基本的分析类。这样的工件，保持它的一致性并没有太大的意义。

这种思路类似于CMM中的KPI的思路，从软件开发过程中找出关键的

工件，把有限的力量投入到保持这些关键工件的一致性上。尽管一致

性狂热者未必认同这种做法，但是关于一个软件组织来说，最重要的

是在有限的资源下的尽量提高软件开发能力。

另一种工具是版本操纵系统，是否使用版本操纵系统与项目大小

无关。再小的项目同样存在着版本问题，只是严重程度不一致而已。

因此将工件纳入到版本操纵系统中来是较好的做法。关于小型的项目

而言，并没有必要限制权限，但关于大一些的项目权限操纵就有必要

了。

一致性的组织保证

首先，假如不进行任何的管理，项目一定是不一致的。这与人的

基因有关系。因此我们需要为一致性制定专门的人选。比如，需求的

一致性应该由架构师与领域专家负责，模型的一致性由开发人员负

责。但是最终需要一位总的负责人，他负责所有工件的一致性，包含

技术与领域两方面，并决定是否将项目中的经验并入构架中。

不要让一致性为难你的开发人员。一致性是很容易滥用的，因此

请确保正确的使用了它们。比如，制定缩进或者留白之类的一致性标

准并没有太大的意义，由于它的成本远远超出了它的意义，同时会遭

到开发人员的严重反对。另外的例子包含过于严苛的编码规则、与模

式的滥用。这些都是经常会犯的错误。它并不可能带来生产率的上升，

只会另开发人员反感。避免它们的办法是，在制定一致性规则之前，

先思考，该条规则的成本是否大过它的利益，开发人员是否愿意同意。

一旦定义了一致性规则之后，就需要进行培训。最好是通过例子

来开始。比如，教授新的模式。假如你进行类似的培训，你就会发现,

把正式的培训与非正式的指导相结合是很好的做法。因此，我们往往

习惯把培训课程分为理论培训与实践两个部分。实践能够安排在课程

结束就开始，也能够安排在项目进行中。

最后，一致性规则需要在整个开发过程中被不择不扣的执行。这

是务必的。此外，治需要评估一致性规则的实际运作情况，假如有不

充分或者是不完善的情况，则需要改进它c假如效果不佳，则要考虑

废止该规则。

6、小结

•使用构架来保证大原则的一致性。

•在情况未确定之前，工件能够是不一致的，但是在关键点时，

工件务必是一致的。

•尽量减少需要保持一致性的工件数量。

.使用工具来保护一致性。

.指定一致性的负责人。

•一致性规则务必合理。

•严格执行一致性，并根据实际情况改进一致性规则。

软件工程需要在科学与艺术之间求得权衡，科学的一面包含了软

件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员

的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、

过程、方法，它们是否能够发挥出人的创新性？或者是它是否足以约

束人的行为？

1、意图

对开发人员的行为进行约束是必要的，但同时却限制了开发人员

的创意。我们如何在这两的极端之间取得平衡呢？

2、示例

成达公司在以往的项目开发中，通常都不限制开发人员的行为，

公司中开发人员都有各自的编码习惯，使用不一致的开发工具，更不

用说遵循什么开发过程了。因此一旦有人员离职，接手的人员往往都

需要花费大力气来熟悉原先的系统，由于原先的人员几乎没有留下文

档，或者是仅有一些旧的、不能使用的文档。公司中也有软件人员向

管理者提出过这方面的建议。但是由于软件开发并不是公司的要紧盈

利机构，公司不太注重这件事c因此这种情况就一直保持下去c由于

公司中的软件人员大多数都有着多年的开发经验，因此日常的运作也

算是基本正常。从今年开始，情况发生了改变，由于经营策略的改变,

公司换了一位老总，新老总对软件部门非常重视，并投入资金，为软

件部分引入了一套严格的规定，制定了统一的编码规则、开发环境，

严格的作息制度、汇报机制。有位员工这样形容新过程，”就差没有

制定上洗手间的时间了”。过程实施以来，员工怨声不断，由于个人

原先熟悉的开发方式被打破，软件开发速度大大降低。客户的投诉也

明显增加，甚至出现了项目中止的情况。过程实施6个月之后，发生

了3位资深的开发人员离职的事件。最后，管理层不得不废止新过程,

回到原先的开发方式上去。

3、分析

开发过程有两种极端。我们能够看看下面的两种情况，你更愿意

在哪一种环境中工作。

项目组的三个程序员分别开发项目的三个模块。需求仅仅持续了

3天的时间。原定干划是1周，但是由于项目甲方人手紧缺，调走了

需求调研的领域专家。三个程序员闷头开发，彼此隔绝。每位程序员

都有自己的类库与开发包。没有文档，没有测试用例。突然，程序员

甲喊道，”昨天我放在这里的需求说明书呢？就是那张上头有脚印的

打印纸。”界面开发一半之后，用户发现大概不一致模块的界面相差

极大，按钮的位置、菜单风格、窗口布局，没有一处相同的。更为糟

糕的是，大概程序员对用户需求的懂得又错了。

程序员乙正在嘀嘀咕咕的修改他的代码，由于架构师在检查了他

的代码之后，指出？100多处与标准规则不一致的地方。包含变量命

名、注释规则等等。“烦死了！"程序员丙伸了个懒腰，他正在修饰他

的设计类图。上次也是这样，模型已经画的尽善尽美了，结果又由于

设计发生变化不得不重来一次。看来今天有没什么时间写代码了。项

目经理正在审查昨天各个开发小组提交上来的文档，”这几份文档的

格式都有问题！"他皱了皱眉头，看来在下午的例会上，他还要着重

强调统一规格的问题。

3、问题

能够看到，上述的两种情形正是我们的模式名称的后半部分所描

述的：混乱与死板。那么，我们如何达成模式名称的前半部分一活跃

而且严谨呢？

4、方法

这又是一个需要权衡的问题。正是这种问题让人头疼不已。造成

软件过程无效或者束缚开发人员的结果有两种不一致来源的因素。一

是在过程选择与创建的时候，我们忽略了一些问题，一种是过程实施

后的操纵上我们没有认确实思考。

软件过程的迷思

很明显的，上面所讨论的两种极端都不是优秀的软件过程。

然而，就像我们看寓言故事一样，在取笑寓言故事中的人物的时候,

可曾想过自己也犯过类似的错误，只是轻重程度不一致而已。尽管

我们不可能犯上例中所有的错误，但是确实会出现其中的一些情形。

那么，我们在建立软件过程的时候，如何防止出现上述的一些情境

呢？

以我们自己为例子。在建立过程的时候，我们选择是以RUP为基

础。为什么不选择XP之类的敏捷方法呢？原因有二：i)敏捷方法的

实践很优秀，但是作为完整的过程，它仍然有其不充分的地方。ii)XP

中有很多优秀的实践，但另一些我们并不完全赞同。在选择了RUP之

后，为了保证过程的灵活，我们删减了大量的活动与工件，仅保留了

一些关键的。但是我们清晰，假如现有的团队规模发生变化，删除的

这些活动与工件可能需要重新添加到过程中来。此外，我们引入了

XP中的一些优秀的实践。比如测试优先、重构与结对编程。关于结

对编程这项实践，我们没有完全采纳XP的建议，而是在一些关键的

活动上，比如指导、模块设计、单元测试，使用了结对编程实践。

不要过于在乎你的过程过轻或者过重，只需要关注它是否合适，

开发人员能否同意,新的过程是否要求开发人员改变原先的习惯，而

他们的反应如何？很多时候，正是对旧习惯的挑战导致了开发过程的

失败或者不顺利。这里需要非常小心的处理。

在引入软件过程的时候，不要花费大量的时间来编写描述过程的

文档，尽量利用现成的。有编写文档的时间，倒不如用来对开发人员

进行培训，并获取他们的支持.在实践中，我们发现，人们往往不可

能去真正阅读并懂得大量的文档。文档过多也将使得工作失去重点。

从一些比较简单的、容易见效的、最好是能够结合现有的一些流行技

术的（程序员们都喜欢）。比如，使用用例技术来改进需求、使用

UML来改进设计。这样做的好处还在于，这些技术往往都有较多的资

料，利用这些资料能够节约编写指南的时间。

•在关键的检查点上保证文档的完整性与一致性。上文中我们提

到了检查点的概念。就像在需求复审这个检查点上，我们需要

保证需求模型完整的再现了用户或者领域专家的思路，而在设

计复审这个检查点上，我们则需要保证设计模型与需求模型的

一致性，并确保开发人员与设计人员都同意当前的设计模型。

只在检查点上同步文档能够大大减少文档的负担，但文档需要

进行同步的检查点则要好好的考虑。比如，帮助文件需要同步

的检查点，界面原型需要同步的检查点。

总之，小心的处理文档，不要让文档成为开发人员怒气的焦点，

不要让编写文档变成一种应付了事的工作。这样的话，既花费了精力，

又得不到应有的效果。

最后一点，千万不要相信过程能够解决一切。"我们使用了最先

进的过程，我们一定能够成功的"这种话无异于痴人说梦。开发软件

的是人，而不是过程。好的过程关于软件的成功来说，只是一个必要

条件，而不是充分备件。永远依靠你的开发人员。当人的行为与过程

冲突或者不一致的时候，想想过程的目的，再做最后的定论C

5、小结

•在创建软件过程时，从现有的软件过程中选择一个适合自己的。

­水无常形，软件过程也是一样，确保它随着时势而变。

•注意引入软件过程的开始阶段，让开发人员参与到软件过程中

来。

•重点关注检查点。

•保持文档活动的敏捷性。

.过程不是仙丹，人才是。

软件过程的改进是一个长期的过程，属于长期的利益。假如长期

利益与短期利益相冲突的时候我们应该如何处理。我们有什么办法来

令短期利益与长期利益结合起来呢？

1、意图

权衡短期利益与长期利益。

2、示例

金商软件是一家专门针对小型企业销售软件产品与定制开发的

公司。他们销售的软件来自于国内的一家知名软件厂商。而公司内部

的软件人员要紧从事定制开发，一方面是满足用户的一些特殊需要，

另一方面是为了进展自己的软件开发力量，以图日后开发出自己的产

品。这种策略刚实施了半年的时间，目前公司的开发人员只有5个人。

由于公司的销售能力很强，因此公司总是能够得到大量的订单。由于

公司目前已经拥有开发力量，因此得到的订单也不像从前，以产品为

主，定制为辅。而是一些完整的开发项目。从10月份开始，公司已

经签了4个项目，按照公司的习惯，通常都承诺在3个月内完成项目。

但是根据软件部分的估算，目前的任务，大概需要60个人月的时间。

到了n月，开发部的所有人员已经连续加班1个月了。其中2个项

目由于增加需求，同意把项目的开发周期延长一个月，但是与60个

人月的工作量比起来，这点时间大概是杯水车薪。在时间的强大压力

之下，开发人员不得不牺牲软件质量，而软件的最后完工看起来是那

么的遥不可及。

3、分析

自从加入到面向对象开发地阵营以来，我们深为这门开发艺术所

感动。编码工作在面向对象思想的指导下显得那么具有美感。以往过

程式编码失控之后的那种无力感再也找不到了。面向对象带给我们的

是极大限度的重用性，当然，我们需要付出前期投入的成本。从学习

面向对象以来，我们学会了使用一种抽象的方式看待世界，思考问题。

有些时候，我们同一些仍然保持传统编程习惯的软件公司交流时，我

们发现大概面向对象并没有表达出太大的优势：

"面向对象技术能够极大的重用现有的构架，大大提高开发速度。”

”我们现在通过增加人手与加班的方式，也能够很快的完成一个项

目。”

”面向对象技术能够减少软件的保护成本。”

"通常我们会指定一些开发新手来保护公司以往的项目，这方面的

成本并不高。”

”面向对象能够不断的积存项目经验，为后续的项目开发提供保证。

II

”通过雇佣有经验的开发人员，我们能够直接获得开发经验，而不

用自己积存”

"面向对象是未来软件开发的主流。"

”保证项目及时完成是管理层最关心的，等到市场上的面向对象程

序员足够多之后我们再使用面向对象吧。”

"此外，现在使用面向对象，人员需要全新的培训，我们没有多余

的人手；由于没有经验，直接把面向对象用于项目实施存在风险，而

我们的项目时间都太少了”

这一段对话点出了面向对象技术的困惑，但也反映了软件开发中

短期利益与长期利益的冲突。

4、问题

如何在软件开发的短期利益与长期利益中寻求平衡点？

5、方法

面向对象的迷思

我们的不明白是从面向对象开始的。归结其原因，是我们并没有

真正的认识面向对象。

"面向对象符合现实世界的特性，因此会更加简单。”

"我们决定从这个项目开始使用面向对象技术，并安排了为期2周

的学习时间。”

”由于使用了先进的面向对象技术，我们把开发周期缩短1/3。”

假如你对面向对象有上述的懂得的话，说明你对面向对象技术的

懂得存在误区。首先，面向对象与面向过程的不一致在于思维方式的

根本不一致，因此，转向面向对象技术决不是一个一蹴而就的过程，

而是需要不断的学习，不断的磨练。假如需要为这个学习过程制定一

个时间的话，我想也应该是在8〜14个月之间。其次，在刚开始使用

面向对象技术时，并不能够节约项目的开发时间，相反，由于学习与

尝试面向对象技术的需要，项目的所需时间会大幅度延长。面向对象

技术的威力在通过一段时间的积存之后会变慢的显露出来，你会发现

一个新的软件只需要对现有的类进行重用，编写少量的代码，甚至使

用代码生成器就能够完成。这使得软件的开发成本大幅度的降低。这

个时候，软件开发将会进入良性循环的周期。

为什么面向对象技术会有如此大的威力呢？原因在于面向对象

的抽象思维。

熟悉了面向对象的知识之后，我们发现事实上面向对象的要紧威

力是它使用一种特定的方法，将一些不断重复的情况简化了。问题在

于，要让软件组织学会使用这种方式是需要代价的。那么，你是否愿

意付出这种代价？今天付出1块钱，明天能够收回10块钱的情况每

个人都会做。但是让你每天投入10000块钱，坚持2年，这样你会在

未来获得10倍的回报。这种情况就未必会有人做了。研究面向对象

技术，进展软件组织的技术框架需要很大的前期投入，而效益却是慢

慢显现的。这就造成了短期利益与长期利益的矛盾。事实上，除了面

向对象技术之外，软件组织中还存在很多同种性质的矛盾：

•所有人都明白项目管理的必要性，甚至言必谈项目管理，但是

真正按照项目关联方式执行的又有多少人呢？

•软件质量是软件组织最看重的，但是由于人员与时间的压力而

牺牲质量的案例多如牛毛。

•计划制定与执行是软件过程中最核心的部分，但是计划赶不上

变化也是目前最流行的口头禅。

由于我们要紧讨论的仍是经验，关于项目管理的原理、案例、数

据的资料有很多书籍都有介绍，因此我们就不用再次的重复它们了。

而我们的出发点，仍然是围绕着前述的核心矛盾，介绍一些实践。这

些实践并不需要很大的成本，但是确实能够起到很好的效果，当然，

它们最能够发挥作用的前提条件是「坚持”。从下面的介绍来看，其

目的都是为了补充或者