| 从这方面看，一个过程的敏捷性是项目
团队根据环境变化动态调整过程的程度和开发人员集体的经验决定的。
实际过程处于频谱中纯粹的敏捷和纯粹的预言性两个极端之间。目前的敏捷过程靠近频谱中纯粹的敏捷端，但并不是纯粹的敏捷，因为他们提供了一个过程框架限制开发人员必须遵守的过程形式。例如，大多数发布的在敏捷过程上的作品规定迭代的、增量的过程，并且提倡诸如先编写测试代码、结对编程和每日审查
会议等特殊形式的实践。
致谢：Bernhard Rumpe的工作部分得到Bayerisches Staatsministerium
für Wissenschaft，Forschung und Kunst through the Bavarian
Habilitation Fellowship and the German Bundesministerium
für Bildung und Forschung through the VirtualSoftwaereengineering
Competence Center (ViSEK)的支持。Robert France and Dan Turk的工作得到Colorado
Advanced Software Institute (CASI) and
Qwest (CASI Project 5-30186)的授权方式的支持。
摘要：软件开发人员和 项目经理努力地评估敏捷过程对他们的开发环境的适应性。本文指出许多已公布的敏捷过程对不同的项目类型来说存在的局限性，敏捷过程应用在这些项目中可能会存在问题。
绪论：当越来越多的组织要求通过及时部署基于Internet的服务来寻求获得竞争优势时，开发人员就承受不断增长的压力以尽快实现新的、增强的服务。敏捷软件开发过程主要针对这个问题发展起来的，即在“网络时代”开发软件的问题。敏捷方法采用技术上和管理上的过程，这些过程能持续地适应。
(1)源自开发过程中获取的经验而进行的变更
(2)软件需求的变更
(3)开发环境的变更。
敏捷过程特别支持尽早尽快地交付可工作代码的产品，这通过迭代的开发过程完成的，其中每次迭代都注重提交可工作的代码以及其他制品（artifacts）以供客户评估，同时也供项目评估。敏捷过程的支持者和批评者都强调在这些过程中注重代码。支持者经常争论说代码是唯一重要的可交付的产品，可以忽视分析和设计模型、文档在软件开发、演化过程中的角色。敏捷过程批评者指出，强调代码能带来全体记忆丢失（corporate
memory loss），因为没有重视编写良好的文档和模型来支持庞大、复杂软件系统的创造和演化。 敏捷支持者和批评者提出的声明引出这样的问题：在当今快速变化的开发环境中，什么样的实践、技术和基础结构适合软件开发过程？特别是，对有关特定应用程序领域和开发环境的敏捷过程适应性的问题的回答通常是根据轶闻报导。
本文，我们基于对已发表有关敏捷过程的作品的分析介绍了我们所认识到的敏捷过程的局限性。许多自称为“敏捷”的过程在价值上、实践上和应用领域有很大的差别。因此评估所有敏捷过程和识别适应于所有敏捷过程的局限性不是一件容易的事情。我们的分析是根据对假设采用极限编程（XP）,
Scrum , 敏捷统一过程，敏捷建模以及敏捷 联盟提出的宣言的研究。这主要是一个分析性研究，由作
者指导的几个XP项目经验作支持。
敏捷联盟
最近几年的文献中，提出许多种称为“敏捷”的过程。为了避免在什么样的过程是“敏捷”的这个问题上引起混淆，17位业界专家在2001年召开的研讨软件过程未来发展趋势的一次
会议上，就什么是“敏捷”达成一致意见。这次会议的一个成果是成立了“敏捷联盟”并发布了联盟敏捷宣言(参考http://www.agilealliance.org/principles.html)。这份联盟敏捷宣言是“敏捷软件开发”价值和目标的浓缩定义，并通过许多共同的原则进行了细化。这些原则如下所示。
1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
2. 在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。
3. 即使到了开发后期，也欢迎需求变化。
4. 经常性地交付可以工作的软件。
5. 可以工作的软件是主要的进度度量 标准。
6. 围绕被激励起的个体来构建项目。为他们提供所需的环境和支持，并信任他们能胜任工作。
7. 最好的架构、需求和设计来自于自组织的 团队。
8. 在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。
9. 敏捷过程提倡可持续的开发速度。
10. 不断地关注最优秀的技术和良好的设计能增强敏捷能力。
11. 简单是根本的。
12. 开发团队每隔一定时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整。
敏捷过程分析
这一节我们在分析敏捷 联盟原则和敏捷过程潜在的假定的基础上，讨论了敏捷过程的局限性。下一小节列出了在我们研究中识别出的管理上和技术上的假定，随后的一小节讨论了由这些假定推导出的局限性。
潜在的假定 敏捷过程声明的比传统说明性过程的优点是建立在这些假定正确有效的基础上。
这些假定在另外一篇论文中进行了更详细地讨论。
假定1：客户要和开发团队协同工作，随时作好和开发人员交流的准备。而且，面对面的交流需要开发人员彼此位于很近的位置。
假定2：文档和软件模型在软件开发中不充当重要的角色。
假定3：软件需求和软件开发环境随着软件开发的发展而发展。
假定4：动态适应不断变化的项目和产品特征的开发过程，更有可能开发出高质量的产品。
假定5：开发人员具有正确地定义和适应过程的经验。换句话说，一个组织能建立由有丰富经验的问题
解决者组成的团队，他们在执行过程期间，能有效地改进过程。
假定6：项目的可见性能主要通过增量和一些度量的传递来获取。
假定7：软件制品（产品和过程）严格的评估仅限于经常非正式的审查和代码测试。
假定8：重用性和通用性不应该是面向应用程序软件开发过程的目标。
假定9：变更的成本不随着时间的变化而显著增加。
假定10：软件可以被增量开发。
假定11：无需为变更作设计，因为任何变更能通过重构代码有效地处理
敏捷过程的局限性
上述的假定通常不是所有的软件开发环境都支持，尤其是也不是被所有的“敏捷”过程支持。这无需惊讶，任何一个敏捷过程都不是银弹（尽管有支持者热情地声明）。在这部分我们将描述敏捷过程通常不适应的情况。可能一些敏捷过程能更好地符合这些假定，而其他的敏捷过程能通过扩展解决这儿讨论的局限性。类似的扩展能合并通常与更多预言性开发实践有关的原则和实践到敏捷过程中。
1.缺乏对 分布式开发环境的支持：
敏捷过程提倡的强调在实践中协作，不能很好地适应推动一些行业实现全球化分布式软件开发环境。 团队成员和客户在地理上分布的开发环境可能无法支持敏捷过程提倡的面对面的交流。在这种情况下，人们至少可能通过诸如
视频 会议的技术手段进行面对面地交流，不过这些技术太昂贵，而且不一定达到预期效果。
面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，但是不会经常发生，而且必须事先计划好以保证所有的相关人员都能参加。可以利用这种面对面的会议作为主要的同步事件，地理上分布的开发者
(1)可以了解其他人的进度
(2)讨论产品下一步开发的计划。
两次会议之间，文档（在代码之上）成为主要的交流方式。及时地创建和维护良好的需求和设计文档，对于保证分布式的开发成员对开发的产品保持一致的观点具有重要的作用。这不应该认为是需要对软件的所有方面都要写文档或建模，文档和模型仅是在对项目和项目有关人员有价值的时候才创建和维护。
2. 缺乏对转包合同的支持
承包商的软件开发任务经常是根据合同中对承包商需要做什么的精确规定而制定的。在承包商必须投标签订合同的情况下，必须精确地定义承包任务。承包商在制定标书时，通常会制定足够详细的计划，计划包括一个规定了里程碑和可交付产品的过程，以进行成本评估。这个过程可能采用一个迭代的、增量的方法，但是为了能完成，承包商必须通过详细说明迭代的次数和每次迭代的交付产品使过程可预言。合同可能允许承包商在时间和成本的限制内对如何开发产品拥有一定程度的灵活性。如果承包商有良好的跟踪记录，并且合同单位相信承包商能开发出满足自己需求的产品，这当然是可能。一个合同若支持在承包商环境的敏捷开发，应该由两部分组成：
这部分定义了
(1)框架，框架限制合同中承包商将如何合并变化到产品中（例如，接受和拒绝可变部分（参见下面）变更的成本和时间
标准）
(2) 承包商必须执行的行为（如质量保证行为）
(3)认为是不可变的需求和必须提交的产品。
这部分定义了在固定部分定义的范围内可变的需求和提交产品。这部分能在固定部分定义的约束下变化。合同签订的时候，应该包括交付产品和需求的优先级。
3. 缺乏对创建可复用制品的支持
类似极限编程的敏捷过程聚焦在创建解决特定问题的软件产品。在“网络时代”开发经常排除通用性的解决方案，即使这很清楚会带来长期的效益。在这种开发环境中，通用解决方案和其他形式的可重用软件（如设计框架）的开发最好在主要开发可重用软件制品的项目中解决。这种特定产品开发环境和可复用软件制品开发环境的分离是位于学院公园的马里兰大学的研究人员开发的称为Experience
Factory的可复用框架的主要特征。
可复用产品广泛的适应性要求其创建的过程要注重 质量控制，因为低质量（尤其是严重的错误）的影响将会和重用该产品的应用程序的数量一样广泛。另一方面，及时开发可重用制品也是需要的。看起来好像有应用敏捷过程来开发可复用软件制品的案例，但是敏捷过程如何很好地适应这个过程仍然不是很清楚。
4. 缺乏对大型 团队开发的支持： 敏捷过程支持“小规模管理”的过程，其中采用的协调、控制、交流机制适应于小型到中等规模的团队。对于更大的团队，必须维护的交流线索会降低诸如面对面交流和评审
会议等实践所带来的效果。大团队很少需要敏捷方法来处理针对“大规模管理”的问题，传统的强调控制文档变化和以架构为中心的开发更适应这种情况。这并不是说敏捷实践不适应这种环境，团队可能有使用敏捷实践的机会，但是敏捷程度可能会比在小项目中使用小得多。
5. 缺乏对开发有严格安全性要求的软件的支持
有严格安全性要求的软件是指一旦失败会导致对人类造成直接伤害或是引起重大经济损失的软件。当前敏捷过程支持的
质量控制机制（非正式的审查，结对编程）并没有证明来说服使用者软件是安全的。实际上，单独这些技术是否是足够的还有些值得怀疑。
软件工程中的正式的规格说明书，严格的测试覆盖，以及其他正式的分析和评估技术能提供更好但更昂贵的机制来解决有严格安全性要求或是严
格商业要求的软件的开发。一些敏捷实践也能对此类软件开发有益。例如：
(1)测试为先（Test-first）的方法需要在写代码之前定义单元测试
(2)敏捷过程增量迭代过程支持的早期可工作代码的产品支持重要性软件探测性开发，这些开发的需求没有很好地定义
(3)结对编程能作为正式审查的有效的补充。
因此，可以想象，敏捷和正式软件开发并非不兼容，而是在需要的时候可以结合：正规的技术可以应用在敏捷方法中来处理软件中重要的部分，以提高质量和增加信任度。
6. 缺乏对开发大型、复杂的软件的支持：
假设代码重构就不需要设计来处理变更对特别大型、复杂的系统是不够的。在这类软件中，可能一些重要的架构方面因为在系统核心服务中起重要作用而很难进行变更。这种情况，变更这些方面的代价会很高，因此需要早期花费精力预期此类变更。依赖代码重构对这类系统也是有问题的。这类软件的复杂性和规模会导致严格的代码重构代价过高而且容易出错。模型能起重要的作用，尤其是有工具能从模型中产生代码的重要部分。以模型为中心制品演化系统的观点是对象管理组织（OMG）的模型驱动架构(MDA)方法的核心思想(参见http://www.omg.org/mda)。
还有一些系统，其功能紧密耦合和集成，不太可能增量地开发。在这种情况下，每次迭代产生代码的迭代方法仍然可以使用，只不过每次迭代产生的代码会包括所有的部分，每部分都出于各种各样的不完整状态。
结论：尽管看起来有许多软件开发基于敏捷过程获得成功，到目前为止大多数成功的故事都仅仅是逸闻。对比敏捷方法和非敏捷方法的效果和局限性将极大地促进我们理解敏捷过程真正的优点和局限性。本文我们根据对部分称为“敏捷”的过程的原则和假设的研究列举了一系列局限性。并不是所有的假定适应所有这些过程，例如，仍然未发表的“Crystal
Blue”，亦即 “Crystal Clear”的兄弟 [7]，就很好地支持大型软件的开发，但可能并不很“敏捷”。很显然，有些领域更需要敏捷开发过程，其中有Internet应用领域，这些应用面临着显著的尽快推向市场的压力和下一个版本更新的成本尽可能小。然而，同样很明显，开发长期规划、大型复杂系统的公司在目前形式下不太可能采用敏捷过程。
通常，一个软件开发项目的某些方面能从敏捷方法获益，而另外一些方面可能从不是很敏捷的或是预言性的方法获益。从这个方面看，实际的软件开发过程可以根据其“敏捷性”程度沿着频谱分类。在频谱的一个极端是纯粹的预言性开发，这些开发中的步骤都是在项目的早期详细地定义好，项目的目标在整个项目的执行过程中保持相对稳定。在频谱的另一个极端是纯粹的敏捷过程，在这些过程中，
步骤和目标是根据以下分析动态决定的：
(1)执行先前过程步骤获取的经验
(2)在本项目之外获取的类似经验
(3)需求和开发环境的变化
| 
