敏捷軟件過程

第九章

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

雖然以上右項也有價值，但是我們認(rèn)為左項具有更大的價值。個體和交互優(yōu)于過程和工具 這里并不是否認(rèn)過程和工具的重要性，而是更強(qiáng)調(diào)軟件開發(fā)中人的作用和交流的作用。因為軟件是由人組成的團(tuán)隊來開發(fā)的，與軟件工程相關(guān)的各類人員〔如工程經(jīng)理、建模人員、設(shè)計師、程序員、測試人員和客戶〕通過充分交流和有效合作，才能成功的開發(fā)出得到用戶滿意的軟件。如果只有定義良好的過程和先進(jìn)的工具，而人員的技能很差，又不能很好的交流和協(xié)作，軟件是很難成功開發(fā)出來的。可運行軟件高于詳盡的文檔對用戶來說，通過執(zhí)行一個可運行的軟件來了解軟件做了些什么，遠(yuǎn)比閱讀厚厚的文檔要容易的多。因此，敏捷軟件開發(fā)強(qiáng)調(diào)不斷地、快速地向用戶提交可運行的軟件〔不一定是完整的軟件〕，以得到用戶的認(rèn)可。好的、必要的文檔仍是需要的，它能幫助人們理解軟件做什么、怎么做以及如何使用，但軟件工程的主要目標(biāo)是創(chuàng)立可運行的軟件。與客戶協(xié)作高于合同〔契約〕談判只有客戶才能明確的說明需要什么樣的軟件，然而大量的實踐說明，在開發(fā)的早期客戶常常不能完整地表達(dá)他們的全部要求，有些早期確定的需求，以后也可能會改變。因此，要想通過合同談判的方式，將需求固定下來常常是有困難的。敏捷軟件開發(fā)強(qiáng)調(diào)與客戶的協(xié)作，通過與客戶的交流和緊密的合作來發(fā)現(xiàn)用戶的需求。對變更及時做出反響高于遵循方案任何軟件工程的開發(fā)都應(yīng)制定一個工程方案，確定各開發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著工程的開展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會改變。因此，工程方案應(yīng)該具有可塑性，有變動的余地。當(dāng)出現(xiàn)變化時及時做出反響，修訂方案以適應(yīng)變化。開發(fā)原那么從上述的價值觀中引出了下面的12條原那么，它們是敏捷實踐區(qū)別于重型過程的特征所在?！蜃顑?yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。◎敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。即使到了開發(fā)的后期，也歡送改變需求?！蚪?jīng)常性的交付可以使用的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好?！蛟谡麄€工程開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天在一起工作。◎圍繞被鼓勵起來的個人來構(gòu)建工程。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。◎在團(tuán)隊內(nèi)部最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談?！蚩墒褂玫能浖鞘滓倪M(jìn)度度量標(biāo)準(zhǔn)?！蛎艚葸^程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。◎不斷的關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力?！蚝唵?-使未完成的工作最大化的藝術(shù)--是根本的?！蜃詈玫臉?gòu)架、需求和設(shè)計出自于自組織的團(tuán)隊?！蛎扛粢欢〞r間，團(tuán)隊會在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對自己的行為進(jìn)行調(diào)整。9.2敏捷開發(fā)方法隨著敏捷軟件的盛行和開展，敏捷開發(fā)方法得到了極大的開展，各軟件開發(fā)公司都對自己的公司采取了相適應(yīng)的過渡過程，對敏捷方法都有自己的追求和適應(yīng)點。敏捷開發(fā)方法雖然有很多種，主流可歸納為以下的六種： XPScrumCrystalMethodsFDDASDMDSDMXP的思想源自二十世紀(jì)90年代KentBeck和WardCunningham在軟件工程的合作經(jīng)歷。XP的核心是溝通、簡明、反響和勇氣。因為方案永遠(yuǎn)趕不上變化，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(jìn)。CrystalMethods由AlistairCockbum在20世紀(jì)90年代末提出。方法認(rèn)為不同類型的工程需要不同的方法。它們盡管不如XP那樣的產(chǎn)出效率，但會有更多的人能夠接受并遵循它。FDD特性驅(qū)動開發(fā)由PeterCoad,JeffdeLuca,EricLefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)工程的開發(fā)模式。此外，F(xiàn)DD是一個模型驅(qū)動的快速迭代開發(fā)過程，它強(qiáng)調(diào)的是簡化、實用。易于被開發(fā)團(tuán)隊接受，適用于需求經(jīng)常變動的工程。ASDM自適應(yīng)軟件開發(fā)由JimHighsmith在1999年正式提出，ASDM強(qiáng)調(diào)開發(fā)方法的適應(yīng)性，這一思想來源于復(fù)雜系統(tǒng)的混沌理論。ASDM不像其他方法那樣有很多具體的實踐做法，它更側(cè)重為ASDM的重要性提供最根本的根底，并從更高的組織和管理層次來闡述開發(fā)方法為什么要具備適應(yīng)性。DSDM動態(tài)系統(tǒng)開發(fā)方法是眾多敏捷開發(fā)方法中的一種，它倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進(jìn)行系統(tǒng)開發(fā)。實踐證明[加“，〞]DSDM是成功的敏捷開發(fā)方法之一。在英國，由于其在各種規(guī)模的軟件組織中的成功，該方法已成為應(yīng)用最為廣泛的快速應(yīng)用開發(fā)方法。DSDM不但遵循了敏捷方法的原理，而且也適應(yīng)那些成熟的傳統(tǒng)開發(fā)方法——有堅實根底的軟件組織。9.3XP-極限編程9.3.1XP的根底—實踐 XP方法是敏捷方法中最著名的一個。極限編程是一個高度迭代的過程，有較多的反響對環(huán)境和需求變化做出調(diào)整，同時極限編程強(qiáng)調(diào)以小版本形式來開發(fā)系統(tǒng)，由此使用戶可以很快使用一個較小的系統(tǒng)，然后不斷增加此系統(tǒng)的功能。它的優(yōu)點就是程序員可以從客戶實際的使用情況里得到反響。極限編程誕生于一個遇到麻煩的商業(yè)軟件工程〔克萊斯勒的綜合小組—ChryslerComprehensiveCompensation簡稱C3系統(tǒng)〕，那么極限編程的實踐就應(yīng)該是實在的和具體的，而不是理論的或抽象的。極限編程與傳統(tǒng)開發(fā)方法不一樣，難以用我們熟悉的瀑布模型的開發(fā)經(jīng)驗去理解它；再者，某些普通的軟件實踐在極限編程中有時被過分強(qiáng)調(diào)，而且變得極端。

