2001 年 2 月，在美國的猶他州，17 位“無政府主義者”共同發表了《敏捷軟體開發宣言》。

• 儘早地、持續地向客戶交付有價值的軟體對開發人員來說是最重要的。
• 擁抱變化，即使在開發的後期。敏捷過程能夠駕馭變化，保持客戶的競爭力。
• 經常交付可工作的軟體，從幾周到幾個月，時間範圍越小越好。
• 在整個專案中，業務人員和開發者緊密合作。
• 圍繞士氣高昂的團隊進行開發，為團隊成員提供適宜的環境，滿足他們的需要，並給予足夠的信任。
• 在團隊中，最有效率的、也是效果最好的溝通方式是面對面地交流。
• 可以工作的軟體是進度首要的度量方式。
• 可持續地開發。投資人、開發團隊和使用者應該保持固定的節奏。
• 不斷追求優秀的技術和良好的設計有助於提高敏捷性。
• 要簡單，儘可能減少工作量。減少工作量的藝術是非常重要的。
• 最好的架構、需求和設計都來自於一個自我組織的團隊。
• 團隊要定期地總結如何能夠更有效率，然後相應地自我調整。

至此，敏捷軟體聯盟建立起來，敏捷軟體開發方法進入了大發展的時代。這份宣言也就是敏捷方法的燈塔，所有的敏捷方法都在向這個方向努力。

極限程式設計

XP 方法可以說是敏捷聯盟中最鮮豔的一面旗幟，也是相對來說最成熟的一種。XP 方法的雛形最初形成於 1996—1999 年間，Kent Beck、Ward Cunningham、Ron Jeffery 夫婦在開發 C3 專案（Chrysler Comprehensive Compensation）的實踐中總結出了 XP 的基本元素。在此之後，Kent Beck 和他的一些好朋友們一起在實踐中完善提高，終於形成了極限程式設計方法。

XP 是一種輕量（敏捷）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟體開發方式。

XP特點

（1）在更短的週期內，更早地提供具體、持續的反饋資訊。

（2）迭代地進行計劃編制，首先在最開始迅速生成一個總體計劃，然後在整個專案開發過程中不斷地發展它。

（3）依賴於自動測試程式來監控開發進度，並及早地捕獲缺陷。

（4）依賴於口頭交流、測試和源程式進行溝通。

（5）倡導持續的、演化式的設計。

（6）依賴於開發團隊內部的緊密協作。

（7）儘可能達到程式設計師短期利益和專案長期利益的平衡。

XP 由價值觀、原則、實踐和行為四個部分組成，它們彼此相互依賴、關聯，並通過行為貫穿於整個生命週期。

四大價值觀

XP 的核心是其總結的溝通、簡單、反饋、勇氣四大價值觀，它們是 XP 的基礎，也是XP 的靈魂。

溝通

通常，程式設計師給人留下的印象就是“內向、不善言談”，專案中的許多問題就出在這些缺乏溝通的開發人員身上。由於某個程式設計師做出了一個設計決定，但是卻不能夠及時地通知團隊中的其他成員，結果使得團隊在協作與配合上出現很多麻煩。而在傳統的開發方法中，並不在意這種口頭溝通不暢的問題，而是希望藉助於完善的流程和麵面俱到的文件、報表、計劃來替代，但是，這又引入了效率不高的新問題。

XP 方法認為，如果小組成員之間無法做到持續的、無間斷的交流，那麼協作就無從談起。從這個角度來看，通過文件、報表等人工製品進行交流，具有很大的侷限性。因此， XP 組合了諸如結對程式設計這樣的最佳實踐，鼓勵大家進行口頭交流、通過交流解決問題，提高效率。

簡單

XP 方法在工作中秉承“夠用即好”的思路，也就是儘量地簡單化，只要今天夠用就行，不考慮明天會出現的新問題。這一點看上去十分容易，但要真正做到保持簡單的工作其實是很難的，因為在傳統的開發方法中，都要求開發人員對未來做一些預先規劃，以便對今後可能發生的變化預留一些擴充套件空間。

溝通和簡單之間還有一種相當微妙的互相支援關係。一方面，團隊成員之間溝通得越多，就越容易明白哪些工作需要做，哪些工作不需要做；另一方面，系統越簡單，需要溝通的內容也就越少，溝通也將更加全面。

