|
本文来自于 Rational Edge：遵循软件开发中一个协调一致的过程的价值是确定无疑的。但是究竟需要什么样的过程呢？究竟有多复杂呢？需要什么样规模的团队？Gary
Pollice教授考虑到企业中对多样化过程的需求情况，详细回答了这些问题。
在我参加 2006 年敏捷年会，这个会议讨论关于方法和技术的问题，之前。我已经开始编写这个月的理论与实践专栏中的文章，这篇文章是关于测试过程中使用和创建模拟对象的问题的。哦，我听到你说“天啦，这是唯一关于敏捷的论文。”我可以向你保证这不是我的意图。我与其他几个人在这次会议上的观点介绍与讨论使我想到总体过程的问题，以及过程在软件开发中扮演角色的问题。
当然，参加会议与没有参加会议的人们所真正关心的问题是找到能够帮助他们完成软件开发的银弹。这使我开始明白这次会议讨论的中心是组织中特定的成功水平，一个与公司规模、软件开发团队规模、以及用来确保成功过程的范围相关的水平。我开始尝试将这些挑选出来，并认为我自己已经有了几种有助于思考软件开发中过程中角色的方法。
对于初试者来说，当一个小的组织逐渐成长成为一个大的企业组织时，事情变化了，你的过程也必须相应变化。敏捷社区够很快指出了敏捷的基本原则之一就是，它可以反映在你为了改进工作方法所表现的行为上。但是这个原则与RUP中的或者任何一个其他现代的方法中的原则没有什么区别。因此就产生这样一个问题：“过程还重要吗？”
“过程还重要吗？”这个问题看起来是一个反问句，尤其是出自于先前的一个“RUP怪老头”的口中，这是我在离开Rational组织从事理论生涯之前的昵称。事实上，这个问题只是稍微带点反问，过程当然重要。有些情况下它是十分重要的――比如当已经选择的过程超过了这个团队的能力，使团队不能够满足顾客的需求的时候。如果我们将满足顾客的需求与质量等同看待，那么过程就会对质量产生潜在的负面作用。
或许这样的问题会更好一点，“特殊的过程重要吗？” ; 在前一个专栏中我讨论了将过程与项目匹配的重要性，定制并裁剪过程以适应一个项目的需要已经是目前被公认的软件开发最佳实践。此外，能够有效支持一个项目团队或者一个组织的过程并不止一个，可能有很多。我可以设想，几乎任何过程（不管是否是定义明确的）都会对一个团队的成功有所帮助。
我认为有两个主要因素中的任何一个存在，都可能会影响适用于特殊情形过程的数量：1）团队的规模和
2）在大的团体背景中过程的作用范围。我将调查这些因素，然后考虑过程层面的需求，在较大的组织中存在多个过程。
一个定义
在我们进入细节之前，让我们确保对“过程”的概念有一个共同的理解。我将查阅我最喜爱的资源，词典，然后采用其中的一个过程定义：“一系列将产生结果的行为、变化或者功能。”2
这是一个简单的描述性的定义，在我看来，这是过程的本质。过程是我们为了完成我们的工作而采取的一系列步骤。它不是我们编写的如何计划我们工作的设计，也不是一系列我们必须盲目遵守的规则。它是我们要做什么，不管是否被记下来，也不管是否被详细说明。
团队规模与沟通
一个有效的过程是支持有效沟通的过程，有效的沟通与项目团队的规模是直接相关的。这对任何在不同规模项目团队工作过的人来说并不陌生。
对于那些读者来说他们可能喜欢更严格的证据，仅仅考虑基于团队规模的可能有的沟通渠道的数量。一个两人项目，A和B，只有一个沟通连接。如果我们增加一个C到这个项目中，我们就有三个沟通连接，A－B，B－C，C－A。当D加入这个团队时，我们就有六个沟通连接，当加入E时，我们的沟通连接达到10个。一个十人团队将会有45个沟通连接。由于有如此多的可能性，同步与关键信息的传送就变得相当困难而且容易出错。
决定沟通连接数量的公式就是你从数量n中挑选出配对数量的公式，不必考虑顺序。公式如下所示：
当我们寻找配对时，它可以减少为
图1中显示了一些重要特征，在那你可以看到增长并不是线性的。当你的团队规模增长，你需要通过决定捕获什么信息以及如何捕获，从而找到沟通渠道公式的方法。
图1. 团队规模对沟通的影响：当团队规模增长，沟通连接的数量并不是呈线性增长的。
团队规模的大小不仅仅影响到沟通渠道的数量，它还影响团队过程的各个部分。一个两人团队一起从事于一个小项目会采用一些机制来分配工作，管理他们的资源代码，给他们的工作归档等等。这对工作人员的确不需要很多指导方针告诉他们改如何完成他们的工作。他们几乎都是告诉对方，一天好几次地要么亲自告诉对方，要么通过电子邮件的方式传达。的确，这就是沟通，但是来自外界的噪音很少有机会来干扰这个沟通。因为他们只有两个人，他们不需要将他们的信息提交给一种更持久的形式，就像隐藏在一个工具或者详细用例描述中的统一建模语言（UML）。几乎任何“微不足道的”过程都会对他们俩起作用。5
当团队规模增长时沟通问题就会出现。问题之一就是工作分配。两个或者三个人一起工作就可以很容易地知道谁在做什么，有什么目的，他们知道向谁谈论关于可能产生的不同想法的问题。一个二十人的团队情况就更不一样了。有些情况下，需要一个主要任务目录，人们可以按照这个目录去完成自己的事情。敏捷方法跟Scrum和极限编程一样都有这样的目录。Scrum称它为缓存，而将情节串连板作为主要的任务获取机制。
如果我们将过程看作一个标准化的机制，那么当团队规模增长时对过程的需求就会随之增长。有很多事情都可能出错，这时如果团队的每个成员都要执行自己不同的任务，尤其当这个任务对每个团队成员都会产生影响时，团队的效率就会降低。
以下是来自以前项目中的一个简单的例子，我将对它进行详细说明：
我在一个由十五个开发人员组成的产品团队工作，主要是创建一个新产品。团队被划分为几个更小的团队，每个负责一个特殊的组件。其中有一个是核心组件，其它所有团队包括我的都是依赖于这个核心组件的。我的工作通常是在向前进展之前，在核心组件做一个小的变化然后测试新的代码。6在这个特定的项目中，有一个模式是始终重复的。如果我做一个变更，有时候我的构建会由于编译错误或者连接错误而失败，但是不是由于我的代码。我会在不同的模块跟踪这个错误，当看到这个检入日志，我会看到Mary在我的上次和当前版本之间做了一个变更，而且已经失效。此时我决不会放弃，而是问Mary7是否做过什么变更，她会承认检入了一个错误的代码。然后我还会问她是否测试了这个代码。她通常给我的是类似于“不，这只是一个很简单的变更”这样的回答。我会继续问她是否编写过代码。她依然回答“这只是一行代码的变更，没有必要去做一个新的版本。”
很显然，Mary的个体过程影响了其他人。我的过程跟其他人的有很大不同。为他们建立一个简单的规则，像除了编写和测试之外，不许其他代码检入，这将会为整个团队节省时间和精力。你可以想象如果十五个人的个体过程都被接受，这个项目看起来将会是什么样的局面。不幸的是，团队决定我们必须详细说明开发人员所做的任何事情。这就是另外一个极端――一个除了消耗我们绝大多数时间而没有任何产物和可利用的行为过程。
从这个例子中得出的道理似乎很简单，但是一个简单的道理可以给你提供一个很有说服力的案例，让你明白当团队规模增长时为什么要采取大家达成一致的过程：选择一个适合团队规模的过程。我想Alistair
Cockburn在他的书中很详细地描述了这个问题，《敏捷软件开发》。他把项目的规模――生产出产品的规模和开发团队的规模――描述成一个必须介入任何过程配置的参数。在我看来，它们产生的团队规模连同沟通的问题与产品的规模是成比例的，因此我将团队规模看作最主要的指示标识。
过程范围以及目的
第二个影响过程数量选择的因素是过程作用的范围。我不是谈论过程是否包含了从项目的起初阶段到结束时的所有开发行为。我说的范围的含义是，过程对整个组织或者团体的影响。
有一些范围对分组目的来说似乎是很正常的。
第一个也是最小的范围是个体过程范围。我们每个人在我们的职务中都会创建一个个体过程。你可能会想到那些主要开发人员，他们更喜欢使用他们的编辑器工作，并在这个编辑器做一切事情，或者那些利用很多整合在可视化的开发环境中的工具中进行工作的人们。有些程序员在他们开始编写程序之前会编写一些伪代码。其他人会加入进来。重要的是我们都有一个适合自己工作的个体过程。至少是有多少开发人员就会有多少个体过程。
第二个过程范围是直接团队过程。直接团队是最小的单元，仅仅比个体大的单元，它参与产品生产或者产品不连续部分生产的合作。在整个范围中，步骤不仅仅影响到所有的个人，而且它还支配着个体开发人员的个体过程。每一个人都必须调整他或者她的个体过程以适应团队的过程。一个良好的团队过程需要使团队中每一个体过程的变化最小化。
在我的过程范围阶梯的第三档是项目范围。这就是说多个团队必须致力于一个项目、一个产品或者产品线的实现。这样的过程在系统工程项目中是十分常见的，此时软件和硬件都必须并行开发，而且必须同步。很多时候这些项目并没有那些“纯粹的”项目所拥有的迅速变更的总数目――比如，计费系统与特殊的硬件或者依赖于特殊硬件的实现并不是并行开发的。
第四个同时也是最大的范围是企业过程范围。一个大的组织在同一时间将会有很多处于不同阶段的项目。这个组织必须勤于管理成本，优化资源，并保证这些项目都为共同的目标做出贡献。大的组织中一个重要的业务活动是项目组合管理，它能够使企业像管理有价值的资产一样管理项目组合。项目组合管理学科起源于管理这些资产就像管理公司其他资产一样的需求。项目组合管理需要一个贯穿所有项目的实际过程的执行。
你可能还会想起其他过程范围。对于这我们的目的来说，这四个已经足够了，在文章的剩余部分我将用到这个层次划分。
既然我已经描述了两个影响组织过程使用的主要因素――团队规模以及过程的范围――让我们考虑一下组织中团队动态变化所暗示的含意。
过程的目的随着范围的变化而变化
下面的观测资料对你来说可能显而易见，但是在我的工作中却让我费解了很长时间。随着过程范围发生变化，拥有这个过程的原因也会变化。我开始认为这是战术与策略的差别。
个体过程就是开发者随着时间的进展使其适应他或者她的工作习惯。过程的目的是帮助开发人员创作优质代码。当我确定我所有的代码都经过测试了，我这样做是因为我想做一个更优秀的开发人员――也就是说，我要把产品做得更好。当我学习设计模式并将它们作为我设计过程中的一部分时，它使我的代码更优秀。我的个体过程是一个十分主动的过程。
一个团队的过程当然也一定是用来帮助团队创造优质产品的过程。但是人们往往希望从团队中获得更多的信息。通常情况下，会有状态报告（被编写的或者其他的），开发人员的绩效评估，以及沟通机制等等。
项目过程是非常具有战略性的。它将包括更多关于市场的信息，整体策略，以及项目将如何为它们做出贡献。这种类型的过程对个体过程的影响非常小，如果有影响，通常也是负面影响。让我更进一步来解释一下这个问题。在项目的层面，过程所关注的问题就是类似于决定产品是否已经准备好可以运输了，对用户来说产品的文档是否合适等等。应该从不同的项目团队获得这些信息。项目过程可能在这些信息上强加一些内容或者格式的限制，每个团队应该有能力决定它是如何产生这些信息的。
我们可以这样理解，无论如何，项目过程发布命令要求每个个体开发人员提供对他们编写的每个功能的详细描述，只是预防万一这些信息可能对某些人有所价值。这毫无疑问会给开发人员的生产力和士气带来负面影响。它还需要我们想要避免的一些文档――大量无用的文档。事实上，如果需要这些文档，这个项目过程就应该简单地告诉团队这些文档是需要的，这样就可以让团队来决定这些文档将会怎样产生。
最后，企业过程不可能涉及到个体的细节。它是一个整体的策略。企业过程在合适的位置确保工作作为一个整体，不断发展起来。编制企业层面的计划比个体层面所花的精力要多许多，这也正是人们所期望的。
当我们看到层次和过程目的区别时，我们开始明白该如何选择并匹配这些过程。
首先，对我来说这些过程像软件一样似乎都有一个构架。设置不同类型的过程可能是组织它们最有效的方法。用我们的层次，我能很容易就能够想象一个大的组织的四层过程结构，如图2所示。每一个层次会对它上面的过程有所帮助。高的层次详细说明了整个过程需要来自低层次的信息的数量（最小限度的），来实现它的目标。注意每个层次仅仅与它上面或者下面的过程传递信息。这同样意味着每个过程的直接影响是直接对它下面的一个层次的过程所产生的东西。比如，一个企业需要做年预算的信息。它希望每个项目提供一个预算信息。这个项目就需要获得来自团队的相关信息，并把它整理成企业所要求的格式。团队就会传达每个人的需求来帮助展开他们的数据――比如，询问关于开发人员所需要的新工具等等。
图2：过程分层
如果组织有一个如图2所示的过程分层，它将会意识到一些如我们在分层的软件构架中所看到的好处。我们可以在不修订整个过程系统的情况下。用新的过程来“替换”这些过程。
范围与规模是相互联系的，但是他们在不同的方面影响了过程的选择。在一个组织中选择一个过程来与范围匹配，通常由组织中的高层管理的一个人或者一个团队来完成。选择一个过程来与团队规模匹配通常由团队中使用它的人或者团队来完成。图2中两个低的层次代表过程是由团队成员为了他们提供的战术价值而完成的―――更好的质量，更快的开发等等。上面的两个层次代表过程是由管理人员选择的，他们为了策略和控制的目的强加了下面的层次。
过程层次需要适当的接口
如果我们按照先前的讨论考虑过程，它将引导我们进入一个过程接口的概念。如果你仔细观察图2，就会看到更高层次的过程会在低层次上强加一些限制。这与我们软件设计中的分类有点相似，它在其它类中调用方法。因为我们要将这种依赖性降到最低，我们在这两者之间创建一个接口。如果我们在过程层面之间创建这样的接口，只要这些低层次过程能够像高层次过程提供合适的接口，我们就可以允许这些低层次过程发展和变更。为了有更大影响范围的过程，这可能需要一个适配器来修改或者格式化信息。
让我们看看一个简单却很现实的例子。团队过程要求除非进行单元测试，否则不允许有代码检入。这里的举例说明了一个介于团队过程与个体过程之间的接口。个人编写测试是在执行代码之前还是在执行代码被编写之后，这个问题真的很重要吗？不一定要按照过程接口的契约，只是要求代码都有单元测试。开发人员有选择什么对他们的工作最有利的自由。
这里有一个高层次的例子。设想一个项目过程跟踪基于面向RUP的过程，但是一个特定的团队决定他们将使用面向XP用户的情况来度量他们的过程。当该出报告时，需要一个适配器的活动，其将用户场景11匹配到他们的用例上，并基于这些用例进行报告。我们一定会争辩说这是不必要的花费，但是如果他们使用用例，开发团队就会更有效，这个花费可能就值得，而不是强迫他们仅仅使用用例来工作。你无法改变高层次过程，因为对于低层次过程来说它是客户或者顾客，它决定什么是报告的必须条件。
定义好的过程接口必须对低层次的过程发出很少数量的指示。如果这些要求太苛刻，这些低层次过程就会和过程一起陷入困境，而不是高效地执行它们的任务。
必须支持微过程
讨论到目前为止，我们已经谈论了不同层次的处理，似乎它们就是完全满足目标层次需求的已被定义好的实体――比如，团队方法似乎是一个包含了团队需要执行的所有任务的单一的方法。这事实上只是一个幻想。并不存在单一的过程，很多小的过程编织在一起形成了似乎是同一层次的统一过程。它们其中的一些微过程是相互独立的，但是很多都是相互影响的。当它们之间相互作用，它们的影响必须非常平稳，因此同一个层次中一个微过程的选择是取决于其他微过程的。
少数几个例子将详细说明我要表达的意思。一些不同层次的微过程可能是：
源代码管理（SCM） 实践是用于团队的。例如，如果没有第二个人评审并承认这个代码（或测试）是正确的，将不允许检入任何文件。12
缺陷跟踪过程 设定统一标准，比如状态类别、部署以及跟踪通常是项目或者企业过程。为缺陷响应措词的标准等等，可以被指定成为项目或者团队过程。
编码标准以及命名约定通常在项目或者企业层次决定的。
工作分配实践 在不同的团队是不同的。每个团队根据他们已经过协议的实践对于分配人员的任务有不同的方法所有的微过程之间必须相互支持，他们必须依照过程接口支持高层次的处理。这种介于处理层次之间的关系可以通过组织中两个处理层次来详细说明，如图3所示。
图3. 两个处理层次之间的关系，项目与团队；同一个层次的微过程必须共同工作
图3中微过程之间有两个接口：SCM过程与状态报告过程。只要所有的微过程在一个团队过程中相互啮合，他们就会找到使两个层次处理相啮合的方法，这个处理就会生效。
这个图在我看来，展示了过程工程的真正艺术――通过限制不同层次之间同步的要求，给那些实体提供尽可能多的自由在较低处理层次工作。
所有这些组合在一起会产生什么结果呢？
以上所讨论的跟我在 2006 年敏捷年会以及我最初的评论有什么关系呢？既然我已经描述了一个考虑团队规模和过程级别的方法，那么我敢断言会议中的敏捷团体主要是考虑团队级别过程，即使很多思想领导者可能会提出不同的要求。正如我在开始提到的，小的组织逐渐成长为企业组织时必须改变他们的过程，同时要意识到敏捷方法可能不能满足企业或者项目层次的需求。
一直困扰我，使我没有“讲授敏捷”的原因之一是，当你给人们一种方法时，他们就会趋于一种狭隘的世界观。他们仅仅看到的是他们目前所面临的环境所允许的范围。在敏捷年会上，我不断听到这样的说法，如果管理者们不介入，让开发人员做他们自己的工作，事情的状况可能会变得更好一些。给人们的印象是，你在管理层爬得越高，事情将变得越糟糕，有能力做出正确决定的人也越少。事实情况是，高级管理层的人通常要么是创建公司的人，要么是从这个阶层出来在公司担任一个更具有战略角色。他们的活动范围不同，他们的价值观也与开发团队的人员不同。开发者们意识到如果公司是有利可图的，那些高层次管理人员就应该做出正确的决定。很多追求利润的公司只追求工作被完成，而不顾公司混乱的领导阶层。
我相信，对于开发者来说，不只是理解他们团队的过程，开始学习有关通常的业务过程是至关重要的。由此可以产生两个正面的事情。首先，他们将了解在高层次过程如何改善接口。第二，他们可以对公司更有战略性的成就有一个合理的评价，以及了解开发团队是如何致力于更高目标的实现的。这些知识将会使他们在公司更有价值。你不必因为承认你所偏爱或者愿意使用的工作方法与你的个人方法相互矛盾而感到羞愧，虽然你的方法是你和公司都得不到什么好处的方法。我宁愿尽可能早地知道这些，而不是在我的绩效评审的时候，或者更糟的是在我的辞退面谈时才知道。
过程很重要，但是没有一种过程适合所有的情况。一个企业在几个不同的层次都有很多个过程。了解这些需要共同工作的过程十分重要，而这是经常会忽视掉的事情。当你了解真正的过程需求时，你就会明白你所遵守的过程远不如它是否与其他过程合作协调重要。
|