摘要：軟件開發人員和 項目經理努力地評估敏捷過程對他們的開發環境的適應性。本文指出許多已公布的敏捷過程對不同的項目類型來說存在的局限性，敏捷過程應用在這些項目中可能會存在問題。
緒論：當越來越多的組織要求通過及時部署基于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. 可以工作的軟件是主要的進度度量 標準。