反饋

是什麼原因使得客戶、管理層這麼不理解開發團隊？究其癥結，就是開發的過程中缺乏必要的反饋。在很多專案中，當開發團隊經歷過了需求分析階段之後，在一個相當長的時間段中，是沒有任何反饋資訊的。整個開發過程對於客戶和管理層而言就像一個黑盒子，進度完全看不到。而且，在專案開發過程中，這樣的現象不僅出現在開發團隊與客戶、管理層之間，還包括在開發團隊內部。因此，開發團隊需要更加註重反饋。反饋對於任何軟體專案的成功都是至關重要的，而在 XP 方法論中則更進一步，通過持續、明確的反饋來暴露軟體狀態的問題。

反饋與溝通有著良好的配合，及時和良好的反饋有助於溝通。而簡單的系統，更有利於測試和反饋。

勇氣

在應用 XP 方法時，每時每刻都在應對變化：由於溝通良好，會有更多需求變更的機會；由於時刻保持系統的簡單，新的變化會帶來一些重新開發的需要；由於反饋及時，會有更多中間打斷思路的新需求。總之，這一切使得開發團隊處於變化之中，因此，這時就需要有勇氣來面對快速開發，面對可能的重新開發。勇氣可以來源於溝通，因為它使得高風險、高回報的試驗成為可能；勇氣可以來源於簡單，因為面對簡單的系統，更容易鼓起勇氣；勇氣可以來源於反饋，因為可以及時獲得每一步前進的狀態（自動測試），會讓人更勇於重構程式碼。

隱藏價值

在 XP 的四大價值觀之下，隱藏著一種更深刻的東西，那就是尊重。因為這一切都建立在團隊成員之間相互關心、相互理解的基礎之上。

最佳實踐

在 XP 中，集成了 12 個最佳實踐，有趣的是，它們沒有一個是創新的概念，大多數概念和程式設計一樣老。其主要的創新點在於提供一種良好的思路將這些最佳實踐結合在一起，並且確保儘可能徹底地執行，使得它們能夠在最大程度上互相支援。

計劃遊戲

計劃遊戲的主要思想就是先快速地制定一份概要的計劃，然後，隨著專案細節的不斷清晰，再逐步完善這份計劃。計劃遊戲產生的結果是一套使用者故事及後續的一兩次迭代的概要計劃。

小型釋出

XP 方法秉承的是“持續整合、小步快走”的哲學思維，也就是說每一次釋出的版本應該儘可能地小，當然前提條件是每個版本有足夠的商業價值，值得釋出。由於小型釋出可以使得整合更頻繁，客戶獲得的中間結果越頻繁，反饋也就越頻繁，客戶就能夠實時地瞭解專案的進展情況，從而提出更多的意見，以便在下一次迭代中計劃進去，以實現更高的客戶滿意度。

隱喻

相對而言，隱喻比較令人費解。根據詞典中的解釋是：“一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處”。隱喻常用於四個方面：尋求共識、發明共享語彙、創新的武器、描述架構。

tips：如果能夠找到合適的隱喻是十分快樂的，但並不是每一種情況都可以找到恰當的隱喻，因此，沒有必要去強求，而是順其自然。

簡單設計

強調簡單的價值觀，引出了簡單性假設原則，落到實處就是“簡單設計”實踐。這個實踐看上去似乎很容易理解，但卻又經常被誤解，許多批評者就指責 XP 忽略設計是不正確的。其實，XP 的簡單設計實踐並不是要忽略設計，而是認為設計不應該在編碼之前一次性完成，因為那樣只能建立在“情況不會發生變化”或者“我們可以預見所有的變化”之類的謊言的基礎上。

測試先行

對於有些團隊而言，有時候程式設計師會以“開發工作太緊張”為理由，繼而忽略測試工作。這樣，就導致了一個惡性迴圈，越是沒空編寫測試程式，程式碼的效率與質量越差，花在找缺陷、解決缺陷的時間也越來越多，實際產能大大降低。由於產能降低，因此時間更緊張，壓力就更大。

重構

