文章目錄

• • 敏捷方法
  • • 1 極限編程 XP
    • • 1．四大價(jià)值觀
      • 2．十二個(gè)最佳實(shí)踐
    • 2 特征驅(qū)動(dòng)開發(fā) FDD
    • • 1．FDD 角色定義
      • 2．核心過(guò)程
      • 3．最佳實(shí)踐
    • 3 并列爭(zhēng)球法 Scrum
    • • 1．Scrum 的五個(gè)活動(dòng)
      • 2．Scrum 的 5 大價(jià)值觀
    • 4 水晶方法 Crystal
    • 5 其他敏捷方法
    • • 開放式源碼
      • 自適應(yīng)軟件開發(fā) Adaptive Software Development ASD 方法

敏捷方法

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

盡早地、持續(xù)地向客戶交付有價(jià)值的軟件對(duì)開發(fā)人員來(lái)說(shuō)是最重要的。

擁抱變化，即使在開發(fā)的后期。敏捷過(guò)程能夠駕馭變化，保持客戶的競(jìng)爭(zhēng)力。

經(jīng)常交付可工作的軟件，從幾周到幾個(gè)月，時(shí)間范圍越小越好。

在整個(gè)項(xiàng)目中，業(yè)務(wù)人員和開發(fā)者緊密合作。

圍繞士氣高昂的團(tuán)隊(duì)進(jìn)行開發(fā)，為團(tuán)隊(duì)成員提供適宜的環(huán)境，滿足他們的需要，并給予足夠的信任。

在團(tuán)隊(duì)中，最有效率的、也是效果最好的溝通方式是面對(duì)面地交流。

可以工作的軟件是進(jìn)度首要的度量方式。

可持續(xù)地開發(fā)。投資人、開發(fā)團(tuán)隊(duì)和用戶應(yīng)該保持固定的節(jié)奏。

不斷追求優(yōu)秀的技術(shù)和良好的設(shè)計(jì)有助于提高敏捷性。

要簡(jiǎn)單，盡可能減少工作量。減少工作量的藝術(shù)是非常重要的。

最好的架構(gòu)、需求和設(shè)計(jì)都來(lái)自于一個(gè)自我組織的團(tuán)隊(duì)。

團(tuán)隊(duì)要定期地總結(jié)如何能夠更有效率，然后相應(yīng)地自我調(diào)整。

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

1 極限編程 XP

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

XP 是一種輕量（敏捷）、高效、低風(fēng)險(xiǎn)、柔性、可預(yù)測(cè)、科學(xué)而且充滿樂(lè)趣的軟件開發(fā)方式。與其他方法論相比，其最大的不同在于：

（1）在更短的周期內(nèi)，更早地提供具體、持續(xù)的反饋信息。

（2）迭代地進(jìn)行計(jì)劃編制，首先在最開始迅速生成一個(gè)總體計(jì)劃，然后在整個(gè)項(xiàng)目開發(fā)過(guò)程中不斷地發(fā)展它。

（3）依賴于自動(dòng)測(cè)試程序來(lái)監(jiān)控開發(fā)進(jìn)度，并及早地捕獲缺陷。

（4）依賴于口頭交流、測(cè)試和源程序進(jìn)行溝通。

（5）倡導(dǎo)持續(xù)的、演化式的設(shè)計(jì)。

（6）依賴于開發(fā)團(tuán)隊(duì)內(nèi)部的緊密協(xié)作。

（7）盡可能達(dá)到程序員短期利益和項(xiàng)目長(zhǎng)期利益的平衡。

XP 由價(jià)值觀、原則、實(shí)踐和行為四個(gè)部分組成，它們彼此相互依賴、關(guān)聯(lián)，并通過(guò)行為貫穿于整個(gè)生命周期。

1．四大價(jià)值觀

XP 的核心是其總結(jié)的溝通、簡(jiǎn)單、反饋、勇氣四大價(jià)值觀，它們是 XP 的基礎(chǔ)，也是XP 的靈魂。

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

XP 方法認(rèn)為，如果小組成員之間無(wú)法做到持續(xù)的、無(wú)間斷的交流，那么協(xié)作就無(wú)從談起。從這個(gè)角度來(lái)看，通過(guò)文檔、報(bào)表等人工制品進(jìn)行交流，具有很大的局限性。因此， XP 組合了諸如結(jié)對(duì)編程這樣的最佳實(shí)踐，鼓勵(lì)大家進(jìn)行口頭交流、通過(guò)交流解決問(wèn)題，提高效率。

（2）簡(jiǎn)單。XP 方法在工作中秉承“夠用即好”的思路，也就是盡量地簡(jiǎn)單化，只要今天夠用就行，不考慮明天會(huì)出現(xiàn)的新問(wèn)題。這一點(diǎn)看上去十分容易，但要真正做到保持簡(jiǎn)單的工作其實(shí)是很難的，因?yàn)樵趥鹘y(tǒng)的開發(fā)方法中，都要求開發(fā)人員對(duì)未來(lái)做一些預(yù)先規(guī)劃，以便對(duì)今后可能發(fā)生的變化預(yù)留一些擴(kuò)展空間。

溝通和簡(jiǎn)單之間還有一種相當(dāng)微妙的互相支持關(guān)系。一方面，團(tuán)隊(duì)成員之間溝通得越多，就越容易明白哪些工作需要做，哪些工作不需要做；另一方面，系統(tǒng)越簡(jiǎn)單，需要溝通的內(nèi)容也就越少，溝通也將更加全面。

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

