緒論：當越來越多的組織要求通過及時部署基于Internet的服務來尋求獲得競爭優勢時，開發人員就承受不斷增長的壓力以盡快實現新的、增強的服務。敏捷軟件開發過程主要針對這個問題發展起來的，即在“網絡時代”開發軟件的問題。敏捷方法采用技術上和管理上的過程，這些過程能持續地適應。
(1)源自開發過程中獲取的經驗而進行的變更
(2)軟件需求的變更
(3)開發環境的變更。
敏捷過程特別支持盡早盡快地交付可工作代碼的產品，這通過迭代的開發過程完成的，其中每次迭代都注重提交可工作的代碼以及其他制品（artifacts）以供客戶評估，同時也供項目評估。敏捷過程的支持者和批評者都強調在這些過程中注重代碼。支持者經常爭論說代碼是唯一重要的可交付的產品，可以忽視分析和設計模型、文檔在軟件開發、演化過程中的角色。敏捷過程批評者指出，強調代碼能帶來全體記憶丟失（corporate memory loss），因為沒有重視編寫良好的文檔和模型來支持龐大、復雜軟件系統的創造和演化。 敏捷支持者和批評者提出的聲明引出這樣的問題：在當今快速變化的開發環境中，什么樣的實踐、技術和基礎結構適合軟件開發過程？特別是，對有關特定應用程序領域和開發環境的敏捷過程適應性的問題的回答通常是根據軼聞報導。
本文，我們基于對已發表有關敏捷過程的作品的分析介紹了我們所認識到的敏捷過程的局限性。許多自稱為“敏捷”的過程在價值上、實踐上和應用領域有很大的差別。因此評估所有敏捷過程和識別適應于所有敏捷過程的局限性不是一件容易的事情。我們的分析是根據對假設采用極限編程（XP）, Scrum , 敏捷統一過程，敏捷建模以及敏捷聯盟提出的宣言的研究。這主要是一個分析性研究，由作
者指導的幾個XP項目經驗作支持。
6. 圍繞被激勵起的個體來構建項目。為他們提供所需的環境和支持，并信任他們能勝任工作。
7. 最好的架構、需求和設計來自于自組織的團隊。
8. 在團隊內部，最有效果和最有效率的傳遞信息的方法是面對面地交流。
9. 敏捷過程提倡可持續的開發速度。
10. 不斷地關注最優秀的技術和良好的設計能增強敏捷能力。
11. 簡單是根本的。
12. 開發團隊每隔一定時間，都會對如何能有效地工作進行反省，然后相應地對自己的行為進行調整。
敏捷過程分析
這一節我們在分析敏捷聯盟原則和敏捷過程潛在的假定的基礎上，討論了敏捷過程的局限性。下一小節列出了在我們研究中識別出的管理上和技術上的假定，隨后的一小節討論了由這些假定推導出的局限性。 潛在的假定 敏捷過程聲明的比傳統說明性過程的優點是建立在這些假定正確有效的基礎上。
這些假定在另外一篇論文中進行了更詳細地討論。
假定1：客戶要和開發團隊協同工作，隨時作好和開發人員交流的準備。而且，面對面的交流需要開發人員彼此位于很近的位置。
假定2：文檔和軟件模型在軟件開發中不充當重要的角色。
假定3：軟件需求和軟件開發環境隨著軟件開發的發展而發展。
假定4：動態適應不斷變化的項目和產品特征的開發過程，更有可能開發出高質量的產品。
假定5：開發人員具有正確地定義和適應過程的經驗。換句話說，一個組織能建立由有豐富經驗的問題
解決者組成的團隊，他們在執行過程期間，能有效地改進過程。
假定7：軟件制品（產品和過程）嚴格的評估僅限于經常非正式的審查和代碼測試。
假定8：重用性和通用性不應該是面向應用程序軟件開發過程的目標。
假定9：變更的成本不隨著時間的變化而顯著增加。
假定10：軟件可以被增量開發。
假定11：無需為變更作設計，因為任何變更能通過重構代碼有效地處理
敏捷過程的局限性
上述的假定通常不是所有的軟件開發環境都支持，尤其是也不是被所有的“敏捷”過程支持。這無需驚訝，任何一個敏捷過程都不是銀彈（盡管有支持者熱情地聲明）。在這部分我們將描述敏捷過程通常不適應的情況�？赡芤恍┟艚葸^程能更好地符合這些假定，而其他的敏捷過程能通過擴展解決這兒討論的局限性。類似的擴展能合并通常與更多預言性開發實踐有關的原則和實踐到敏捷過程中。
敏捷聯盟
最近幾年的文獻中，提出許多種稱為“敏捷”的過程。為了避免在什么樣的過程是“敏捷”的這個問題上引起混淆，17位業界專家在2001年召開的研討軟件過程未來發展趨勢的一次會議上，就什么是“敏捷”達成一致意見。這次會議的一個成果是成立了“敏捷聯盟”并發布了聯盟敏捷宣言這份聯盟敏捷宣言是“敏捷軟件開發”價值和目標的濃縮定義，并通過許多共同的原則進行了細化。這些原則如下所示。
1. 我們最優先要做的是通過盡早、持續地交付有價值的軟件來使客戶滿意。
2. 在項目的整個開發期間，業務人員和開發人員必須天天在一起工作。
3. 即使到了開發后期，也歡迎需求變化。
4. 經常性地交付可以工作的軟件。
5. 可以工作的軟件是主要的進度度量標準。
6. 圍繞被激勵起的個體來構建項目。為他們提供所需的環境和支持，并信任他們能勝任工作。
7. 最好的架構、需求和設計來自于自組織的團隊。
8. 在團隊內部，最有效果和最有效率的傳遞信息的方法是面對面地交流。
9. 敏捷過程提倡可持續的開發速度。
10. 不斷地關注最優秀的技術和良好的設計能增強敏捷能力。
11. 簡單是根本的。
12. 開發團隊每隔一定時間，都會對如何能有效地工作進行反省，然后相應地對自己的行為進行調整。
敏捷過程分析
這一節我們在分析敏捷聯盟原則和敏捷過程潛在的假定的基礎上，討論了敏捷過程的局限性。下一小節列出了在我們研究中識別出的管理上和技術上的假定，隨后的一小節討論了由這些假定推導出的局限性。 潛在的假定 敏捷過程聲明的比傳統說明性過程的優點是建立在這些假定正確有效的基礎上。
這些假定在另外一篇論文中進行了更詳細地討論。
假定1：客戶要和開發團隊協同工作，隨時作好和開發人員交流的準備。而且，面對面的交流需要開發人員彼此位于很近的位置。
假定2：文檔和軟件模型在軟件開發中不充當重要的角色。
假定3：軟件需求和軟件開發環境隨著軟件開發的發展而發展。
假定4：動態適應不斷變化的項目和產品特征的開發過程，更有可能開發出高質量的產品。
假定5：開發人員具有正確地定義和適應過程的經驗。換句話說，一個組織能建立由有豐富經驗的問題
解決者組成的團隊，他們在執行過程期間，能有效地改進過程。
假定6：項目的可見性能主要通過增量和一些度量的傳遞來獲取。
假定7：軟件制品（產品和過程）嚴格的評估僅限于經常非正式的審查和代碼測試。
假定8：重用性和通用性不應該是面向應用程序軟件開發過程的目標。
假定9：變更的成本不隨著時間的變化而顯著增加。
假定10：軟件可以被增量開發。
假定11：無需為變更作設計，因為任何變更能通過重構代碼有效地處理
敏捷過程的局限性
上述的假定通常不是所有的軟件開發環境都支持，尤其是也不是被所有的“敏捷”過程支持。這無需驚訝，任何一個敏捷過程都不是銀彈（盡管有支持者熱情地聲明）。在這部分我們將描述敏捷過程通常不適應的情況�？赡芤恍┟艚葸^程能更好地符合這些假定，而其他的敏捷過程能通過擴展解決這兒討論的局限性。類似的擴展能合并通常與更多預言性開發實踐有關的原則和實踐到敏捷過程中。
1.缺乏對分布式開發環境的支持：
敏捷過程提倡的強調在實踐中協作，不能很好地適應推動一些行業實現全球化分布式軟件開發環境。團隊成員和客戶在地理上分布的開發環境可能無法支持敏捷過程提倡的面對面的交流。在這種情況下，人們至少可能通過諸如視頻會議的技術手段進行面對面地交流，不過這些技術太昂貴，而且不一定達到預期效果。
面對面的交流在分布式的開發環境和在非分布式的開發環境中同等重要，但是不會經常發生，而且必須事先計劃好以保證所有的相關人員都能參加�？梢岳眠@種面對面的會議作為主要的同步事件，地理上分布的開發者
(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)需求和開發環境的變化
從這方面看，一個過程的敏捷性是項目團隊根據環境變化動態調整過程的程度和開發人員集體的經驗決定的。
實際過程處于頻譜中純粹的敏捷和純粹的預言性兩個極端之間。目前的敏捷過程靠近頻譜中純粹的敏捷端，但并不是純粹的敏捷，因為他們提供了一個過程框架限制開發人員必須遵守的過程形式。例如，大多數發布的在敏捷過程上的作品規定迭代的、增量的過程，并且提倡諸如先編寫測試代碼、結對編程和每日審查會議等特殊形式的實踐。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