重構是一種對程式碼進行改進而不影響功能實現的技術，XP 需要開發人員在“聞到程式碼的壞味道”時，就有重構程式碼的勇氣。重構的目的是降低變化引發的風險、使得程式碼優化更加容易。

結對程式設計

從 20 世紀 60 年代開始，就有類似的實踐在進行，長年以來的研究結果給出的結論是，結對程式設計的效率反而比單獨程式設計更高。一開始雖然會犧牲一些速度，但慢慢地，開發速度會逐漸加快。究其原因，主要是結對程式設計大大降低了溝通的成本，提高了工作的質量。結對程式設計技術被譽於 XP 保證工作質量、強調人文主義的一個最典型的實踐，應用得當還能夠使開發團隊協作更加順暢、知識交流與共享更加頻繁、團隊穩定性也會更加牢固。

集體程式碼所有制

由於 XP 方法鼓勵團隊進行結對程式設計，而且認為結對程式設計的組合應該動態地搭配，根據任務的不同、專業技能的不同進行最優組合。因此，每一個人都會遇到不同的程式碼，程式碼的所有制就不再適合於私有，因為那樣會給修改工作帶來巨大的不便。所謂集體程式碼所有制，就是團隊中的每個成員都擁有對程式碼進行改進的權利，每個人都擁有全部程式碼，也都需要對全部程式碼負責。同時，XP 強調程式碼是誰破壞的（修改後出現問題），就應該由誰來修復。

tips：集體程式碼所有制是 XP 與其他敏捷方法的一個較大不同，也是從另一個側面體現了 XP 中蘊含的很深厚的編碼情節。

持續整合

在前面談到小型釋出、重構、結對程式設計、集體程式碼所有制等最佳實踐的時候，多次提到“持續整合”，可以說持續整合是這些最佳實踐的基本支撐條件。

每週工作 40 小時

這是最讓開發人員開心、管理者反對的一個最佳實踐了，加班、再加班早已成為開發人員的家常便飯，也是管理者最常使用的一種策略。而 XP 方法認為，加班最終會扼殺團隊的積極性，最終導致專案的失敗，這也充分體現了 XP 方法關注人的因素比關注過程的因素更多一些。不過，有一點是需要解釋的，“每週工作 40 小時”中的“40”不是一個絕對數，它所代表的意思是團隊應該保證按照“正常的時間” 進行工作。

現場客戶

為了保證開發出來的結果與客戶的預想接近，XP 方法認為最重要的是需要將客戶請到開發現場。就像計劃遊戲中提到過的，在 XP 專案中，應該時刻保證客戶負責業務決策，開發團隊負責技術決策。因此，在專案中有客戶在現場明確使用者故事，並做出相應的業務決策，對於 XP 專案而言有著十分重要的意義。

編碼標準

擁有編碼標準可以避免團隊在一些與開發進度無關的細枝末節問題上發生爭論，而且會給重構、結對程式設計帶來很大的麻煩。不過，XP 方法的編碼標準的目的不是建立一個事無鉅細的規則列表，而是要能夠提供一個確保程式碼清晰，便於交流的指導方針。

特徵驅動開發

FDD 方法來自於一個大型的新加坡銀行專案。FDD 的創立者 Jeff De Luca 和 Peter Coad 分別是這個專案的專案經理和首席架構設計師。在 Jeff 和 Peter 接手專案時，客戶已經經歷了一次專案的失敗，從使用者到高層都對這個專案持懷疑的態度，專案組士氣低落。隨後， Jeff 和 Peter 採用了特徵驅動、彩色建模等方法，最終獲得了巨大成功。

FDD 是也是一個迭代的開發模型。FDD的每一步都強調質量，不斷地交付可執行的軟體，並以很小的開發提供精確的專案進度報告和狀態資訊。同敏捷方法一樣，FDD 弱化了過程在軟體開發中的地位。雖然 FDD 中也定義了開發的過程，不過一個幾頁紙就能完全描述的過程深受開發者的喜愛。

FDD 角色定義

FDD 認為，有效的軟體開發不可缺少的三個要素是：人、過程和技術。軟體開發不能沒有過程，也不能沒有技術，但軟體開發中最重要的是人。個人的生產率和人的技能將會決定專案的成敗。

專案經理