反饋與溝通有著良好的配合，及時(shí)和良好的反饋有助于溝通。而簡(jiǎn)單的系統(tǒng)，更有利于測(cè)試和反饋。

（4）勇氣。在應(yīng)用 XP 方法時(shí)，每時(shí)每刻都在應(yīng)對(duì)變化：由于溝通良好，會(huì)有更多需求變更的機(jī)會(huì)；由于時(shí)刻保持系統(tǒng)的簡(jiǎn)單，新的變化會(huì)帶來(lái)一些重新開發(fā)的需要；由于反饋及時(shí)，會(huì)有更多中間打斷思路的新需求。總之，這一切使得開發(fā)團(tuán)隊(duì)處于變化之中，因此，這時(shí)就需要有勇氣來(lái)面對(duì)快速開發(fā)，面對(duì)可能的重新開發(fā)。勇氣可以來(lái)源于溝通，因?yàn)樗沟酶唢L(fēng)險(xiǎn)、高回報(bào)的試驗(yàn)成為可能；勇氣可以來(lái)源于簡(jiǎn)單，因?yàn)槊鎸?duì)簡(jiǎn)單的系統(tǒng)，更容易鼓起勇氣；勇氣可以來(lái)源于反饋，因?yàn)榭梢约皶r(shí)獲得每一步前進(jìn)的狀態(tài)（自動(dòng)測(cè)試），會(huì)讓人更勇于重構(gòu)代碼。

在 XP 的四大價(jià)值觀之下，隱藏著一種更深刻的東西，那就是尊重。因?yàn)檫@一切都建立在團(tuán)隊(duì)成員之間相互關(guān)心、相互理解的基礎(chǔ)之上。

2．十二個(gè)最佳實(shí)踐

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

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

（2）小型發(fā)布。XP 方法秉承的是“持續(xù)集成、小步快走”的哲學(xué)思維，也就是說(shuō)每一次發(fā)布的版本應(yīng)該盡可能地小，當(dāng)然前提條件是每個(gè)版本有足夠的商業(yè)價(jià)值，值得發(fā)布。由于小型發(fā)布可以使得集成更頻繁，客戶獲得的中間結(jié)果越頻繁，反饋也就越頻繁，客戶就能夠?qū)崟r(shí)地了解項(xiàng)目的進(jìn)展情況，從而提出更多的意見，以便在下一次迭代中計(jì)劃進(jìn)去，以實(shí)現(xiàn)更高的客戶滿意度。

（3）隱喻。相對(duì)而言，隱喻比較令人費(fèi)解。根據(jù)詞典中的解釋是：“一種語(yǔ)言的表達(dá)手段，它用來(lái)暗示字面意義不相似的事物之間的相似之處”。隱喻常用于四個(gè)方面：尋求共識(shí)、發(fā)明共享語(yǔ)匯、創(chuàng)新的武器、描述架構(gòu)。

如果能夠找到合適的隱喻是十分快樂(lè)的，但并不是每一種情況都可以找到恰當(dāng)?shù)碾[喻，因此，沒有必要去強(qiáng)求，而是順其自然。

（4）簡(jiǎn)單設(shè)計(jì)。強(qiáng)調(diào)簡(jiǎn)單的價(jià)值觀，引出了簡(jiǎn)單性假設(shè)原則，落到實(shí)處就是“簡(jiǎn)單設(shè)計(jì)”實(shí)踐。這個(gè)實(shí)踐看上去似乎很容易理解，但卻又經(jīng)常被誤解，許多批評(píng)者就指責(zé) XP 忽略設(shè)計(jì)是不正確的。其實(shí)，XP 的簡(jiǎn)單設(shè)計(jì)實(shí)踐并不是要忽略設(shè)計(jì)，而是認(rèn)為設(shè)計(jì)不應(yīng)該在編碼之前一次性完成，因?yàn)槟菢又荒芙⒃凇扒闆r不會(huì)發(fā)生變化”或者“我們可以預(yù)見所有的變化”之類的謊言的基礎(chǔ)上。

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

（6）重構(gòu)。重構(gòu)是一種對(duì)代碼進(jìn)行改進(jìn)而不影響功能實(shí)現(xiàn)的技術(shù)，XP 需要開發(fā)人員在“聞到代碼的壞味道”時(shí)，就有重構(gòu)代碼的勇氣。重構(gòu)的目的是降低變化引發(fā)的風(fēng)險(xiǎn)、使得代碼優(yōu)化更加容易。

（7）結(jié)對(duì)編程。從 20 世紀(jì) 60 年代開始，就有類似的實(shí)踐在進(jìn)行，長(zhǎng)年以來(lái)的研究結(jié)果給出的結(jié)論是，結(jié)對(duì)編程的效率反而比單獨(dú)編程更高。一開始雖然會(huì)犧牲一些速度，但慢慢地，開發(fā)速度會(huì)逐漸加快。究其原因，主要是結(jié)對(duì)編程大大降低了溝通的成本，提高了工作的質(zhì)量。結(jié)對(duì)編程技術(shù)被譽(yù)于 XP 保證工作質(zhì)量、強(qiáng)調(diào)人文主義的一個(gè)最典型的實(shí)踐，應(yīng)用得當(dāng)還能夠使開發(fā)團(tuán)隊(duì)協(xié)作更加順暢、知識(shí)交流與共享更加頻繁、團(tuán)隊(duì)穩(wěn)定性也會(huì)更加牢固。

