为什么这个问题是错误的

Ron Jeffries，一个著名的极限编程（XP）开发员，宣称 XP 实践在任何范围内都能很好的工作。他说当人们对大型项目的敏捷反感时，他们实际上并不理解敏捷；因此，他们并不能评价大型项目的适用性。 ¹ 笔者赞成他的观点。笔者不会去讨论关于敏捷的定义，因为笔者已经在The Rational Edge 2007 年 5 月的文章中做了详细的阐述。 ² 笔者假设您已经阅读了这篇文章，还有《敏捷宣言》（Agile Manifesto）及其实践的内容。 ³

《敏捷宣言》（Agile Manifesto）对项目的大小并没有做特定的限制。实际上，敏捷宣言是一种价值的定义，这种价值是宣告选择用以应用到软件开发中去的。如果您在一个拥有这些价值的公司中工作，或者您所在的项目团队拥有这些价值，那么您可能会决定使用敏捷实践。如果因为某些原因您没有或者不能采用这些价值，那么您就不需要为敏捷而操心了。与一些流行的看法相反，这并不意味着您是一个不思进取的人！

因为价值是公司的属性，所以现在就可以很容易的看出问题“敏捷适合任何项目规模吗？”是糟糕的问题了。价值决定了公司是怎样进行业务活动的，而不是公司或者项目的规模决定的。显然大型的公司拥有更多的过程和管理，但是核心的价值是不受影响的。

我想要做一个小型试验。我研究了一些大型和小型的公司。我查看了他们关于业务行为哲学的描述和信息。阅读下列信息，并查看您是否可以识别公司，或者至少是公司的规模以及它的软件项目。

1. 公司 A 列出了一些他们信仰的东西，如下所示：
   1. 关注用户并尽力满足他们的需求。
   2. 快总比慢好。
   3. 您不需去等待一个答案。
   4. 保持认真。
   5. 很好就是不够好。
2. 公司 B 的原则宣称“他们致力于快速并精确的构建软件。最成功的软件项目是强有力的管理，高级的技术技巧，以及使用定义良好开发方法学或者过程的混合体”。
3. 公司 C 有三条强调的值：
   1. 服务每位客户的成功。
   2. 创新非常重要，对我们公司以及我们所处的世界都很重要。
   3. 所有关系中的信赖和个人责任感。
4. 公司 D 看重整体性，诚实，开放性，个人的优异，构建性的自我批评以及相互的尊重。尊重员工和合作者，并拥有一定的技术。他们进行巨大的挑战，并为征服它们而骄傲。他们通过奖励客户，投资者，合作者，以及员工，提供结果，并为最高质量奋斗，而对他们负责。
5. 公司 E 有一句话来描述他们的任务：“通过创新性，智能化，可用的数字媒体方案的概念和执行来服务客户。”
6. 公司 F 相信：
   1. 最佳的方案从清晰和明了的方案开始。
   2. 最佳的地址是标准遵循者。
   3. 最佳的软件是迭代开发的，并有最好的客户参与其中。
   4. 最佳的代码从测试开始。

无须再说，他们对使命的理解和陈述值得我们的尊敬。现在，您是否已经可以决定公司的信息及其规模？在这里我不会提出公司的名字，但是我将会简单的介绍如下：

1. 一家是我们每天都要与之打交道的跨国公司。
2. 一家为客户编写软件和专业培训 XP 团队的小型公司。
3. 世界最大的技术公司之一。
4. 世界上最大的软件公司之一。
5. 一家为其客户构建 Web 程序和其他系统的中等规模的公司。
6. 一个从前是我学生的人创建的小型咨询公司。

当我在寻找这些公司，以及他们任务和价值的时候，我没有发现任何与规模或者“敏捷”相关的信息。

哪些敏捷实践能够适合大型的项目？

那么，针对大型项目的敏捷，什么才是应该问的正确的问题？我相信正确的问题是“哪些敏捷实践最适合支持大型公司或者大型项目？”

不同规模的公司可能会使用不同的过程和实践。与涉及到一个或者两个人的项目相比，涉及到数百人的项目肯定会有不同的控制和抑制因素。沟通频率会随着项目成员的增加而按指数增加。为了获取重要的交流信息，大型的团队必须以更加严格和正式的方式进行工作。上面所有我提到的公司，运行的是敏捷方法很适合的项目。可能并不是所有的项目都认同敏捷，但是许多公司确实是认同的。这样的项目与顾客有规则的交流，并且必须处理需求的快速更改。开发团队成员相互之间必须有紧密的合作，并要快速不带迟疑的对系统作出决定。

