第9章 敏捷軟件過程

第九章

敏捷軟件過程9.1 敏捷實踐9.2 敏捷開發(fā)方法9.3 XP-極限編程9.4Scrum9.5DSDM-動態(tài)系統(tǒng)開發(fā)方法9.6Crystal方法9.7FDD特性驅(qū)動開發(fā)9.8ASD自適應(yīng)軟件開發(fā)9.9本章小結(jié)9.1

敏捷實踐9.1.1

敏捷聯(lián)盟

2001年初，由于看到許多公司的軟件團隊陷入了不斷增長的過程的泥潭，一批業(yè)界專家聚集在一起概括出了一些可以讓軟件開發(fā)團隊具有快速工作、響應(yīng)變化能力的價值觀和原則。他們稱自己為敏捷聯(lián)盟。在隨后的幾個月中，他們創(chuàng)建出了一份價值觀聲明。也就是敏捷聯(lián)盟的宣言（TheManifestooftheAgileAlliance）。敏捷軟件開發(fā)宣言： 我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。通過這項工作，我們認為：個體和交互可運行軟件客戶合作響應(yīng)變化過程和工具詳盡的文檔合同談判遵循計劃勝過

雖然以上右項也有價值，但是我們認為左項具有更大的價值。個體和交互優(yōu)于過程和工具

這里并不是否定過程和工具的重要性，而是更強調(diào)軟件開發(fā)中人的作用和交流的作用。因為軟件是由人組成的團隊來開發(fā)的，與軟件項目相關(guān)的各類人員（如項目經(jīng)理、建模人員、設(shè)計師、程序員、測試人員和客戶）通過充分交流和有效合作，才能成功的開發(fā)出得到用戶滿意的軟件。如果只有定義良好的過程和先進的工具，而人員的技能很差，又不能很好的交流和協(xié)作，軟件是很難成功開發(fā)出來的?？蛇\行軟件高于詳盡的文檔

對用戶來說，通過執(zhí)行一個可運行的軟件來了解軟件做了些什么，遠比閱讀厚厚的文檔要容易的多。因此，敏捷軟件開發(fā)強調(diào)不斷地、快速地向用戶提交可運行的軟件（不一定是完整的軟件），以得到用戶的認可。好的、必要的文檔仍是需要的，它能幫助人們理解軟件做什么、怎么做以及如何使用，但軟件工程的主要目標是創(chuàng)建可運行的軟件。與客戶協(xié)作高于合同（契約）談判

只有客戶才能明確的說明需要什么樣的軟件，然而大量的實踐表明，在開發(fā)的早期客戶常常不能完整地表達他們的全部要求，有些早期確定的需求，以后也可能會改變。因此，要想通過合同談判的方式，將需求固定下來常常是有困難的。敏捷軟件開發(fā)強調(diào)與客戶的協(xié)作，通過與客戶的交流和緊密的合作來發(fā)現(xiàn)用戶的需求。對變更及時做出反應(yīng)高于遵循計劃

任何軟件項目的開發(fā)都應(yīng)制定一個項目計劃，確定各開發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著項目的發(fā)展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會改變。因此，項目計劃應(yīng)該具有可塑性，有變動的余地。當出現(xiàn)變化時及時做出反應(yīng)，修訂計劃以適應(yīng)變化。9.1.2

開發(fā)原則

從上述的價值觀中引出了下面的12條原則，它們是敏捷實踐區(qū)別于重型過程的特征所在?！蜃顑?yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意?！蛎艚葸^程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。即使到了開發(fā)的后期，也歡迎改變需求?！蚪?jīng)常性的交付可以使用的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好?！蛟谡麄€項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天在一起工作。◎圍繞被激勵起來的個人來構(gòu)建項目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作?！蛟趫F隊內(nèi)部最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談?！蚩墒褂玫能浖鞘滓倪M度度量標準?！蛎艚葸^程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度?！虿粩嗟年P(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力?！蚝唵?-使未完成的工作最大化的藝術(shù)--是根本的?！蜃詈玫臉?gòu)架、需求和設(shè)計出自于自組織的團隊?！蛎扛粢欢〞r間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。9.2

敏捷開發(fā)方法隨著敏捷軟件的盛行和發(fā)展，敏捷開發(fā)方法得到了極大的發(fā)展，各軟件開發(fā)公司都對自己的公司采取了相適應(yīng)的過渡過程，對敏捷方法都有自己的追求和適應(yīng)點。敏捷開發(fā)方法雖然有很多種，主流可歸納為以下的六種：

XP

Scrum

CrystalMethods

FDD

ASDM

DSDMXP的思想源自二十世紀90年代KentBeck和WardCunningham在軟件項目的合作經(jīng)歷。XP的核心是溝通、簡明、反饋和勇氣。因為計劃永遠趕不上變化，XP無需開發(fā)人員在軟件開始初期做出很多的文檔。XP提倡測試先行，為了將以后出現(xiàn)Bug的幾率降到最低。Scrum是一種迭代的增量化過程，用于產(chǎn)品開發(fā)或者工作管理，它是一種可以集合各種開發(fā)實踐的經(jīng)驗化過程框架。Scrum中發(fā)布產(chǎn)品的重要性高于一切。該方法由KenSchwaber和JeffSutherland提出，旨在尋求充分發(fā)揮面向?qū)ο蠛蜆?gòu)建技術(shù)的開發(fā)方法，是對迭代式面向?qū)ο蠓椒ǖ母倪M。CrystalMethods由AlistairCockbum在20世紀90年代末提出。方法認為不同類型的項目需要不同的方法。它們盡管不如XP那樣的產(chǎn)出效率，但會有更多的人能夠接受并遵循它。FDD特性驅(qū)動開發(fā)由PeterCoad,JeffdeLuca,EricLefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)項目的開發(fā)模式。此外，F(xiàn)DD是一個模型驅(qū)動的快速迭代開發(fā)過程，它強調(diào)的是簡化、實用。易于被開發(fā)團隊接受，適用于需求經(jīng)常變動的項目。ASDM自適應(yīng)軟件開發(fā)由JimHighsmith在1999年正式提出，ASDM強調(diào)開發(fā)方法的適應(yīng)性，這一思想來源于復雜系統(tǒng)的混沌理論。ASDM不像其他方法那樣有很多具體的實踐做法，它更側(cè)重為ASDM的重要性提供最根本的基礎(chǔ)，并從更高的組織和管理層次來闡述開發(fā)方法為什么要具備適應(yīng)性。DSDM動態(tài)系統(tǒng)開發(fā)方法是眾多敏捷開發(fā)方法中的一種，它倡導以業(yè)務(wù)為核心，快速而有效地進行系統(tǒng)開發(fā)。實踐證明[加“，”]DSDM是成功的敏捷開發(fā)方法之一。在英國，由于其在各種規(guī)模的軟件組織中的成功，該方法已成為應(yīng)用最為廣泛的快速應(yīng)用開發(fā)方法。DSDM不但遵循了敏捷方法的原理，而且也適應(yīng)那些成熟的傳統(tǒng)開發(fā)方法——有堅實基礎(chǔ)的軟件組織。9.3

XP-極限編程9.3.1XP的基礎(chǔ)—實踐