9.3.2XP方法的價值和規(guī)那么XP方法通過在一些對費用控制嚴(yán)格的公司中適用，已經(jīng)被證明是非常有效的。因此由KentBeck提出了4條根本的價值原那么：交流、簡易、反響和勇氣，在此根底上形成了12條XP工程應(yīng)遵循的實踐準(zhǔn)那么。XP還有一個最突出的特點，就是它對測試極度重視，XP的設(shè)計過程是“紀(jì)律性〞與“適配性〞的高度統(tǒng)一，這也使得XP在適配性方法中成為開展最好的一種方法。＊交流〔Communication〕XP方法強(qiáng)調(diào)交流的價值，通過交流，既可以向工程的相關(guān)人員提供信息，又可以從他們那里獲取信息。大量實踐說明，工程失敗的重要原因之一是交流不暢，使得客戶的需求不能準(zhǔn)確的傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設(shè)計的變動未能及時告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難等。因此，所有工程相關(guān)人員之間充分而有效的交流是軟件開發(fā)成功所必不可少的。＊簡單〔Simplicity〕XP團(tuán)隊使他們的設(shè)計盡可能的簡單、具有表現(xiàn)力。此外，他們僅僅關(guān)注于方案在本次迭代中要完成的用戶素材而不會考慮那些未來的用戶素材。相反，在一次次的迭代中，他們不斷變遷系統(tǒng)設(shè)計，使之對正在實現(xiàn)的用戶素材而言始終保持在最優(yōu)狀態(tài)。簡單的價值使得軟件開發(fā)是敏捷的，它表達(dá)了敏捷開發(fā)的一次，并且只有一次〔Justenough〕的指導(dǎo)思想，即開發(fā)中的代碼及其制品既不需要太多也不需要太少，剛好即可。今天只做今天的事，明天如需要，那么通過不斷的改進(jìn)設(shè)計和重構(gòu)來滿足明天的需求。今天所保持的簡潔，可以降低明天由于變更所帶來的費用。＊反響〔Feedback〕Beck說：“對于編程而言，樂觀主義是一種冒險。而反響那么是相應(yīng)的解決良藥。〞及時有效的反響，其價值表達(dá)在能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。XP的實踐者認(rèn)為反響比起前饋〔Feedforward〕來得更為重要。無論是用反復(fù)的構(gòu)建或者頻繁的用戶功能測試，XP都能不斷地接收到反響，而反響的及時程度是很重要的，它能及時發(fā)現(xiàn)偏差，并對軟件環(huán)境有很好的認(rèn)識。＊勇氣〔Courage〕無論你是使用CMM方法或者是XP的方法，方法使用的本身就是需要勇氣的。敏捷軟件開發(fā)對大多數(shù)軟件機(jī)構(gòu)來說是一個新方法，是對軟件開發(fā)現(xiàn)狀的一個挑戰(zhàn)，因此采用敏捷軟件就更需要勇氣。XP方法的12個核心實踐 XP的實踐、價值、原那么和活動之間的關(guān)系是：原那么來自于價值；而價值和原那么又是以12個實踐為根底的；12個實踐關(guān)聯(lián)著四個主要的軟件開發(fā)活動。XP實踐提供了對實際操作的指導(dǎo)?？梢杂靡粋€很簡單的圖示來表示出這四者之間的關(guān)系〔如圖9.1所示〕。圖9.1極限編程的實踐、價值、原那么和活動某些軟件模型具有很大的強(qiáng)制性，在開發(fā)階段中規(guī)定了必須進(jìn)行的實踐，目的卻并不是為了提高隊伍的開發(fā)能力，往往只是為了方便管理層去監(jiān)控工程。XP是一個價值驅(qū)動的模型，所有實踐必須表達(dá)出價值。這意味著，當(dāng)在某些情況下不能表達(dá)出XP的價值時，就沒有必要進(jìn)行這些實踐了；另一方面，即使有的實踐不包括在以下介紹的12個極限編程實踐中，只要能表達(dá)出XP的價值，XP的隊伍也是可以采用的?！暾膱F(tuán)隊XP方法要求所有團(tuán)隊成員應(yīng)該在同一個場所工作。成員中必須有一名現(xiàn)場用戶，由他提出需求，確定需求的優(yōu)先級，編寫驗收測試用例。通常團(tuán)隊還設(shè)一位“教練〞角色，指導(dǎo)XP方法的實施，負(fù)責(zé)與外部溝通和協(xié)作?！桨笇Σ?XP工程每兩周交付一次可以工作的軟件。每兩周的迭代〔Iteration,也可稱為重復(fù)周期或循環(huán)周期〕都實現(xiàn)了現(xiàn)場用戶的一些要求。在每次迭代結(jié)束時，會給現(xiàn)場用戶演示迭代生成的系統(tǒng)，以得到他們的反響。

迭代方案

