第9章 敏捷軟件過程

第九章

敏捷軟件過程9.1 敏捷實(shí)踐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

敏捷實(shí)踐9.1.1

敏捷聯(lián)盟

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

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

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

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

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

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

開發(fā)原則

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

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

XP

Scrum

CrystalMethods

FDD

ASDM

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

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

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

9.3.2

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

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

＊交流（Communication）

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

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

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

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

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

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

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

迭代計(jì)劃

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

※規(guī)則游戲

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

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

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

1.要通過測試。

2.避免重復(fù)的代碼。

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

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

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

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

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

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

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

3.減小了忽略編寫編程用例的幾率，因?yàn)榻Y(jié)對者會互相提醒對方。

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

5.所有編碼都隨時(shí)得到檢驗(yàn)。

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

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

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

※編碼標(biāo)準(zhǔn)

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

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

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

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

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

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

條

目描

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

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

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

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

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

Scrum9.4.1

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

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

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

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

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

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

Scrum實(shí)踐

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

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

1.產(chǎn)品Backlog

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

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

3.Scrum團(tuán)隊(duì)

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

4.每日Scrum會議

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

5.Sprint計(jì)劃會議

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

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

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

8.Scrum中嵌套Scrum

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

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

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

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

Scrum案例分析

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

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

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

角色（Role）：產(chǎn)品主管（ProcuctOwner），他負(fù)責(zé)項(xiàng)目的商業(yè)價(jià)值；SCRUM師傅（ScrumMaster），他負(fù)責(zé)團(tuán)隊(duì)的運(yùn)轉(zhuǎn)和生產(chǎn)；以及自組織的團(tuán)隊(duì)。

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

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

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

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

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

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