让我们看一下敏捷实践，并看看它们是如何适用于大型项目的。让我们承认大型的项目要有二十或者更多的人员参与，但是这是一个任意的门槛。您可以决定，我的标准根据您对大型项目的概念是否需要调整。

Ron Jeffries 说大多数的 XP 实践适合大型的项目。大多数对敏捷感兴趣的人都或多或少的对 XP 有一些了解，这就使得它成为一个好的起始点。Ron 的 XProgramming.com Web 网站识别十三种实践。 ⁴ 接下来的是我对这些实践是否适用的评价。对于每一项实践我都指出了我是否认为它适用，并简单的呈现了我的意见。

整个团队（不）。这种实践需要所有的团队成员坐在一起进行商量。至少要有一个顾客代表在场。大多数团队都是分布式的，这样有可能每一个分开的地理位置都有一个顾客代表，所以可能它并不是经济上合理的。而且，找到一个可以容纳二十多人或者更多人的房间可能是非常困难的。大型的团队会在项目的生命周期内拥有小型的分团队。每一个这些团队可能都可以使用 Whole Team 实践。

计划策略（是）。计划策略让一个团队简单的计划和追踪。不管团队用以获取需求的工具以及迭代的长度，计划策略都让生产现实的迭代计划变得更加容易。

小版本（可能）。“小”是一个主观性的词语，取决于您的定义。但是，大多数的软件系统允许团队去选择最终系统的一部分，以完全执行一个小型的版本。它遵循迭代和增殖开发的原则，并在使用 IBM®Rational®Unified Process （RUP）的各种版本的项目上运行良好。一些系统，特别是那些涉及到集成通用硬件和软件的系统，对与使用小型版本可能不太友好。

定制测试（是）。还有谁比客户更能知道系统必须去做什么？顾客代表可以书写测试用例，或者帮助书写任意项目的测试用例。实际上，对于一个更不敏捷的项目来说，顾客通常指定验收测试作为合约的一部分，或者它的补充物。

简单设计（可能）。设计应该尽可能的简单，这是理想化的。正如 Jeffries 描述的那样，这种 实践确实是不断增值的设计。项目需要的设计的数量，应该由项目的类型以及项目需求来决定。

配对编程（是）。成对编程看起来可以产生更好的质量且避免过大的压力。只要有两个团队成员可以一起工作，这种实践就可以进行。如果团队是完全地理分开的，那么这种实践就无效了， ⁵ 但是它与团队的规模无关。

测试驱动开发（是）。对质量有严重责任的开发员，应该为他们的工作书写单元测试。如果他们书写单元测试的话，他们就可以在执行代码之前就去书写了。项目规模并不影响什么时候书写测试的选择。

重构（是）。好的程序员不停的工作，以创建更加强壮更具维护性和有效的代码。项目的规模再一次与此无关。

持续集成（可能）。小型项目可以使用简单的工具去执行持续的集成实践。拥有多个位置和多个代码库的大型项目，可能并不能构建完整的项目。显然他们会需要更高级的工具，以达到一个更加有效的集成过程。经济考虑可能会是决定是否采取实践最重要的因素。

集体代码拥有权（值得怀疑）。虽然小分队的团队成员可能会理解所有他们创建的代码，他们非常理解其他团队成员工作 的几率很小。一般的代码所有权会在开发员之间进行分配。

编码标准（是）。没有编码标准的任意规模的项目都注定会出问题。

隐喻（不）。坚定的 XP 支持者对这个问题很关心。有一些人做了长期的尝试，想要人们意识到隐喻的价值。我仍然没有被说服。显然，在我们开发结构时我们使用了很多的隐喻，但是它们并不能取代结构的作用。在笔者看来，随着项目的变大，试着得到隐喻的精确信息是十分低效的。

可持续步伐（是）。这不仅仅关系到公司和项目的规模，还关系到公司和项目的文化。

我赞成 Jeffries 的评价，他说大多数 XP 实践能够很好地适应大型的项目。那么其他的敏捷实践呢 ？