XP方法是敏捷方法中最著名的一個。極限編程是一個高度迭代的過程，有較多的反饋對環(huán)境和需求變化做出調(diào)整，同時極限編程強調(diào)以小版本形式來開發(fā)系統(tǒng)，由此使用戶可以很快使用一個較小的系統(tǒng)，然后不斷增加此系統(tǒng)的功能。它的優(yōu)點就是程序員可以從客戶實際的使用情況里得到反饋。極限編程誕生于一個遇到麻煩的商業(yè)軟件項目（克萊斯勒的綜合小組—ChryslerComprehensiveCompensation簡稱C3系統(tǒng)），那么極限編程的實踐就應(yīng)該是實在的和具體的，而不是理論的或抽象的。極限編程與傳統(tǒng)開發(fā)方法不一樣，難以用我們熟悉的瀑布模型的開發(fā)經(jīng)驗去理解它；再者，某些普通的軟件實踐在極限編程中有時被過分強調(diào)，而且變得極端。

9.3.2

XP方法的價值和規(guī)則

XP方法通過在一些對費用控制嚴格的公司中適用，已經(jīng)被證明是非常有效的。因此由KentBeck提出了4條基本的價值原則：交流、簡易、反饋和勇氣，在此基礎(chǔ)上形成了12條XP項目應(yīng)遵循的實踐準則。XP還有一個最突出的特點，就是它對測試極度重視，XP的設(shè)計過程是“紀律性”與“適配性”的高度統(tǒng)一，這也使得XP在適配性方法中成為發(fā)展最好的一種方法。

＊交流（Communication）

XP方法強調(diào)交流的價值，通過交流，既可以向項目的相關(guān)人員提供信息，又可以從他們那里獲取信息。大量實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準確的傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設(shè)計的變動未能及時告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難等。因此，所有項目相關(guān)人員之間充分而有效的交流是軟件開發(fā)成功所必不可少的。＊簡單（Simplicity）

XP團隊使他們的設(shè)計盡可能的簡單、具有表現(xiàn)力。此外，他們僅僅關(guān)注于計劃在本次迭代中要完成的用戶素材而不會考慮那些未來的用戶素材。相反，在一次次的迭代中，他們不斷變遷系統(tǒng)設(shè)計，使之對正在實現(xiàn)的用戶素材而言始終保持在最優(yōu)狀態(tài)。簡單的價值使得軟件開發(fā)是敏捷的，它體現(xiàn)了敏捷開發(fā)的一次，并且只有一次（Justenough）的指導思想，即開發(fā)中的代碼及其制品既不需要太多也不需要太少，剛好即可。今天只做今天的事，明天如需要，則通過不斷的改進設(shè)計和重構(gòu)來滿足明天的需求。今天所保持的簡潔，可以降低明天由于變更所帶來的費用。＊反饋（Feedback）

Beck說：“對于編程而言，樂觀主義是一種冒險。而反饋則是相應(yīng)的解決良藥。”及時有效的反饋，其價值體現(xiàn)在能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。XP的實踐者認為反饋比起前饋（Feedforward）來得更為重要。無論是用反復的構(gòu)建或者頻繁的用戶功能測試，XP都能不斷地接收到反饋，而反饋的及時程度是很重要的，它能及時發(fā)現(xiàn)偏差，并對軟件環(huán)境有很好的認識。＊勇氣（Courage）

無論你是使用CMM方法或者是XP的方法，方法使用的本身就是需要勇氣的。敏捷軟件開發(fā)對大多數(shù)軟件機構(gòu)來說是一個新方法，是對軟件開發(fā)現(xiàn)狀的一個挑戰(zhàn)，因此采用敏捷軟件就更需要勇氣。9.3.3

XP方法的12個核心實踐 XP的實踐、價值、原則和活動之間的關(guān)系是：原則來自于價值；而價值和原則又是以12個實踐為基礎(chǔ)的；12個實踐關(guān)聯(lián)著四個主要的軟件開發(fā)活動。XP實踐提供了對實際操作的指導?？梢杂靡粋€很簡單的圖示來表示出這四者之間的關(guān)系（如圖9.1所示）。圖9.1極限編程的實踐、價值、原則和活動某些軟件模型具有很大的強制性，在開發(fā)階段中規(guī)定了必須進行的實踐，目的卻并不是為了提高隊伍的開發(fā)能力，往往只是為了方便管理層去監(jiān)控項目。XP是一個價值驅(qū)動的模型，所有實踐必須體現(xiàn)出價值。這意味著，當在某些情況下不能體現(xiàn)出XP的價值時，就沒有必要進行這些實踐了；另一方面，即使有的實踐不包括在以下介紹的12個極限編程實踐中，只要能體現(xiàn)出XP的價值，XP的隊伍也是可以采用的?！暾膱F隊

XP方法要求所有團隊成員應(yīng)該在同一個場所工作。成員中必須有一名現(xiàn)場用戶，由他提出需求，確定需求的優(yōu)先級，編寫驗收測試用例。通常團隊還設(shè)一位“教練”角色，指導XP方法的實施，負責與外部溝通和協(xié)作。※計劃對策

XP項目每兩周交付一次可以工作的軟件。每兩周的迭代（Iteration,也可稱為重復周期或循環(huán)周期）都實現(xiàn)了現(xiàn)場用戶的一些要求。在每次迭代結(jié)束時，會給現(xiàn)場用戶演示迭代生成的系統(tǒng)，以得到他們的反饋。

迭代計劃

發(fā)布計劃每次迭代通常耗時兩周。這是一次較小的交付，可能會被加入到產(chǎn)品中，也可能不會。它由客戶根據(jù)開發(fā)人員確定的預算而選擇的一些用戶素材組成。XP團隊通常會創(chuàng)建一個計劃來規(guī)劃隨后大約6次迭代的內(nèi)容，這就是所謂的發(fā)布計劃。一次發(fā)布通常需要3個月的工作。它表示了一次較大的交付，通常此次交付會被加入到產(chǎn)品中。發(fā)布計劃是由一組客戶根據(jù)開發(fā)人員給出的預算所選擇的、排好優(yōu)先級別的用戶素材組成。※隱喻 隱喻是所有XP實踐中最難理解的一個。設(shè)定XP項目隱喻(Metaphor)的前提是所有的項目參與人員都必須對相關(guān)的抽象概念有統(tǒng)一的、具體的認識。在克萊斯勒薪酬支付系統(tǒng)開發(fā)(C3系統(tǒng))項目中，開發(fā)小組就使用了生產(chǎn)流水線這一隱喻。由于流水線這個概念在克萊斯勒公司中人人皆知，不同階段的薪酬支付方法就變得很具體而便于理解了。為了避免歧義，保持較高的生產(chǎn)效率，每一個人對抽象問題的概念的理解都應(yīng)該盡可能相同。

※規(guī)則游戲

開發(fā)任何系統(tǒng)，都要有系統(tǒng)需求。在XP中，系統(tǒng)需求的記錄有點像日志形式，稱為用戶故事。用戶故事是規(guī)則游戲(PlanningGame)中的一個重要環(huán)節(jié)，它具體描述了系統(tǒng)會怎樣解決實際問題和系統(tǒng)的行為等。每一個故事都被記錄在索引卡上，用于說明一個客戶需要的功能。每個故事都應(yīng)有其可體現(xiàn)的價值，但實際上某一個故事的價值，在很大程度上要依賴于其他故事或支持其他故事的實行?！鶞y試驅(qū)動

