过程引入的反模式——如何避免一个过程对您的影响-UML软件工程组织-火龙果软件

UML软件工程组织

过程引入的反模式——如何避免一个过程对您的影响

作者：不详　来源：网络

本文内容包括:

模式（Pattern）与反模式
描述过程反模式
结论

本文来自于 Rational Edge：在一个软件开发组织中处理过程采用问题有合适的方法，也有不合适的方法。在本文里作者指出了一些常见的错误，即通常被看作是反模式（anti-pattern）,是由项目领导者在过渡到迭代开发方法时所造成的。

　软件开发组织比以往更能意识到适当地拥有一个有效过程的重要性。当我谈到有效这个词时，意思是指一个通过帮助管理风险、变更、时间表、质量、以及所有对软件开发项目成功有贡献的事情从而帮助组织达到它的目标的过程。这个月我们将思考如何在您的组织中实现这样一个过程。

无论怎样，我们将间接地处理这个问题。也就是说，我们不是考虑那些帮助改善过程的积极行为，而是关注那些看起来能够大幅度提高我们的过程，但实际上使事情变得更糟糕的行为。这些负面的行为通常是按照下面的反模式标题进行分类的。

模式（Pattern）与反模式

模式是当今软件专业人员工具箱中的一部分。明确地说，我们学习设计模式——设计我们程序的方法，使它们功能更强大、更灵活、更准确。Erich Gamma 在90年代初期他的博士论文中提出了软件设计模式的基础。Gamma 从 Christopher Alexander 那获得很多灵感，Christopher Alexander 是一位研究体系结构学科（不是软件体系结构）中模式概念的架构师。1995年设计模式一书的出版使模式的发展成为软件开发学科。 1

模式仅仅是一个解决普遍发生问题的被证实过的方法。模式并不是您仅仅只需要剪切和粘贴的具体解决方法，而是一个您如何解决问题的方法。模式与只需要在空白处填写内容的模板并不完全一样。

模式不是发明。您不需要在遇到一个问题的时候坐下来专门创造一个模式来帮助您解决这个问题。事实是我们把模式看作可再度使用的组件，它应该给我们这样的警告：我们发现了模式而不是发明了模式。我们可能经常认为我们要编写一个可重用的软件组件，事实上重用就表明在前面已经使用过。因此我们真的不知道我们所创建的可重用组件是否是一件很好的事情，直到有人使用我们的组件，然后又有人重用。对于模式也是这个道理。我告诉我的学生们一个简单地经验：一次是事件，两次是偶然，三次就是该想想您是否发现了模式的时候了。

模式因为能够让软件开发人员使用一种常见的语言而变得十分流行。他们使用像“适配器（adapter）”和“门面（facade）”等术语就像工匠使用“燕尾接合”一样。这种语言用能够传输大量语义的单词丰富了我们的词汇量。一旦模式变得流行起来，模式就开始出现在软件开发的其它领域，如过程，需求分析等等。每个专业领域都想引入这个以新的眼光观察世界的方法。模式是 90年代的“下一个重大事件”。现在已经有一些关于过程、需求管理、软件构架、测试、项目管理等模式的书籍和文章。从业者和理论家们都想采取一种很好的方法让它适合于我们所做的任何事情。我只热爱80年代中期面向对象的 pen。我仅仅是说 pen.write ，它就能够神奇地完成它的工作。 2

在我看来，这种寻找模式的热潮导致了一种典型的情景：因为树木挡住了道路所以我们看不到森林。突然之间所有的事物都变成了一种模式，从持有一个编码标准到支持代码走查以及选择一个程序设计的语言。应用模式需要思考，理解这些问题，判断使用这种模式的后果，以及经验。

发现和应用模式的后果之一是，模式就像药品，会导致滥用或错用。换句话说，我们对一个特定的模式开处方，但是令我们感到懊恼的是，这个病人（在我们的例子中是一个软件开发组织）的病情变得更加严重，甚至可能死去。在我们观察这些效果时，我们发现了一种反模式。当一个似乎能够很好解决问题的方法实际上使问题变得更加糟糕时，就会出现一种反模式。我认为 Fred Brooks 所描述的就是首批反模式之一，他说在一个进度延迟的项目中增加更多的人员会导致进度更加延迟。 3

