文章目錄

• • 敏捷方法
  • • 1 極限編程 XP
    • • 1．四大價值觀
      • 2．十二個最佳實踐
    • 2 特征驅動開發 FDD
    • • 1．FDD 角色定義
      • 2．核心過程
      • 3．最佳實踐
    • 3 并列爭球法 Scrum
    • • 1．Scrum 的五個活動
      • 2．Scrum 的 5 大價值觀
    • 4 水晶方法 Crystal
    • 5 其他敏捷方法
    • • 開放式源碼
      • 自適應軟件開發 Adaptive Software Development ASD 方法

敏捷方法

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

盡早地、持續地向客戶交付有價值的軟件對開發人員來說是最重要的。

擁抱變化，即使在開發的后期。敏捷過程能夠駕馭變化，保持客戶的競爭力。

經常交付可工作的軟件，從幾周到幾個月，時間范圍越小越好。

在整個項目中，業務人員和開發者緊密合作。

圍繞士氣高昂的團隊進行開發，為團隊成員提供適宜的環境，滿足他們的需要，并給予足夠的信任。

在團隊中，最有效率的、也是效果最好的溝通方式是面對面地交流。

可以工作的軟件是進度首要的度量方式。

可持續地開發。投資人、開發團隊和用戶應該保持固定的節奏。

不斷追求優秀的技術和良好的設計有助于提高敏捷性。

要簡單，盡可能減少工作量。減少工作量的藝術是非常重要的。

最好的架構、需求和設計都來自于一個自我組織的團隊。

團隊要定期地總結如何能夠更有效率，然后相應地自我調整。

至此，敏捷軟件聯盟建立起來，敏捷軟件開發方法進入了大發展的時代。這份宣言也就是敏捷方法的燈塔，所有的敏捷方法都在向這個方向努力。目前已形成多種敏捷方法，其中 XP 傳播最為廣泛，為此，本節主要介紹 XP，其次簡單介紹另外幾種很有特色的開發模型。

1 極限編程 XP

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

XP 是一種輕量（敏捷）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟件開發方式。與其他方法論相比，其最大的不同在于：

（1）在更短的周期內，更早地提供具體、持續的反饋信息。

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

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

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

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

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

（7）盡可能達到程序員短期利益和項目長期利益的平衡。

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

1．四大價值觀

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

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

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

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

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

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

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

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

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

2．十二個最佳實踐

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

（1）計劃游戲。計劃游戲的主要思想就是先快速地制定一份概要的計劃，然后，隨著項目細節的不斷清晰，再逐步完善這份計劃。計劃游戲產生的結果是一套用戶故事及后續的一兩次迭代的概要計劃。

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

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

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

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

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

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

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

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

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

（9）持續集成。在前面談到小型發布、重構、結對編程、集體代碼所有制等最佳實踐的時候，多次提到“持續集成”，可以說持續集成是這些最佳實踐的基本支撐條件。

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

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

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

有句經典名言“1+1>2”最適合表達 XP 的觀點，Kent Beck 認為，XP 方法的最大價值在于，在項目中融會貫通地運用這 12 個最佳實踐，而非單獨使用。當然，可以使用其中的一些實踐，但這并不意味著就應用了 XP 方法。XP 方法真正能夠發揮其效能，就必須完整地運用 12 個實踐。

2 特征驅動開發 FDD

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

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

1．FDD 角色定義

FDD 認為，有效的軟件開發不可缺少的三個要素是：人、過程和技術。軟件開發不能沒有過程，也不能沒有技術，但軟件開發中最重要的是人。個人的生產率和人的技能將會決定項目的成敗。為了讓項目團隊能夠緊密地工作在一起，FDD 定義了 6 種關鍵的項目角色：

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

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

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

（4）主程序員。主程序員將帶領一個小組完成特征的詳細設計和構建的工作，一般要求主程序員具有一定的工作經驗，并能夠帶動小組的工作。

（5）程序員。若干個程序員在主程序員的帶領下形成一個開發小組，按照特征開發計劃完成開發。

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

根據項目規模的大小，有些角色是可以重復的。例如在一個小規模項目中，項目經理自身的能力很強，他就可以同時擔當項目經理、首席架構設計師和開發經理的角色。

2．核心過程

FDD 共有 5 個核心過程，如圖 6-6 所示。

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

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

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

（4）特征設計。在這一階段，主程序員將帶領特征小組對特征進行詳細設計，為后面的構建做準備。

（5）特征構建。特征構建和特征設計這兩個階段合并起來可以看做特征的實現階段，這兩個階段反復地迭代，直到完成全部的開發。

3．最佳實踐

組成 FDD 的最佳實踐包括：領域對象建模、根據特征進行開發、類的個體所有、組成特征小組、審查、定期構造、配置管理、結果的可見性。

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

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

3 并列爭球法 Scrum

并列爭球法使用了迭代的方法，其中，把每段時間（30天）一次的迭代稱為一個“沖刺”，并按需求的優先級別來實現產品，多個自組織和自治的小組并行地遞增實現產品。

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

1．Scrum 的五個活動

Scrum 主要包括：產品待辦事項列表梳理、Sprint 計劃會議、每日 Scrum 會議、Sprint 評審會議、Sprint 回顧會議等五個活動。

（1）產品待辦事項列表梳理

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

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

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

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

（2）Sprint 計劃會議

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

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

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

決定在 Sprint 中需要完成哪些工作

決定這些工作如何完成

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

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

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

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

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

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

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

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

Sprint 計劃會議的產出。Sprint計劃會議最終需要 Scrum 團隊對 Sprint 需要完成工作的數量和復雜度達成共識，并預期在一個合理的條件范圍內完成它們。開發團隊預測并共同承諾他們要完成的工作量?？偠灾?#xff1a;在 Sprint 計劃會議中，開發團隊和產品負責人一起考慮并討論產品待辦事項，確保他們對這些事項的理解，選擇一些他們預測能完成的事項，創建足夠詳細的計劃來確保他們能夠完成這些事項。

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

（3）每日 Scrum 會議

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

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

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

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

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

（4）Sprint 評審會議

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

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

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

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

（5）Sprint 回顧會議

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

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

2．Scrum 的 5 大價值觀

Scrum 的 5 大價值觀為：

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

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

開放—Scrum 把項目中的一切開放給每個人看。

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

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

4 水晶方法 Crystal

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

透明水晶方法有七大體系特征：

（1）經常交付

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

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

（2）反思改進

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

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

（3）滲透式交流

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

（4）個人安全

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

（5）焦點

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

（6）與專家用戶建立方便的聯系

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

（7）配有自動測試、配置管理和經常集成功能的技術環境

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

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

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

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

5 其他敏捷方法

除了上面介紹的幾種敏捷方法，以下敏捷方法我們也需要掌握其基本特征。

開放式源碼

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

自適應軟件開發 Adaptive Software Development ASD 方法

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

參考文章：開發方法—敏捷方法

總結

以上是生活随笔為你收集整理的【中级软考】什么是“敏捷过程的开发方法（敏捷方法agile）“（极限编程XP、特征驱动开发FDD、并列争球法Scrum、水晶法Crystal、开放源码法、自适应软件开发 ASD方法）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。