本文来自于 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