專案經理是開發的組織者，但專案經理不是開發的主宰。對於專案團隊來說，專案經理應該是團隊的保護屏障。他將同團隊外界（如高層領導、人事甚至寫字樓的物業管理員）進行溝通，努力為團隊提供一個適宜的開發環境。

首席架構設計師

不難理解，首席架構設計師負責系統架構的設計。

開發經理

開發經理負責團隊日常的開發，解決開發中出現的技術問題與資源衝突。

主程式設計師

主程式設計師將帶領一個小組完成特徵的詳細設計和構建的工作，一般要求主程式設計師具有一定的工作經驗，並能夠帶動小組的工作。

程式設計師

若干個程式設計師在主程式設計師的帶領下形成一個開發小組，按照特徵開發計劃完成開發。

領域專家

領域專家是對業務領域精通的人，一般由客戶、系統分析員等擔當。領域專家作為關鍵的專案角色正是敏捷宣言中“業務人員同開發人員緊密合作”的體現。

核心過程

開發整體物件模型

開發整體物件模型也就是業務建模的階段。不過 FDD 強調的是系統地完整地面向物件建模，這種做法有助於把握整個系統，而不僅僅關注系統中的若干個點。在這一階段，領域專家和首席架構設計師相互配合，完成整體物件模型。

構造特徵列表

完成系統建模後，需要構造一個完整的特徵列表。所謂特徵指的是一個小的、對客戶有價值的功能。採用動作、結果和目標來描述特徵，特徵的粒度最好可以在兩週之內實現。在這一階段中，可以整理出系統的需求。

計劃特徵開發

很少看到有哪個軟體在開發過程中明確包含計劃過程，其實任何一個軟體專案都必須有計劃——無論是過載方法還是敏捷方法。在這一階段中，專案經理根據構造出的特徵列表、特徵間的依賴關係進行計劃，安排開發任務。

特徵設計

在這一階段，主程式設計師將帶領特徵小組對特徵進行詳細設計，為後面的構建做準備。

特徵構建

特徵構建和特徵設計這兩個階段合併起來可以看做特徵的實現階段，這兩個階段反覆地迭代，直到完成全部的開發。

最佳實踐

組成 FDD 的最佳實踐包括：

• 領域物件建模
• 根據特徵進行開發
• 類的個體所有
• 組成特徵小組
• 審查
• 定期構造
• 配置管理
• 結果的可見性

其中，最有特色的莫過於類的個體所有。幾乎所有的開發模型都是程式碼共有，程式設計師們負責開發系統中的全部程式碼，並通過配置管理和變更控制來保持程式碼的一致性。在 FDD 中，將類分配給特定的任何小組，分配給 A 成員的程式碼將全部由 A 來維護，除 A 外的角色都不能修改它，只能使用它。這樣做當然有它的優點：個人對所分配的類很容易保持概念的完整性；開發類程式碼的人肯定是最熟悉這個類的主人；而對這個類的支配感會促使開發人員產生自豪感，從而更出色地完成任務。不過FDD 也提到了類個體所有的缺陷：專案中的依賴關係增強、當 A 需要 B 修改他自己的類時，必須等待 B 完成修改才能使用；類的個體所有增加了員工離職的損失。面對這些優點和缺陷，顯然 FDD 認為類的個體所有對系統開發更有幫助。

除類的個體所有外，審查也是 FDD 中很具特色的一項實踐。不少人都認為審查是非常嚴格的軟體過程所特有的，因為進行審查不但要花費不少的人力和時間，對審查者本身的素質也有要求。然而在 FDD 中，明確地將審查作為一項最佳實踐提出。審查是一種很有效的發現缺陷的手段，但經常被忽視，國內的軟體組織中很少有嚴格審查制度保證軟體質量。有效的審查可以發現很多潛在的問題，而這些問題往往是無法通過測試發現的，例如建模、需求和設計期的缺陷。這些潛在的缺陷大多要到系統測試甚至釋出後才能發現，修正這些缺陷的代價是很大的。

Scrum