發(fā)布方案每次迭代通常耗時兩周。這是一次較小的交付，可能會被參加到產(chǎn)品中，也可能不會。它由客戶根據(jù)開發(fā)人員確定的預(yù)算而選擇的一些用戶素材組成。XP團(tuán)隊通常會創(chuàng)立一個方案來規(guī)劃隨后大約6次迭代的內(nèi)容，這就是所謂的發(fā)布方案。一次發(fā)布通常需要3個月的工作。它表示了一次較大的交付，通常此次交付會被參加到產(chǎn)品中。發(fā)布方案是由一組客戶根據(jù)開發(fā)人員給出的預(yù)算所選擇的、排好優(yōu)先級別的用戶素材組成?！[喻 隱喻是所有XP實踐中最難理解的一個。設(shè)定XP工程隱喻(Metaphor)的前提是所有的工程參與人員都必須對相關(guān)的抽象概念有統(tǒng)一的、具體的認(rèn)識。在克萊斯勒薪酬支付系統(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)有其可表達(dá)的價值，但實際上某一個故事的價值，在很大程度上要依賴于其他故事或支持其他故事的實行?！鶞y試驅(qū)動 XP方法提倡測試優(yōu)先，即用戶素材的驗收測驗是在就要實現(xiàn)該用戶素材之前或?qū)崿F(xiàn)該用戶素材的同時進(jìn)行編寫的。測試優(yōu)先為開發(fā)人員提供編程前對代碼進(jìn)行周密思考的時機(jī)，使開發(fā)人員很快發(fā)現(xiàn)他們的想法實際上是否可行?！唵卧O(shè)計 簡單設(shè)計就是編碼時，只依據(jù)當(dāng)時的需求，程序員不必為可能發(fā)生的改變或擴(kuò)展考慮。因為使用XP的開發(fā)人員認(rèn)識到，只有代碼可讀性、可維護(hù)性及單元測試，才會真正影響到將來代碼修改的難度和本錢。如果代碼的可維護(hù)性足夠好，做任何的更改都不是太大的問題。 另外，簡單設(shè)計還包括其他四個意思：1.要通過測試。2.防止重復(fù)的代碼。3.明確表達(dá)每一步編碼的目的，即代碼的可讀性。4.使用盡可能少的對象類和對象方法?！貥?gòu)重構(gòu)(Refactoring)可以用簡單的數(shù)學(xué)方法來解釋，即以更簡潔而直接的表達(dá)式來代替難懂或繁瑣的表達(dá)式。表達(dá)式越復(fù)雜，重構(gòu)的優(yōu)點就越明顯。因此重構(gòu)是在不影響既有程序行為的前提下，對源代碼進(jìn)行改進(jìn)和簡化。在整個開發(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)隊的效率，而且會大大減少缺陷率。在XP中突出強(qiáng)調(diào)結(jié)對編程，即所有的產(chǎn)品代碼都是由結(jié)對的程序員使用同一電腦共同完成的，并且兩個人的角色可以互換即動態(tài)調(diào)整。結(jié)對的關(guān)系每天至少要改變一次，以便于每個程序員在一天中可以在兩個不同的結(jié)對中工作。在一次迭代期間，每個團(tuán)隊成員應(yīng)該和所有其他的團(tuán)隊成員在一起工作過，并且他們應(yīng)該參與本次迭代中所涉及的每項工作。這將極大促進(jìn)知識在團(tuán)隊中的傳播。另外，個別人員的流動對工程的進(jìn)展造成的影響也會降到最低。 在XP里，結(jié)對編程所能帶來的好處可歸結(jié)為以下幾點： 1.所有的設(shè)計都是由兩個人討論決定的。 2.系統(tǒng)的任何一個局部都至少有兩個人熟悉，防止了由于人事更替造成的問題。 3.減小了忽略編寫編程用例的幾率，因為結(jié)對者會互相提醒對方。 4.在編程過程中與不同的人結(jié)對可以進(jìn)一步增強(qiáng)知識與經(jīng)驗的共享。 5.所有編碼都隨時得到檢驗。 6.兩個程序員可以同時分別關(guān)注操作層面和理論層面，加強(qiáng)了程序的設(shè)計。但在實際操作中，結(jié)對編程作為XP中的一個核心實踐，它的生產(chǎn)力或效率常被質(zhì)疑?！掷m(xù)集成 程序員每天會屢次的插入他們的代碼并進(jìn)行集成，規(guī)那么很簡單。第一個插入的只要完成插入就可以了，所有其他的人負(fù)責(zé)代碼的合并工作。持續(xù)集成(ContinuousIntegration)能保持工程組中所有開發(fā)好的模塊始終是組裝完畢，完畢集成測試且是可執(zhí)行的。 持續(xù)集成的關(guān)鍵在于當(dāng)天必須完成所有代碼的集成。假設(shè)一個集成任務(wù)，在當(dāng)天不能完成，這意味著集成過于復(fù)雜，因此最好分步實行；否那么就說明采用的解決方法過于復(fù)雜，需要一個更簡單的來代替。假設(shè)集成問題不能當(dāng)天解決，便要有勇氣丟掉當(dāng)天的工作，重新來過?！w代碼所有權(quán) 結(jié)對編程中的每一個都具有拆出任何模塊并對它進(jìn)行修改的權(quán)力。沒有程序員對任何一個特定的模塊或技術(shù)單獨負(fù)責(zé)。沒有人比其他人在一個模塊或者技術(shù)上具有更多的權(quán)威。因此總體上每個成員都對整個系統(tǒng)有了一定程度的了解。此外，結(jié)對編程、編碼標(biāo)準(zhǔn)、持續(xù)集成等實踐都是為代碼全體共有提供支持的，能及時發(fā)現(xiàn)因修改代碼而引起的沖突，防止沖突的集中爆發(fā)。

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

XP方法強(qiáng)調(diào)制定一個統(tǒng)一的編碼標(biāo)準(zhǔn)，包括命名、注釋、格式等編程風(fēng)格，使得所有的程序代碼就像出自一人之手。編碼標(biāo)準(zhǔn)這一實踐的關(guān)鍵，并不在于編制怎樣的標(biāo)準(zhǔn)，而在于所有人都要共同遵守。這和工業(yè)生產(chǎn)中運用統(tǒng)一的產(chǎn)品標(biāo)準(zhǔn)有類似的作用?！沙掷m(xù)步調(diào) XP方法強(qiáng)調(diào)每周40小時工作制。由于人的精力是有限的，敏捷軟件開發(fā)要求每個團(tuán)隊的成員都能始終保持精力充分，充滿活力。長時間超負(fù)荷的工作會影響工作效率，因此，XP方法要求每周工作時間不超過40小時，即使加班，也不要連續(xù)工作超過兩周。以上從價值、原那么、實踐、活動及其之間的聯(lián)系對極限編程做了介紹。極限編程與傳統(tǒng)編程方式的最大不同，是容許系統(tǒng)需求在開發(fā)過程中變更。XP以迭代過程來支持對需求變化做出相應(yīng)的改變。XP的價值高于實踐，進(jìn)行這些實踐的目的都是為了實現(xiàn)XP的價值。表9-1總結(jié)了XP和傳統(tǒng)方法的區(qū)別。表9-1極限編程和傳統(tǒng)方法的區(qū)別傳統(tǒng)編程方法極限編程客戶的溝通是有限的使客戶參與到開發(fā)小組中沒有隱喻使用了隱喻軟件設(shè)計是在設(shè)計階段確立軟件是連續(xù)設(shè)計的基于將來可能的條件進(jìn)行設(shè)計基于當(dāng)前情況進(jìn)行設(shè)計實施較為復(fù)雜操作相當(dāng)簡單開發(fā)人員獨立進(jìn)行工作結(jié)對編程分派任務(wù)組員自行協(xié)調(diào)任務(wù)定期進(jìn)行集成持續(xù)進(jìn)行集成對于需求改變，隊伍是恐懼的對于需求改變，隊伍是進(jìn)取的軟件開發(fā)完畢后測試軟件修改前后都測試上下級之間溝通有限積極地多方面溝通9.3.4XP案例分析工程概況及背景： 實例公司——亞洲領(lǐng)先的電子商務(wù)解決方案供給商，在J2EE架構(gòu)的工程執(zhí)行方面有豐富的經(jīng)驗，結(jié)合RUP(RationalUnifiedProcess)形成了自己的一套電子商務(wù)工程實施方法論，并在多個工程中成功進(jìn)行實施。同時，由于具體工程時間和本錢的限制，也出現(xiàn)了一些問題，主要有以下兩點： 1.工程交付后，用戶提出很多的修改意見，有些甚至涉及系統(tǒng)架構(gòu)的修改，出現(xiàn)這種情況的主要原因是：很多工程雖然是采用增量迭代式的開發(fā)周期，但是在部署前才發(fā)布版本，用戶只是在工程部署后才看到真正的系統(tǒng)，因此會發(fā)現(xiàn)很多界面、流程等方面的問題。 2.對于用戶提交Bug的修改周期過長：開發(fā)人員在做開發(fā)的時候，對于單元測試的重視程度不夠，模塊開發(fā)結(jié)束后就提交給測試人員進(jìn)行測試，而測試人員由于時間的關(guān)系，并不能發(fā)現(xiàn)所有的問題；在用戶提交Bug后，開發(fā)人員由于工程接近尾聲，對于代碼的修改產(chǎn)生惰性，同時又沒有形成有效的回歸測試方法，因此修改的周期比較長。 針對XP的核心價值，可以看到，如果能夠加強(qiáng)與用戶的溝通、增加工程中測試實施的力度，就可以從一定程度上解決上述問題。 從2001年開始，公司內(nèi)部展開對于XP等敏捷方法的研究，希望能夠借鑒一些做法，來完善工程方法論。2002年5月，上層決定在公司的一個新的工程中啟用XP的一些最正確實踐，來檢驗其效果。該工程是為一家國際知名生產(chǎn)廠商的合作伙伴提供配件定購、申請、回收等效勞，工程的情況如下表9-2所示：