（8）集體代碼所有制。由于 XP 方法鼓勵(lì)團(tuán)隊(duì)進(jìn)行結(jié)對(duì)編程，而且認(rèn)為結(jié)對(duì)編程的組合應(yīng)該動(dòng)態(tài)地搭配，根據(jù)任務(wù)的不同、專業(yè)技能的不同進(jìn)行最優(yōu)組合。因此，每一個(gè)人都會(huì)遇到不同的代碼，代碼的所有制就不再適合于私有，因?yàn)槟菢訒?huì)給修改工作帶來(lái)巨大的不便。所謂集體代碼所有制，就是團(tuán)隊(duì)中的每個(gè)成員都擁有對(duì)代碼進(jìn)行改進(jìn)的權(quán)利，每個(gè)人都擁有全部代碼，也都需要對(duì)全部代碼負(fù)責(zé)。同時(shí)，XP 強(qiáng)調(diào)代碼是誰(shuí)破壞的（修改后出現(xiàn)問(wèn)題），就應(yīng)該由誰(shuí)來(lái)修復(fù)。

集體代碼所有制是 XP 與其他敏捷方法的一個(gè)較大不同，也是從另一個(gè)側(cè)面體現(xiàn)了 XP 中蘊(yùn)含的很深厚的編碼情節(jié)。

（9）持續(xù)集成。在前面談到小型發(fā)布、重構(gòu)、結(jié)對(duì)編程、集體代碼所有制等最佳實(shí)踐的時(shí)候，多次提到“持續(xù)集成”，可以說(shuō)持續(xù)集成是這些最佳實(shí)踐的基本支撐條件。

（10）每周工作 40 小時(shí)。這是最讓開發(fā)人員開心、管理者反對(duì)的一個(gè)最佳實(shí)踐了，加班、再加班早已成為開發(fā)人員的家常便飯，也是管理者最常使用的一種策略。而 XP 方法認(rèn)為，加班最終會(huì)扼殺團(tuán)隊(duì)的積極性，最終導(dǎo)致項(xiàng)目的失敗，這也充分體現(xiàn)了 XP 方法關(guān)注人的因素比關(guān)注過(guò)程的因素更多一些。不過(guò)，有一點(diǎn)是需要解釋的，“每周工作 40 小時(shí)”中的“40”不是一個(gè)絕對(duì)數(shù)，它所代表的意思是團(tuán)隊(duì)?wèi)?yīng)該保證按照“正常的時(shí)間” 進(jìn)行工作。

（11）現(xiàn)場(chǎng)客戶。為了保證開發(fā)出來(lái)的結(jié)果與客戶的預(yù)想接近，XP 方法認(rèn)為最重要的是需要將客戶請(qǐng)到開發(fā)現(xiàn)場(chǎng)。就像計(jì)劃游戲中提到過(guò)的，在 XP 項(xiàng)目中，應(yīng)該時(shí)刻保證客戶負(fù)責(zé)業(yè)務(wù)決策，開發(fā)團(tuán)隊(duì)負(fù)責(zé)技術(shù)決策。因此，在項(xiàng)目中有客戶在現(xiàn)場(chǎng)明確用戶故事，并做出相應(yīng)的業(yè)務(wù)決策，對(duì)于 XP 項(xiàng)目而言有著十分重要的意義。

（12）編碼標(biāo)準(zhǔn)。擁有編碼標(biāo)準(zhǔn)可以避免團(tuán)隊(duì)在一些與開發(fā)進(jìn)度無(wú)關(guān)的細(xì)枝末節(jié)問(wèn)題上發(fā)生爭(zhēng)論，而且會(huì)給重構(gòu)、結(jié)對(duì)編程帶來(lái)很大的麻煩。不過(guò)，XP 方法的編碼標(biāo)準(zhǔn)的目的不是創(chuàng)建一個(gè)事無(wú)巨細(xì)的規(guī)則列表，而是要能夠提供一個(gè)確保代碼清晰，便于交流的指導(dǎo)方針。

有句經(jīng)典名言“1+1>2”最適合表達(dá) XP 的觀點(diǎn)，Kent Beck 認(rèn)為，XP 方法的最大價(jià)值在于，在項(xiàng)目中融會(huì)貫通地運(yùn)用這 12 個(gè)最佳實(shí)踐，而非單獨(dú)使用。當(dāng)然，可以使用其中的一些實(shí)踐，但這并不意味著就應(yīng)用了 XP 方法。XP 方法真正能夠發(fā)揮其效能，就必須完整地運(yùn)用 12 個(gè)實(shí)踐。

2 特征驅(qū)動(dòng)開發(fā) FDD

FDD 方法來(lái)自于一個(gè)大型的新加坡銀行項(xiàng)目。FDD 的創(chuàng)立者 Jeff De Luca 和 Peter Coad 分別是這個(gè)項(xiàng)目的項(xiàng)目經(jīng)理和首席架構(gòu)設(shè)計(jì)師。在 Jeff 和 Peter 接手項(xiàng)目時(shí)，客戶已經(jīng)經(jīng)歷了一次項(xiàng)目的失敗，從用戶到高層都對(duì)這個(gè)項(xiàng)目持懷疑的態(tài)度，項(xiàng)目組士氣低落。隨后， Jeff 和 Peter 采用了特征驅(qū)動(dòng)、彩色建模等方法，最終獲得了巨大成功。