Scrum是一個用於開發和維持複雜產品的框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱為一個Sprint，每個Sprint的建議長度是2到4周(網際網路產品研發可以使用1周的Sprint)。在Scrum 中，使用產品 Backlog 來管理產品的需求，產品 Backlog 是一個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。Scrum 團隊總是先開發對客戶具有較高價值的需求。在 Sprint 中，Scrum 團隊從產品 Backlog 中挑選最高優先順序的需求進行開發。挑選的需求在 Sprint 計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為 Sprint backlog。在每個迭代結束時，Scrum 團隊將遞交潛在可交付的產品增量。 Scrum 起源於軟體開發專案，但它適用於任何複雜的或是創新性的專案。

Scrum 的五個活動

產品待辦事項列表梳理

產品待辦事項通常會很大，也很寬泛，而且想法會變來變去、優先順序也會變化，所以產品待辦事項列表梳理是一個始終貫穿整個 Scrum 專案的活動。該活動包含但不限於以下的內容：保持產品待辦事項列表有序、把看起來不再重要的事項移除或者降級、增加或提升湧現出來的或變得更重要的事項、將事項分解成更小的事項、將事項歸併為更大的事項、對事項進行估算。

產品待辦事項列表梳理的一個最大好處是為即將到來的幾個 Sprint 做準備。為此，梳理時會特別關注那些即將被實現的事項。需要考慮不少因素，這包括但不限於以下的內容：

理想情況下，下一個 Sprint 的備選事項都應該提升“商業價值”。開發團隊需要能夠在一個 Sprint 內完成每一個事項。每個人都需要清楚預期產出是什麼。

產品開發決定了，有可能需要其他的技能和輸入。因此，產品待辦事項列表梳理最好是所有團隊成員都參與的活動，而不單單是產品負責人。

Sprint 計劃會議

每個 Sprint 都以 Sprint 計劃會議作為開始，這是一個固定時長的會議，在這個會議中，Scrum 團隊共同選擇和理解在即將到來的 Sprint 中要完成的工作。

整個團隊都要參加 Sprint 計劃會議。針對排好序的產品待辦事項列表（Product Backlog），產品負責人和開發團隊成員討論每個事項，並對該事項達成共識，包括根據當前的“完成的定義”，為了完成該事項所需要完成的所有事情。所有的 Scrum 會議都是限定時長的。Sprint 計劃會議推薦時長是Sprint 中的每週對應兩小時或者更少（例如，一個 Sprint 包含 2 個星期，則 Sprint 計劃會議時長應為4 個小時或者更少）。因為會議是限制時長的,Sprint 計劃會議的成功十分依賴於產品待辦事項列表的質量。這就是產品待辦事項列表梳理十分重要的原因。

在 Scrum 中，Sprint 計劃會議有兩部分：

第一部分：需要完成哪些工作?

在會議的第一部分，產品負責人向開發團隊介紹排好序的產品待辦事項，整個Scrum團隊共同理解這些工作。

Sprint 中需要完成的產品待辦事項數目完全由開發團隊決定。為了決定做多少，開發團隊需要考慮當前產品增量的狀態，團隊過去的工作情況，團隊當前的生產能力，以及排好序的產品待辦事項列表。做多少工作只能由開發團隊決定。產品負責人或任何其他人，都不能給開發團隊強加更多的工作量。

通常 Sprint 都有個目標，稱作 Sprint 目標。這將十分有效地幫助大家更加專注於需要完成的工作的本質，而不必花太多精力去關注那些對於我們需要完成的工作並不重要的小細節。

第二部分：如何完成工作？

在會議的第二部分裡，開發團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增量。他們進行足夠的設計和計劃，從而有信心可以在 Sprint 中完成所有工作。前幾天的工作會被分解成小的單元，每個工作單元不超過一天。之後要完成的工作可以稍大些，以後再對它們進行分解。

決定如何完成工作是開發團隊的職責，決定做什麼則是產品負責人的職責。在計劃會議的第二部分，產品負責人可以繼續留下來回答問題，以及澄清一些誤解。

不管怎樣，團隊應該很容易找到產品負責人。

Sprint 計劃會議的產出。Sprint計劃會議最終需要 Scrum 團隊對 Sprint 需要完成工作的數量和複雜度達成共識，並預期在一個合理的條件範圍內完成它們。開發團隊預測並共同承諾他們要完成的工作量。總而言之：在 Sprint 計劃會議中，開發團隊和產品負責人一起考慮並討論產品待辦事項，確保他們對這些事項的理解，選擇一些他們預測能完成的事項，建立足夠詳細的計劃來確保他們能夠完成這些事項。

