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

过程塑造（小型软件团队过程改进方法）一、从方法到编码这是一篇偏重于介绍方法学（特别是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。本系列包括：知识接力、代码是最终目、一致性的思考、活跃和混乱、严谨和死板、短期利益和长期利益的权衡。软件管理和软件开发是截然区分的吗？对于项目经理来说，其职责是软件项目的管理，而对于架构师、编码人员来说，其职责是软件设计和开发。虽然在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感受到软件管理和软件开发之间客观存在的沟壑。我常常听到来自两个方面的声音。一边抱怨说设计师、编程人员阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边抱怨软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。现代的方法学理论以及相应的过程实践为我们奠定了软件开发科学管理的基础，个中的翘楚包括RUP和XP，纵观这些方法、过程，都非常强调过程的流畅、生命周期的延续。而在实际的应用中，我们却常常能够看见对它们的不恰当的理解，不正确的使用。尤其是那些希望在自己的软件团体中引入新型的方法过程新手们。对于他们来说，最容易犯的一个错误就是忽视了如何利用一个软件过程来创造一个成功的软件。关于如何建立一个软件过程的资料很多，但是这些资料并没有把为什么需要过程，过程的目的是什么之类的问题说清楚。而这些资料的读者们，往往需要花费大量的时间，亲自进行实践之后，才能获得这些问题的答案，而付出的代价是教训和挫折。同样的，我和我的伙伴们也经历了这样一个过程。因此，我希望把我在过程应用、过程改造中涉及到的问题例举出来（采用过程模式的方式）。如果大家能够利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。但是本文中所讨论的内容都可以对以上的活动起到部分的指导作用。敏捷？敏捷！从开始研究软件工程，我就对敏捷过程的概念情有独衷，但是随着学习的深入（所犯错误的增多），我发现敏捷是无处不在的，她是一种尺度，一种处于混乱和死板之间的平衡艺术。有句俏皮话说的是一放就乱，一管就死，这句话很好的点出了软件过程的一种无奈性。如果没有严格的规定，软件开发就陷入一种混乱、无序的状态，但是如果制定了过于严格的规定，软件人员的思路又受到极大的约束，管理成本也随之上升。敏捷正是一种处于两个极端之间微妙平衡的艺术。这种艺术难以完全表述，但是可以通过一些指导，来帮助大家达到这种境界。因此，我们可以推想的到，敏捷是见仁见智的。每一个软件团体都有自身的特性，其敏捷过程必然都不尽相同。如何设计出成功的敏捷过程，来保证软件团体的成功呢？本文通过一些过程模式的讨论，揭开了问题的一角。关于过程设计的完整的讨论，大家可以参考敏捷软件开发[AlistairCockburn]一书（该书近来将有中文版面世），该书详细的描述了过程设计的来龙去脉，以及如何根据组织的特点来选择适当的过程。因此，虽然本文中并没有特别提到敏捷的字眼，但是所讨论的内容无不在敏捷思维的范围之内。MDA推动软件可重用框架的建立我有一个梦想，希望有一天能够不用在诸多的平台之间摇来摆去。虽说Java语言的口号就是跨平台。但事实上，我们还是无法完全摆脱平台的束缚。在UML2.0的规范中，提到了一个MDA（ModelDrivenArchitecture）的概念。在众多的软件平台中不知该如何选择，已经演变为当今软件开发的主要难题。MDA的存在目的就是为了解决这个问题。通过MDA技术，一个UML的模型可以是平台无关的，称为PIM（Platform-IndependentModel），也可以是和特定平台相关的，称为PSM（Platform-SpecificModel）。利用平台技术的软件商，可以专注于自己的领域，集中描述业务功能，业务规则，而无须考虑特定的技术，构建出一个PIM，然后，通过支持MDA的工具，将PIM转换（通过不同Profile进行映射）为一个或多个PSM。这时候的模型仍然是UML的。但是，这个转换过程虽然有工具的辅助，但仍然需要外力的介入。接下来，开发工具将会从PSM中产生可执行代码。这就是MDA的思路，它把以往以程序为中心的开发模式转变为以设计为中心的开发模式。以往的重用，往往是基于代码的，例如算法的重用、界面组件的重用，却往往没有将重用提升到设计的层次上。MDA为我们建立可重用的框架提供了一个很好的指导。注意上面的这副图，最外面的两层就表达了MDA可以用于设计重用的基本理念。倒数第二层的含义是利用MDA来进行通用软件（例如事务、目录服务）的模型设计，倒数第一层则表示MDA可以用于特定业务领域的设计建模。可以想象，今后软件公司中的最有价值的资产，就是这些设计模型。本文并不打算详细讨论MDA，除了简单的介绍MDA的思路之外，更重要的一点是企业可重用框架的建立。软件企业的核心在于知识，如何有效的将人脑中的知识存储起来，并不断的使用和发展，是软件企业成功的关键。本文提到的可重用框架，指的就是将软件开发相关知识存储起来的框架。这个思路是本文的一个核心思路。在本文看来，可重用框架不但包括了设计模型，还包括了过程和方法。软件开发是在这个框架之内运作的，同时反过来影响着框架的完善和改进。过程塑造模式语言下述的模式都是从软件开发过程中，围绕着可重用框架的建立整理出来的一些经验，之所以整理为模式的形式，是因为这种方式有利于类似情况的鉴别和对其进行必要的扩展。在软件开发中会遇到各种各样的问题，以上模式中讨论到的问题都是我们在实践中，或是和其他开发团队沟通中反复遇到的。因此坚定了我们将之整理为模式的信心。目前我们得到的模式并不多，但是随着经验的增加，我们会得到更多的积累。本文介绍的模式都比较注重权衡的艺术。我们认为这是敏捷思维的必然结果。世界上并没有什么绝对的事情，尤其是目前多变的社会中，昨天的标准并不适合于今天的环境。因此，我们的平衡点也在不断的变化。传统、经典、学术的瀑布模型为我们建立了软件开发的基本过程，虽然有各种新的生命周期模型的提出，但是基本的过程并没有太大的变化。例如，增强性的瀑布过程是在瀑布模型的基础上增加了回溯到上一个阶段的能力；迭代式过程的每一次迭代都是一次微小的瀑布生命周期。在这个生命周期模型中，信息在初始需求收集阶段生成，并通过分析、设计、编码、部署等阶段转化为用户最终需要的软件。在这样一个延续性极强的周期中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？这些问题正是知识接力模式所重点关注的。我不只一次的见过为过程而关注过程的情况。产生这种结果的一种原因是“过程麻痹症”。过程一旦定型，就不再改变，即便当初制定过程的环境已经发生了变化也是如此。过程的制定一定是针对特定的目标的，这个目标就是开发出成功的软件，如果不能够服务于这个目标，遵循过程又有什么意义呢？另一种原因是过程被分割为彼此独立的片断，每个开发人员只关注自己的职责，而忽略了最终的软件。过程的代码是最终目的，开发过程中的所有活动都围绕着这一目的而展开。如果没有最后的用于交付的代码，软件就无法成为软件。因此，必须保证过程能够产出代码，而且是优秀的代码。一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。可以想到，这又是一个需要权衡的问题。软件项目中的一致性大致可以分为两种，一种是不同工件之间的一致性（例如设计模型中的类名称和实际代码中的类名称的一致性），一种是工件和软件过程的一致性（类名称需要满足命名标准）。我们如何考虑这两种情况下的一致性呢？人们说管理既是科学也是艺术，这句话用来形容软件工程再适合不过了。如果说这里有什么不够恰当的地方的话，我倒觉得是软件工程的这个提法有些许的欠妥。软件工程的思路源自于人们渴望软件开发能够像土木工程那样成熟。但是几十年的经验下来，大家可以肯定，软件开发和土木工程有着太多的不同：开发人员和建筑工人也有着截然不同的差异，知识的组装和钢筋混凝土更是天差万别。（但为了保证延续性，我们在本文中仍然延续软件工程的提法。）因此，软件工程需要在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、过程、方法，它们是否能够发挥出人的创新性？或是它是否足以约束人的行为？这就是活跃和混乱、严谨和死板模式所要告诉我们的。应该说，本文中所讨论的模式更适合于使用面向对象技术的开发团队。尤其是短期利益和长期利益的权衡模式。和大多数人一样，我们最早也是过程式编程阵营的一员。在经过长时间的学习和不断的犯错之后，我们终于转向了面向对象。面向对象最大的好处包括了以下几个方面：将实现和接口分离，即把如何做隐藏起来，而把做什么展示给客户。继承和多态使得我们能够在一个抽象的层次上（基类和接口）思考问题，并能够根据现实的需求进行灵活的调整（子类和实现）。通过设计模式和设计技巧的应用，可以有效的降低系统的不同部分之间的耦合度。尤其是简化客户端的代码。在使用和比较过几种开发语言和开发环境之后，我们发现，其实最关键的并不是使用什么样的面向对象语言（或环境），关键的是你运用面向对象思维的能力，或者说对现实世界的理解、抽象、映射的能力。这种能力决定了你的开发水平的高低，而语言和环境只是一种重要的实现手段和工具而已。而这种思维能力，虽然可以通过例子和讨论来进行介绍，但更关键的还是在实践中进行练习。在本文讨论的模式中，我们会夹带的对这些内容进行讨论。因为我们认为，开发思想和开发过程是无法区分的，否则，你的开发过程就没有灵魂。这也是我们的主题所要强调的：从方法到编码，铸造起一个敏捷的、流畅的过程，才能够保证开发过程的成功，开发软件的成功。此外，本篇是总论性文章，在撰写此文时，该篇其实是最后完工的，因此，建议大家在看过全文之后，如果还有耐心，可以重看此篇，相信会有另外一番收获。现在请大家进入我们的模式之旅。二、知识接力在软件过程中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？1、意图软件开发过程是知识传递、知识转换的过程。注重知识转换中的完整性，保证知识经过各个阶段和活动，顺利的转换为软件是极为重要的。2、示例元朗公司是国内某银行的下属企业。从年初开始，公司就投入了大量的人力为银行开发新版本的国际收支系统。考虑到这是一个非常庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人员有些来自于其它的项目组，有些人员来自别的公司。为了保证开发的顺利进行，项目经理引入了软件过程。但是从一开始，麻烦的事情就出现了。项目组中的技术人员和银行的领域专家之间不断出现意见相左的情况。主要的问题是后加入的员工对目标领域不熟悉，难以配合领域专家的工作。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析阶段不得不在原先的基础上延长了50%的时间。在进入设计和编码阶段之后，问题少了许多。但在设计到编码的过程中仍是出了一些麻烦，原因是新加入的人员不熟悉开发团队的设计风格。经过一番周折，问题基本解决了。可等到项目进入到测试阶段，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严重错误。经过对错误的复审，排除了其中17%的严