关于 Scrum 的笔记

另一项流行的是 Scrum。 ⁶ Scrum 是一种可以适用于许多类型工作的管理过程。

基本上，Scrum 是一种构建产品的增长的迭代过程。它在构建新的产品时最有效，但是也可用于其它的条件下。Scrum 的主要目的是日常的循环以及 30 天的循环。图 1 是一个图标，选自 Wikipedia 关于 Scrum 的网页 ⁷ ，如下所示：

图 1：Scrum 循环。

Scrum 有一些非常基本的思想，并以一种适合软件开发团队工作的方式进行组织。特定的实践有：

1. 迭代开发。这是大多数软件开发过程的例程需要的图片，不管是不是敏捷的。在 Scrum 中，迭代校正 sprints，定义为 30 天。
2. 短期会议固定的日常循环 下，每一位团队成员都回答三个问题：
   1. 上一次会议我完成了什么？
   2. 达到我的目标碰到了什么障碍？
   3. 下一次会议之前我需要做些什么？

有一个人扮演的是 Scrum 管理员的角色，并未扫清障碍负责。

• 两种挤压未作之事：产品所有需求的产品积压以及 sprint 积压，包含了当前 sprint 规划需求。在sprint 期间 sprint 积压并没有改变。
• 回顾每一个 sprint 尾期以改善过程。

没有 Scrum 概念是特别新的。Scrum 以一种低负荷的方式进行组织，并依靠自我组织的团队。

对大型的团队来说 Scrum 是否适合？Ken Schwabe，Scrum 创作人之一，肯定地回答了这个问题。他指出通过“scrums of scrums”，可以适应大型团队。 ⁸ 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，提供了四种方法学的精彩对比。在阅读这篇文章之后，您就会理解怎样去比较和对比其他的文章了。

结论

每一个专业的管理员和开发专业人士都想做的更好。现在敏捷方法看上去为一些小型团队和项目，提供了利益，这就让我们去思考，我们怎样让这种利益在更大的背景下仍然有效。方法就是首先关注想要的结果，然后决定什么样的实践将会最好，而不是在理解想要的结果之前去理解敏捷。

不管您做什么，如果可能的话，将您的实践建立在迭代开发的基础之上。很少有瀑布模型有效的情况发生。所有现代的方法都是建立在迭代，增值开发的基础之上。 ⁹ 使用这些作为一个基础，并添加与您的公司和项目文化相匹配的敏捷实践。

注解

1. 查看 Agile Forums » Advancing Agile » Large Projects。
2. 查看“敏捷软件开发：关于它的起源以及创始人的传记”。
3. 查看 Manifesto for Agile Software Development 和 Principles behind the Agile Manifesto。
4. 查看 What is Extreme Programming?。
5. 为支持分布的成对编程，构建了一些实验系统。结果到目前为止并不确定。
6. 查看关于 Scrum 的信息。
7. 查看 维基百科上的 Scrum 条目。
8. 关于 Scrum 概念的描述可以从 Mountain Goat Software 的网站上找到。
9. 人们可能会掉入的陷阱，是将敏捷方法当做瀑布模型的反面。这并不是事实。迭代开发并不是瀑布模型的反面。您并不一定要使用敏捷方法来进行迭代开发。

参考资料

• IBM Rational 敏捷开发工具包：本工具包将帮助您了解 IBM Rational 为敏捷开发所提供的技术和解决方案，以及最佳实践。帮助您更好地运用 IBM Rational 软件实施敏捷开发，将敏捷开发的实践落到实处。
• 查看 Rational Edge 电子期刊 其他精彩文章，获得了解高效软件开发背后的概念。
• 访问 developerWorks 上的 Rational 软件专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
• 了解 IBM Rational 软件交付平台，包括适用于并行开发和地域分布式团队的协作工具，以及用于架构管理、资产管理、变更和发布管理，集成需求管理、过程和组合管理，和质量管理。
• 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
• 浏览 技术书店，获得有关这些和其它技术主题的书籍。

• 下载 IBM Rational 软件的试用版。
• 下载这些 IBM 产品评估版，并着手使用来自于 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的应用程序开发工具和中间件产品。

• 参与论坛讨论。
• 查看 developerWorks 博客，并加入 developerWorks 社区。