在先前的文章中我曾经描写了一些在为您的组织和团队执行过程时值得思考的重要问题。 4 然而在这里我将展现一些在您考虑调整小组的过程时需要密切关注的反模式。

描述过程反模式

反模式，跟模式一样，可以用一定的形式来描述它们。也跟模式一样，没有普遍适用的方式可以描述它们。出于对我们的目的的考虑，我将用下面我曾描述过的说明形式对过程反模式进行描述:

名称：名称为反模式提供了一个简短，描述性的标签。
上下文：描述了您将要解决的问题。
影响力：这种影响力描述了这样一些事情，在组织上下文关系中，它促使您考虑利益以及优势等方面的问题，并引导您向解决问题方法的方向靠近。
解决方案：这是反模式中最关键的一点。在考虑到这些影响力之后，您选择了这种方法。您这样做是因为它看起来是合乎逻辑的，正如 Brooks 所说的在延迟的项目中增加人员的例子那样。然而，实际的经验告诉我们这种解决方案实际上会导致更多的问题。
后果：描述了使用这种模式的负面效应。
替代方案：这是一种替代的解决方案，您可以考虑用来避免这种负面效应。

免责声明

我选择用来表现反模式的描述并不是唯一的。我已经从 Coplien 和 Harrison 所著的Organizational Patterns of Agile Software Development中拷贝了绝大多数他们的观点。我向每一位想要学习如何提高软件开发组织效果的人推荐这本书。

我还要向大家说明的一点是我的列表中的这些反模式并没有经过实际验证。这些模式反映了我个人的观察结论，这些结论是我从组织以及那些我曾参与、观察，或者学习过的项目中得到的。从学术的观点来看，这些仅仅是更严格研究的开端。Coplien 和 Harrison 已经完成了他们的预备工作，并对他们书中所提到的模式进行了深入地研究。我并不是说这篇文章能够让人产生跟他们一样的信息。然而，我确实认为您可以找到一些能与您经历产生共鸣的例子，并让您产生深入的思考。

现在，了解一下反模式...

名称:	一次性服下所有的药
上下文:	过程就像对您有好处的药一样。它能够帮助组织产生正常的工作和健康状态，并使事情顺利进展。在一定程度上，一个组织可以决定改善他们生产软件的方法以及改善他们的过程。
影响力:	今天，过程是十分重要的。我们必须能够承受对过程的审计和调整过程的一致性。我们要尽可能地高效。有许多公司，咨询人员，以及可利用的书籍能够帮助我们完成令那些平庸而简陋的软件开发组织羡慕的转变。管理人员已经采纳了这个过程改进的理念并下达了全速前进的命令。
解决方案:	我们决定在我们整个组织中实现一个完整的软件开发生命周期 (SDLC)的过程。我们预备了培训材料，花钱雇佣了最好的顾问和技术支持，并安排了这个过程发布的时间。从现在开始，每个人都要以一种一致的、可预测的方式来做任何事情，以便能够度量和持续地完善。
后果:	不幸的是，当我们采取这种方法没有取得更好的效果时，事情会变得更加糟糕。变更，尤其是积极的变更会花费一定的时间。没有这种方法，个人和组织可以进行较小的、不会导致大的破坏的变更。然而，我们相信服用整瓶过程药剂可以迅速治愈我们所有的疾病。它所做的唯一的事情就是使团队和它的成员们花费了大量的难以接受的时间和精力来试图遵循这个过程，几乎没有时间实际解决分配给他们的问题。最后，他们放弃尝试使这个过程生效和（或者）放弃尝试构建软件。
替代方案	小范围内采用过程。确定您认为过程改进能够提供最大帮助的关键领域。实施这些过程，评估结果，然后预备下一个少量的增量。如果您收集了关于变更是否以及怎样工作的良好数据，每个人都能够理解这些利益，并且愿意接受下一个变更。

我总是对这个反模式出现的高频率感到诧异。对我来说是增量地进行变更似乎是一种常识。在上个世纪九十年代，我曾见到许多组织都尝试大规模地改变他们做事情的方法，而不管他们要实施的过程。我在那些设法利用 Rational 统一过程，RUP，软件工程研究所的能力成熟度模型(CMM)以及像类似极限编程 (XP)一样的敏捷过程的组织中也观察到相同的现象。我们想要相信采取一个新过程最好的方法是停止按照当前处理事情的方式去做，转而采取新的方法来做事情。但是我们往往丢弃了我们组织中颇有价值的做事方法，因为在新的、更好的、更现代的过程中对它们应该做更加详细的定义。