條

目描

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

4.方案博弈(PlanningGame) XP：要求結(jié)合工程進(jìn)展和技術(shù)情況，確定下一階段要開發(fā)與發(fā)布的系統(tǒng)范圍。 評述：工程的方案在建立起來以后，需要根據(jù)工程的進(jìn)展來進(jìn)行調(diào)整，一成不變的方案是不存在。因此，工程團(tuán)隊需要控制風(fēng)險、預(yù)見變化，從而制定有效、可行的工程方案。 工程：在系統(tǒng)實現(xiàn)前，首先按照需求的優(yōu)先級做了迭代周期的劃分，將高風(fēng)險的需求優(yōu)先實現(xiàn)；同時，工程團(tuán)隊每天早晨參加一個15分鐘的工程會議，確定當(dāng)天以及目前迭代周期中每個成員要完成的任務(wù)。5.系統(tǒng)隱喻(SystemMetaphor) XP：通過隱喻來描述系統(tǒng)如何運作、新的功能以何種方式參加到系統(tǒng)。它通常包含了一些可以參照和比較的類和設(shè)計模式。XP不需要事先進(jìn)行詳細(xì)的架構(gòu)設(shè)計。 評述：XP在系統(tǒng)實現(xiàn)初期不需要進(jìn)行詳細(xì)的架構(gòu)設(shè)計，而是在迭代周期中不斷的細(xì)化架構(gòu)。對于小型的系統(tǒng)或者架構(gòu)設(shè)計的分析會推遲整個工程的方案的情況下，逐步細(xì)化系統(tǒng)架構(gòu)倒是可以的；但是，對于大型系統(tǒng)或者是希望采用新架構(gòu)的系統(tǒng)，就需要在工程初期進(jìn)行詳細(xì)的系統(tǒng)架構(gòu)設(shè)計，并在第一個迭代周期中進(jìn)行驗證，同時在后續(xù)迭代周期中逐步進(jìn)行細(xì)化。 工程：開發(fā)團(tuán)隊在設(shè)計初期，決定參照STRUTS框架，結(jié)合工程的情況，構(gòu)建了針對工作流程處理的工程框架。首先，團(tuán)隊決定在第一個迭代周期實現(xiàn)配件申請的工作流程，在實際工程開發(fā)中驗證了根本的程序框架；而后，又在其它迭代周期中，對框架逐漸精化。6.簡單設(shè)計(SimpleDesign) XP：認(rèn)為代碼的設(shè)計應(yīng)該盡可能的簡單，只要滿足當(dāng)前功能的要求，不多也不少。 評述：傳統(tǒng)的軟件開發(fā)過程，對于設(shè)計是自頂而下的，強(qiáng)調(diào)設(shè)計先行，在代碼開始編寫之前，要有一個完美的設(shè)計模型。它的前提是需求不變化，或者很少變化；而XP認(rèn)為需求是會經(jīng)常變化的，因此設(shè)計不能一蹴而就，而應(yīng)該是一項持續(xù)進(jìn)行的過程。 盡可能包含最少的類與方法。對于國內(nèi)大局部的軟件開發(fā)組織來說，應(yīng)該首先確定一個靈活的系統(tǒng)架構(gòu)，而后在每個迭代周期的設(shè)計階段可以采用XP的簡單設(shè)計原那么，將設(shè)計進(jìn)行到底。 工程：在工程的系統(tǒng)架構(gòu)經(jīng)過驗證后的迭代周期內(nèi)，堅持簡單設(shè)計的原那么。對于新的迭代周期中出現(xiàn)需要修改設(shè)計和代碼的情況，首先對原有系統(tǒng)進(jìn)行“代碼重構(gòu)〞，而后再增加新的功能。7.測試驅(qū)動(Test-driven) XP：強(qiáng)調(diào)“測試先行〞。在編碼開始之前，首先將測試寫好，而后再進(jìn)行編碼，直至所有的測試都得以通過。 評述：Rup與XP對測試都是非常的重視，只是兩者對于測試在整個工程開發(fā)周期內(nèi)首先出現(xiàn)的位置處理不同。XP是一項測試驅(qū)動的軟件開發(fā)過程，它認(rèn)為測試先行使得開發(fā)人員對自己的代碼有足夠的信心，同時也有勇氣進(jìn)行代碼重構(gòu)。測試應(yīng)該實現(xiàn)一定的自動化，同時能夠清晰的給出測試成功或者失敗的結(jié)果。在這方面，xUnit測試框架做了很多的工作，因此很多實施XP的團(tuán)隊，都采用它們進(jìn)行測試工作。 工程：我們在工程初期就對Junit進(jìn)行了一定的研究工作，在工程編碼中，采用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)，通常有兩個關(guān)鍵點應(yīng)該進(jìn)行重構(gòu)：對于一個功能實現(xiàn)和實現(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)的時候要注意，不要過分的依賴重構(gòu)，甚至輕視設(shè)計，否那么，對于大中型的系統(tǒng)而言，將設(shè)計推遲或者干脆不作設(shè)計，會造成一場災(zāi)難。 工程：我們在工程中將Jrefactory工具部署到JBuilder中進(jìn)行代碼的重構(gòu)，重構(gòu)的時間是在各個迭代周期的前后。代碼重構(gòu)在工程中的作用是改善既有設(shè)計，而不是代替設(shè)計。9.結(jié)對編程(PairProgramming) XP：認(rèn)為在工程中采用成對編程比單獨編程更加有效。成對編程是由兩個開發(fā)人員在同一臺電腦上共同編寫解決同一問題的代碼，通常一個人負(fù)責(zé)寫編碼，而另一個負(fù)責(zé)保證代碼的正確性與可讀性。 評述：其實，成對編程是一種非正式的同級評審(PeerReview)。它要求成對編程的兩個開發(fā)人員在性格和技能上應(yīng)該相互匹配，目前在國內(nèi)還不是十分適合推廣。成對編程只是加強(qiáng)開發(fā)人員溝通與評審的一種方式，而非唯一的方式。具體的方式可以結(jié)合工程的情況進(jìn)行。 工程：在工程中并沒有采用成對編程的實踐，而是在工程實施的各個階段，加強(qiáng)了走查以及同級評審的力度。需求獲取、設(shè)計與分析都有多人參與，在成果提交后，交叉進(jìn)行走查；而在編碼階段，開發(fā)人員之間也要在每個迭代周期后進(jìn)行同時評審。10.集體代碼所有權(quán)〔CollectionOwnership〕 XP：認(rèn)為開發(fā)小組的每個成員都有更改代碼的權(quán)利，所有的人對于全部代碼負(fù)責(zé)。 評論：代碼全體擁有并不意味者開發(fā)人員可以互相推委責(zé)任，而是強(qiáng)調(diào)所有的人都要負(fù)責(zé)。如果一個開發(fā)人員的代碼有錯誤，另外一個開發(fā)人員也可以進(jìn)行BUG的修復(fù)。在目前，國內(nèi)的軟件開發(fā)組織，可以在一定程度上實施該實踐，但是同時需要注意一定要有嚴(yán)格的代碼控制管理。 工程：我們在工程開發(fā)初期，首先向開發(fā)團(tuán)隊進(jìn)行“代碼全體擁有〞的教育，同時要求開發(fā)人員不僅要了解系統(tǒng)的架構(gòu)、自己的代碼，同時也要了解其它開發(fā)人員的工作以及代碼情況。這個實踐與同級評審有一定的互補(bǔ)作用，從而保證人員的變動不會對工程的進(jìn)度造成很大的影響。在工程執(zhí)行中，有一個開發(fā)人員由于參加培訓(xùn)，缺席工程執(zhí)行一周，由于實行了“代碼全體擁有〞的實踐，其它的開發(fā)人員成功地分擔(dān)了該成員的測試與開發(fā)任務(wù)，從而保證工程的如期交付。11.持續(xù)集成(ContinuousIntegration) XP：提倡在一天中集成系統(tǒng)屢次，而且隨著需求的改變，要不斷的進(jìn)行回歸測試。因為，這樣可以使得團(tuán)隊保持一個較高的開發(fā)速度，同時防止了一次系統(tǒng)集成的惡夢。 評述：持續(xù)集成也不是XP專有的最正確實踐，著名的微軟公司就有每日集成(DailyBuild)的成功實踐。但是，要注意的是，持續(xù)集成也需要良好的軟件配置變更管理系統(tǒng)的有效支持。 工程：使用VSS作為軟件配置管理系統(tǒng)，堅持每天進(jìn)行一次的系統(tǒng)集成，將已經(jīng)完成的功能有效地結(jié)合起來，進(jìn)行測試。12.小型發(fā)布(SmallRelease) XP：強(qiáng)調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本，從而可以很容易地估計每個迭代周期的進(jìn)度，便于控制工作量和風(fēng)險；同時，也可以及時處理用戶的反響。 評論：小型發(fā)布突出表達(dá)了敏捷方法的優(yōu)點。RUP強(qiáng)調(diào)迭代式的開發(fā)，對于系統(tǒng)的發(fā)布并沒有作出過多的規(guī)定。用戶在提交需求后，只有在部署時才能看到真正的系統(tǒng)，這樣就不利于迅速獲得用戶的反響。如果能夠保證測試先行、代碼重構(gòu)、持續(xù)集成等最正確實踐，實現(xiàn)小型發(fā)布也不是一件困難的事情，在有條件的組織可以考慮使用。 工程：工程在籌備階段就配置了一臺測試與發(fā)布效勞器，在工程實施過程中，平均每兩周〔一個迭代周期結(jié)束后〕進(jìn)行一個小型發(fā)布；用戶在發(fā)布后兩個工作日內(nèi)，向工程小組提交"用戶接收測試報告"，由工程經(jīng)理評估測試報告，將有效的BUG提交至RationalClearCase，并分配給相應(yīng)的開發(fā)人員。工程小組應(yīng)該在下一個迭代周期結(jié)束前修復(fù)所有用戶提交的問題。 以上是XP的最正確實踐在工程中的應(yīng)用情況，讓我們查看以下該工程的詳細(xì)統(tǒng)計數(shù)據(jù)表9-3：表9-3工程管理統(tǒng)計數(shù)據(jù)表條目描述項目開始時間2002/4/25項目預(yù)期結(jié)束時間2002/6/28項目實際結(jié)束日期2002/7/2項目預(yù)計成本199080項目實際成本177340CPI(ConsumerPriceIndex)1.155SPI(SchedulePerformanceIndex)1.028其中，工程執(zhí)行過程中提交了一個“用戶需求變更〞，該變更對于工程周期的影響為6個工作日。工程實施后，在用戶接收測試中，只提交了2個BUG，而且在提交當(dāng)天就得到了解決。目前，工程運行平穩(wěn)，并得到了用戶的好評。因此，我們認(rèn)為，XP在該工程中的實施有效地保證了工程質(zhì)量和工程周期。9.4Scrum簡史 Scrum在橄欖球中叫正集團(tuán)，正集團(tuán)以一個緊密整合的單位來協(xié)作，每個隊員都扮演一個定義明確的角色，并且在團(tuán)隊的每個進(jìn)展中完成自己所擔(dān)負(fù)的任務(wù)。整個團(tuán)隊有一個單一的焦點，工作的優(yōu)先權(quán)也是清楚的。因此，我們希望軟件隊伍像Scrum一樣，以一種高度整合的方式工作；另外，他們也是個自我定向和自我組織的團(tuán)隊。 把橄欖球中的正集團(tuán)〔Scrum〕的協(xié)作理念應(yīng)用到管理上，源自一本《創(chuàng)新求勝-智價企業(yè)論》[TakeuchiandNonaka1986]總結(jié)十家日本創(chuàng)新公司共同最正確實踐的著作。在該書中首次用橄欖球中Scrum在場地中移動橄欖球的團(tuán)隊行為，來解釋適應(yīng)性且自我組織的團(tuán)隊特征。 在1994年，JeffSutherland把這樣的團(tuán)隊特征應(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)用于更多的實際工程里，適用于需求難以預(yù)測的復(fù)雜商務(wù)應(yīng)用產(chǎn)品的開發(fā)。在2001中，他們把Scrum擴(kuò)展成一個新的版本。Scrum將工業(yè)過程控制中的概念應(yīng)用到軟件開發(fā)中來，認(rèn)為軟件開發(fā)過程更多是經(jīng)驗性過程(EmpiricalProcess)，而不是確定性過程(DefinedProcess)。確定性過程是可明確描述的、可預(yù)測的過程，因而可重復(fù)〔Repeatable〕執(zhí)行并能產(chǎn)生預(yù)期的結(jié)果，能通過科學(xué)理論對其最優(yōu)化。

