4. 缺乏对大型 团队开发的支持： 敏捷过程支持“小规模管理”的过程，其中采用的协调、控制、交流机制适应于小型到中等规模的团队。对于更大的团队，必须维护的交流线索会降低诸如面对面交流和评审 会议等实践所带来的效果。大团队很少需要敏捷方法来处理针对“大规模管理”的问题，传统的强调控制文档变化和以架构为中心的开发更适应这种情况。这并不是说敏捷实践不适应这种环境，团队可能有使用敏捷实践的机会，但是敏捷程度可能会比在小项目中使用小得多。
5. 缺乏对开发有严格安全性要求的软件的支持
有严格安全性要求的软件是指一旦失败会导致对人类造成直接伤害或是引起重大经济损失的软件。当前敏捷过程支持的 质量控制机制（非正式的审查，结对编程）并没有证明来说服使用者软件是安全的。实际上，单独这些技术是否是足够的还有些值得怀疑。 软件工程中的正式的规格说明书，严格的测试覆盖，以及其他正式的分析和评估技术能提供更好但更昂贵的机制来解决有严格安全性要求或是严
格商业要求的软件的开发。一些敏捷实践也能对此类软件开发有益。例如：
(1)测试为先（Test-first）的方法需要在写代码之前定义单元测试
(2)敏捷过程增量迭代过程支持的早期可工作代码的产品支持重要性软件探测性开发，这些开发的需求没有很好地定义
(3)结对编程能作为正式审查的有效的补充。
因此，可以想象，敏捷和正式软件开发并非不兼容，而是在需要的时候可以结合：正规的技术可以应用在敏捷方法中来处理软件中重要的部分，以提高质量和增加信任度。
6. 缺乏对开发大型、复杂的软件的支持：
假设代码重构就不需要设计来处理变更对特别大型、复杂的系统是不够的。在这类软件中，可能一些重要的架构方面因为在系统核心服务中起重要作用而很难进行变更。这种情况，变更这些方面的代价会很高，因此需要早期花费精力预期此类变更。依赖代码重构对这类系统也是有问题的。这类软件的复杂性和规模会导致严格的代码重构代价过高而且容易出错。模型能起重要的作用，尤其是有工具能从模型中产生代码的重要部分。以模型为中心制品演化系统的观点是对象管理组织（OMG）的模型驱动架构(MDA)方法的核心思想(参见http://www.omg.org/mda)。
还有一些系统，其功能紧密耦合和集成，不太可能增量地开发。在这种情况下，每次迭代产生代码的迭代方法仍然可以使用，只不过每次迭代产生的代码会包括所有的部分，每部分都出于各种各样的不完整状态。
结论：尽管看起来有许多软件开发基于敏捷过程获得成功，到目前为止大多数成功的故事都仅仅是逸闻。对比敏捷方法和非敏捷方法的效果和局限性将极大地促进我们理解敏捷过程真正的优点和局限性。本文我们根据对部分称为“敏捷”的过程的原则和假设的研究列举了一系列局限性。并不是所有的假定适应所有这些过程，例如，仍然未发表的“Crystal Blue”，亦即 “Crystal Clear”的兄弟 [7]，就很好地支持大型软件的开发，但可能并不很“敏捷”。很显然，有些领域更需要敏捷开发过程，其中有Internet应用领域，这些应用面临着显著的尽快推向市场的压力和下一个版本更新的成本尽可能小。然而，同样很明显，开发长期规划、大型复杂系统的公司在目前形式下不太可能采用敏捷过程。
通常，一个软件开发项目的某些方面能从敏捷方法获益，而另外一些方面可能从不是很敏捷的或是预言性的方法获益。从这个方面看，实际的软件开发过程可以根据其“敏捷性”程度沿着频谱分类。在频谱的一个极端是纯粹的预言性开发，这些开发中的步骤都是在项目的早期详细地定义好，项目的目标在整个项目的执行过程中保持相对稳定。在频谱的另一个极端是纯粹的敏捷过程，在这些过程中，
步骤和目标是根据以下分析动态决定的：
(1)执行先前过程步骤获取的经验
(2)在本项目之外获取的类似经验
(3)需求和开发环境的变化
文章来源于领测软件测试网 https://www.ltesting.net/