XP方法提倡測試優(yōu)先，即用戶素材的驗收測驗是在就要實現(xiàn)該用戶素材之前或?qū)崿F(xiàn)該用戶素材的同時進行編寫的。測試優(yōu)先為開發(fā)人員提供編程前對代碼進行周密思考的機會，使開發(fā)人員很快發(fā)現(xiàn)他們的想法實際上是否可行。※簡單設(shè)計

簡單設(shè)計就是編碼時，只依據(jù)當時的需求，程序員不必為可能發(fā)生的改變或擴展考慮。因為使用XP的開發(fā)人員認識到，只有代碼可讀性、可維護性及單元測試，才會真正影響到將來代碼修改的難度和成本。如果代碼的可維護性足夠好，做任何的更改都不是太大的問題。 另外，簡單設(shè)計還包括其他四個意思：

1.要通過測試。

2.避免重復的代碼。

3.明確表達每一步編碼的目的，即代碼的可讀性。

4.使用盡可能少的對象類和對象方法?！貥?gòu)

重構(gòu)(Refactoring)可以用簡單的數(shù)學方法來解釋，即以更簡潔而直接的表達式來代替難懂或繁瑣的表達式。表達式越復雜，重構(gòu)的優(yōu)點就越明顯。因此重構(gòu)是在不影響既有程序行為的前提下，對源代碼進行改進和簡化。

在整個開發(fā)過程中，應(yīng)對程序結(jié)構(gòu)進行持續(xù)不斷的梳理，在不影響程序的外部可見行為的情況下，按照高內(nèi)聚低耦合的原則對程序內(nèi)部的結(jié)構(gòu)進行改進，保持代碼的簡潔，無冗余。※結(jié)對編程

LaurieWillians和Nosek的研究表明，結(jié)對非但不降低開發(fā)團隊的效率，而且會大大減少缺陷率。在XP中突出強調(diào)結(jié)對編程，即所有的產(chǎn)品代碼都是由結(jié)對的程序員使用同一電腦共同完成的，并且兩個人的角色可以互換即動態(tài)調(diào)整。結(jié)對的關(guān)系每天至少要改變一次，以便于每個程序員在一天中可以在兩個不同的結(jié)對中工作。在一次迭代期間，每個團隊成員應(yīng)該和所有其他的團隊成員在一起工作過，并且他們應(yīng)該參與本次迭代中所涉及的每項工作。這將極大促進知識在團隊中的傳播。另外，個別人員的流動對項目的進展造成的影響也會降到最低。 在XP里，結(jié)對編程所能帶來的好處可歸結(jié)為以下幾點：

1.所有的設(shè)計都是由兩個人討論決定的。

2.系統(tǒng)的任何一個部分都至少有兩個人熟悉，避免了由于人事更替造成的問題。

3.減小了忽略編寫編程用例的幾率，因為結(jié)對者會互相提醒對方。

4.在編程過程中與不同的人結(jié)對可以進一步增強知識與經(jīng)驗的共享。

5.所有編碼都隨時得到檢驗。

6.兩個程序員可以同時分別關(guān)注操作層面和理論層面，加強了程序的設(shè)計。

但在實際操作中，結(jié)對編程作為XP中的一個核心實踐，它的生產(chǎn)力或效率常被質(zhì)疑?！掷m(xù)集成

程序員每天會多次的插入他們的代碼并進行集成，規(guī)則很簡單。第一個插入的只要完成插入就可以了，所有其他的人負責代碼的合并工作。持續(xù)集成(ContinuousIntegration)能保持項目組中所有開發(fā)好的模塊始終是組裝完畢，完畢集成測試且是可執(zhí)行的。 持續(xù)集成的關(guān)鍵在于當天必須完成所有代碼的集成。若一個集成任務(wù)，在當天不能完成，這意味著集成過于復雜，因此最好分步實行；否則就說明采用的解決方法過于復雜，需要一個更簡單的來代替。若集成問題不能當天解決，便要有勇氣丟掉當天的工作，重新來過?！w代碼所有權(quán) 結(jié)對編程中的每一個都具有拆出任何模塊并對它進行修改的權(quán)力。沒有程序員對任何一個特定的模塊或技術(shù)單獨負責。沒有人比其他人在一個模塊或者技術(shù)上具有更多的權(quán)威。因此總體上每個成員都對整個系統(tǒng)有了一定程度的了解。此外，結(jié)對編程、編碼標準、持續(xù)集成等實踐都是為代碼全體共有提供支持的，能及時發(fā)現(xiàn)因修改代碼而引起的沖突，避免沖突的集中爆發(fā)。

※編碼標準

XP方法強調(diào)制定一個統(tǒng)一的編碼標準，包括命名、注釋、格式等編程風格，使得所有的程序代碼就像出自一人之手。編碼標準這一實踐的關(guān)鍵，并不在于編制怎樣的標準，而在于所有人都要共同遵守。這和工業(yè)生產(chǎn)中運用統(tǒng)一的產(chǎn)品標準有類似的作用?！沙掷m(xù)步調(diào)

XP方法強調(diào)每周40小時工作制。由于人的精力是有限的，敏捷軟件開發(fā)要求每個團隊的成員都能始終保持精力充沛，充滿活力。長時間超負荷的工作會影響工作效率，因此，XP方法要求每周工作時間不超過40小時，即使加班，也不要連續(xù)工作超過兩周。以上從價值、原則、實踐、活動及其之間的聯(lián)系對極限編程做了介紹。極限編程與傳統(tǒng)編程方式的最大不同，是容許系統(tǒng)需求在開發(fā)過程中變更。XP以迭代過程來支持對需求變化做出相應(yīng)的改變。XP的價值高于實踐，進行這些實踐的目的都是為了實現(xiàn)XP的價值。表9-1總結(jié)了XP和傳統(tǒng)方法的區(qū)別。表9-1極限編程和傳統(tǒng)方法的區(qū)別傳統(tǒng)編程方法極限編程客戶的溝通是有限的使客戶參與到開發(fā)小組中沒有隱喻使用了隱喻軟件設(shè)計是在設(shè)計階段確立軟件是連續(xù)設(shè)計的基于將來可能的條件進行設(shè)計基于當前情況進行設(shè)計實施較為復雜操作相當簡單開發(fā)人員獨立進行工作結(jié)對編程分派任務(wù)組員自行協(xié)調(diào)任務(wù)定期進行集成持續(xù)進行集成對于需求改變，隊伍是恐懼的對于需求改變，隊伍是進取的軟件開發(fā)完畢后測試軟件修改前后都測試上下級之間溝通有限積極地多方面溝通9.3.4XP案例分析

項目概況及背景： 實例公司——亞洲領(lǐng)先的電子商務(wù)解決方案供應(yīng)商，在J2EE架構(gòu)的項目執(zhí)行方面有豐富的經(jīng)驗，結(jié)合RUP(RationalUnifiedProcess)形成了自己的一套電子商務(wù)項目實施方法論，并在多個項目中成功進行實施。同時，由于具體項目時間和成本的限制，也出現(xiàn)了一些問題，主要有以下兩點：

1.項目交付后，用戶提出很多的修改意見，有些甚至涉及系統(tǒng)架構(gòu)的修改，出現(xiàn)這種情況的主要原因是：很多項目雖然是采用增量迭代式的開發(fā)周期，但是在部署前才發(fā)布版本，用戶只是在項目部署后才看到真正的系統(tǒng)，因此會發(fā)現(xiàn)很多界面、流程等方面的問題。