經(jīng)驗性過程與之相反，應(yīng)作為一個黑箱〔BlackBox〕來處理，通過對黑箱的輸入輸出不斷進(jìn)行度量，在此根底上，結(jié)合經(jīng)驗判斷對黑箱進(jìn)行調(diào)控，使其不越出設(shè)定的邊界，從而產(chǎn)生滿意的輸出。Scrum方法將傳統(tǒng)開發(fā)中的分析、設(shè)計、實施視為一個黑箱，認(rèn)為應(yīng)加強(qiáng)黑箱內(nèi)部的混沌性，使工程組工作在混沌的邊沿，充分發(fā)揮人的創(chuàng)造力。如果將經(jīng)驗性過程按確定性過程來處理〔如瀑布模型〕，必將使過程缺乏適應(yīng)力。Scrum的生產(chǎn)測度 Scrum的所有實踐圍繞著一個迭代、增量的過程骨架展開。圖9.2說明了Scrum的核心系統(tǒng)表示。Scrum結(jié)合了一種每天進(jìn)行的討論影響生產(chǎn)問題的站立會議，鼓勵開發(fā)人員列出正在加工哪些部件、已經(jīng)完成哪些部件以及可能遇到的問題。Scrum將開發(fā)工作按三個層次組織：短距、版本和產(chǎn)品。一個短距是30天〔或4個工作周〕。版本一般是假設(shè)干短距、通常是6~9個短距。產(chǎn)品是一系列版本。 需求要轉(zhuǎn)換為“產(chǎn)品任務(wù)單〞的客戶增值功能列表，可以在工程開展以后增加產(chǎn)品任務(wù)單，不一定在工程的一開始就固定下來。對于每個版本，會從產(chǎn)品任務(wù)單取出一局部，編成版本任務(wù)單。對于每個短距，要從版本任務(wù)單取出一局部，編成短距任務(wù)單。短距任務(wù)單不能進(jìn)一步分解，一旦達(dá)成一致就不能更改。開發(fā)團(tuán)隊肯定要在30天的短距中完成，因為短距任務(wù)單不會變化。

