敏捷软件过程的局限性[1]

　　摘要：软件开发人员和 项目经理努力地评估敏捷过程对他们的开发环境的适应性。本文指出许多已公布的敏捷过程对不同的项目类型来说存在的局限性，敏捷过程应用在这些项目中可能会存在问题。

　　绪论：当越来越多的组织要求通过及时部署基于Inte.net的服务来寻求获得竞争优势时，开发人员就承受不断增长的压力以尽快实现新的、增强的服务。敏捷软件开发过程主要针对这个问题发展起来的，即在“网络时代”开发软件的问题。敏捷方法采用技术上和管理上的过程，这些过程能持续地适应。

　　(1)源自开发过程中获取的经验而进行的变更
　　(2)软件需求的变更
　　(3)开发环境的变更。

　　敏捷过程特别支持尽早尽快地交付可工作代码的产品，这通过迭代的开发过程完成的，其中每次迭代都注重提交可工作的代码以及其他制品（artifacts）以供客户评估，同时也供项目评估。敏捷过程的支持者和批评者都强调在这些过程中注重代码。支持者经常争论说代码是唯一重要的可交付的产品，可以忽视分析和设计模型、文档在软件开发、演化过程中的角色。敏捷过程批评者指出，强调代码能带来全体记忆丢失（corporate memory loss），因为没有重视编写良好的文档和模型来支持庞大、复杂软件系统的创造和演化。 敏捷支持者和批评者提出的声明引出这样的问题：在当今快速变化的开发环境中，什么样的实践、技术和基础结构适合软件开发过程？特别是，对有关特定应用程序领域和开发环境的敏捷过程适应性的问题的回答通常是根据轶闻报导。

　　本文，我们基于对已发表有关敏捷过程的作品的分析介绍了我们所认识到的敏捷过程的局限性。许多自称为“敏捷”的过程在价值上、实践上和应用领域有很大的差别。因此评估所有敏捷过程和识别适应于所有敏捷过程的局限性不是一件容易的事情。我们的分析是根据对假设采用极限编程（XP）, Scrum , 敏捷统一过程，敏捷建模以及敏捷 联盟提出的宣言的研究。这主要是一个分析性研究，由作
者指导的几个XP项目经验作支持。

　　敏捷联盟 

　　最近几年的文献中，提出许多种称为“敏捷”的过程。为了避免在什么样的过程是“敏捷”的这个问题上引起混淆，17位业界专家在2001年召开的研讨软件过程未来发展趋势的一次 会议上，就什么是“敏捷”达成一致意见。这次会议的一个成果是成立了“敏捷联盟”并发布了联盟敏捷宣言(参考http://www.agilealliance.org/principles.html)。这份联盟敏捷宣言是“敏捷软件开发”价值和目标的浓缩定义，并通过许多共同的原则进行了细化。这些原则如下所示。 

　　1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。

　　2. 在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。 

　　3. 即使到了开发后期，也欢迎需求变化。 

　　4. 经常性地交付可以工作的软件。 

　　5. 可以工作的软件是主要的进度度量 标准。 

[1]  [2]  [3]  [4]  [5]