FDD 是也是一個(gè)迭代的開發(fā)模型。FDD的每一步都強(qiáng)調(diào)質(zhì)量，不斷地交付可運(yùn)行的軟件，并以很小的開發(fā)提供精確的項(xiàng)目進(jìn)度報(bào)告和狀態(tài)信息。同敏捷方法一樣，FDD 弱化了過(guò)程在軟件開發(fā)中的地位。雖然 FDD 中也定義了開發(fā)的過(guò)程，不過(guò)一個(gè)幾頁(yè)紙就能完全描述的過(guò)程深受開發(fā)者的喜愛。

1．FDD 角色定義

FDD 認(rèn)為，有效的軟件開發(fā)不可缺少的三個(gè)要素是：人、過(guò)程和技術(shù)。軟件開發(fā)不能沒有過(guò)程，也不能沒有技術(shù)，但軟件開發(fā)中最重要的是人。個(gè)人的生產(chǎn)率和人的技能將會(huì)決定項(xiàng)目的成敗。為了讓項(xiàng)目團(tuán)隊(duì)能夠緊密地工作在一起，FDD 定義了 6 種關(guān)鍵的項(xiàng)目角色：

（1）項(xiàng)目經(jīng)理。項(xiàng)目經(jīng)理是開發(fā)的組織者，但項(xiàng)目經(jīng)理不是開發(fā)的主宰。對(duì)于項(xiàng)目團(tuán)隊(duì)來(lái)說(shuō)，項(xiàng)目經(jīng)理應(yīng)該是團(tuán)隊(duì)的保護(hù)屏障。他將同團(tuán)隊(duì)外界（如高層領(lǐng)導(dǎo)、人事甚至寫字樓的物業(yè)管理員）進(jìn)行溝通，努力為團(tuán)隊(duì)提供一個(gè)適宜的開發(fā)環(huán)境。

（2）首席架構(gòu)設(shè)計(jì)師。不難理解，首席架構(gòu)設(shè)計(jì)師負(fù)責(zé)系統(tǒng)架構(gòu)的設(shè)計(jì)。

（3）開發(fā)經(jīng)理。開發(fā)經(jīng)理負(fù)責(zé)團(tuán)隊(duì)日常的開發(fā)，解決開發(fā)中出現(xiàn)的技術(shù)問(wèn)題與資源沖突。

（4）主程序員。主程序員將帶領(lǐng)一個(gè)小組完成特征的詳細(xì)設(shè)計(jì)和構(gòu)建的工作，一般要求主程序員具有一定的工作經(jīng)驗(yàn)，并能夠帶動(dòng)小組的工作。

（5）程序員。若干個(gè)程序員在主程序員的帶領(lǐng)下形成一個(gè)開發(fā)小組，按照特征開發(fā)計(jì)劃完成開發(fā)。

（6）領(lǐng)域?qū)＜摇ｎI(lǐng)域?qū)＜沂菍?duì)業(yè)務(wù)領(lǐng)域精通的人，一般由客戶、系統(tǒng)分析員等擔(dān)當(dāng)。領(lǐng)域?qū)＜易鳛殛P(guān)鍵的項(xiàng)目角色正是敏捷宣言中“業(yè)務(wù)人員同開發(fā)人員緊密合作”的體現(xiàn)。

根據(jù)項(xiàng)目規(guī)模的大小，有些角色是可以重復(fù)的。例如在一個(gè)小規(guī)模項(xiàng)目中，項(xiàng)目經(jīng)理自身的能力很強(qiáng)，他就可以同時(shí)擔(dān)當(dāng)項(xiàng)目經(jīng)理、首席架構(gòu)設(shè)計(jì)師和開發(fā)經(jīng)理的角色。

2．核心過(guò)程

FDD 共有 5 個(gè)核心過(guò)程，如圖 6-6 所示。

（1）開發(fā)整體對(duì)象模型。開發(fā)整體對(duì)象模型也就是業(yè)務(wù)建模的階段。不過(guò) FDD 強(qiáng)調(diào)的是系統(tǒng)地完整地面向?qū)ο蠼?#xff0c;這種做法有助于把握整個(gè)系統(tǒng)，而不僅僅關(guān)注系統(tǒng)中的若干個(gè)點(diǎn)。在這一階段，領(lǐng)域?qū)＜液褪紫軜?gòu)設(shè)計(jì)師相互配合，完成整體對(duì)象模型。

（2）構(gòu)造特征列表。完成系統(tǒng)建模后，需要構(gòu)造一個(gè)完整的特征列表。所謂特征指的是一個(gè)小的、對(duì)客戶有價(jià)值的功能。采用動(dòng)作、結(jié)果和目標(biāo)來(lái)描述特征，特征的粒度最好可以在兩周之內(nèi)實(shí)現(xiàn)。在這一階段中，可以整理出系統(tǒng)的需求。

（3）計(jì)劃特征開發(fā)。很少看到有哪個(gè)軟件在開發(fā)過(guò)程中明確包含計(jì)劃過(guò)程，其實(shí)任何一個(gè)軟件項(xiàng)目都必須有計(jì)劃——無(wú)論是重載方法還是敏捷方法。在這一階段中，項(xiàng)目經(jīng)理根據(jù)構(gòu)造出的特征列表、特征間的依賴關(guān)系進(jìn)行計(jì)劃，安排開發(fā)任務(wù)。

（4）特征設(shè)計(jì)。在這一階段，主程序員將帶領(lǐng)特征小組對(duì)特征進(jìn)行詳細(xì)設(shè)計(jì)，為后面的構(gòu)建做準(zhǔn)備。