最終產生的待辦事項列表就是“Sprint 待辦事項列表（Sprint Backlog）”。

每日 Scrum 會議

開發團隊是自組織的。開發團隊通過每日 Scrum 會議來確認他們仍然可以實現 Sprint 的目標。這個會議每天在同樣的時間和同樣的地點召開。每一個開發團隊成員需要提供以下三點資訊：

• 從上一個每日 Scrum 到現在，我完成了什麼；
• 從現在到下一個每日 Scrum，我計劃完成什麼；
• 有什麼阻礙了我的進展；

每日 Scrum 中可能有簡要的問題澄清和回答，但是不應該有任何話題的討論。通常，許多團隊會在每日 Scrum 之後馬上開會處理他們遇到的任何問題。

每日 Scrum 既不是向管理層彙報，也不是向產品負責人或者 ScrumMaster 彙報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的瞭解。只有 Scrum 團隊的成員，包括 ScrumMaster 和產品負責人，可以在會議中發言。其他感興趣的人可以來旁聽。在必要時，開發團隊會基於會議中的發現重新組織他們的工作來完成 Sprint 的目標。

每日 Scrum 是 Scrum 的一個關鍵組成部分，它可以帶來透明性,信任和更好的績效。它能幫助快速發現問題，並促進團隊的自組織和自立。所有 Scrum 會議都是限定時長的。每日 Scrum 通常不超過15 分鐘。

Sprint 評審會議

Sprint 結束時，Scrum 團隊和相關人員一起評審 Sprint 的產出。Sprint 評審會議的推薦時長是Sprint 中的每一週對應一個小時（例如，一個 Sprint 包含 2 個星期，則 Sprint 評審會議時長為 2 個小時）。

討論圍繞著 Sprint 中完成的產品增量。由於 Sprint 的產出會涉及一些人的“利益”，因此一個明智的做法是邀請他們參加這個會議，這會很有幫助。這個會議是個非正式的會議,幫助大家瞭解我們目前進展到哪裡，並一起討論我們下一步如何推進。每個人都可以在 Sprint 評審會議上發表意見。當然，產品負責人會對未來做出最終的決定，並適當地調整產品待辦事項列表 Product Backlog。

團隊會找到他們自己的方式來開 Sprint 評審會議。通常會演示產品增量,整個小組也會經常討論他們在 Sprint 中觀察到了什麼、有哪些新的產品想法出現。他們還會討論產品待辦事項列表的狀態、可能的完成日期以及在這些日期前能完成什麼。

Sprint 評審會議向每個人展示了當前產品增量的概況。因此，通常都會在 Sprint 評審會議中調整產品待辦事項列表。

Sprint 回顧會議

在每個 Sprint 結束後,Scrum 團隊會聚在一起開 Sprint 回顧會議,目的是回顧一下團隊在流程人際關係以及工具方面做得如何。團隊識別出哪些做得好,哪些做得不好,並找出潛在的改進事項,為將來的改進制定計劃。Sprint 回顧會議的推薦時長是 Sprint 中的每一週對應一個小時（例如，一個 Sprint 包含2 個星期，則 Sprint 回顧會議時長為 2 個小時）。

Scrum 團隊總是在 Scrum 的框架內，改進他們自己的流程。

Scrum 的 5 大價值觀

承諾—願意對目標做出承諾。

專注—把你的心思和能力都用到你承諾的工作上去。

開放—Scrum 把專案中的一切開放給每個人看。

尊重—每個人都有他獨特的背景和經驗。

勇氣—有勇氣做出承諾，履行承諾，接受別人的尊重。

水晶方法

水晶方法（Crystal），是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列，其目的是發展一種提倡“機動性的”方法，包含具有共性的核心元素，每個都含有獨特的角色、過程模式、工作產品和實踐。Crystal 家族實際上是一組經過證明、對不同型別專案非常有效的敏捷過程，它的發明使得敏捷團隊可以根據其專案和環境選擇最合適的 Crystal 家族成員（分為 Crystal Clear，Crystal Yellow，Crystal Orange 和 Crystal Red 分別適用於不同的專案）。水晶方法中，使用頻度較高的是Crystal Clear——透明水晶方法。透明水晶方法，適合於一個小團隊來進行敏捷開發，人數在 6 人以下為宜。

