敏捷过程的局限性

    上述的假定通常不是所有的软件开发环境都支持，尤其是也不是被所有的“敏捷”过程支持。这无需惊讶，任何一个敏捷过程都不是银弹（尽管有支持者热情地声明）。在这部分我们将描述敏捷过程通常不适应的情况。可能一些敏捷过程能更好地符合这些假定，而其他的敏捷过程能通过扩展解决这儿讨论的局限性。类似的扩展能合并通常与更多预言性开发实践有关的原则和实践到敏捷过程中。

    1.缺乏对分布式开发环境的支持：

    敏捷过程提倡的强调在实践中协作，不能很好地适应推动一些行业实现全球化分布式软件开发环境。团队成员和客户在地理上分布的开发环境可能无法支持敏捷过程提倡的面对面的交流。在这种情况下，人们至少可能通过诸如视频会议的技术手段进行面对面地交流，不过这些技术太昂贵，而且不一定达到预期效果。

    面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，但是不会经常发生，而且必须事先计划好以保证所有的相关人员都能参加。可以利用这种面对面的会议作为主要的同步事件，地理上分布的开发者

    （1）可以了解其他人的进度

    （2）讨论产品下一步开发的计划。

    两次会议之间，文档（在代码之上）成为主要的交流方式。及时地创建和维护良好的需求和设计文档，对于保证分布式的开发成员对开发的产品保持一致的观点具有重要的作用。这不应该认为是需要对软件的所有方面都要写文档或建模，文档和模型仅是在对项目和项目有关人员有价值的时候才创建和维护。

    2. 缺乏对转包合同的支持

    承包商的软件开发任务经常是根据合同中对承包商需要做什么的精确规定而制定的。在承包商必须投标签订合同的情况下，必须精确地定义承包任务。承包商在制定标书时，通常会制定足够详细的计划，计划包括一个规定了里程碑和可交付产品的过程，以进行成本评估。这个过程可能采用一个迭代的、增量的方法，但是为了能完成，承包商必须通过详细说明迭代的次数和每次迭代的交付产品使过程可预言。合同可能允许承包商在时间和成本的限制内对如何开发产品拥有一定程度的灵活性。如果承包商有良好的跟踪记录，并且合同单位相信承包商能开发出满足自己需求的产品，这当然是可能。一个合同若支持在承包商环境的敏捷开发，应该由两部分组成：

    固定部分：

    这部分定义了（1）框架，框架限制合同中承包商将如何合并变化到产品中（例如，接受和拒绝可变部分（参见下面）变更的成本和时间标准）

    （2） 承包商必须执行的行为（如质量保证行为）

    （3）认为是不可变的需求和必须提交的产品。

    可变部分：

    这部分定义了在固定部分定义的范围内可变的需求和提交产品。这部分能在固定部分定义的约束下变化。合同签订的时候，应该包括交付产品和需求的优先级。

    3. 缺乏对创建可复用制品的支持

    类似极限编程的敏捷过程聚焦在创建解决特定问题的软件产品。在“网络时代”开发经常排除通用性的解决方案，即使这很清楚会带来长期的效益。在这种开发环境中，通用解决方案和其他形式的可重用软件（如设计框架）的开发最好在主要开发可重用软件制品的项目中解决。这种特定产品开发环境和可复用软件制品开发环境的分离是位于学院公园的马里兰大学的研究人员开发的称为Experience Factory的可复用框架的主要特征。

    可复用产品广泛的适应性要求其创建的过程要注重质量控制，因为低质量（尤其是严重的错误）的影响将会和重用该产品的应用程序的数量一样广泛。另一方面，及时开发可重用制品也是需要的。看起来好像有应用敏捷过程来开发可复用软件制品的案例，但是敏捷过程如何很好地适应这个过程仍然不是很清楚。

    4. 缺乏对大型团队开发的支持

    敏捷过程支持“小规模管理”的过程，其中采用的协调、控制、交流机制适应于小型到中等规模的团队。对于更大的团队，必须维护的交流线索会降低诸如面对面交流和评审会议等实践所带来的效果。大团队很少需要敏捷方法来处理针对“大规模管理”的问题，传统的强调控制文档变化和以架构为中心的开发更适应这种情况。这并不是说敏捷实践不适应这种环境，团队可能有使用敏捷实践的机会，但是敏捷程度可能会比在小项目中使用小得多。