（5）特征構(gòu)建。特征構(gòu)建和特征設(shè)計(jì)這兩個(gè)階段合并起來(lái)可以看做特征的實(shí)現(xiàn)階段，這兩個(gè)階段反復(fù)地迭代，直到完成全部的開發(fā)。

3．最佳實(shí)踐

組成 FDD 的最佳實(shí)踐包括：領(lǐng)域?qū)ο蠼！⒏鶕?jù)特征進(jìn)行開發(fā)、類的個(gè)體所有、組成特征小組、審查、定期構(gòu)造、配置管理、結(jié)果的可見性。

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

除類的個(gè)體所有外，審查也是 FDD 中很具特色的一項(xiàng)實(shí)踐。不少人都認(rèn)為審查是非常嚴(yán)格的軟件過(guò)程所特有的，因?yàn)檫M(jìn)行審查不但要花費(fèi)不少的人力和時(shí)間，對(duì)審查者本身的素質(zhì)也有要求。然而在 FDD 中，明確地將審查作為一項(xiàng)最佳實(shí)踐提出。審查是一種很有效的發(fā)現(xiàn)缺陷的手段，但經(jīng)常被忽視，國(guó)內(nèi)的軟件組織中很少有嚴(yán)格審查制度保證軟件質(zhì)量。有效的審查可以發(fā)現(xiàn)很多潛在的問(wèn)題，而這些問(wèn)題往往是無(wú)法通過(guò)測(cè)試發(fā)現(xiàn)的，例如建模、需求和設(shè)計(jì)期的缺陷。這些潛在的缺陷大多要到系統(tǒng)測(cè)試甚至發(fā)布后才能發(fā)現(xiàn)，修正這些缺陷的代價(jià)是很大的。

3 并列爭(zhēng)球法 Scrum

并列爭(zhēng)球法使用了迭代的方法，其中，把每段時(shí)間（30天）一次的迭代稱為一個(gè)“沖刺”，并按需求的優(yōu)先級(jí)別來(lái)實(shí)現(xiàn)產(chǎn)品，多個(gè)自組織和自治的小組并行地遞增實(shí)現(xiàn)產(chǎn)品。

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

1．Scrum 的五個(gè)活動(dòng)

Scrum 主要包括：產(chǎn)品待辦事項(xiàng)列表梳理、Sprint 計(jì)劃會(huì)議、每日 Scrum 會(huì)議、Sprint 評(píng)審會(huì)議、Sprint 回顧會(huì)議等五個(gè)活動(dòng)。

（1）產(chǎn)品待辦事項(xiàng)列表梳理

產(chǎn)品待辦事項(xiàng)通常會(huì)很大，也很寬泛，而且想法會(huì)變來(lái)變?nèi)ァ?yōu)先級(jí)也會(huì)變化，所以產(chǎn)品待辦事項(xiàng)列表梳理是一個(gè)始終貫穿整個(gè) Scrum 項(xiàng)目的活動(dòng)。該活動(dòng)包含但不限于以下的內(nèi)容：保持產(chǎn)品待辦事項(xiàng)列表有序、把看起來(lái)不再重要的事項(xiàng)移除或者降級(jí)、增加或提升涌現(xiàn)出來(lái)的或變得更重要的事項(xiàng)、將事項(xiàng)分解成更小的事項(xiàng)、將事項(xiàng)歸并為更大的事項(xiàng)、對(duì)事項(xiàng)進(jìn)行估算。

產(chǎn)品待辦事項(xiàng)列表梳理的一個(gè)最大好處是為即將到來(lái)的幾個(gè) Sprint 做準(zhǔn)備。為此，梳理時(shí)會(huì)特別關(guān)注那些即將被實(shí)現(xiàn)的事項(xiàng)。需要考慮不少因素，這包括但不限于以下的內(nèi)容：

理想情況下，下一個(gè) Sprint 的備選事項(xiàng)都應(yīng)該提升“商業(yè)價(jià)值”。開發(fā)團(tuán)隊(duì)需要能夠在一個(gè)Sprint 內(nèi)完成每一個(gè)事項(xiàng)。每個(gè)人都需要清楚預(yù)期產(chǎn)出是什么。

產(chǎn)品開發(fā)決定了，有可能需要其他的技能和輸入。因此，產(chǎn)品待辦事項(xiàng)列表梳理最好是所有團(tuán)隊(duì)成員都參與的活動(dòng)，而不單單是產(chǎn)品負(fù)責(zé)人。

（2）Sprint 計(jì)劃會(huì)議

每個(gè) Sprint 都以 Sprint 計(jì)劃會(huì)議作為開始，這是一個(gè)固定時(shí)長(zhǎng)的會(huì)議，在這個(gè)會(huì)議中，Scrum 團(tuán)隊(duì)共同選擇和理解在即將到來(lái)的 Sprint 中要完成的工作。

整個(gè)團(tuán)隊(duì)都要參加 Sprint 計(jì)劃會(huì)議。針對(duì)排好序的產(chǎn)品待辦事項(xiàng)列表（Product Backlog），產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)成員討論每個(gè)事項(xiàng)，并對(duì)該事項(xiàng)達(dá)成共識(shí)，包括根據(jù)當(dāng)前的“完成的定義”，為了完成該事項(xiàng)所需要完成的所有事情。所有的 Scrum 會(huì)議都是限定時(shí)長(zhǎng)的。Sprint 計(jì)劃會(huì)議推薦時(shí)長(zhǎng)是 Sprint 中的每周對(duì)應(yīng)兩小時(shí)或者更少（例如，一個(gè) Sprint 包含 2 個(gè)星期，則Sprint 計(jì)劃會(huì)議時(shí)長(zhǎng)應(yīng)為 4 個(gè)小時(shí)或者更少）。因?yàn)闀?huì)議是限制時(shí)長(zhǎng)的,Sprint 計(jì)劃會(huì)議的成功十分依賴于產(chǎn)品待辦事項(xiàng)列表的質(zhì)量。這就是產(chǎn)品待辦事項(xiàng)列表梳理十分重要的原因。