2.對于用戶提交Bug的修改周期過長：開發(fā)人員在做開發(fā)的時候，對于單元測試的重視程度不夠，模塊開發(fā)結(jié)束后就提交給測試人員進行測試，而測試人員由于時間的關(guān)系，并不能發(fā)現(xiàn)所有的問題；在用戶提交Bug后，開發(fā)人員由于項目接近尾聲，對于代碼的修改產(chǎn)生惰性，同時又沒有形成有效的回歸測試方法，因此修改的周期比較長。

針對XP的核心價值，可以看到，如果能夠加強與用戶的溝通、增加項目中測試實施的力度，就可以從一定程度上解決上述問題。 從2001年開始，公司內(nèi)部展開對于XP等敏捷方法的研究，希望能夠借鑒一些做法，來完善項目方法論。2002年5月，上層決定在公司的一個新的項目中啟用XP的一些最佳實踐，來檢驗其效果。該項目是為一家國際知名手機生產(chǎn)廠商的合作伙伴提供手機配件定購、申請、回收等服務(wù)，項目的情況如下表9-2所示：

條

目描

述項目名稱合作伙伴管理系統(tǒng)處理工作流程9個項目周期43個工作日項目小組人員5人，其中資深顧問2名從上表9-2中可以看出，該項目是一個小型項目，而且項目小組成員對于XP在項目開始之前都有一定的了解，另一方面，客戶要求的項目周期比我們預期估計的時間有一定的余地，因此公司決定利用這個項目進行XP的試驗性實踐?！靀P的最佳實踐以及在項目中的應(yīng)用

在項目執(zhí)行過程中，基本上還是采用RUP的軟件過程，而沒有死板的套用XP的做法，例如：在需求分析階段，還是采用UseCase來對需求進行描述，而不是XP規(guī)定的CRC卡片；在系統(tǒng)分析與設(shè)計階段，首先進行系統(tǒng)的架構(gòu)設(shè)計，而不是簡單的套用XP的“簡單設(shè)計”實踐?！煜旅娼Y(jié)合項目的具體情況，討論一下XP的12個最佳實踐1.現(xiàn)場客戶(On-siteCustomer) XP：要求至少有一名實際的客戶代表在整個項目開發(fā)周期在現(xiàn)場負責確定需求、回答團隊問題以及編寫功能驗收測試。 評述：現(xiàn)場用戶可以從一定程度上解決項目團隊與客戶溝通不暢的問題，但是對于國內(nèi)用戶來講，目前階段還不能保證有一定技術(shù)層次的客戶常駐開發(fā)現(xiàn)場。解決問題的方法有兩種：一是可以采用在客戶那里現(xiàn)場開發(fā)的方式；二是采用有效的溝通方式。項目：首先，在項目合同簽署前，向客戶進行項目開發(fā)方法論的介紹，使得客戶清楚項目開發(fā)的階段、各個階段要發(fā)布的成果以及需要客戶提供的支持等；其次，由項目經(jīng)理每周向客戶匯報項目的進展情況，提供目前發(fā)布版本的位置，并提示客戶系統(tǒng)相應(yīng)的反饋與支持。2.代碼規(guī)范(CodeStandards) XP：強調(diào)通過指定嚴格的代碼規(guī)范來進行溝通，盡可能減少不必要的文檔。 評述：XP對于代碼規(guī)范的實踐，具有雙重含義：一是希望通過建立統(tǒng)一的代碼規(guī)范，來加強開發(fā)人員之間的溝通，同時為代碼走查提供了一定的標準；二是希望減少項目開發(fā)過程中的文檔，XP認為代碼是最好的文檔。對于目前國內(nèi)的大多數(shù)項目團隊來說，建立有效的代碼規(guī)范，加強團隊內(nèi)代碼的統(tǒng)一性，是理所當然的；但是，認為代碼可以代替文檔卻是不可取的，因為代碼的可讀性與規(guī)范的文檔相比有一定的差距。同時，如果沒有統(tǒng)一的代碼規(guī)范，代碼全體擁有就無從談起。 項目：在項目實施初期，就由項目的技術(shù)經(jīng)理建立代碼規(guī)范，并將其作為代碼審查的標準。3.每周40小時工作制(40-hourWeek) XP：要求項目團隊人員每周工作時間不能超過40小時，加班不得連續(xù)超過兩周，否則反而會影響生產(chǎn)率。 評述：該實踐充分體現(xiàn)了XP的“以人為本”的原則。但是，如果要真正的實施下去，對于項目進度和工作量合理安排的要求就比較高。 項目：由于項目的工期比較充裕，因此，很幸運的是開發(fā)小組并沒有違反該實踐。