圖9.2Scrum核心系統(tǒng)架構(gòu)9.4.3Scrum的開發(fā)方式 Scrum主管〔ScrumMaster〕每日會主動參與Scrum實踐，每天早上，都有一個簡短〔約15分鐘〕的討論工程進(jìn)展的Scrum會議，他聆聽每位成員的工作報告，并和所期待的情況進(jìn)度做出比較。例如，如果有人花費了3天時間在一個簡單的工作上，那就是說這位成員需要幫助。Scrum主管也會了解整個隊伍在進(jìn)度速度方面的報告：他們是否停滯不前？是否被誤導(dǎo)？是否在前進(jìn)？當(dāng)成員需要幫助時，管理層應(yīng)該參與解決問題。 在每日的Scrum的會議里，團(tuán)隊報告他們遇到了障礙而不能自行解決時，Scrum主管就要負(fù)責(zé)解決，假設(shè)問題連他都不能馬上解決，便要盡快將問題報告高層了解。當(dāng)問題被提升時，Scrum主管讓組織知道他們團(tuán)隊的政策、過程、結(jié)構(gòu)和設(shè)備等，這有助于組織迅速解決問題。Scrum實踐Scrum實踐不像其他的軟件模型，并沒有說明設(shè)計、編碼、軟件質(zhì)量等，因為Scrum強(qiáng)調(diào)程序員的自我組織。我們先簡單了解Scrum是怎樣去管理一個軟件開發(fā)工程的。先從用戶需求開始，像極限編程中的用戶故事一樣，系統(tǒng)需求被分為一系列的子需求，叫產(chǎn)品Backlog。所有的產(chǎn)品Backlog都由一個人來管理，叫做產(chǎn)品擁有者。有什么需求變更，都應(yīng)通過產(chǎn)品擁有者去增加或刪除產(chǎn)品Backlog。 產(chǎn)品擁有者和程序員〔Scrum團(tuán)隊〕一起計算開發(fā)每個產(chǎn)品Backlog所需的時間。但產(chǎn)品擁有者會決定哪些產(chǎn)品Backlog應(yīng)該先做。一局部產(chǎn)品Backlog被先挑選出來，Scrum團(tuán)隊就會在未來30天內(nèi)完成，這局部產(chǎn)品Backlog叫做SprintBacklog，而這30天那么叫做Sprint。當(dāng)Scrum團(tuán)隊開始了Sprint后，沒人能夠干擾Scrum團(tuán)隊，團(tuán)隊將會自我組織。 他們可以一周工作60個小時，可以結(jié)對編程或單人編程等，但是他們要承諾在30天后完成SprintBacklog。另外，每天早上，團(tuán)隊要出席15分鐘的Scrum會議，成員可以向Scrum主管報告遇到的任何解決不了的問題。Scrum主管的角色相當(dāng)?shù)闹匾３謭F(tuán)隊不斷進(jìn)步且不受外界干擾。30天后，也就是一個Sprint完畢了，Scrum主管將會報告在過去的30天完成的工作和下一個Sprint的任務(wù)。