在 Scrum 中，Sprint 計(jì)劃會(huì)議有兩部分：

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

決定這些工作如何完成

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

在會(huì)議的第一部分，產(chǎn)品負(fù)責(zé)人向開發(fā)團(tuán)隊(duì)介紹排好序的產(chǎn)品待辦事項(xiàng)，整個(gè)Scrum團(tuán)隊(duì)共同理解這些工作。

Sprint 中需要完成的產(chǎn)品待辦事項(xiàng)數(shù)目完全由開發(fā)團(tuán)隊(duì)決定。為了決定做多少，開發(fā)團(tuán)隊(duì)需要考慮當(dāng)前產(chǎn)品增量的狀態(tài)，團(tuán)隊(duì)過(guò)去的工作情況，團(tuán)隊(duì)當(dāng)前的生產(chǎn)能力，以及排好序的產(chǎn)品待辦事項(xiàng)列表。做多少工作只能由開發(fā)團(tuán)隊(duì)決定。產(chǎn)品負(fù)責(zé)人或任何其他人，都不能給開發(fā)團(tuán)隊(duì)強(qiáng)加更多的工作量。

通常 Sprint 都有個(gè)目標(biāo)，稱作 Sprint 目標(biāo)。這將十分有效地幫助大家更加專注于需要完成的工作的本質(zhì)，而不必花太多精力去關(guān)注那些對(duì)于我們需要完成的工作并不重要的小細(xì)節(jié)。

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

在會(huì)議的第二部分里，開發(fā)團(tuán)隊(duì)需要根據(jù)當(dāng)前的“完成的定義”一起決定如何實(shí)現(xiàn)下一個(gè)產(chǎn)品增量。他們進(jìn)行足夠的設(shè)計(jì)和計(jì)劃，從而有信心可以在 Sprint 中完成所有工作。前幾天的工作會(huì)被分解成小的單元，每個(gè)工作單元不超過(guò)一天。之后要完成的工作可以稍大些，以后再對(duì)它們進(jìn)行分解。

決定如何完成工作是開發(fā)團(tuán)隊(duì)的職責(zé)，決定做什么則是產(chǎn)品負(fù)責(zé)人的職責(zé)。在計(jì)劃會(huì)議的第二部分，產(chǎn)品負(fù)責(zé)人可以繼續(xù)留下來(lái)回答問(wèn)題，以及澄清一些誤解。

不管怎樣，團(tuán)隊(duì)?wèi)?yīng)該很容易找到產(chǎn)品負(fù)責(zé)人。

Sprint 計(jì)劃會(huì)議的產(chǎn)出。Sprint計(jì)劃會(huì)議最終需要 Scrum 團(tuán)隊(duì)對(duì) Sprint 需要完成工作的數(shù)量和復(fù)雜度達(dá)成共識(shí)，并預(yù)期在一個(gè)合理的條件范圍內(nèi)完成它們。開發(fā)團(tuán)隊(duì)預(yù)測(cè)并共同承諾他們要完成的工作量。總而言之：在 Sprint 計(jì)劃會(huì)議中，開發(fā)團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人一起考慮并討論產(chǎn)品待辦事項(xiàng)，確保他們對(duì)這些事項(xiàng)的理解，選擇一些他們預(yù)測(cè)能完成的事項(xiàng)，創(chuàng)建足夠詳細(xì)的計(jì)劃來(lái)確保他們能夠完成這些事項(xiàng)。

最終產(chǎn)生的待辦事項(xiàng)列表就是“Sprint 待辦事項(xiàng)列表（Sprint Backlog）”。

（3）每日 Scrum 會(huì)議

開發(fā)團(tuán)隊(duì)是自組織的。開發(fā)團(tuán)隊(duì)通過(guò)每日 Scrum 會(huì)議來(lái)確認(rèn)他們?nèi)匀豢梢詫?shí)現(xiàn) Sprint 的目標(biāo)。這個(gè)會(huì)議每天在同樣的時(shí)間和同樣的地點(diǎn)召開。每一個(gè)開發(fā)團(tuán)隊(duì)成員需要提供以下三點(diǎn)信息：

從上一個(gè)每日 Scrum 到現(xiàn)在，我完成了什么；從現(xiàn)在到下一個(gè)每日 Scrum，我計(jì)劃完成什么；有什么阻礙了我的進(jìn)展。

每日 Scrum 中可能有簡(jiǎn)要的問(wèn)題澄清和回答，但是不應(yīng)該有任何話題的討論。通常，許多團(tuán)隊(duì)會(huì)在每日 Scrum 之后馬上開會(huì)處理他們遇到的任何問(wèn)題。

每日 Scrum 既不是向管理層匯報(bào)，也不是向產(chǎn)品負(fù)責(zé)人或者 ScrumMaster 匯報(bào)。它是一個(gè)開發(fā)團(tuán)隊(duì)內(nèi)部的溝通會(huì)議，來(lái)保證他們對(duì)現(xiàn)狀有一致的了解。只有 Scrum 團(tuán)隊(duì)的成員，包括ScrumMaster 和產(chǎn)品負(fù)責(zé)人，可以在會(huì)議中發(fā)言。其他感興趣的人可以來(lái)旁聽。在必要時(shí)，開發(fā)團(tuán)隊(duì)會(huì)基于會(huì)議中的發(fā)現(xiàn)重新組織他們的工作來(lái)完成 Sprint 的目標(biāo)。