4.計劃博弈(PlanningGame) XP：要求結(jié)合項目進展和技術(shù)情況，確定下一階段要開發(fā)與發(fā)布的系統(tǒng)范圍。 評述：項目的計劃在建立起來以后，需要根據(jù)項目的進展來進行調(diào)整，一成不變的計劃是不存在。因此，項目團隊需要控制風險、預見變化，從而制定有效、可行的項目計劃。 項目：在系統(tǒng)實現(xiàn)前，首先按照需求的優(yōu)先級做了迭代周期的劃分，將高風險的需求優(yōu)先實現(xiàn)；同時，項目團隊每天早晨參加一個15分鐘的項目會議，確定當天以及目前迭代周期中每個成員要完成的任務(wù)。5.系統(tǒng)隱喻(SystemMetaphor) XP：通過隱喻來描述系統(tǒng)如何運作、新的功能以何種方式加入到系統(tǒng)。它通常包含了一些可以參照和比較的類和設(shè)計模式。XP不需要事先進行詳細的架構(gòu)設(shè)計。 評述：XP在系統(tǒng)實現(xiàn)初期不需要進行詳細的架構(gòu)設(shè)計，而是在迭代周期中不斷的細化架構(gòu)。對于小型的系統(tǒng)或者架構(gòu)設(shè)計的分析會推遲整個項目的計劃的情況下，逐步細化系統(tǒng)架構(gòu)倒是可以的；但是，對于大型系統(tǒng)或者是希望采用新架構(gòu)的系統(tǒng)，就需要在項目初期進行詳細的系統(tǒng)架構(gòu)設(shè)計，并在第一個迭代周期中進行驗證，同時在后續(xù)迭代周期中逐步進行細化。 項目：開發(fā)團隊在設(shè)計初期，決定參照STRUTS框架，結(jié)合項目的情況，構(gòu)建了針對工作流程處理的項目框架。首先，團隊決定在第一個迭代周期實現(xiàn)配件申請的工作流程，在實際項目開發(fā)中驗證了基本的程序框架；而后，又在其它迭代周期中，對框架逐漸精化。6.簡單設(shè)計(SimpleDesign) XP：認為代碼的設(shè)計應(yīng)該盡可能的簡單，只要滿足當前功能的要求，不多也不少。 評述：傳統(tǒng)的軟件開發(fā)過程，對于設(shè)計是自頂而下的，強調(diào)設(shè)計先行，在代碼開始編寫之前，要有一個完美的設(shè)計模型。它的前提是需求不變化，或者很少變化；而XP認為需求是會經(jīng)常變化的，因此設(shè)計不能一蹴而就，而應(yīng)該是一項持續(xù)進行的過程。 盡可能包含最少的類與方法。對于國內(nèi)大部分的軟件開發(fā)組織來說，應(yīng)該首先確定一個靈活的系統(tǒng)架構(gòu)，而后在每個迭代周期的設(shè)計階段可以采用XP的簡單設(shè)計原則，將設(shè)計進行到底。 項目：在項目的系統(tǒng)架構(gòu)經(jīng)過驗證后的迭代周期內(nèi)，堅持簡單設(shè)計的原則。對于新的迭代周期中出現(xiàn)需要修改設(shè)計和代碼的情況，首先對原有系統(tǒng)進行“代碼重構(gòu)”，而后再增加新的功能。7.測試驅(qū)動(Test-driven) XP：強調(diào)“測試先行”。在編碼開始之前，首先將測試寫好，而后再進行編碼，直至所有的測試都得以通過。 評述：Rup與XP對測試都是非常的重視，只是兩者對于測試在整個項目開發(fā)周期內(nèi)首先出現(xiàn)的位置處理不同。XP是一項測試驅(qū)動的軟件開發(fā)過程，它認為測試先行使得開發(fā)人員對自己的代碼有足夠的信心，同時也有勇氣進行代碼重構(gòu)。測試應(yīng)該實現(xiàn)一定的自動化，同時能夠清晰的給出測試成功或者失敗的結(jié)果。在這方面，xUnit測試框架做了很多的工作，因此很多實施XP的團隊，都采用它們進行測試工作。 項目：我們在項目初期就對Junit進行了一定的研究工作，在項目編碼中，采用Jbuilder6.0提供的測試框架進行測試類的編寫。但是，不是對所有的方法與用例都編寫，而只是針對關(guān)鍵方法類、重要業(yè)務(wù)邏輯處理類等進行。8.代碼重構(gòu)(Refactoring) XP：強調(diào)代碼重構(gòu)在其中的作用，認為開發(fā)人員應(yīng)該經(jīng)常進行重構(gòu)，通常有兩個關(guān)鍵點應(yīng)該進行重構(gòu)：對于一個功能實現(xiàn)和實現(xiàn)后。 評述：代碼重構(gòu)是指在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少復雜性、消除冗余、增加靈活性和提高性能。重構(gòu)不是XP所特有的行為，在任何的開發(fā)過程中都可能并且應(yīng)該發(fā)生。在使用代碼重構(gòu)的時候要注意，不要過分的依賴重構(gòu)，甚至輕視設(shè)計，否則，對于大中型的系統(tǒng)而言，將設(shè)計推遲或者干脆不作設(shè)計，會造成一場災(zāi)難。 項目：我們在項目中將Jrefactory工具部署到JBuilder中進行代碼的重構(gòu)，重構(gòu)的時間是在各個迭代周期的前后。代碼重構(gòu)在項目中的作用是改善既有設(shè)計，而不是代替設(shè)計。9.結(jié)對編程(PairProgramming) XP：認為在項目中采用成對編程比獨自編程更加有效。成對編程是由兩個開發(fā)人員在同一臺電腦上共同編寫解決同一問題的代碼，通常一個人負責寫編碼，而另一個負責保證代碼的正確性與可讀性。 評述：其實，成對編程是一種非正式的同級評審(PeerReview)。它要求成對編程的兩個開發(fā)人員在性格和技能上應(yīng)該相互匹配，目前在國內(nèi)還不是十分適合推廣。成對編程只是加強開發(fā)人員溝通與評審的一種方式，而非唯一的方式。具體的方式可以結(jié)合項目的情況進行。 項目：在項目中并沒有采用成對編程的實踐，而是在項目實施的各個階段，加強了走查以及同級評審的力度。需求獲取、設(shè)計與分析都有多人參與，在成果提交后，交叉進行走查；而在編碼階段，開發(fā)人員之間也要在每個迭代周期后進行同時評審。10.集體代碼所有權(quán)（CollectionOwnership）

XP：認為開發(fā)小組的每個成員都有更改代碼的權(quán)利，所有的人對于全部代碼負責。 評論：代碼全體擁有并不意味者開發(fā)人員可以互相推委責任，而是強調(diào)所有的人都要負責。如果一個開發(fā)人員的代碼有錯誤，另外一個開發(fā)人員也可以進行BUG的修復。在目前，國內(nèi)的軟件開發(fā)組織，可以在一定程度上實施該實踐，但是同時需要注意一定要有嚴格的代碼控制管理。 項目：我們在項目開發(fā)初期，首先向開發(fā)團隊進行“代碼全體擁有”的教育，同時要求開發(fā)人員不僅要了解系統(tǒng)的架構(gòu)、自己的代碼，同時也要了解其它開發(fā)人員的工作以及代碼情況。這個實踐與同級評審有一定的互補作用，從而保證人員的變動不會對項目的進度造成很大的影響。在項目執(zhí)行中，有一個開發(fā)人員由于參加培訓，缺席項目執(zhí)行一周，由于實行了“代碼全體擁有”的實踐，其它的開發(fā)人員成功地分擔了該成員的測試與開發(fā)任務(wù)，從而保證項目的如期交付。11.持續(xù)集成(ContinuousIntegration) XP：提倡在一天中集成系統(tǒng)多次，而且隨著需求的改變，要不斷的進行回歸測試。因為，這樣可以使得團隊保持一個較高的開發(fā)速度，同時避免了一次系統(tǒng)集成的惡夢。 評述：持續(xù)集成也不是XP專有的最佳實踐，著名的微軟公司就有每日集成(DailyBuild)的成功實踐。但是，要注意的是，持續(xù)集成也需要良好的軟件配置變更管理系統(tǒng)的有效支持。 項目：使用VSS作為軟件配置管理系統(tǒng)，堅持每天進行一次的系統(tǒng)集成，將已經(jīng)完成的功能有效地結(jié)合起來，進行測試。12.小型發(fā)布(SmallRelease) XP：強調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計每個迭代周期的進度，便于控制工作量和風險；同時，也可以及時處理用戶的反饋。 評論：小型發(fā)布突出體現(xiàn)了敏捷方法的優(yōu)點。RUP強調(diào)迭代式的開發(fā)，對于系統(tǒng)的發(fā)布并沒有作出過多的規(guī)定。用戶在提交需求后，只有在部署時才能看到真正的系統(tǒng)，這樣就不利于迅速獲得用戶的反饋。如果能夠保證測試先行、代碼重構(gòu)、持續(xù)集成等最佳實踐，實現(xiàn)小型發(fā)布也不是一件困難的事情，在有條件的組織可以考慮使用。 項目：項目在籌備階段就配置了一臺測試與發(fā)布服務(wù)器，在項目實施過程中，平均每兩周（一個迭代周期結(jié)束后）進行一個小型發(fā)布；用戶在發(fā)布后兩個工作日內(nèi)，向項目小組提交"用戶接收測試報告"，由項目經(jīng)理評估測試報告，將有效的BUG提交至RationalClearCase，并分配給相應(yīng)的開發(fā)人員。項目小組應(yīng)該在下一個迭代周期結(jié)束前修復所有用戶提交的問題。