體系特徵

經常交付

任何專案，無論大小、敏捷程度，其最重要的一項體系特徵是每過幾個月就向用戶交付已測試的執行程式碼。如果你使用了此體系特徵，你就會發現，“經常交付”的作用還是很讓人吃驚的。

專案主辦者根據團隊的工作進展獲得重要反饋。使用者有機會發現他們原來的需求是否是他們真正想要的，也有機會將觀察結果反饋到開發當中。開發人員打破未決問題的死結，從而實現對重點的持續關注。團隊得以調整開發和配置的過程，並通過完成這些工作鼓舞團隊的士氣。

反思改進

在我們的開發中，時常會出現這樣那樣的問題，技術難題、各種煩心事等，這會在很大的程度上影響專案的進展。而且，如果其他任務對這項任務有依賴的話，那麼其他的任務也會被推遲，這就很可能會導致專案的失敗。

換句話說，如果，我們能夠經常在迭代會中及時地反思和改進，那麼，這種事情應該是不會發生的，或者說發生了，也能夠很快地找到解決方案去應對它。事實上，從慌亂的日常開發中，抽出一點時間來思考更為行之有效的工作方法就已經足夠了。

滲透式交流

滲透交流就是資訊流向團隊成員的背景聽覺，使得成員就像通過滲透一樣獲取相關資訊。這種交流通常都是通過團隊成員在同一間工作室內工作而實現的。若其中一名成員提出問題，工作室內的其他成員可以選擇關注或不關注的態度，可以加入到這個問題的討論當中來，也可以繼續忙自己的工作。

個人安全

個人安全指的是當你指出困擾你的問題時，你不用擔心受到報復。個人安全非常重要，有了它，團隊可以發現和改正自身的缺點。沒有它，團隊成員們知而不言，缺點則愈發嚴重以至於損害整個團隊。個人安全是邁向信任的第一步。有了信任，團隊協作才能真正地實施，開發效率也就會直線上升的。

焦點

所謂“焦點”，就是確定首先要做什麼，然後安排時間，以平和的心態開展工作。確保團隊成員清楚地瞭解他們自己最重要的任務是什麼，確保他們能夠有充分的時間去完成這些任務。

與專家使用者建立方便的聯絡

與專家使用者持續建立方便的聯絡能夠給團隊提供：對經常交付進行配置以及測試的地方，關於成品質量的快速反饋，關於設計理念的快速反饋，最新的（使用者）需求。

配有自動測試、配置管理和經常整合功能的技術環境

自動測試可以為開發人員在程式碼修改後就可以進行自動測試，並且能夠發現存在的一些 bug，以至開發人員能夠及時地進行修改，對於他們來說，節省了時間，提高了效率，而且還不用為煩人的測試而苦惱。

配置管理系統允許人們不同步地對工作進行檢查，可撤銷更改，並且可以將某一系統設定儲存後進行新系統的釋出，當新系統出現問題，即可還原原系統的設定。

經常整合可以使得團隊在一天之內對系統進行多次整合。其實，團隊越頻繁地對系統進行整合，他們就能夠越快地發現錯誤，堆積到一起的錯誤也會越少，並使他們產生更新的靈感。

最好的團隊是將這三大技術結合成“持續測試整合技術”。這樣做他們可以在幾分鐘內發現因整合所產生的錯誤。

其他敏捷方法

開放式原始碼

開放式原始碼指的是開放原始碼界所用的一種運作方式。開放式原始碼專案有一個特別之處，就是程式開發人員在地域上分佈很廣，這使得它和其他敏捷方法不同，因為一般的敏捷方法都強調專案組成員在同一地點工作。開放原始碼的一個突出特點就是查錯排障（debug）的高度並行性，任何人發現了錯誤都可將改正原始碼的“補丁”檔案發給維護者。然後由維護者將這些“補丁”或是新增的程式碼併入原始碼庫。

ASD 方法

ASD (Adaptive Software Development)方法由 Jim Highsmith提出，其核心是三個非線性的、重疊的開發階段：猜測、合作與學習。