每日 Scrum 是 Scrum 的一個(gè)關(guān)鍵組成部分，它可以帶來(lái)透明性,信任和更好的績(jī)效。它能幫助快速發(fā)現(xiàn)問(wèn)題，并促進(jìn)團(tuán)隊(duì)的自組織和自立。所有 Scrum 會(huì)議都是限定時(shí)長(zhǎng)的。每日 Scrum 通常不超過(guò) 15 分鐘。

（4）Sprint 評(píng)審會(huì)議

Sprint 結(jié)束時(shí)，Scrum 團(tuán)隊(duì)和相關(guān)人員一起評(píng)審 Sprint 的產(chǎn)出。Sprint 評(píng)審會(huì)議的推薦時(shí)長(zhǎng)是Sprint 中的每一周對(duì)應(yīng)一個(gè)小時(shí)（例如，一個(gè) Sprint 包含 2 個(gè)星期，則 Sprint 評(píng)審會(huì)議時(shí)長(zhǎng)為 2 個(gè)小時(shí)）。

討論圍繞著 Sprint 中完成的產(chǎn)品增量。由于 Sprint 的產(chǎn)出會(huì)涉及一些人的“利益”，因此一個(gè)明智的做法是邀請(qǐng)他們參加這個(gè)會(huì)議，這會(huì)很有幫助。這個(gè)會(huì)議是個(gè)非正式的會(huì)議,幫助大家了解我們目前進(jìn)展到哪里，并一起討論我們下一步如何推進(jìn)。每個(gè)人都可以在 Sprint 評(píng)審會(huì)議上發(fā)表意見。當(dāng)然，產(chǎn)品負(fù)責(zé)人會(huì)對(duì)未來(lái)做出最終的決定，并適當(dāng)?shù)卣{(diào)整產(chǎn)品待辦事項(xiàng)列表 Product Backlog。

團(tuán)隊(duì)會(huì)找到他們自己的方式來(lái)開 Sprint 評(píng)審會(huì)議。通常會(huì)演示產(chǎn)品增量,整個(gè)小組也會(huì)經(jīng)常討論他們?cè)?Sprint 中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。他們還會(huì)討論產(chǎn)品待辦事項(xiàng)列表的狀態(tài)、可能的完成日期以及在這些日期前能完成什么。

Sprint 評(píng)審會(huì)議向每個(gè)人展示了當(dāng)前產(chǎn)品增量的概況。因此，通常都會(huì)在 Sprint 評(píng)審會(huì)議中調(diào)整產(chǎn)品待辦事項(xiàng)列表。

（5）Sprint 回顧會(huì)議

在每個(gè) Sprint 結(jié)束后,Scrum 團(tuán)隊(duì)會(huì)聚在一起開 Sprint 回顧會(huì)議,目的是回顧一下團(tuán)隊(duì)在流程人際關(guān)系以及工具方面做得如何。團(tuán)隊(duì)識(shí)別出哪些做得好,哪些做得不好,并找出潛在的改進(jìn)事項(xiàng),為將來(lái)的改進(jìn)制定計(jì)劃。Sprint 回顧會(huì)議的推薦時(shí)長(zhǎng)是 Sprint 中的每一周對(duì)應(yīng)一個(gè)小時(shí)（例如，一個(gè)Sprint 包含 2 個(gè)星期，則 Sprint 回顧會(huì)議時(shí)長(zhǎng)為 2 個(gè)小時(shí)）。

Scrum 團(tuán)隊(duì)總是在 Scrum 的框架內(nèi)，改進(jìn)他們自己的流程。

2．Scrum 的 5 大價(jià)值觀

Scrum 的 5 大價(jià)值觀為：

承諾—愿意對(duì)目標(biāo)做出承諾。

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

開放—Scrum 把項(xiàng)目中的一切開放給每個(gè)人看。

尊重—每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)。

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

4 水晶方法 Crystal

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

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

（1）經(jīng)常交付

任何項(xiàng)目，無(wú)論大小、敏捷程度，其最重要的一項(xiàng)體系特征是每過(guò)幾個(gè)月就向用戶交付已測(cè)試的運(yùn)行代碼。如果你使用了此體系特征，你就會(huì)發(fā)現(xiàn)，“經(jīng)常交付”的作用還是很讓人吃驚的。

項(xiàng)目主辦者根據(jù)團(tuán)隊(duì)的工作進(jìn)展獲得重要反饋。用戶有機(jī)會(huì)發(fā)現(xiàn)他們?cè)瓉?lái)的需求是否是他們真正想要的，也有機(jī)會(huì)將觀察結(jié)果反饋到開發(fā)當(dāng)中。開發(fā)人員打破未決問(wèn)題的死結(jié)，從而實(shí)現(xiàn)對(duì)重點(diǎn)的持續(xù)關(guān)注。團(tuán)隊(duì)得以調(diào)整開發(fā)和配置的過(guò)程，并通過(guò)完成這些工作鼓舞團(tuán)隊(duì)的士氣。

（2）反思改進(jìn)