以上是XP的最佳實踐在項目中的應(yīng)用情況，讓我們查看以下該項目的詳細統(tǒng)計數(shù)據(jù)表9-3：表9-3項目管理統(tǒng)計數(shù)據(jù)表條目描述項目開始時間2002/4/25項目預期結(jié)束時間2002/6/28項目實際結(jié)束日期2002/7/2項目預計成本199080項目實際成本177340CPI(ConsumerPriceIndex)1.155SPI(SchedulePerformanceIndex)1.028其中，項目執(zhí)行過程中提交了一個“用戶需求變更”，該變更對于項目周期的影響為6個工作日。項目實施后，在用戶接收測試中，只提交了2個BUG，而且在提交當天就得到了解決。目前，項目運行平穩(wěn)，并得到了用戶的好評。因此，我們認為，XP在該項目中的實施有效地保證了項目質(zhì)量和項目周期。9.4

Scrum9.4.1

簡史 Scrum在橄欖球中叫正集團，正集團以一個緊密整合的單位來協(xié)作，每個隊員都扮演一個定義明確的角色，并且在團隊的每個進展中完成自己所擔負的任務(wù)。整個團隊有一個單一的焦點，工作的優(yōu)先權(quán)也是清楚的。因此，我們希望軟件隊伍像Scrum一樣，以一種高度整合的方式工作；另外，他們也是個自我定向和自我組織的團隊。 把橄欖球中的正集團（Scrum）的協(xié)作理念應(yīng)用到管理上，源自一本《創(chuàng)新求勝-智價企業(yè)論》[TakeuchiandNonaka1986]總結(jié)十家日本創(chuàng)新公司共同最佳實踐的著作。在該書中首次用橄欖球中Scrum在場地中移動橄欖球的團隊行為，來解釋適應(yīng)性且自我組織的團隊特征。 在1994年，JeffSutherland把這樣的團隊特征應(yīng)用到軟件開發(fā)中，那時候，他在Easel公司里，并在該公司引入了部分的Scrum實踐。后來，受到一份關(guān)于波特蘭公司超生產(chǎn)力的項目的報告的影響，他們首先有效的使用了結(jié)構(gòu)化的每日會議。在1995年，KenSchwaber和JeffSutherland一起在Easel公司里把Scrum正規(guī)化，其結(jié)果發(fā)表于1995年。在1996年，Sutherland加盟獨立公司，而且邀請Schwaber協(xié)助將Scrum的概念應(yīng)用于更多的實際項目里，適用于需求難以預測的復雜商務(wù)應(yīng)用產(chǎn)品的開發(fā)。在2001中，他們把Scrum擴展成一個新的版本。

Scrum將工業(yè)過程控制中的概念應(yīng)用到軟件開發(fā)中來，認為軟件開發(fā)過程更多是經(jīng)驗性過程(EmpiricalProcess)，而不是確定性過程(DefinedProcess)。確定性過程是可明確描述的、可預測的過程，因而可重復（Repeatable）執(zhí)行并能產(chǎn)生預期的結(jié)果，能通過科學理論對其最優(yōu)化。

經(jīng)驗性過程與之相反，應(yīng)作為一個黑箱（BlackBox）來處理，通過對黑箱的輸入輸出不斷進行度量，在此基礎(chǔ)上，結(jié)合經(jīng)驗判斷對黑箱進行調(diào)控，使其不越出設(shè)定的邊界，從而產(chǎn)生滿意的輸出。Scrum方法將傳統(tǒng)開發(fā)中的分析、設(shè)計、實施視為一個黑箱，認為應(yīng)加強黑箱內(nèi)部的混沌性，使項目組工作在混沌的邊沿，充分發(fā)揮人的創(chuàng)造力。如果將經(jīng)驗性過程按確定性過程來處理（如瀑布模型），必將使過程缺乏適應(yīng)力。9.4.2

Scrum的生產(chǎn)測度 Scrum的所有實踐圍繞著一個迭代、增量的過程骨架展開。圖9.2說明了Scrum的核心系統(tǒng)表示。Scrum結(jié)合了一種每天進行的討論影響生產(chǎn)問題的站立會議，鼓勵開發(fā)人員列出正在加工哪些部件、已經(jīng)完成哪些部件以及可能遇到的問題。Scrum將開發(fā)工作按三個層次組織：短距、版本和產(chǎn)品。一個短距是30天（或4個工作周）。版本一般是若干短距、通常是6~9個短距。產(chǎn)品是一系列版本。 需求要轉(zhuǎn)換為“產(chǎn)品任務(wù)單”的客戶增值功能列表，可以在項目開展以后增加產(chǎn)品任務(wù)單，不一定在項目的一開始就固定下來。對于每個版本，會從產(chǎn)品任務(wù)單取出一部分，編成版本任務(wù)單。對于每個短距，要從版本任務(wù)單取出一部分，編成短距任務(wù)單。短距任務(wù)單不能進一步分解，一旦達成一致就不能更改。開發(fā)團隊肯定要在30天的短距中完成，因為短距任務(wù)單不會變化。

圖9.2Scrum核心系統(tǒng)架構(gòu)9.4.3Scrum的開發(fā)方式

Scrum主管（ScrumMaster）每日會主動參與Scrum實踐，每天早上，都有一個簡短（約15分鐘）的討論項目進展的Scrum會議，他聆聽每位成員的工作報告，并和所期待的情況進度做出比較。例如，如果有人花費了3天時間在一個簡單的工作上，那就是說這位成員需要幫助。Scrum主管也會了解整個隊伍在進度速度方面的報告：他們是否停滯不前？是否被誤導？是否在前進？當成員需要幫助時，管理層應(yīng)該參與解決問題。 在每日的Scrum的會議里，團隊報告他們遇到了障礙而不能自行解決時，Scrum主管就要負責解決，若問題連他都不能馬上解決，便要盡快將問題報告高層了解。當問題被提升時，Scrum主管讓組織知道他們團隊的政策、過程、結(jié)構(gòu)和設(shè)備等，這有助于組織迅速解決問題。9.4.4

Scrum實踐

Scrum實踐不像其他的軟件模型，并沒有說明設(shè)計、編碼、軟件質(zhì)量等，因為Scrum強調(diào)程序員的自我組織。我們先簡單了解Scrum是怎樣去管理一個軟件開發(fā)項目的。先從用戶需求開始，像極限編程中的用戶故事一樣，系統(tǒng)需求被分為一系列的子需求，叫產(chǎn)品Backlog。所有的產(chǎn)品Backlog都由一個人來管理，叫做產(chǎn)品擁有者。有什么需求變更，都應(yīng)通過產(chǎn)品擁有者去增加或刪除產(chǎn)品Backlog。 產(chǎn)品擁有者和程序員（Scrum團隊）一起計算開發(fā)每個產(chǎn)品Backlog所需的時間。但產(chǎn)品擁有者會決定哪些產(chǎn)品Backlog應(yīng)該先做。一部分產(chǎn)品Backlog被先挑選出來，Scrum團隊就會在未來30天內(nèi)完成，這部分產(chǎn)品Backlog叫做SprintBacklog，而這30天則叫做Sprint。當Scrum團隊開始了Sprint后，沒人能夠干擾Scrum團隊，團隊將會自我組織。 他們可以一周工作60個小時，可以結(jié)對編程或單人編程等，但是他們要承諾在30天后完成SprintBacklog。另外，每天早上，團隊要出席15分鐘的Scrum會議，成員可以向Scrum主管報告遇到的任何解決不了的問題。Scrum主管的角色相當?shù)闹匾?，他要保持團隊不斷進步且不受外界干擾。30天后，也就是一個Sprint完畢了，Scrum主管將會報告在過去的30天完成的工作和下一個Sprint的任務(wù)。

