面對面的交流在分布式的開發環境和在非分布式的開發環境中同等重要，但是不會經常發生，而且必須事先計劃好以保證所有的相關人員都能參加�？梢岳眠@種面對面的會議作為主要的同步事件，地理上分布的開發者
(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/