在我們的開發(fā)中，時(shí)常會(huì)出現(xiàn)這樣那樣的問(wèn)題，技術(shù)難題、各種煩心事等，這會(huì)在很大的程度上影響項(xiàng)目的進(jìn)展。而且，如果其他任務(wù)對(duì)這項(xiàng)任務(wù)有依賴的話，那么其他的任務(wù)也會(huì)被推遲，這就很可能會(huì)導(dǎo)致項(xiàng)目的失敗。

換句話說(shuō)，如果，我們能夠經(jīng)常在迭代會(huì)中及時(shí)地反思和改進(jìn)，那么，這種事情應(yīng)該是不會(huì)發(fā)生的，或者說(shuō)發(fā)生了，也能夠很快地找到解決方案去應(yīng)對(duì)它。事實(shí)上，從慌亂的日常開發(fā)中，抽出一點(diǎn)時(shí)間來(lái)思考更為行之有效的工作方法就已經(jīng)足夠了。

（3）滲透式交流

滲透交流就是信息流向團(tuán)隊(duì)成員的背景聽覺，使得成員就像通過(guò)滲透一樣獲取相關(guān)信息。這種交流通常都是通過(guò)團(tuán)隊(duì)成員在同一間工作室內(nèi)工作而實(shí)現(xiàn)的。若其中一名成員提出問(wèn)題，工作室內(nèi)的其他成員可以選擇關(guān)注或不關(guān)注的態(tài)度，可以加入到這個(gè)問(wèn)題的討論當(dāng)中來(lái)，也可以繼續(xù)忙自己的工作。

（4）個(gè)人安全

個(gè)人安全指的是當(dāng)你指出困擾你的問(wèn)題時(shí)，你不用擔(dān)心受到報(bào)復(fù)。個(gè)人安全非常重要，有了它，團(tuán)隊(duì)可以發(fā)現(xiàn)和改正自身的缺點(diǎn)。沒有它，團(tuán)隊(duì)成員們知而不言，缺點(diǎn)則愈發(fā)嚴(yán)重以至于損害整個(gè)團(tuán)隊(duì)。個(gè)人安全是邁向信任的第一步。有了信任，團(tuán)隊(duì)協(xié)作才能真正地實(shí)施，開發(fā)效率也就會(huì)直線上升的。

（5）焦點(diǎn)

所謂“焦點(diǎn)”，就是確定首先要做什么，然后安排時(shí)間，以平和的心態(tài)開展工作。確保團(tuán)隊(duì)成員清楚地了解他們自己最重要的任務(wù)是什么，確保他們能夠有充分的時(shí)間去完成這些任務(wù)。

（6）與專家用戶建立方便的聯(lián)系

與專家用戶持續(xù)建立方便的聯(lián)系能夠給團(tuán)隊(duì)提供：對(duì)經(jīng)常交付進(jìn)行配置以及測(cè)試的地方，關(guān)于成品質(zhì)量的快速反饋，關(guān)于設(shè)計(jì)理念的快速反饋，最新的（用戶）需求。

（7）配有自動(dòng)測(cè)試、配置管理和經(jīng)常集成功能的技術(shù)環(huán)境

自動(dòng)測(cè)試可以為開發(fā)人員在代碼修改后就可以進(jìn)行自動(dòng)測(cè)試，并且能夠發(fā)現(xiàn)存在的一些bug，以至開發(fā)人員能夠及時(shí)地進(jìn)行修改，對(duì)于他們來(lái)說(shuō)，節(jié)省了時(shí)間，提高了效率，而且還不用為煩人的測(cè)試而苦惱。

配置管理系統(tǒng)允許人們不同步地對(duì)工作進(jìn)行檢查，可撤銷更改，并且可以將某一系統(tǒng)設(shè)置保存后進(jìn)行新系統(tǒng)的發(fā)布，當(dāng)新系統(tǒng)出現(xiàn)問(wèn)題，即可還原原系統(tǒng)的設(shè)置。

經(jīng)常集成可以使得團(tuán)隊(duì)在一天之內(nèi)對(duì)系統(tǒng)進(jìn)行多次集成。其實(shí)，團(tuán)隊(duì)越頻繁地對(duì)系統(tǒng)進(jìn)行集成，他們就能夠越快地發(fā)現(xiàn)錯(cuò)誤，堆積到一起的錯(cuò)誤也會(huì)越少，并使他們產(chǎn)生更新的靈感。

最好的團(tuán)隊(duì)是將這三大技術(shù)結(jié)合成“持續(xù)測(cè)試集成技術(shù)”。這樣做他們可以在幾分鐘內(nèi)發(fā)現(xiàn)因集成所產(chǎn)生的錯(cuò)誤。

5 其他敏捷方法

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

開放式源碼

開放式源碼指的是開放源碼界所用的一種運(yùn)作方式。開放式源碼項(xiàng)目有一個(gè)特別之處，就是程序開發(fā)人員在地域上分布很廣，這使得它和其他敏捷方法不同，因?yàn)橐话愕拿艚莘椒ǘ紡?qiáng)調(diào)項(xiàng)目組成員在同一地點(diǎn)工作。開放源碼的一個(gè)突出特點(diǎn)就是查錯(cuò)排障（debug）的高度并行性，任何人發(fā)現(xiàn)了錯(cuò)誤都可將改正源碼的“補(bǔ)丁”文件發(fā)給維護(hù)者。然后由維護(hù)者將這些“補(bǔ)丁”或是新增的代碼并入源碼庫(kù)。

自適應(yīng)軟件開發(fā) Adaptive Software Development ASD 方法

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

參考文章：開發(fā)方法—敏捷方法

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。