接下來我們需要了解的就是Scrum中每個角色和實踐的細節(jié)。

1.產(chǎn)品Backlog

產(chǎn)品Backlog是指任何認為對系統(tǒng)必要的需求，或者是認為應(yīng)有的需求。

2.產(chǎn)品主管產(chǎn)品擁有者管理產(chǎn)品Backlog，他會和Scrum團隊一起估算大概需要多少時間開發(fā)每一個產(chǎn)品Backlog。

3.Scrum團隊

Scrum主管和Scrum團隊開會并回顧檢討產(chǎn)品Backlog，Scrum團隊會承諾在未來30天（Sprint）內(nèi)完成哪些產(chǎn)品Backlog，團隊對每個Sprint都要有這樣的約束，但在Sprint內(nèi)，團隊有權(quán)去安排需要的事情，唯一的限制就是不能與公司的標準和傳統(tǒng)慣例有沖突。

4.每日Scrum會議

每個Scrum團隊每天早上都要出席一個15分鐘的Scrum狀態(tài)報告會議。在會議中，團隊要簡短回答三個問題：（1）從上次會議以后到現(xiàn)在有什么新的進展；（2）有什么正在阻礙工作的進行；（3）在下次會議之前將做什么

5.Sprint計劃會議

Sprint計劃會議其實是由兩個連續(xù)的會議組成的。在第一個會議里，Scrum團隊、產(chǎn)品擁有者、管理層和用戶一起討論，明確在下一個Sprint里應(yīng)該建立哪些功能。在第二個會議里，Scrum團隊自己確定如何在下一個Sprint里面編寫這些功能。

6.SprintScrum團隊在30天里把SprintBacklog開發(fā)出來，這段期間叫做Sprint。

7.Sprint回顧當Sprint完結(jié)后，便要舉行Sprint回顧會議，而在Scrum主管要協(xié)調(diào)和引導此會議，并和團隊成員一起訂立議程等。

8.Scrum中嵌套Scrum

前面已經(jīng)介紹了一個小的Scrum團隊，他們?yōu)橐粋€8人的團隊，若超過這個規(guī)模便很難有效的工作，團隊的生產(chǎn)力便會下降，團隊的控制機構(gòu)（就是每日Scrum和SprintBacklog）會變得很臃腫，所有只能應(yīng)付中小型的項目。但對于比較大型的項目來說，Scrum團隊的規(guī)?？梢詳U展嗎？答案是肯定的。Scrum能夠適用于100個隊員的團隊，而其方法很簡單，就是Scrum中嵌套Scrum，如圖9.3所示。 我們總結(jié)出以下Scrum實踐的特征：◎Scrum團隊是自我定向以及自我組織的團隊◎一旦選定工作，便限定在30天里，不許再另外增加工作◎每天有15分鐘的會議，討論關(guān)鍵問題◎通常30天為一個循環(huán)◎每個循環(huán)結(jié)束后，有一個回顧會議◎每個循環(huán)的計劃，都以客戶的需求為驅(qū)動Scrum團隊Scrum主管Scrum團隊Scrum團隊Scrum團隊嵌套Scrum的Scrum主管9.4.5

監(jiān)測進展 JeffSutherland與KenSchwaber合作發(fā)展了Scrum，并將其應(yīng)用到了實際的項目，他們改進了Scrum監(jiān)測使之達到一個合理的日常管理費用——開發(fā)人員每日一分鐘，項目經(jīng)理每日10分鐘。Scrum使用一種十分簡單但強有力的工具來監(jiān)測項目的進展：一張Sprint待交付表圖。該圖在水平軸上劃分日期，在垂直軸上標記按小時計算剩余的工作：在30天期限結(jié)束的時候，剩余的工作量應(yīng)該為0。所以在開始以前剩余的工作應(yīng)該為預計完成所有Sprint待交付表特性所需的全部小時數(shù)。每一天，在Jeff的系統(tǒng)中，開發(fā)人員記錄完成一項工作消耗的時間和完成的百分比。自動待交付表工具計算工作完成量和剩余量。如果一個開發(fā)人員有一個需要兩天完成的任務(wù)在開始后變成了一個三天的任務(wù)，項目領(lǐng)導會得到二個方面日常反饋，一個是項目進展（或者延期等其他方面），一個是證明不夠準確的預計。9.4.6

Scrum方法的實踐效果和發(fā)展方向

Scrum在實踐中大大提高了生產(chǎn)率（根據(jù)軟件生產(chǎn)率組織的CapersJones稱可提高6倍），在實施中有一個“間斷平衡”（Punctuatedequilibrium）現(xiàn)象（類似于自然界中物種的進化，在經(jīng)過一段相對平衡的各自獨立、并行的發(fā)展期后，在交匯處發(fā)生變異），即在經(jīng)過緊張、并行的Sprint開發(fā)后，在Sprint評審時，軟件產(chǎn)品產(chǎn)生較劇烈的變化。敏捷軟件開發(fā)有不少的指導性原則，指導軟件開發(fā)者怎樣開發(fā)軟件。因為敏捷聯(lián)盟中的17個人里面有6個是XP的支持者，我們應(yīng)該相當清楚，XP中的大部分實踐能夠反映這些敏捷規(guī)則。Scrum方法也在設(shè)法借鑒XP方法。9.4.7

Scrum案例分析

失敗案例一： 某知名大型互聯(lián)網(wǎng)公司，被采訪者是一個叫David的工程師。他是這樣總結(jié)失敗的原因：“有些高層錯誤理解了Scrum和Agile，導致歪曲了某些東西，使得Agile變得形式化”他們在項目中嘗試使用了SCRUM中的一個實踐：每日SCRUM會議。下面是David描述不了解SCRUM的項目經(jīng)理，如何使用這個實踐的： “項目經(jīng)理發(fā)現(xiàn)這個東西挺好，就單獨把DailyScrum拿來進行推廣；結(jié)果，這個經(jīng)理并不理解什么是Scrum，他把DailyScrum變成了DailyReport：每個員工都要在早上固定時間開DailyScrum，然后把當天的任務(wù)告訴給他，讓他來決定工作是不是飽滿。而其他Scrum的精華部分都沒有推廣?！笔“咐?一個離岸開發(fā)的某創(chuàng)業(yè)型公司。雖然團隊比較特殊（離岸開發(fā)團隊），但這個失敗案例卻非常典型和普遍。 “某一天，國外的PM突然發(fā)來幾個鏈接，一看講的是一個聞所未聞的詞，就是Scrum了。好像就給了一兩天的時間去看Scrum的介紹文檔，然后就開Stand-upMeeting（站立會議）。”和第一個案例相比，這個案例的團隊是真正的在推行Scrum。從表面看，大家也是在按照Scrum框架的方式工作：有相應(yīng)劃分的角色，有具體的分解任務(wù)，有會議，也有迭代（Sprint），為什么會同樣導致失??？

成功案例分析： 下面看一下有的團隊是如何在項目引入Scrum的。他們路線是這樣：“我們不是采用純粹的Scrum，而是將Agile中的很多理念，包括XP的部分做法，然后結(jié)合現(xiàn)有的開發(fā)環(huán)境與要求，用Scrum的回顧不斷地做改進，從而找出自己的一條路。如果我們在回顧這個Sprint覺得自己代碼Review（審查）做的不好，下個Sprint就會引入新的代碼Review機制。這個Sprint覺得重復性的Bug較多，下個Sprint就會引入缺陷預防機制。我們是自底向上，先做小范圍試點，再全面推廣，中間對過程進行不斷改進”9.4.8

