面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，但是不会经常发生，而且必须事先计划好以保证所有的相关人员都能参加。可以利用这种面对面的会议作为主要的同步事件，地理上分布的开发者
(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)需求和开发环境的变化
从这方面看，一个过程的敏捷性是项目团队根据环境变化动态调整过程的程度和开发人员集体的经验决定的。
实际过程处于频谱中纯粹的敏捷和纯粹的预言性两个极端之间。目前的敏捷过程靠近频谱中纯粹的敏捷端，但并不是纯粹的敏捷，因为他们提供了一个过程框架限制开发人员必须遵守的过程形式。例如，大多数发布的在敏捷过程上的作品规定迭代的、增量的过程，并且提倡诸如先编写测试代码、结对编程和每日审查会议等特殊形式的实践。
文章来源于领测软件测试网 https://www.ltesting.net/