名称:	引进外部专家
上下文:	当我们对新的做事方法进行变更时，我们要确定这种方法是正确的。我们不能浪费时间来做事情，最后仅仅发现我们做错了。因此我们要雇佣专家顾问加入并启动这个新的过程。
影响力:	由于我们面临着最终期限，因此时间就是金钱，与金钱成本相比较时间对我们来说更宝贵。另外，专家经历过这些，他们知道什么是值得期待的以及怎样指导我们穿过变更的危险过程，因此我们不用横冲直撞或者在浅水区搁浅。在当今业界，雇佣顾问已经变成了一种生活的方式，因此我们可以向我们的管理人员证明这样做是正当的。
解决方案:	雇佣专家顾问，让它负责新方法的部署。
后果:	这种方案很可能是成功的，但是这种好的机会以后不一定会再有。即使它现在是成功的，它很可能对组织不会有永久的效果。实质上，您已经放弃了您的职责，把您对团队的控制权利也交给了顾问。只要这个专家使事情继续进展，您的小组成员就可能执行得很好，但是一旦专家离开，事情就会回复到以前的状态。
替代方案:	雇佣一个专家指导者，帮助您的小组成员，培育他们的知识基础和满足感，从而让他们自己实施过程变更。

有一句中国谚语：“授之以鱼，不如授之以渔”。同样的逻辑可以运用到过程改进中。告诉他怎样把事情做得更好，他会在您看的时候这样做。教他充分地思考并决定什么样的变更可以帮助他，他就会变成变更的主人并使变更变成他自己的。

Kent Beck 曾经说过软件开发只是简单地倾听、测试、编码，以及设计，任何提出不同意见的人都是想要向您出售东西。然而我并不认为他的那套关于软件开发的行为是完整的，我认为他这样说并不明智。商业中的顾问也是在出售东西——他们自己。他们出售地越多，您得到的就越多，因此如果他们能够使他们自己变得不可缺少，他们就能够出售地越来越多。这就是看待事物的方式。我认为真正优秀的过程和方法学顾问是愿意帮助您的组织学习知识，并通过这些为您内部拥有的知识帮助您取得成功的人。一段成功雇佣期过后他们高兴地离开，您也变得十分自信。这些顾问能够跟您一起工作，但不仅仅只与您合作。

名称:	计划过程实施进度表
上下文:	实施一个新的过程，即使您是逐渐增加地进行也会花费很多的时间。您要确定小组成员学习新方法和让他们能够很好地使用这些方法的时间进度。
影响力:	任何事都不是免费的。做事需要花费时间。无论何时您承担了一项意义重大的任务，都需要为它指定一个进度表。您要在您自己的进度表的剩余时间来完成这项任务。为什么采用新过程的任务要不同于任何您的团队需要完成任何其他任务呢？增加进度表的时间来实施这个过程。
解决方案:	为这个过程的实施确定一个固定的时间。
后果:	过程实施与软件开发有很多共同之处。都需要花费人类的精力和时间。都容易受到计划外变更的影响。当学习和训练成为这项任务的一部分，人们会有不同的反应。有各种不同的学习方式，每个人花费的不同的时间来学习，这主要取决于他们的学习方式和天生的学习能力。对于小组也有相同的特性。每个小组对新信息的适应有不同的步调。当您为学习新过程确定一个固定的时间段，有些对项目的成功十分重要的知识可能被忽略掉。
替代方案:	把过程实施看成一个单独的项目。允许您的小组迭代地和增量地学习新过程。像管理其它项目一样管理这个实施的范围。

当我还是“RUP倔老头”的时候，我有机会调查和观察许多客户。在瑞士哥德堡对 Volvo 工厂的访问是一次难忘的访问。Boris Karlsson 和他的职员负责软件工程小组的过程改进。Boris 的团队用他们处理软件项目的方式从事过程实施。他们收集需求，安排一些必需的活动让开发人员了解如何使用这个新过程，然后在不同的开发小组实施这个操作项目。他们开发了即时训练程序模块和实践训练，并指导小组工作。这是我所见过的最成功的RUP地首次实施之一。 6