小結(jié) 嚴格的說，SCRUM是遵循敏捷方法的一個軟件開發(fā)框架。在SCRUM框架中，融入敏捷開發(fā)的精神和思想，就被稱作SCRUM開發(fā)方法。SCRUM是一個什么樣的開發(fā)框架呢？簡單說，它由三個角色（Role），三種會議（Ceremonie），三項工件（Artifact）組成。

角色（Role）：產(chǎn)品主管（ProcuctOwner），他負責項目的商業(yè)價值；SCRUM師傅（ScrumMaster），他負責團隊的運轉(zhuǎn)和生產(chǎn)；以及自組織的團隊。

會議（Ceremonie）：迭代計劃會議，每日晨會（dailyscrummeetings），迭代回顧會議。

工件（Artifact）：用來排列任務(wù)的優(yōu)先級和跟蹤任務(wù)。待開發(fā)任務(wù)列表（productbacklog），迭代任務(wù)列表（thesprintbacklog），進度圖（burndownchart）。9.5.1DSDM原理

DSDM無疑提出了一個探索式開發(fā)方法的概念。在DSDM早期的手冊中，它強調(diào)，“沒有什么事情能一次就做好”，強調(diào)老的80–20規(guī)則（最后20%可能很耗時），強調(diào)系統(tǒng)使用者不可能在一開始就預見所有的需求，并推薦一種迭代法，該方法中，“只要能進入下一步，當前的步驟就足夠了”。DSDM的9條原理與敏捷宣言的原理是一致的。9.5DSDM-動態(tài)系統(tǒng)開發(fā)方法1.積極的用戶參與是必要的2.必須賦予DSDM團隊決定權(quán)3.重點在于產(chǎn)品的經(jīng)常性交付4.適應(yīng)業(yè)務(wù)需要是所交付產(chǎn)品被接受的一個基本標準5.迭代和增量式開發(fā)對于最終給出精確的業(yè)務(wù)解決方案是必要的6.開發(fā)期間的任何修改都是可逆的7.需求必須定位在高水平8.測試必須貫穿整個生命周期9.所有相關(guān)人員之間的協(xié)作合作方法是至關(guān)重要的9.5.2DSDM的過程

在圖中展示了DSDM開發(fā)過程的概略圖。每個主要部分—功能模型迭代，設(shè)計與構(gòu)建迭代，以及實現(xiàn)都是他們各自的迭代過程。DSDM的三個相互關(guān)聯(lián)的迭代模型和時間框（應(yīng)用于迭代和發(fā)布）的應(yīng)用最初可能很混亂，但是一旦定義好，他們就能夠做出非常靈活的項目計劃。當看見圖9.4的DSDM圖時，你可能會想“測試”階段在哪里？再一次為了保持與敏捷哲學一致，測試不再作為一種單獨的、特殊的行為，因為它是功能模型、設(shè)計與構(gòu)建迭代的一個共有部分。協(xié)作價值和原理是DSDM的另一個要點。利用對DSDM，從事項目開發(fā)，希望能做到：◎團隊有決策權(quán)◎成員要成為項目的成功付出100%的努力◎?qū)τ趩我荒繕艘x擇多種專業(yè)化人員組成工作組◎時間是每個人成功的標準◎執(zhí)行人員可以被快速任命和獎勵◎鼓勵個人與工作組之間的協(xié)作與合作9.6.1Crystal應(yīng)用（七大體系特征）

體系特征一：經(jīng)常交付體系特征二：反思改進體系特征三：滲透式交流體系特征四：個人安全體系特征五：焦點體系特征六：與用戶建立方便的聯(lián)系體系特征七：配有自動測試、配置管理和經(jīng)常集成等功能的技術(shù)環(huán)境9.6Crystal方法9.6.2Crystal框架流程Crystal項目管理體系使用的是各種長度的嵌套式循環(huán)過程：開發(fā)、迭代、交付周期以及整個項目的開發(fā)過程，人們何時開展哪些工作取決于他們處于哪個工作周期。 大多數(shù)的項目存在7種循環(huán)： ◎項目周期(一個項目開發(fā)周期，持續(xù)時間不限) ◎交付周期(一個交付的時間單位，一個星期到3個月不等) ◎迭代周期(一個估計、開發(fā)的時間單位，一個星期到三個月不等) ◎工作周 ◎集成周期(一個開發(fā)、集成以及系統(tǒng)測試的時間單位，30分鐘到3天不等) ◎工作日 ◎開發(fā)(對一段代碼進行開發(fā)以及測試的過程，幾分鐘到幾個小時不等)Crystal項目管理系統(tǒng)要求每一個項目都應(yīng)該進行多次的交付，但不是每一次交付都要進行多次迭代。每一個周期都有它獨特的先后順序和獨有的節(jié)奏。某一天內(nèi)，不同的周期中會發(fā)出不同的活動。這些活動每時、每天、每周都在改變。因此想要做出一個完整的先行描述變得幾乎不可能。在下圖中，將各個周期進行展開，并以不同的方式將周期畫上陰影，這樣活動就能與其周期相連。9.7FDD特性驅(qū)動開發(fā)9.7.1FDD過程模型FDD(FeatureDrivenDevelopment)是由Jeff（JeffDeLuca是澳大利亞墨爾本一家名為Nebulon的IT咨詢公司的項目主任）提出的，他為那些對敏捷方法的作用感到懷疑的人提供了兩個關(guān)于特性驅(qū)動開發(fā)的成功案例。比如說新加坡一家大銀行的一個復雜的商業(yè)貸款應(yīng)用系統(tǒng)。在Jeff沒有加入該項目之前，該項目是一個巨大的困難，該項目是一個涉及大范圍的商業(yè)、公司和消費者貸款系統(tǒng)，它融合了大量的貸款憑證（從信用卡到大型跨行的公司貸款）和廣泛的貸款功能（從調(diào)查到完成后臺監(jiān)測）。在與PeterCoad（建模師）合作的新加坡項目的工作中，F(xiàn)DD得到了修正。FDD把項目中各種食物的反應(yīng)時間問題壓縮為越來越短的業(yè)務(wù)周期。

FDD過程反映了從早期的以過程為中心的方法學中學習的過程。FDD要求自始自終的足夠的過程來保證可擴展性和可重復性，并始終鼓勵創(chuàng)造性和革新。FDD堅持如下觀點：為了用于更大的項目，一個用于構(gòu)建系統(tǒng)的系統(tǒng)是必要的只有簡單的、定義良好的過程才能更好的起作用過程的步驟應(yīng)該是合乎邏輯的，并且它的價值應(yīng)能立即清晰地展現(xiàn)在每個團隊成員面前“過程自負”將阻礙實際工作的開展好的過程在幕后起作用，這樣團隊成員就可以專注于結(jié)果短的、迭代的、特性驅(qū)動的生命周期是最好的 在更高層次上對FDD進行簡單概括——它只有5個過程，如圖9.6所示?；ㄔ诿總€過程上的項目時間分解如下：過程1：開發(fā)整體模型(初始10%，項目進行中4%)過程2：構(gòu)建特性列表(4%，項目進行中1%)過程3：按特性制定計劃(2%，項目進行中2%)過程