接下來我們需要了解的就是Scrum中每個角色和實踐的細(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)隊一起估算大概需要多少時間開發(fā)每一個產(chǎn)品Backlog。 3.Scrum團(tuán)隊Scrum主管和Scrum團(tuán)隊開會并回憶檢討產(chǎn)品Backlog，Scrum團(tuán)隊會承諾在未來30天〔Sprint〕內(nèi)完成哪些產(chǎn)品Backlog，團(tuán)隊對每個Sprint都要有這樣的約束，但在Sprint內(nèi)，團(tuán)隊有權(quán)去安排需要的事情，唯一的限制就是不能與公司的標(biāo)準(zhǔn)和傳統(tǒng)慣例有沖突。 4.每日Scrum會議每個Scrum團(tuán)隊每天早上都要出席一個15分鐘的Scrum狀態(tài)報告會議。在會議中，團(tuán)隊要簡短答復(fù)三個問題：〔1〕從上次會議以后到現(xiàn)在有什么新的進(jìn)展；〔2〕有什么正在阻礙工作的進(jìn)行；〔3〕在下次會議之前將做什么 5.Sprint方案會議Sprint方案會議其實是由兩個連續(xù)的會議組成的。在第一個會議里，Scrum團(tuán)隊、產(chǎn)品擁有者、管理層和用戶一起討論，明確在下一個Sprint里應(yīng)該建立哪些功能。在第二個會議里，Scrum團(tuán)隊自己確定如何在下一個Sprint里面編寫這些功能。 6.SprintScrum團(tuán)隊在30天里把SprintBacklog開發(fā)出來，這段期間叫做Sprint。 7.Sprint回憶當(dāng)Sprint完結(jié)后，便要舉行Sprint回憶會議，而在Scrum主管要協(xié)調(diào)和引導(dǎo)此會議，并和團(tuán)隊成員一起訂立議程等。 8.Scrum中嵌套Scrum前面已經(jīng)介紹了一個小的Scrum團(tuán)隊，他們?yōu)橐粋€8人的團(tuán)隊，假設(shè)超過這個規(guī)模便很難有效的工作，團(tuán)隊的生產(chǎn)力便會下降，團(tuán)隊的控制機(jī)構(gòu)〔就是每日Scrum和SprintBacklog〕會變得很臃腫，所有只能應(yīng)付中小型的工程。但對于比較大型的工程來說，Scrum團(tuán)隊的規(guī)模可以擴(kuò)展嗎？答案是肯定的。Scrum能夠適用于100個隊員的團(tuán)隊，而其方法很簡單，就是Scrum中嵌套Scrum，如圖9.3所示。 我們總結(jié)出以下Scrum實踐的特征：◎Scrum團(tuán)隊是自我定向以及自我組織的團(tuán)隊◎一旦選定工作，便限定在30天里，不許再另外增加工作◎每天有15分鐘的會議，討論關(guān)鍵問題◎通常30天為一個循環(huán)◎每個循環(huán)結(jié)束后，有一個回憶會議◎每個循環(huán)的方案，都以客戶的需求為驅(qū)動Scrum團(tuán)隊Scrum主管Scrum團(tuán)隊Scrum團(tuán)隊Scrum團(tuán)隊嵌套Scrum的Scrum主管監(jiān)測進(jìn)展 JeffSutherland與KenSchwaber合作開展了Scrum，并將其應(yīng)用到了實際的工程，他們改進(jìn)了Scrum監(jiān)測使之到達(dá)一個合理的日常管理費用——開發(fā)人員每日一分鐘，工程經(jīng)理每日10分鐘。Scrum使用一種十分簡單但強(qiáng)有力的工具來監(jiān)測工程的進(jìn)展：一張Sprint待交付表圖。該圖在水平軸上劃分日期，在垂直軸上標(biāo)記按小時計算剩余的工作：在30天期限結(jié)束的時候，剩余的工作量應(yīng)該為0。所以在開始以前剩余的工作應(yīng)該為預(yù)計完成所有Sprint待交付表特性所需的全部小時數(shù)。每一天，在Jeff的系統(tǒng)中，開發(fā)人員記錄完成一項工作消耗的時間和完成的百分比。自動待交付表工具計算工作完成量和剩余量。如果一個開發(fā)人員有一個需要兩天完成的任務(wù)在開始后變成了一個三天的任務(wù)，工程領(lǐng)導(dǎo)會得到二個方面日常反響，一個是工程進(jìn)展〔或者延期等其他方面〕，一個是證明不夠準(zhǔn)確的預(yù)計。Scrum方法的實踐效果和開展方向Scrum在實踐中大大提高了生產(chǎn)率〔根據(jù)軟件生產(chǎn)率組織的CapersJones稱可提高6倍〕，在實施中有一個“間斷平衡〞〔Punctuatedequilibrium〕現(xiàn)象〔類似于自然界中物種的進(jìn)化，在經(jīng)過一段相對平衡的各自獨立、并行的開展期后，在交匯處發(fā)生變異〕，即在經(jīng)過緊張、并行的Sprint開發(fā)后，在Sprint評審時，軟件產(chǎn)品產(chǎn)生較劇烈的變化。敏捷軟件開發(fā)有不少的指導(dǎo)性原那么，指導(dǎo)軟件開發(fā)者怎樣開發(fā)軟件。因為敏捷聯(lián)盟中的17個人里面有6個是XP的支持者，我們應(yīng)該相當(dāng)清楚，XP中的大局部實踐能夠反映這些敏捷規(guī)那么。Scrum方法也在設(shè)法借鑒XP方法。Scrum案例分析失敗案例一： 某知名大型互聯(lián)網(wǎng)公司，被采訪者是一個叫David的工程師。他是這樣總結(jié)失敗的原因：“有些高層錯誤理解了Scrum和Agile，導(dǎo)致歪曲了某些東西，使得Agile變得形式化〞他們在工程中嘗試使用了SCRUM中的一個實踐：每日SCRUM會議。下面是David描述不了解SCRUM的工程經(jīng)理，如何使用這個實踐的： “工程經(jīng)理發(fā)現(xiàn)這個東西挺好，就單獨把DailyScrum拿來進(jìn)行推廣；結(jié)果，這個經(jīng)理并不理解什么是Scrum，他把DailyScrum變成了DailyReport：每個員工都要在早上固定時間開DailyScrum，然后把當(dāng)天的任務(wù)告訴給他，讓他來決定工作是不是飽滿。而其他Scrum的精華局部都沒有推廣。〞失敗案例二： 一個離岸開發(fā)的某創(chuàng)業(yè)型公司。雖然團(tuán)隊比較特殊〔離岸開發(fā)團(tuán)隊〕，但這個失敗案例卻非常典型和普遍。 “某一天，國外的PM突然發(fā)來幾個鏈接，一看講的是一個聞所未聞的詞，就是Scrum了。好似就給了一兩天的時間去看Scrum的介紹文檔，然后就開Stand-upMeeting〔站立會議〕。〞和第一個案例相比，這個案例的團(tuán)隊是真正的在推行Scrum。從外表看，大家也是在按照Scrum框架的方式工作：有相應(yīng)劃分的角色，有具體的分解任務(wù)，有會議，也有迭代〔Sprint〕，為什么會同樣導(dǎo)致失敗？

