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

过程塑造（小型软件团队过程改进方法）一、从方法到编码这是一篇偏重于介绍方法学（特别是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。 本系列包括： 知识接力、 代码是最终目、 一致性的思考、 活跃和混乱、严谨和死板、 短期利益和长期利益的权衡。软件管理和软件开发是截然区分的吗？ 对于项目经理来说，其职责是软件项目的管理，而对于架构师、编码人员来说，其职责是软件设计和开发。虽然在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感受到软件管理和软件开发之间客观存在的沟壑。 我常常听到来自两个方面的声音。一边抱怨说设计师、编程人员阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边抱怨软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。 现代的方法学理论以及相应的过程实践为我们奠定了软件开发科学管理的基础，个中的翘楚包括RUP和XP，纵观这些方法、过程，都非常强调过程的流畅、生命周期的延续。而在实际的应用中，我们却常常能够看见对它们的不恰当的理解，不正确的使用。尤其是那些希望在自己的软件团体中引入新型的方法过程新手们。对于他们来说，最容易犯的一个错误就是忽视了如何利用一个软件过程来创造一个成功的软件。关于如何建立一个软件过程的资料很多，但是这些资料并没有把为什么需要过程，过程的目的是什么之类的问题说清楚。而这些资料的读者们，往往需要花费大量的时间，亲自进行实践之后，才能获得这些问题的答案，而付出的代价是教训和挫折。同样的，我和我的伙伴们也经历了这样一个过程。因此，我希望把我在过程应用、过程改造中涉及到的问题例举出来（采用过程模式的方式）。如果大家能够利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。但是本文中所讨论的内容都可以对以上的活动起到部分的指导作用。敏捷？敏捷！ 从开始研究软件工程，我就对敏捷过程的概念情有独衷，但是随着学习的深入（所犯错误的增多），我发现敏捷是无处不在的，她是一种尺度，一种处于混乱和死板之间的平衡艺术。有句俏皮话说的是一放就乱，一管就死，这句话很好的点出了软件过程的一种无奈性。如果没有严格的规定，软件开发就陷入一种混乱、无序的状态，但是如果制定了过于严格的规定，软件人员的思路又受到极大的约束，管理成本也随之上升。敏捷正是一种处于两个极端之间微妙平衡的艺术。这种艺术难以完全表述，但是可以通过一些指导，来帮助大家达到这种境界。 因此，我们可以推想的到，敏捷是见仁见智的。每一个软件团体都有自身的特性，其敏捷过程必然都不尽相同。如何设计出成功的敏捷过程，来保证软件团体的成功呢？本文通过一些过程模式的讨论，揭开了问题的一角。关于过程设计的完整的讨论，大家可以参考敏捷软件开发Alistair Cockburn一书（该书近来将有中文版面世），该书详细的描述了过程设计的来龙去脉，以及如何根据组织的特点来选择适当的过程。 因此，虽然本文中并没有特别提到敏捷的字眼，但是所讨论的内容无不在敏捷思维的范围之内。 MDA推动软件可重用框架的建立 我有一个梦想，希望有一天能够不用在诸多的平台之间摇来摆去。虽说Java语言的口号就是跨平台。但事实上，我们还是无法完全摆脱平台的束缚。 在UML2.0的规范中，提到了一个MDA（Model Driven Architecture）的概念。在众多的软件平台中不知该如何选择，已经演变为当今软件开发的主要难题。MDA的存在目的就是为了解决这个问题。通过MDA技术，一个UML的模型可以是平台无关的，称为PIM（Platform-Independent Model），也可以是和特定平台相关的，称为PSM（Platform-Specific Model）。利用平台技术的软件商，可以专注于自己的领域，集中描述业务功能，业务规则，而无须考虑特定的技术，构建出一个PIM，然后，通过支持MDA的工具，将PIM转换（通过不同Profile进行映射）为一个或多个PSM。这时候的模型仍然是UML的。但是，这个转换过程虽然有工具的辅助，但仍然需要外力的介入。接下来，开发工具将会从PSM中产生可执行代码。这就是MDA的思路，它把以往以程序为中心的开发模式转变为以设计为中心的开发模式。 以往的重用，往往是基于代码的，例如算法的重用、界面组件的重用，却往往没有将重用提升到设计的层次上。MDA为我们建立可重用的框架提供了一个很好的指导。注意上面的这副图，最外面的两层就表达了MDA可以用于设计重用的基本理念。倒数第二层的含义是利用MDA来进行通用软件（例如事务、目录服务）的模型设计，倒数第一层则表示MDA可以用于特定业务领域的设计建模。可以想象，今后软件公司中的最有价值的资产，就是这些设计模型。 本文并不打算详细讨论MDA，除了简单的介绍MDA的思路之外，更重要的一点是企业可重用框架的建立。软件企业的核心在于知识，如何有效的将人脑中的知识存储起来，并不断的使用和发展，是软件企业成功的关键。本文提到的可重用框架，指的就是将软件开发相关知识存储起来的框架。这个思路是本文的一个核心思路。在本文看来，可重用框架不但包括了设计模型，还包括了过程和方法。软件开发是在这个框架之内运作的，同时反过来影响着框架的完善和改进。 过程塑造模式语言下述的模式都是从软件开发过程中，围绕着可重用框架的建立整理出来的一些经验，之所以整理为模式的形式，是因为这种方式有利于类似情况的鉴别和对其进行必要的扩展。在软件开发中会遇到各种各样的问题，以上模式中讨论到的问题都是我们在实践中，或是和其他开发团队沟通中反复遇到的。因此坚定了我们将之整理为模式的信心。目前我们得到的模式并不多，但是随着经验的增加，我们会得到更多的积累。 本文介绍的模式都比较注重权衡的艺术。我们认为这是敏捷思维的必然结果。世界上并没有什么绝对的事情，尤其是目前多变的社会中，昨天的标准并不适合于今天的环境。因此，我们的平衡点也在不断的变化。 传统、经典、学术的瀑布模型为我们建立了软件开发的基本过程，虽然有各种新的生命周期模型的提出，但是基本的过程并没有太大的变化。例如，增强性的瀑布过程是在瀑布模型的基础上增加了回溯到上一个阶段的能力；迭代式过程的每一次迭代都是一次微小的瀑布生命周期。在这个生命周期模型中，信息在初始需求收集阶段生成，并通过分析、设计、编码、部署等阶段转化为用户最终需要的软件。在这样一个延续性极强的周期中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？这些问题正是 知识接力模式所重点关注的。 我不只一次的见过为过程而关注过程的情况。产生这种结果的一种原因是“过程麻痹症”。过程一旦定型，就不再改变，即便当初制定过程的环境已经发生了变化也是如此。过程的制定一定是针对特定的目标的，这个目标就是开发出成功的软件，如果不能够服务于这个目标，遵循过程又有什么意义呢？另一种原因是过程被分割为彼此独立的片断，每个开发人员只关注自己的职责，而忽略了最终的软件。过程的 代码是最终目的，开发过程中的所有活动都围绕着这一目的而展开。如果没有最后的用于交付的代码，软件就无法成为软件。因此，必须保证过程能够产出代码，而且是优秀的代码。 一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。可以想到，这又是一个需要权衡的问题。软件项目中的一致性大致可以分为两种，一种是不同工件之间的一致性（例如设计模型中的类名称和实际代码中的类名称的一致性），一种是工件和软件过程的一致性（类名称需要满足命名标准）。我们如何考虑这两种情况下的一致性呢？ 人们说管理既是科学也是艺术，这句话用来形容软件工程再适合不过了。如果说这里有什么不够恰当的地方的话，我倒觉得是软件工程的这个提法有些许的欠妥。软件工程的思路源自于人们渴望软件开发能够像土木工程那样成熟。但是几十年的经验下来，大家可以肯定，软件开发和土木工程有着太多的不同：开发人员和建筑工人也有着截然不同的差异，知识的组装和钢筋混凝土更是天差万别。（但为了保证延续性，我们在本文中仍然延续软件工程的提法。）因此，软件工程需要在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、过程、方法，它们是否能够发挥出人的创新性？或是它是否足以约束人的行为？这就是 活跃和混乱、严谨和死板模式所要告诉我们的。 应该说，本文中所讨论的模式更适合于使用面向对象技术的开发团队。尤其是 短期利益和长期利益的权衡模式。和大多数人一样，我们最早也是过程式编程阵营的一员。在经过长时间的学习和不断的犯错之后，我们终于转向了面向对象。面向对象最大的好处包括了以下几个方面： 将实现和接口分离，即把如何做隐藏起来，而把做什么展示给客户。 继承和多态使得我们能够在一个抽象的层次上（基类和接口）思考问题，并能够根据现实的需求进行灵活的调整（子类和实现）。 通过设计模式和设计技巧的应用，可以有效的降低系统的不同部分之间的耦合度。尤其是简化客户端的代码。 在使用和比较过几种开发语言和开发环境之后，我们发现，其实最关键的并不是使用什么样的面向对象语言（或环境），关键的是你运用面向对象思维的能力，或者说对现实世界的理解、抽象、映射的能力。这种能力决定了你的开发水平的高低，而语言和环境只是一种重要的实现手段和工具而已。而这种思维能力，虽然可以通过例子和讨论来进行介绍，但更关键的还是在实践中进行练习。在本文讨论的模式中，我们会夹带的对这些内容进行讨论。因为我们认为，开发思想和开发过程是无法区分的，否则，你的开发过程就没有灵魂。这也是我们的主题所要强调的：从方法到编码，铸造起一个敏捷的、流畅的过程，才能够保证开发过程的成功，开发软件的成功。 此外，本篇是总论性文章，在撰写此文时，该篇其实是最后完工的，因此，建议大家在看过全文之后，如果还有耐心，可以重看此篇，相信会有另外一番收获。 现在请大家进入我们的模式之旅。 二、知识接力 在软件过程中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？1、 意图软件开发过程是知识传递、知识转换的过程。注重知识转换中的完整性，保证知识经过各个阶段和活动，顺利的转换为软件是极为重要的。2、示例 元朗公司是国内某银行的下属企业。从年初开始，公司就投入了大量的人力为银行开发新版本的国际收支系统。考虑到这是一个非常庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人员有些来自于其它的项目组，有些人员来自别的公司。为了保证开发的顺利进行，项目经理引入了软件过程。但是从一开始，麻烦的事情就出现了。项目组中的技术人员和银行的领域专家之间不断出现意见相左的情况。主要的问题是后加入的员工对目标领域不熟悉，难以配合领域专家的工作。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析阶段不得不在原先的基础上延长了50%的时间。在进入设计和编码阶段之后，问题少了许多。但在设计到编码的过程中仍是出了一些麻烦，原因是新加入的人员不熟悉开发团队的设计风格。经过一番周折，问题基本解决了。可等到项目进入到测试阶段，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严重错误。经过对错误的复审，排除了其中17%的严重错误。经过分析，发现其中70%的错误都是发生在后加入人员负责的模块中。而产生大量错误的一个主要原因是在编码阶段，由于银行启用了新的会计制度，导致大量模块被修改，由于时间紧迫，因此没有进行正规的需求调研。现在看来，领域专家和技术专家对同一个问题的理解并不相同。最后，项目的开发周期延长了40%。3、 分析软件过程每经历一个阶段，就会发生一次知识转换的情况。这种转换是由人来完成的，这就是像是接力一样，一个人把脑中的知识以某种方式传递给另一个人，再有另一个人传递下去，直至编码人员把这些知识固化在最终的软件中。在软件成型之前，知识的主要载体是文档和模型。我们称它们为工件（Artifact）。例如，需求阶段时，领域专家在技术专家的帮助下，将自己脑中对领域的认识传递给技术人员，并最终形成需求规格书或是用例模型。而在分析设计阶段，技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分析模型、设计模型、数据模型等工件。最后，在编码阶段，编码人员把这些工件中隐藏的知识转化为软件的形式。经过测试和部署，软件将会交付到用户手中。这是非常典型的软件开发过程，再简单的软件开发也需要经历上述的这些阶段。可以看到，在上述的软件开发过程中，知识形式发生了两次的重要转换，知识所属角色也改变了两次。知识完成第一次的形式转换之后，将成为需求规格书（或同类工件）的形式，知识从领域专家的脑中转换到技术专家的脑中。然后，知识开始了第二次的形式转换，形成设计模型（以及同类工件）。随着知识从技术专家转移到编码人员，知识转换为其最终的软件形式。在这些转换的过程中，最容易出现信息遗漏、信息失真的情况。保证转换过程中知识的完整性和正确性，对软件开发具有重要的意义。4、问题如果保证转换时知识的完整性和正确性？5、方法 知识转换的主体是人，因此我们主要的对策也是针对人来展开的。我们知道，软件过程的特点就是：越早埋下祸根对项目的杀伤力越大。所以我们首先需要重点防范的对象应该是在初始需求分析阶段。需求分析阶段涉及的知识非常的多，大家如果有兴趣可以参看我的文章需求的实践。但这里我们重点的任务是找出需求分析阶段中发生知识转移的关键点。领域专家和技术专家是需求阶段中最重要的两种人，不论你的项目和团队规模属于哪一种层次，一定都包含这两种角色。如果你的团队中领域专家和技术专家是同一种人，那么恭喜你，你可以不用阅读这一段的内容了。可惜在强调分工协作和软件规模不断扩大的今天，这种人已经非常难找了。领域专家是知识的最初持有者，其职责是为项目提供准确的、完整的需求信息。技术专家的职责则是帮助领域专家完成这一项工作。所以，首先请保证领域专家和技术专家是能够沟通的，示例中的项目的第一个问题就是团队的新成员和领域专家之间存在沟通壁垒。在我们的经验中，就发生过一位优秀的技术人员和一位资深的领域专家争吵的事情。剖析原因之后，我们发现，最主要的原因是他们两个人都太优秀了，技术人员有一定的领域经验，领域专家有一定的开发经验，这导致了双方在讨论中的强硬立场。因此，如果遇到类似的情况，请对你的组织进行岗位调整。但在执行这项工作之前，请小心你的说辞，不要伤害到任何一个人。我们的某个小组有麻烦，那边非常需要你的经验和能力会是一句不错的说辞。其次，技术专家不应该提出任何可能影响领域专家的问题。只有领域专家才能够提出需求，技术专家起到的只是辅助作用。因此请杜绝这种情况。再次，如果你的领域专家不只一个人，那么你需要考虑领域专家之间可能出现的不一致。为领域团队指定一位领导者是一种不错的做法。在我们的一个项目中，就曾邀请对方公司的财务总监担任这一角色。理由有二：1、财务总监具有权威性；2、财务总监了解公司的全部运作。此外，如果领域专家分布在不同地点的话，你需要在该阶段的某个时期，安排需求讨论会，并考虑一种能够沟通的方式，以便随时能够了解身处异地的领域专家的意见。这种情况对于那些拥有分公司的公司（例如银行、证券、保险、销售公司等等）而言非常的普遍。因此，我们在需求分析阶段，首先要处理好领域专家和技术专家之间的关系。应该说，这里提到的内容不仅仅适用于需求阶段，在整个的开发过程中都有用处。需求不是实现。需求表示的是有什么（What），并不关心如何做（How）。如果在需求分析阶段把精力分散到了如何实现需求上，那么需求分析的效果就会受到影响。这体现在需求的完整性和正确性两个方面。领域专家和技术专家都可能犯类似的错误。领域专家往往只能够针对自己的工作来描述需求，而他会很容易的把自己对于需求实现看法参杂到需求描述中。从项目的整体范围来看，这种需求描述有时候是有问题的。如果你开发的是一个定制应用，那问题还不大，如果你开发的是一个产品，那么问题就很严重了。领域专家描述的需求一定是你需要的内容吗？例如，你打算开发一个配送的管理应用，但是领域专家把大量的精力花在了他在原先的公司中如何实现配送的流程上，这个过程可能适合于他的公司，但是对于产品而言，可能就不合适，因为并非所有的配送公司都使用这种流程的。好吧，你想要的内容和你不想要的内容混合在一起，这使得你不得不花费精力对需求进行进一步的整理。因此，好的做法是，一开始就明确领域专家应该提供什么，而且，尽可能的提供需求，而不是需求实现。多问一些诸如如果环境发生变化，你该如何做之类的问题，否则你会发现，用户的需求变化将会对你的软件造成很大的影响。再说技术专家，技术专家常常犯的毛病是把分析参杂到需求调研中来，从需求描述中精练出一些业务实体（或进行CRC讨论）是可以的，但是过早的考虑实现方式将会限制你的思维。因此，请确保需求只是需求，这样才能够尽可能保证需求的完整性和正确性。需求复审是非常重要的检查点。请确保你正确的使用它。需求复审需要领域专家和技术专家、以及管理者的参与。需求复审是保证需求完整性和正确性的最后一道防线。在很多的文章（包括我的需求的实践一文）、过程都对需求复审进行了论述，我们这里就不赘述了。在实践过程中，我们发现，需求复审还有一个好的方式，为了能够通过需求复审，需求分析人员（包括领域专家和技术专家）会非常努力的找出需求中的问题。所以，在你的过程中加入这个检查点是非常有必要的。好的，如果这一切都进行顺利的话，最后的需求规格书应该是比较完美的，而技术专家也已经从领域专家那里了解到了足够的信息，可以开始下一阶段的开发了。这里，我们再花一些笔墨来讨论迭代过程中，我们如何处理需求。实践中，我们认为迭代次数并不是越多越好，应该根据项目规模和团队特点进行区分，每一次的迭代都可能有自己的目标。例如首次迭代的周期可能比较短，其主要的目标定为提供软件原型、验证主要设计思路等。第二次的迭代的周期可以长一些，目标可以定位为实现主要功能。如果软件规模比较大，也可以为每次迭代设定需求范围（或主要场景），这样就能够防止需求扩散的情况。这已经超出了本文的范围，因此我们这里只是简单的提一下。分析阶段是发生职责转换的重要阶段。该阶段的成败对软件开发至关重要。对于面向对象开发而言，这个过程最主要的任务是对领域进行建模。比较好的方式是使用UML来描述领域知识，例如，我比较经常使用类图来建立分析模型，使用顺序图来描述动态流程。请确保技术团队中最出色的分析建模人员参与这个初始分析建模的过程。他的职责包括指导建模和对模型进行审查。如果在一个迭代过程中，这个模型是不断演进的，这可以减少一些风险。在这个过程中，建模人员可以吸收领域知识，这对于后续阶段中指导其他开发人员是很重要的，对公司的长远目标也具有重要意义（参见 短期利益和长期利益的权衡模式）。如果建模人员缺少面向对象开发的经验，他会很容易把对象变成一个数据容器。这种方式并不是不好，但它把数据和行为区分开来，无法站在一个抽象的高度上对领域进行分析。 很难严格的区分分析阶段和设计阶段，至少我是这么觉得的。他们的差别仅仅是在分析的详细程度上（有点类似于以往的概要设计和详细设计）。在实践中，我们发现，并没有必要严格的区分它们，但是你需要保证模型已经完整的描述了需求。这里可以设置检查点来验证，也可以在设计模型出来之后再进行检查，这取决于具体的项目。因此，我们在分析阶段和设计阶段结束之前需要进行设计复审。从Martin Fowler提出分析模式的概念之后（现在他的第二本分析模式正在写作中），它就成为分析建模的有利助手之一对领域概念进行分析和建模，并描述它们之间的关系（我在点空间上的一篇读书笔记反应了需求和分析之间的关系）。但是请千万注意，不要误用和滥用分析模式。因为任何分析模式的提出，都是基于某个上下文环境中的需求的，如果上下文环境不同，那么模式就需要改进或改造。因此，分析模式是一个好的开始，但需要你针对实际需求具体分析。在应用模式方面，Frank Buschmann的Applying Patterns是一篇不错的参考文章，其中文版发布在点空间上。请按照逐步精化（迭代）的方式来完善、改进你的分析模型。优秀的设计一定不会过于复杂。如果你的分析模型出现过于复杂的情况，到处充斥着复杂的关系网。那么，你需要对你的设计进行结构上的改进。例如，采用分层（参见 敏捷架构设计一文中的分层模式）、组件技术、或是使用单向联系。坚持这一过程，你会发现最后的设计是简洁的、完美的。 在设计阶段，要注意的事项和分析阶段相差不多，例如不要误用和滥用设计模式。但是有一点是需要额外强调的。当分析模型已经能够完整、正确的描述需求之后，我们就需要在设计模型中添加设计资料。例如对包、组件、类、方法的描述。这时候，需求的信息已经被打散到软件的各个部分中了。而设计模型在被实现时，设计模型中的信息又将进入到代码中。因此，保持这些信息的一致性就显得非常的关键。而由于设计模型处在中间地带，它的重要性又是不言而喻的。基本的处理思路分为两步：在需求发生改变时，请同步更改设计模型以及设计模型中的信息。再由设计模型驱动代码的修改。第一个步骤是需要手动实现的，但是第二个步骤可以由计算机辅助实现，即保持设计模型和代码信息的一致性（将在 一致性的思考模式中讨论）。目前有很多的建模工具都可以做到这一点，甚至能够实现产生最终的API文档。善用这项功能，它能令你事半功倍。 在软件过程中设立反馈活动，可以有效的减少项目的偏差。就像我们骑自行车，很少能够走一条直线，一般我们是根据对目标的偏差进行忽左忽右的调整。这就是反馈的机理。原型法是一种不错的反馈机制，根据我们的经验，视觉刺激对用户是最为关键的，因此不论你的需求文档做的如何的优秀，仍然比不上一个能够看得见的软件原型有效。这一实践很多的软件工程资料中都有叙述，我们就不深入了解了。另一种反馈机制是渐进交付。把软件产品分为多个迭代周期，每个周期交付一个可运行的软件，在获得用户的反馈意见之后，在下一个迭代周期进行改进，最后一个迭代周期交付的就是完整的软件了。6、对可重用框架的改进 在找到了适合软件企业自身的知识接力方法之后，应当将其作为规范或指导意见，加入到现有的软件过程中。例如，在需求分析完成之后强制要求进行需求评审。加入到过程中的方法，小心不要流于形式。这样，既付出了成本，又收不到应用的效果。使用工具也是保持知识顺利交接的重要方法。例如，采用自动产生源代码的工具，模型设计工具、帮助产生工具、对象-关系映射工具等等。如果这些工具对你的过程起到了润滑的作用，请规范和普及工具的使用。7、小结 请确保领域专家和技术专家之间的顺畅沟通。 完整、准确的描述需求。 进行需求复审和设计复审。 保证分析模型（设计模型）能够完整的描述需求。 保持需求信息到设计信息到代码注释的一致。 使用反馈机制。 三、代码是最终目 过程的最终目的是代码，开发过程中的所有活动都围绕着这一目的而展开。如果没有最后的用于交付的代码，软件就无法成为软件。因此，必须保证过程能够产出代码，而且是优秀的代码。1、意图 无论哪一种过程，其最终目的都是为了产生出可执行、并且可用的软件。因此软件过程中的各种活动应该围绕着快速、准确的实现这一目的而展开的。 2、示例 维力亚软件公司是一家合资公司，由于有外资背景，公司内部很早就引入了软件工程，并严格的对人员角色进行分工。包括领域建模人员、架构设计师、高级程序员、程序员、界面设计师等等多种角色。每个人各司其职，充分发挥出了分工的特点。但是随着公司开发项目的逐渐增多，这种方式也显露出其弊端来。每个人的主要目标都是为了通过评审，而有时候，就算是通过评审的工件，依然可能存在问题。但这时候扯皮就出现了。项目中存在的一些中空地带。以及交错地带，常常发生无人问津的情况。开发过程的效率开始下降，开发成本开始上升。问题虽然不是一下子出现的，但是已经逐渐变得严重起来了。 3、分析 我们在进行过程设计，或引入一个过程理论的时候，有没有思考过该过程的每一个阶段、每一个活动的目的是什么，它们对生成最后的软件有什么样的帮助，这些帮助对于我们所在的组织有意义吗。很多情况下，我们并没有这么做，或者随着软件过程的定型，就不再思考这类的问题。一开始并没有什么了不起的，但是当软件过程演变成了一种政治体系的时候，那么问题就会慢慢严重起来。 4、问题如何让过程围绕着产出软件的核心目标而不断演进？ 5、方法 从上一篇介绍的内容中，我们知道软件过程的每一个阶段都是知识转换的过程，知识转换的终点就是软件。问题在于，我们如何保证这种转换的效率呢？ 现代软件的发展的趋势是重用。我们开发一个软件已经很少会从最底层开始编写了。我们使用各种各样的技术和平台。包括数据库、分布式体系、UI机制、业务元素等等。因此现在的软件编写往往都是站在巨人的肩膀上开始的。不同的软件组织，肩膀的高低也不一样。比如有的软件组织使用J2EE平台，有的软件组织则使用.NET平台。但是可以肯定的一点是，每个软件组织都或多或少的拥有自己的平台体系开发经验。这些经验的表现形式也不尽相同，可能是保存在某些高级技术人员的脑中，也可能是保存为文档、模型或代码的形式。对于单个的项目而言，其过程一定是从需求开始，以部署（以及后续维护）为终结的。但是对于长时间存在的软件组织而言，更重要的是项目经验、技术经验、管理经验的积累。这样说可能过于抽象，我们举一个具体的例子。在完成了一个库存管理项目之后，我们把库存管理的领域知识制作为商业组件的形式，而把项目中学习到的一些编码的技巧整理为模式的形式，并把项目过程中积累的过程方法添加到现有的软件过程中。这些经验的堆积就是在一开始我们提出的可重用框架。对一个软件团队的来说，它的所有软件项目都应该是围绕着这一个可重用框架而展开的。 迄今为止，我们见过的大多数的可重用框架表现形式都可以总结为：以开发平台为基础，积累自己的商业组件，并以此为中心订立开发活动。这种形式是不是最好并没有定论，但我们是抱着学习的态度来研究它的。 以开发平台为基础的意思是软件组织必须有自己所熟悉的开发平台，其大部分的项目都是在此基础上进行的。目前最流行的两种软件开发平台是J2EE和.NET，但是就算是同一个平台，不同的软件组织对平台内部的侧重也是不同的（同样对于J2EE技术，有的软件组织可能把JSP和Servlet作为核心选择，而另一些软件组织则把重点放在EJB上）。选择一种广泛应用的、具有生命力的平台技术是非常重要的。因为你的框架将会以此为基础进行，而框架的转移成本是非常之高的。虽然我们在一开始介绍的MDA思路为我们绘制了一副平台无关设计的美好愿景，但是在目前阶段，我们仍然要面对不同软件平台造成的严重隔阂。 必须指出的是，我们上面提到的开发平台指的是在操作系统这个层次之上的平台，也就是俗称的中间件平台。但是从中间件到最终的产品之间有没有过渡的平台呢。其实可重用框架就扮演了这一角色。软件市场上已经出现了商业化的可重用框架了。IBM的SanFrancisco框架就是这种概念的代表。 平台技术仅仅只是提供了一个技术，而软件组织要生存和发展，还需要积累和发展自己的商业组件。并将商业组件发展成为可重用框架。商业组件的好坏，直接和软件组织的能力、经验，以及平台技术相关。商业组件可能直接表现为代码的形式（Bean、类、COM组件等），也可能只是描述性的记录（文档）。商业组件是经验积累而成的。请注意，商业组件的设计并不完全等同于面向对象开发，因为面向对象只是一种技术手段，但是商业组件设计的优劣，更重要的是对业务的理解程度。举一个最浅显的例子，一个精通面向对象开发、面向组件开发的设计师，让他介入他完全不了解的行业组件设计，他的表现将会大打折扣。 到目前为之，大家所认识的框架仍然是技术型的框架。但事实并非如此，框架还包括了外延的一系列软件活动。这才是一个完整的框架。结合之前我们讨论的软件交付为开发目标。我们把这种开发方式称为以可重用框架为核心，以交付为目标的软件开发。这其实并不是什么了不起的概念，大部分的软件组织都已经这么做了，只是没有意识到自己的方式而已。了解这一点，能够帮助软件组织有效的改进自身的构架。 平台技术和组件开发并不是本文的重点，因此我们在肯定了两者的重要性之后，把精力转移到软件活动上。 在拥有一个框架核心（平台和商业组件）之后，框架需要包含这样的活动（或活动集）：收集项目需求，并将需求映射到核心构架上来。这其实就是需求阶段到设计阶段要做的事情。但是由于我们的活动是以软件交付为目标的，因此我们需要明确的指出活动中的注意事项。 为映射工作设计需求描述规格。需求并不是一件容易的事。最难的莫过于尺度的把握了，例如需求要多详细。使用现成的技术来定义需求描述规格，并根据核心框架的特点进行必要的扩展。例如，我们使用成熟的用例技术来描述需求，同时我们要求需求按照不同类的商业组件进行分类索引。用例技术的推荐读物是Alistair Cockburn的Writing Effective Use Cases一书，该书目前已有英文影印版。 保证需求规格能够被项目成员所理解。这里的项目成员包括客户、领域专家、需求调研者、分析模型设计师。只有他们了解需求，才能够保证信息的正确的传递。（参见 知识接力模式）。 为实现需求制定分析（设计）规则和指南 。这是把需求映射到核心构架上的重要步骤。制定规则是必要的，但要小心，不要让规则限制住开发人员的创造力（参见 活跃和混乱、严谨和死板模式）。规则的形式可能是设计规范、分析模式、类库、组件重用等等。在指南中提供示例，描述如何将需求转换为设计模型是一种不错的做法。同样好的做法还包括了模式指南。 确保测试贯穿了需求模型和设计模型。我们终于提到了测试。测试在软件过程中扮演着重要的角色。但遗憾的是在本文中直接提到的机会并不多，从某个角度上看。 知识接力模式中提到的复审其实也算是一种测试。测试的信息都包含在需求模型和设计模型之中，例如前置条件和后置条件。在完成需求模型和设计模型时同步完成测试用例是一种非常好的做法（我们的团队正是采用这种做法），但是需要小心文档一致性（参见 一致性的思考模式）的所需要付出的额外成本。 如同在 知识接力模式中提到的那样，让领域专家、架构师和高级开发人员对需求模型和设计模型进行复审。 原型方法能够有效的帮助最终软件的成功。所谓原型方法，就是选取系统的某个部分（最直接或风险最高的部分，通常是界面原型）， 实现并呈现给用户，以获得反馈，为后续的活动提供指导。原型方法最大的好处是能够帮助用户认识软件，消除用户的疑虑，并发掘潜藏的需求。围绕着是否抛弃原型这一根本问题，原型方法可以分为渐进原型方法和舍弃型原型方法。前者是在一个软件原型的基础上不断的演进，并最终发展为可用的软件，后者则是在开发出原型之后就将它舍弃。渐进原型方法充分利用了原型，但是由于缺乏前期设计，可能会导致最终产品存在性能或设计问题。舍弃型原型克服了这个问题，但是它浪费了原型开发的那段时间。不论采用何种方法，最重要的是在项目一开始就决定采用哪一种原型方法。模棱两可的使用两种方法是兵家大忌。最终你无法利用任何一种方法的优点，而所有的缺点都将降临到你身上。相较而言，渐进型原型方法更适合于应用在小型项目上，因为项目并不复杂的话，设计的改进比较容易。对于一个拥有构架的团队而言，把原型方法纳入构架之中是很有意义的。如果构架足够成数，迅速开发出一个原型并不是什么很困难的事情。这样就可以在投入最小化的情况下获得原型方法的优势。如果情况是这样的话，舍弃型原型方法似乎更适合一些。 在 知识接力模式中，我们简要的提到了设计模型信息和代码信息的转换问题。使用建模工具来自动从设计模型抽取信息，并生成项目的代码。这种方法能够大幅度的提高软件开发效率，并对软件的最终交付有很大的帮助。同样，将代码中的信息转回到设计模型中（属于反向工程的一部分）也是有意义的。如果缺少这样的工具，那么请人为的保证信息的同步，当然，并没有必要保持实时的同步（参见 一致性的思考模式）。 软件的成功和测试活动是无法区分的。我们前面简单的讨论过测试信息是来源于需求的。测试信息随着需求模型的生成而生成，并通过设计模型进行转换，在软件过程进入到实现阶段时，测试信息最终被转变为单元测试用例的形式。单元测试用例可能是针对单个方法的单个用例，也可能是针对某个开发包的几组用例。我们需要注意两点，首先是在软件过程中保证这个流程的顺畅和正确。就像在 知识接力模式中讨论的那样，正确、完整的信息传递保证了最终软件的成功出产，测试信息的成功传递保证了最终软件的可用性。测试是软件的保证。因此，我们需要几个活动来保证测试信息的成功： 从需求模型中生成接受测试。该活动把需求映射到测试上。在这个活动中，不但要注意功能性需求（如完成的功能），还需要注意非功能性需求（性能要求）。同样的，接受测试也需要接受复审。可以按照需求的组织方式来组织接受测试。 设计模型完成之后，接受测试已经细化到模型的各个元素上了（例如包、类）。该项活动和将需求映射到设计的活动是同步进行的。因为它们处理的信息是非常类似的。和接受测试一样，这两个活动都需要由团队来保证。 在进入编码阶段之后，开发人员根据接受测试和设计模型，将会为自己负责的部分设计编写单元测试。单元测试的编写顺序是否优先于编码，这取决于各人的看法。关于这方面的讨论，可以参看XP的单元测试实践。从我个人的经验来看，先写单元测试，再写代码不失为一个很好的办法，另一种做法是，让两个紧密合作的开发人员相互为对方编写单元测试。 其次，我们需要保证测试的最小单元单元测试的成功。所谓皮之不存，毛将焉附。单元测试没有组织好，最后的软件是不会成功的： 需要注意单元测试的覆盖率。这里的覆盖率指的是是否能够完全检测出错误所在。比如边界条件的测试等。开发团队中的架构师之类的角色需要为此负责，如果无法检查所有的单元测试，那么可以进行抽查和代码复审会议的形式。后者是一种很优秀的做法。从代码中抽取出一段，开发人员一起分析单元测试存在哪些问题，会使得大家编写单元测试的功力不断的增长。 单元测试一定要是自动化的。Junit就是一个不错的自动化测试框架。保证单元测试的自动化，并且避免单元测试和特定环境相关，这样就可以顺利的进行回归测试。这对于迭代式的软件开发是非常必要的。同时，我们也应该认识到，单元测试的稳定性取决于设计的稳定性。我们可以想象，如果测试的类方法的参数、命名都发生改变，那么测试是肯定需要重新组织的。所以，面向对象的抽象思维对于现代软件开发而言是费产重要的。为了做到测试的自动化，尽量避免将逻辑硬编码在界面中，并小心的处理数据库。可以尝试着建立测试数据库。 如果测试的内容需要并入核心构架，那么这部分的测试工作需要增加，并对构架可能的修改进行测试。因此，学习开源软件的做法，将构架的稳定版本和开发版本相区分是比较保险的。 让测试活动随着软件开发的进行而进行，让测试活动贯穿整个开发周期。这有点类似于全面质量管理的思想。因为软件开发过程的失败并不是突然而至的，而是在平时的不经意间一点一点的积累起来的。使用测试活动来消除这种微小的不稳定性，能够大幅度的提高最终软件的质量。但是，在一个团队中引入正规的。频繁的测试活动是需要耐心的。可以先从单元测试着手，慢慢的普及这种做法。 测试活动可以衍生为日创建和冒烟测试。对于有复数的开发人员参与的软件项目，就无法避免正视集成测试的局面。有过类似经验的人都可以想象的到这种集成测试的难度。专门有一句话是描述这种局面的：我们已经花了90%的时间来完成90%的软件，但我们还需要90%的时间来完成剩下的10%。现代的软件往往都包括成百上千的文件，这些文件的编译链接的过程是很复杂的。而日创建的思想就是每天进行一次这样的过程，形成一个可执行文件。但这只是日创建第一部分内容。日创建还需要对软件进行冒烟测试，测试的主要内容就是单元测试中所编写的内容，保证软件可以通过所有的测试。 日创建需要留下一些调试的时间，尤其是在软件开发初期，不同开发人员的代码整合在一起出现问题的可能性极大。随着对这项实践的熟悉程度，问题会逐渐减少。日创建可以很明显的提高产品质量，以及提升团队的士气。虽然日创建活动需要付出额外的一些成本，但是相对于集成测试的不可控，这些成本还是值得的。 6、小结 投资于框架能够保证软件开发的成功。 应用有效的实践活动来完善框架。 将需求映射到核心框架上来。 使用原型法。 注意测试活动。 如果可能，使用日创建，并进行冒烟测试。 规则不同于指南。规则是目标受众所必须遵守的，而指南是建议目标受众遵守的。四、一致性的思考 一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。可以想到，这又是一个需要权衡的问题。1、意图 软件过程中的大部分工件都需要保持其相互之间的一致性。可是，工件越多，保持一致性的开销也就越大。我们需要在一致性和成本之间保持平衡。2、示例 天利软件公司的项目经理正在为开发过程中出现的大量的不一致问题头疼不已。从软件过程一开始的需求阶段，版本问题就一直困扰着项目组的成员。项目组的成员并非没有经验，只是这一次的项目规模超过了以往的项目，因此公司决定采用严格的过程，以保证软件质量。开发过程中每个活动都必须产出文档。第一次的不一致发生在需求调研中期的一次研讨会上，当时的会议上发现了三种不同版本的需求规格书。之后情况越来越糟，文档的数量不断增多，由于所有的开发人员都需要编写文档、使用文档，因此发生了各种原先没有料到的事情，包括新文档被覆盖；设计人员手中的需求规格书不是最新的版本；设计书变更之后，代码却没有相应的变更；代码中的方法说明和设计模型中的方法说明不一致。为了对文档进行控制，公司不得不从项目组中抽调了两名开发人员来控制文档，并加强了文档的管理。但是随之而来的是开发周期的延长。3、分析 一致性包括两个方面：一是不同工件之间的一致性，二是使用同样的方法来处理问题。软件过程的每个阶段都需要产出不同的工件。典型的例如需求分析阶段将产出需求规格书、用例模型、非功能需求等，设计阶段产出设计模型、类图。而在软件开发中，我们常常会遇到需求的变更的情况，因此我们需要依次对我们的需求模型、分析模型、设计模型、代码进行修改，以保持它们之间的一致性。如果项目处于前期阶段，这种修改量并不大，因为工件较少，如果项目进行到后期。需求的改变将会涉及到大量的工件。对于期限比较紧张的项目而言（这似乎是所有项目共同的特征），这种成本几乎是无法接受的。另一方面，在同一个软件组织中，解决同样的问题有着不同的办法。不同的人有着不同的编码习惯、不同的目录组织方式、不同的类库、不同的框架。虽然我们并不反对同一问题的不同解法，但是当这种情况对项目的进展起到负面的效果的时候，我们就有必要来思考这个问题了。4、问题 我们如何在一致性和一致性带来的成本之间做好平衡？我们如何保证不同工件之间的一致性，又该如何保证项目中解决方法的一致性。5、方法 首先，我们应该肯定，一致性这个问题并没有标准的答案。不同的项目对一致性有着不同的要求。对于要求严格、规模庞大、涉及到一些重要领域的项目来说，一致性的要求是极为严格的。而对于一个小型的、较为无关紧要的项目来说，一致性的要求就低了许多。因此，和前面介绍的模式类似的，一致性的正确的答案只能够从读者自己的项目中去寻找。而这里提供的，是寻找该项标准的建议。我们先从后者解决方法一致性入手。和这个标准答案相关的是一致性的程度。一致性的标准可大可小。大的标准包括了设计原则、软件架构；小的标准包括用例的书写格式、设计模型的注释格式等等。由于大的标准对开发过程的作用最大，因此在进行一致性处理的时候，应该先从大的标准入手。在 代码是最终目的模式中，我们提到了构架的概念。以构架为中心来制定标准，保证一致性是一种自然的思路。核心构架应该要能够确定软件开发的方向，这样可以最有效的保证一致性，但是不要涉及到过于具体的细节，除非你对它们已经有足够的经验。而标准的深入程度则要取决于组织经验、已有的软件过程、项目规模等因素。 对于项目来说，一致性存在一个逐步精化的过程。正如我们上面所讲的，一开始最重要的是引入核心原则，这里我们认为是可重用框架。对于可重用框架中已经明确确立的事项，必需要严格的遵守，因为框架中的内容是足够稳定的，已经经过验证的。这其实是重用思想的一种衍生。我们在 短期利益和长期利益的权衡模式中还会谈到。如果有必要，引入的核心原则需要针对项目进行部分调整。例如，框架中根据项目的规模大小定义了用例的三种写作模板，在项目开始的时候，我们会选择其中最接近的一种模板，并根据项目增删模板中的一些元素。而对于框架中不曾定义的，一些尚未明晰的事件，我们在项目初期不需要进行过于详细的处理，而是随着项目的进展来慢慢的完善它。例如，由于需求没有确定，我们并不知道最后的设计模型是什么样的，因此我们先根据框架定义，选择JSP和Servelet作为主要的技术基础，由JSP负责提供视图，由Servelet提供业务逻辑。其它的信息则等待进一步的精化。 在项目一开始的时候，不要过分注意工件的修饰。例如，我们选择的用例模板要求每一个用例都需要包括6种元素，包括主要角色、级别、前置条件、主要流程、备选流程、优先级。并规定引用其它用例的地方需要做出链接。但是在一开始需求调研的时候就按照这种标准完善用例将会提高成本，因为需求尚未稳定，我们主要的工作是尽可能完整的收集用例，而不是把时间花费在修饰用例上。因此一开始任何形式的用例描述都是允许的。你可以使用几句话来描述用例（事实上，利用自然语言来描述用例有着图形无法比拟的优势），并用着重号标记出其中可能和其它用例相关联的词汇。这样就已经足够了，