人们经常问笔者敏捷是否适合大型的项目，或者是否它只适合小型的项目和团队。笔者意识到这是一个很难解释的问题。您可能会问为 1000 个人准备食物，是否和为准备四口之家的食物没有本质区别。当然是这样的，但是您可以看到不同的方法，食谱以及器具。您可能会在一个 20 加仑的容器中混合沙拉，而不是一个小罐中进行的。
为什么这个问题是错误的？
Ron Jeffries，一个著名的极限编程（XP）开发员，宣称 XP 实践在任何范围内都能很好的工作。他说当人们对大型项目的敏捷反感时，他们实际上并不理解敏捷；因此，他们并不能评价大型项目的适用性。1 笔者赞成他的观点。笔者不会去讨论关于敏捷的定义，因为笔者已经在The Rational Edge 2007 年 5月的文章中做了详细的阐述。 2 笔者假设您已经阅读了这篇文章，还有《敏捷宣言》（Agile Manifesto）及其实践的内容。 3
《敏捷宣言》（Agile Manifesto）对项目的大小并没有做特定的限制。实际上，敏捷宣言是一种价值的定义，这种价值是宣告选择用以应用到软件开发中去的。如果您在一个拥有这些价值的公司中工作，或者您所在的项目团队拥有这些价值，那么您可能会决定使用敏捷实践。如果因为某些原因您没有或者不能采用这些价值，那么您就不需要为敏捷而操心了。与一些流行的看法相反，这并不意味着您是一个不思进取的人！
因为价值是公司的属性，所以现在就可以很容易的看出问题“敏捷适合任何项目规模吗？”是糟糕的问题了。价值决定了公司是怎样进行业务活动的，而不是公司或者项目的规模决定的。显然大型的公司拥有更多的过程和管理，但是核心的价值是不受影响的。
我想要做一个小型试验。我研究了一些大型和小型的公司。我查看了他们关于业务行为哲学的描述和信息。阅读下列信息，并查看您是否可以识别公司，或者至少是公司的规模以及它的软件项目。
公司 A 列出了一些他们信仰的东西，如下所示：
关注用户并尽力满足他们的需求。
快总比慢好。
您不需去等待一个答案。
保持认真。
很好就是不够好。
公司 B 的原则宣称“他们致力于快速并精确的构建软件。最成功的软件项目是强有力的管理，高级的技术技巧，以及使用定义良好开发方法学或者过程的混合体”。
公司 C 有三条强调的值：
服务每位客户的成功。
创新非常重要，对我们公司以及我们所处的世界都很重要。
所有关系中的信赖和个人责任感。
公司 D 看重整体性，诚实，开放性，个人的优异，构建性的自我批评以及相互的尊重。尊重员工和合作者，并拥有一定的技术。他们进行巨大的挑战，并为征服它们而骄傲。他们通过奖励客户，投资者，合作者，以及员工，提供结果，并为最高质量奋斗，而对他们负责。
公司 E 有一句话来描述他们的任务：“通过创新性，智能化，可用的数字媒体方案的概念和执行来服务客户。”
公司 F 相信：
最佳的方案从清晰和明了的方案开始。
最佳的地址是标准遵循者。
最佳的软件是迭代开发的，并有最好的客户参与其中。
最佳的代码从测试开始。
无须再说，他们对使命的理解和陈述值得我们的尊敬。现在，您是否已经可以决定公司的信息及其规模？在这里我不会提出公司的名字，但是我将会简单的介绍如下：
一家是我们每天都要与之打交道的跨国公司。
一家为客户编写软件和专业培训 XP 团队的小型公司。
世界最大的技术公司之一。
世界上最大的软件公司之一。
一家为其客户构建 Web 程序和其他系统的中等规模的公司。
一个从前是我学生的人创建的小型咨询公司。
当我在寻找这些公司，以及他们任务和价值的时候，我没有发现任何与规模或者“敏捷”相关的信息。
哪些敏捷实践能够适合大型的项目？
那么，针对大型项目的敏捷，什么才是应该问的正确的问题？我相信正确的问题是“哪些敏捷实践最适合支持大型公司或者大型项目？”
不同规模的公司可能会使用不同的过程和实践。与涉及到一个或者两个人的项目相比，涉及到数百人的项目肯定会有不同的控制和抑制因素。沟通频率会随着项目成员的增加而按指数增加。为了获取重要的交流信息，大型的团队必须以更加严格和正式的方式进行工作。上面所有我提到的公司，运行的是敏捷方法很适合的项目。可能并不是所有的项目都认同敏捷，但是许多公司确实是认同的。这样的项目与顾客有规则的交流，并且必须处理需求的快速更改。开发团队成员相互之间必须有紧密的合作，并要快速不带迟疑的对系统作出决定。
让我们看一下敏捷实践，并看看它们是如何适用于大型项目的。让我们承认大型的项目要有二十或者更多的人员参与，但是这是一个任意的门槛。您可以决定，我的标准根据您对大型项目的概念是否需要调整。
Ron Jeffries 说大多数的 XP 实践适合大型的项目。大多数对敏捷感兴趣的人都或多或少的对 XP 有一些了解，这就使得它成为一个好的起始点。Ron 的 XProgramming.com Web 网站识别十三种实践。 4接下来的是我对这些实践是否适用的评价。对于每一项实践我都指出了我是否认为它适用，并简单的呈现了我的意见。
整个团队（不）。这种实践需要所有的团队成员坐在一起进行商量。至少要有一个顾客代表在场。大多数团队都是分布式的，这样有可能每一个分开的地理位置都有一个顾客代表，所以可能它并不是经济上合理的。而且，找到一个可以容纳二十多人或者更多人的房间可能是非常困难的。大型的团队会在项目的生命周期内拥有小型的分团队。每一个这些团队可能都可以使用 Whole Team 实践。
计划策略（是）。计划策略让一个团队简单的计划和追踪。不管团队用以获取需求的工具以及迭代的长度，计划策略都让生产现实的迭代计划变得更加容易。
小版本（可能）。“小”是一个主观性的词语，取决于您的定义。但是，大多数的软件系统允许团队去选择最终系统的一部分，以完全执行一个小型的版本。它遵循迭代和增殖开发的原则，并在使用IBM®Rational®Unified Process （RUP）的各种版本的项目上运行良好。一些系统，特别是那些涉及到集成通用硬件和软件的系统，对与使用小型版本可能不太友好。
定制测试（是）。还有谁比客户更能知道系统必须去做什么？顾客代表可以书写测试用例，或者帮助书写任意项目的测试用例。实际上，对于一个更不敏捷的项目来说，顾客通常指定验收测试作为合约的一部分，或者它的补充物。
简单设计（可能）。设计应该尽可能的简单，这是理想化的。正如 Jeffries 描述的那样，这种 实践确实是不断增值的设计。项目需要的设计的数量，应该由项目的类型以及项目需求来决定。
配对编程（是）。成对编程看起来可以产生更好的质量且避免过大的压力。只要有两个团队成员可以一起工作，这种实践就可以进行。如果团队是完全地理分开的，那么这种实践就无效了， 5 但是它与团队的规模无关。
测试驱动开发（是）。对质量有严重责任的开发员，应该为他们的工作书写单元测试。如果他们书写单元测试的话，他们就可以在执行代码之前就去书写了。项目规模并不影响什么时候书写测试的选择。
重构（是）。好的程序员不停的工作，以创建更加强壮更具维护性和有效的代码。项目的规模再一次与此无关。
持续集成（可能）。小型项目可以使用简单的工具去执行持续的集成实践。拥有多个位置和多个代码库的大型项目，可能并不能构建完整的项目。显然他们会需要更高级的工具，以达到一个更加有效的集成过程。经济考虑可能会是决定是否采取实践最重要的因素。
集体代码拥有权（值得怀疑）。虽然小分队的团队成员可能会理解所有他们创建的代码，他们非常理解其他团队成员工作 的几率很小。一般的代码所有权会在开发员之间进行分配。
编码标准（是）。没有编码标准的任意规模的项目都注定会出问题。
隐喻（不）。坚定的 XP 支持者对这个问题很关心。有一些人做了长期的尝试，想要人们意识到隐喻的价值。我仍然没有被说服。显然，在我们开发结构时我们使用了很多的隐喻，但是它们并不能取代结构的作用。在笔者看来，随着项目的变大，试着得到隐喻的精确信息是十分低效的。
可持续步伐（是）。这不仅仅关系到公司和项目的规模，还关系到公司和项目的文化。
我赞成 Jeffries 的评价，他说大多数 XP 实践能够很好地适应大型的项目。那么其他的敏捷实践呢 ？
对大型的团队来说 Scrum 是否适合？
Ken Schwabe，Scrum 创作人之一，肯定地回答了这个问题。他指出通过“scrums of scrums”，可以适应大型团队。 8 Scrum开发员说这项技术适用于超过 500 人的大型团队。我并不能确定这些团队成员是否都只忙于一个项目。
还有许多其他我们会讨论的，关于对大型团队适用性的敏捷方法学。您可以自己去执行这些实践。在这里，我想要推荐一种更有效使用时间的方式。
重构问题
在试着决定怎样通过关注技术或者过程，而不是项目来应用“流行”技术，工具和过程时，我已经掉进了一个陷阱。当我在处理设计和开发 Rational Unified Process，也就是 RUP 时，我与我的客户进行讨论，并发现那些成功者，关注的是为项目的成功需要去完成的项目和工作。
关于 RUP 的一个微观概念，是这是一个过程而不是一个过程框架。成功的 RUP 采用从他们的项目开始，并定制 RUP 以使其适合他们的项目和公司。我想在我们试着对采用任意的方法学，包括敏捷技术的采用时，相同的方法也是有效的。
识别价值
任何向公司引入更改的尝试都将会失败，除非这种更改与公司的核心价值相协调。例如，试想一下，向您的公司引入一项软件再使用实践。软件再使用的益处总所周知。但是根据开发员所写代码的数量进行奖励，那么这种价值就很难引入。开发员知道他们是怎么评价的。程序员将可能抛弃这种方法，以确保他们并没有再使用模型，因为它将会使更少的代码被书写出来，这就意味着更差的性能。
如果我们假设采用敏捷方法时，您并不准备更改公司的价值，那么如果您想要使敏捷方法获得成功的话，您就必须选择与实际价值相匹配的实践。
识别背景
项目和公司存在于一个背景中。背景就是项目或者公司存在的环境。背景的一些典型特征是：
团队位置团队成员是否位于同样的地理位置（例如一个单独的区域）？团队成员是否可以有规律或者无规律的聚会？如果他们并不位于单独的区域，那么他们的地理分布如何？他们是否被一些时区或者地理因素所阻隔？
已存在的实践和工具如果您不断的引入敏捷方法的话，那么它们就必须执行已存在的过程和工具。更改必须以一种尽可能自然的方式进行整合。当一开始团队将更改整合到他们的工作方式中去时，一般都会引起生产效率的下降。如果更改与现存的实践并不协调的话，这种下降会更加的明显，而且新的操作可能永远不会产生想要的结果。
人员因为人才是最终使用新过程和实践的一方，所以他们的个性与工作习惯也必须在考虑范围之内。如果您的公司的成功是一群有独立意志的贡献者所做的话，那么引入一项需要大量合作的过程的话，这种组合很可能毁于交流不善良。
例程许多公司拥有大量的例程或者规范。特别是政府规划更是在这一中环境下进行的。定义良好的重大事件，需要正规的检查和大量格式正确以及准备充分的文件来支持检查。不强调例程以提高项目其他特征的实践，在这样的公司内将不会受到欢迎。
决定背景的其他因素取决于项目和公司。
定义成功
在您为您的公司和项目识别实践价值和背景之后，您仍然有一个最重要的问题要问：新实践或者新过程的最终目标是什么？换句话说，什么可以定义成功？
我认为“变得更加敏捷”并不是一个目标。因为它太容易了。今天许多的敏捷媒体文章对许多管理员和项目领导进行了狂轰滥炸。他们从开发员那里听到了关于敏捷的信息，这些开发员是在寻找书写代码更加省时的方法，而不是努力支持软件开发的其他方法。但是，努力变得敏捷并不是最终的目的。必须要有一个或者多大能够被认为是更改目标的可识别业务。
一旦您开始奋斗，您就可以问正确的问题了：“我们可以将什么样的实践，整合到与我们的价值相匹配的已存在的背景中去，这样我们的员工具可会积极的响应它，并最终到达预设的目标？”如果您的价值和背景指示一项敏捷位置的话，那么您就当然应该采用敏捷方法了。如我在上面所述的那样，项目规模的影响可以忽略。
应当重视的参考材料
我建议您要熟悉敏捷以及一些敏捷方法学，这样可以帮助您决定什么实践最能适合您的需求。据我看来，下面的书籍和网站将会给您一个关于这个问题的较好的原因。
Agile Software Development 2nd edition.: The Cooperative Game（《敏捷软件开发》第二版），Alistair Cockburn，Pearson Education，2007。Alistair Cockburn 对软件开发原则有一个广阔的视角。他定义了一系列的过程（他的 Crystal 家族），并分类了过程的应用性。该书为理解敏捷提供了一个好的基础。
Agile Software Development in the Large: Diving into the Deep（《大型的敏捷软件开发：深入研究》），Jutta Eckstein，Dorset House，2004。Jutta Eckstein 关注了怎样对大型的软件开发应用敏捷方法进行的咨询和研究。本书给出了她对大型项目应用敏捷方法，怎样达到这一点，以及怎样做到更好的观点。如果您要查看对大型的项目或者公司应用敏捷方法的话，那么这篇文章您就必须要阅读。
Martin Fowler 的网站，http://www.martinfowler.com/。我喜欢 Martin Fowler 的作品。在我看来，他和 Craig Larman 是软件开发方面的最好的两大学者之一。他们写的就是我想要读的。Martin 关于敏捷和 XP 的文章应该在您需读文章的列表上。
前面提到过的 Craig Larman，他的网站 http://www.craiglarman.com 是很有价值的。他的书，Agile and Iterative Development: A Manager’s Guide（《敏捷和迭代化开发：项目经理指南》），Addison-Wesley，2003，提供了四种方法学的精彩对比。在阅读这篇文章之后，您就会理解怎样去比较和对比其他的文章了。
结论
每一个专业的管理员和开发专业人士都想做的更好。现在敏捷方法看上去为一些小型团队和项目，提供了利益，这就让我们去思考，我们怎样让这种利益在更大的背景下仍然有效。方法就是首先关注想要的结果，然后决定什么样的实践将会最好，而不是在理解想要的结果之前去理解敏捷。
不管您做什么，如果可能的话，将您的实践建立在迭代开发的基础之上。很少有瀑布模型有效的情况发生。所有现代的方法都是建立在迭代，增值开发的基础之上。 9 使用这些作为一个基础，并添加与您的公司和项目文化相匹配的敏捷实践。
关于作者：
Gary Pollice 是伍斯特市伍斯特工学院的一名实践教授，文学硕士。 他讲授软件工程、设计、测试以及其它计算机科学的课程，同时也指导学生设计。在进入学术界之前，他有 35 年多的开发各种软件的经验，从商业应用到编译器和工具。他的最后一份业界工作是在 IBM Rational 软件，他是有名的“RUP 倔老头”，同时也是最早的 Rational Suite 团队的成员之一。他是《小团队开发软件：一种以 RUP 为核心的方法》一书的主要作者，该书由 Addison-Wesley 于 2004 年出版。他在数学方面取得了学士学位，在计算机科学领域取得理科硕士学位。
作者:Gary Pollice
来源:IBM developerWorks