成功案例分析： 下面看一下有的團(tuán)隊是如何在工程引入Scrum的。他們路線是這樣：“我們不是采用純粹的Scrum，而是將Agile中的很多理念，包括XP的局部做法，然后結(jié)合現(xiàn)有的開發(fā)環(huán)境與要求，用Scrum的回憶不斷地做改進(jìn)，從而找出自己的一條路。如果我們在回憶這個Sprint覺得自己代碼Review〔審查〕做的不好，下個Sprint就會引入新的代碼Review機(jī)制。這個Sprint覺得重復(fù)性的Bug較多，下個Sprint就會引入缺陷預(yù)防機(jī)制。我們是自底向上，先做小范圍試點，再全面推廣，中間對過程進(jìn)行不斷改進(jìn)〞小結(jié) 嚴(yán)格的說，SCRUM是遵循敏捷方法的一個軟件開發(fā)框架。在SCRUM框架中，融入敏捷開發(fā)的精神和思想，就被稱作SCRUM開發(fā)方法。SCRUM是一個什么樣的開發(fā)框架呢？簡單說，它由三個角色〔Role〕，三種會議〔Ceremonie〕，三項工件〔Artifact〕組成。角色〔Role〕：產(chǎn)品主管〔ProcuctOwner〕，他負(fù)責(zé)工程的商業(yè)價值；SCRUM師傅〔ScrumMaster〕，他負(fù)責(zé)團(tuán)隊的運轉(zhuǎn)和生產(chǎn)；以及自組織的團(tuán)隊。會議〔Ceremonie〕：迭代方案會議，每日晨會〔dailyscrummeetings〕，迭代回憶會議。工件〔Artifact〕：用來排列任務(wù)的優(yōu)先級和跟蹤任務(wù)。待開發(fā)任務(wù)列表〔productbacklog〕，迭代任務(wù)列表〔thesprintbacklog〕，進(jìn)度圖〔burndownchart〕。9.5.1DSDM原理 DSDM無疑提出了一個探索式開發(fā)方法的概念。在DSDM早期的手冊中，它強(qiáng)調(diào)，“沒有什么事情能一次就做好〞，強(qiáng)調(diào)老的80–20規(guī)那么〔最后20%可能很耗時〕，強(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)隊決定權(quán)3.重點在于產(chǎn)品的經(jīng)常性交付4.適應(yīng)業(yè)務(wù)需要是所交付產(chǎn)品被接受的一個根本標(biāo)準(zhǔ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)用最初可能很混亂，但是一旦定義好，他們就能夠做出非常靈活的工程方案。當(dāng)看見圖9.4的DSDM圖時，你可能會想“測試〞階段在哪里？再一次為了保持與敏捷哲學(xué)一致，測試不再作為一種單獨的、特殊的行為，因為它是功能模型、設(shè)計與構(gòu)建迭代的一個共有局部。協(xié)作價值和原理是DSDM的另一個要點。利用對DSDM，從事工程開發(fā)，希望能做到：◎團(tuán)隊有決策權(quán)◎成員要成為工程的成功付出100%的努力◎?qū)τ趩我荒繕?biāo)要選擇多種專業(yè)化人員組成工作組◎時間是每個人成功的標(biāo)準(zhǔn)◎執(zhí)行人員可以被快速任命和獎勵◎鼓勵個人與工作組之間的協(xié)作與合作9.6.1Crystal應(yīng)用〔七大體系特征〕體系特征一：經(jīng)常交付體系特征二：反思改進(jìn)體系特征三：滲透式交流體系特征四：個人平安體系特征五：焦點體系特征六：與用戶建立方便的聯(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ā)(對一段代碼進(jìn)行開發(fā)以及測試的過程，幾分鐘到幾個小時不等)Crystal工程管理系統(tǒng)要求每一個工程都應(yīng)該進(jìn)行屢次的交付，但不是每一次交付都要進(jìn)行屢次迭代。每一個周期都有它獨特的先后順序和獨有的節(jié)奏。某一天內(nèi)，不同的周期中會發(fā)出不同的活動。這些活動每時、每天、每周都在改變。因此想要做出一個完整的先行描述變得幾乎不可能。在以下圖中，將各個周期進(jìn)行展開，并以不同的方式將周期畫上陰影，這樣活動就能與其周期相連。9.7FDD特性驅(qū)動開發(fā)9.7.1FDD過程模型FDD(FeatureDrivenDevelopment)是由Jeff〔JeffDeLuca是澳大利亞墨爾本一家名為Nebulon的IT咨詢公司的工程主任〕提出的，他為那些對敏捷方法的作用感到疑心的人提供了兩個關(guān)于特性驅(qū)動開發(fā)的成功案例。比方說新加坡一家大銀行的一個復(fù)雜的商業(yè)貸款應(yīng)用系統(tǒng)。在Jeff沒有參加該工程之前，該工程是一個巨大的困難，該工程是一個涉及大范圍的商業(yè)、公司和消費者貸款系統(tǒng)，它融合了大量的貸款憑證〔從信用卡到大型跨行的公司貸款〕和廣泛的貸款功能〔從調(diào)查到完成后臺監(jiān)測〕。在與PeterCoad〔建模師〕合作的新加坡工程的工作中，F(xiàn)DD得到了修正。FDD把工程中各種食物的反響時間問題壓縮為越來越短的業(yè)務(wù)周期。FDD過程反映了從早期的以過程為中心的方法學(xué)中學(xué)習(xí)的過程。FDD要求自始自終的足夠的過程來保證可擴(kuò)展性和可重復(fù)性，并始終鼓勵創(chuàng)造性和革新。FDD堅持如下觀點：為了用于更大的工程，一個用于構(gòu)建系統(tǒng)的系統(tǒng)是必要的只有簡單的、定義良好的過程才能更好的起作用過程的步驟應(yīng)該是符合邏輯的，并且它的價值應(yīng)能立即清晰地展現(xiàn)在每個團(tuán)隊成員面前“過程自負(fù)〞將阻礙實際工作的開展好的過程在幕后起作用，這樣團(tuán)隊成員就可以專注于結(jié)果短的、迭代的、特性驅(qū)動的生命周期是最好的 在更高層次上對FDD進(jìn)行簡單概括——它只有5個過程，如圖9.6所示?；ㄔ诿總€過程上的工程時間分解如下：過程1：開發(fā)整體模型(初始10%，工程進(jìn)行中4%)過程2：構(gòu)建特性列表(4%，工程進(jìn)行中1%)過程3：按特性制定方案(2%，工程進(jìn)行中2%)過程4：按特性進(jìn)行設(shè)計過程5：按特性進(jìn)行構(gòu)建(設(shè)計和構(gòu)建共占