名称:	集体所有制
上下文:	为了让每个小组成员都能够运用新过程，每个人都被授予过程的“所有权”。
影响力:	如果人们拥有对变更的输入和一定的控制权，那么他们对变更会有更好的响应。通过让每个小组成员持有过程实施的所有权，您可以获得他们的支持并让他们自愿接受，并处理引进新方法过程中不可避免出现的破坏性的事情。在作出决策时组织需要员工的参与。因为过程采用是一件十分重要的事情，小组成员有一定的能力— —有时是一种责任——来定义明确的过程和实施计划。员工参与工作。在许多公司里有大量描述与人分享管理成功的例子，比如质量改善。
解决方案:	小组成员定义批准过程和过程首次开始之前怎样引入过程。
后果:	这种方法通常会产生两种负面的结果。首先，这个新的过程可能永远不会被启用。人们认为他们有权否决任何他们不喜欢的事情，并利用他们的权利破坏会议以及其它可能制造实际的过程的集会。事实上，他们毁掉这种开始，正如立法者通过使法规保存在委员会来毁掉法规一样。其次，如果过程变更已经被引进，它们只是人们喜爱的但是并不能共同工作的一些技术的组合，这比变更引进之前采用的任何合适的过程都更糟糕。
替代方案:	一个很小的团队可以决定特定的过程变更。在开始这个变更之前，这个团队要与小组成员见面并展示这个过程，然后收集他们的反馈，在变更开始实施之前合并那些有意义的反馈意见。

重要的是给每个人一个贡献自己想法的机会，并让他们知道他们的意见已经被人所知。实施变更最有效的方法是明确地描述变更，为什么它是必要的，以及您所期望的利益。然后您让人们来发表意见。他们是会受到这个变更影响的人。结果证明他们经常会有一些可以使变更有效的建议，或者他们会提出一些您可能从没想到过的问题。您不得不承认他们有很好的建议，在好的建议面前不用因为改变了您的观点而担心。如果在您的思想中缺乏灵活性，您就不能执行过程变更——这里不允许自负的思想存在。

名称:	小增量，短迭代
上下文:	在一个软件开发项目之后您决定形成您的过程改进项目：迭代的和增量的。当增量十分微小，迭代做得尽可能的简短时，软件项目似乎就能实施得最好。
影响力:	您需要改善，并且在尽可能快的压力下进行变更。我们认为小的增量可以让我们快速引进它们。一旦我们完成了一个变更的配置就开始引进下一个。人们在一定的时间内学习，这种方法事实上可以缩短过程变更的总体时间，一旦这种方法被实施我们就可以从变更中获利，这似乎是很合理的。这种实际的效果是逐渐累计的。
解决方案:	您要设立部署小组，培训材料，每个变更的培训会议以及确定会议的时间，使每个引进新方法的迭代之间的间隔十分短。
后果:	这种方法会导致混乱。因为您只是被教授了一些东西，但是并不意味着您理解并且能够使用它。人们花费不同的时间来学习，甚至还不能完全掌握。仅仅将新的变更在快速连续的时间内抛给他们事实上延长了变更发生的时间，甚至可能导致整个过程改进的悲惨的失败。
替代方案:	识别服务于组织或者过程的一个特定领域的小的变更。比如，培训人们如何对他们的需求分析，系统设计以及测试使用用例。让他们在一个完整的项目上使用新的技术。然后引进下一套方法和变更。任何事情都需要时间。除非您允许人们对新的方法融会贯通，使用他们，使它们使用于他们特定的项目，最终将它们的使用变为己有，利用它们您将确定可以成功，而不是偶然。这就是一个欲速则不达的例子。

结论

这几个反模式的例子让您了解到如果您用错误的方法来应用好的观念，将会产生什么样的错误。您可能能够思考得更多一些。我迫切希望您们阅读Organizati on al Patterns of Agile Software Development并且能够思考一下文中提到的模式的反模式。如果没有其它事情，我想让您更深入地思考模式本身。在以后的栏目中我们将研究更多应用于人、过程，以及工具的反模式。