15敏捷軟件開(kāi)發(fā)1

第15章敏捷軟件開(kāi)發(fā)15．1敏捷軟件開(kāi)發(fā)的價(jià)值觀及開(kāi)發(fā)原則敏捷軟件開(kāi)發(fā)宣言給出了如下四個(gè)價(jià)值觀：1．個(gè)人和交互高于過(guò)程和工具這里并不是否定過(guò)程和工具的重要性，而是更強(qiáng)調(diào)軟件開(kāi)發(fā)中人的作用和交流的作用。因?yàn)檐浖怯扇私M成的團(tuán)隊(duì)來(lái)開(kāi)發(fā)的，與軟件項(xiàng)目相關(guān)的各類人員（如，項(xiàng)目經(jīng)理、建模人員、設(shè)計(jì)師、程序員、測(cè)試人員以及客戶）通過(guò)充分的交流和有效的合作，才能成功地開(kāi)發(fā)出得到用戶滿意的軟件。如果光有定義良好的過(guò)程和先進(jìn)的工具，而人員的技能很差，又不能很好地交流和協(xié)作，軟件是很難成功地開(kāi)發(fā)的。2．可運(yùn)行軟件高于詳盡的文檔對(duì)用戶來(lái)說(shuō)，通過(guò)執(zhí)行一個(gè)可運(yùn)行的軟件來(lái)了解軟件做了什么，遠(yuǎn)比閱讀厚厚的文檔要容易得多。因此敏捷軟件開(kāi)發(fā)強(qiáng)調(diào)不斷地快速地向用戶提交可運(yùn)行的軟件（不一定是完整的軟件），以得到用戶的認(rèn)可。好的必要的文檔仍是需要的，它能幫助我們理解軟件做什么，怎么做以及如何使用，但軟件開(kāi)發(fā)的主要目標(biāo)是創(chuàng)建可運(yùn)行的軟件。3．與客戶協(xié)作高于合同（契約）談判只有客戶才能明確地說(shuō)明需要什么樣的軟件，然而，大量的實(shí)踐表明，在開(kāi)發(fā)的早期客戶常常不能完整地表達(dá)他們的全部需求，有些早期確定的需求，以后也可能會(huì)改變。因此，要想通過(guò)合同談判的方式，將需求固定下來(lái)常常是困難的。敏捷軟件開(kāi)發(fā)強(qiáng)調(diào)與客戶的協(xié)作，通過(guò)與客戶的交流和緊密合作來(lái)發(fā)現(xiàn)用戶的需求。4．對(duì)變更及時(shí)做出反應(yīng)高于遵循計(jì)劃任何軟件項(xiàng)目的開(kāi)發(fā)都應(yīng)該制訂一個(gè)項(xiàng)目計(jì)劃，確定各開(kāi)發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著項(xiàng)目的進(jìn)展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會(huì)改變。因此，項(xiàng)目計(jì)劃應(yīng)具有可塑性，有變動(dòng)的余地。當(dāng)出現(xiàn)變化時(shí)及時(shí)做出反應(yīng)，修訂計(jì)劃以適應(yīng)變化。敏捷軟件開(kāi)發(fā)必須遵循的十二個(gè)原則如下：1．最優(yōu)先的是通過(guò)盡早地和不斷地提交有價(jià)值的軟件使客戶滿意；歡迎變化的需求，即使該變化出現(xiàn)在開(kāi)發(fā)的后期，為了對(duì)客戶的競(jìng)爭(zhēng)優(yōu)勢(shì)Agile過(guò)程利用變化作為動(dòng)力；以幾周到幾個(gè)月為周期，盡快、不斷地交付可運(yùn)行軟件；在整個(gè)項(xiàng)目過(guò)程中，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天一起工作；以積極向上的員工為中心建立項(xiàng)目組，給予他們所需的環(huán)境和支持，對(duì)他們的工作予以充分的信任；項(xiàng)目組內(nèi)效率最高、最有效的信息傳遞方式是面對(duì)面的交流；測(cè)量項(xiàng)目進(jìn)展的首要依據(jù)是可運(yùn)行的軟件；敏捷過(guò)程提倡可持續(xù)的開(kāi)發(fā)，項(xiàng)目發(fā)起者、開(kāi)發(fā)者和用戶應(yīng)能長(zhǎng)期保持恒定的速度；應(yīng)時(shí)刻關(guān)注技術(shù)上的精益求精和好的設(shè)計(jì)，以增強(qiáng)敏捷性；簡(jiǎn)單化（這是盡可能減少不必要工作的藝術(shù)）是必不可少的；最好的構(gòu)架、需求和設(shè)計(jì)出自于自我組織的團(tuán)隊(duì)；團(tuán)隊(duì)要定期反思怎樣才能更有效，并據(jù)此調(diào)整自己的行為。15．2XP方法簡(jiǎn)介XP是eXtremeProgramming的縮寫，稱為極限編程。它是由KentBeck于1999年提出的一種Agile方法，它適用于軟件需求模糊且揮發(fā)性（Volatile，指今天的要求明天可能就不需要了）強(qiáng)、開(kāi)發(fā)團(tuán)隊(duì)人數(shù)在10人以下、開(kāi)發(fā)地點(diǎn)集中（在一個(gè)辦公室里）的場(chǎng)合。XP方法是所有Agile方法中最引人注目的方法之一，它已成功地應(yīng)用于許多軟件項(xiàng)目的開(kāi)發(fā)中，并取得顯著的效果。如IONA公司的obix技術(shù)支持小組在采用XP方法后，其軟件生產(chǎn)率提高于67%。15．2．1XP方法的價(jià)值觀和核心實(shí)踐XP方法的四個(gè)價(jià)值觀如下：1．交流（Communication）XP方法強(qiáng)調(diào)交流的價(jià)值，通過(guò)交流你既可以向項(xiàng)目的相關(guān)人員提供信息，又可以從他們那里獲得信息。大量的實(shí)踐表明，項(xiàng)目失敗的重要原因之一是交流不暢，使得客戶的需求不能準(zhǔn)確地傳遞給開(kāi)發(fā)人員，造成開(kāi)發(fā)人員不能充分理解需求；模型或設(shè)計(jì)的變動(dòng)未能及時(shí)告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難；等等。因此，所有項(xiàng)目相關(guān)人員之間充分的有效的交流是軟件開(kāi)發(fā)成功所必不可少的。XP方法提倡面對(duì)面的交流，這是一種有效的也是效率最高的交流方式。XP方法對(duì)團(tuán)隊(duì)人數(shù)（10人以下）和開(kāi)發(fā)地點(diǎn)（在同一辦公室）的限制有利于面對(duì)面的交流。通常一張圖或幾句話就能把問(wèn)題講清楚，這遠(yuǎn)比通過(guò)文檔（包括E-mail）進(jìn)行交流的效率要高得多。2．簡(jiǎn)單（Simplicity）簡(jiǎn)單是指在確保得到客戶滿意的軟件的前提下，做最簡(jiǎn)潔的工作。包括簡(jiǎn)單的過(guò)程（如對(duì)統(tǒng)一過(guò)程的剪裁）、簡(jiǎn)單的模型（可用多種模型，如UML中的圖、結(jié)構(gòu)化的數(shù)據(jù)模型等，只要能簡(jiǎn)單地解決問(wèn)題即可）、簡(jiǎn)單的文檔（只編寫項(xiàng)目相關(guān)人員所需的必要的文檔）、簡(jiǎn)潔的設(shè)計(jì)和實(shí)現(xiàn)等。簡(jiǎn)單的價(jià)值使得軟件開(kāi)發(fā)是敏捷的，它體現(xiàn)了敏捷開(kāi)發(fā)的“剛剛好（Justenough）”思想，即開(kāi)發(fā)中的活動(dòng)及制品既不要太多也不要太少，剛好即可。今天只做要做的事，明天如需要，則通過(guò)不斷地改進(jìn)設(shè)計(jì)和重構(gòu)來(lái)滿足明天的要求。3．反饋（Feedback）及時(shí)有效的反饋的價(jià)值體現(xiàn)在能確定開(kāi)發(fā)工作是否正確，及時(shí)發(fā)現(xiàn)開(kāi)發(fā)工作的偏差并加以糾正。例如團(tuán)隊(duì)式的模型開(kāi)發(fā)，與該模型相關(guān)的人員（包括客戶）一起開(kāi)發(fā)，此時(shí)，每個(gè)人的意見(jiàn)可能在幾秒鐘或幾分鐘里就得到反饋。通過(guò)非正式的評(píng)審（如走查，Walkthrough）可在幾分鐘或幾個(gè)小時(shí)里得到反饋，這比正式評(píng)審要快得多。反饋的及時(shí)程度是很重要的，它能及時(shí)發(fā)現(xiàn)偏差，及時(shí)糾正。4．勇氣（Courage）敏捷軟件開(kāi)發(fā)對(duì)大多數(shù)軟件機(jī)構(gòu)來(lái)說(shuō)是一個(gè)新方法，是對(duì)軟件開(kāi)發(fā)現(xiàn)狀的挑戰(zhàn)，因此采用敏捷軟件開(kāi)發(fā)需要勇氣。ScottW.Ambler在他的著作“敏捷建模：極限編程和統(tǒng)一過(guò)程的有效實(shí)踐”中指出：“敏捷方法要求與其他人緊密合作，信任他們，也相信自己，這需要勇氣；XP和敏捷建模（AM）等方法要求做能做到的最簡(jiǎn)單的事，相信明天能解決明天的問(wèn)題，這需要勇氣；AM要求只有在絕對(duì)需要的時(shí)候才創(chuàng)建文檔，而不是只要覺(jué)得舒適就去創(chuàng)建，這需要勇氣；XP和AM要求讓業(yè)務(wù)人員制定業(yè)務(wù)決策，例如排定需求的優(yōu)先級(jí)，而讓技術(shù)人員制定技術(shù)決策，例如軟件怎樣去滿足各個(gè)需求，這需要勇氣;AM要求用可能的最簡(jiǎn)單的工具，例如白板和紙，只有在復(fù)雜建模工具能提供可能的最好價(jià)值時(shí)才去使用它們，這需要勇氣；AM要求不要只是為了推遲如用代碼檢證模型等困難任務(wù)，而把圖加工得更漂亮來(lái)拖延時(shí)間，這需要勇氣；AM要求信任你的同時(shí)，相信程序員能制定設(shè)計(jì)決策，因此不需要給他們提供過(guò)多的細(xì)節(jié)，這需要勇氣；AM要求決心去成功，去結(jié)束IT產(chǎn)業(yè)中接近災(zāi)難和徹底失敗的循環(huán)，這需要勇氣?！贝送?，“需要勇氣來(lái)承認(rèn)自己是會(huì)犯錯(cuò)誤的，需要勇氣來(lái)相信自己明天能克服明天出現(xiàn)的問(wèn)題。”在這本書中，作者還給出第五個(gè)價(jià)值觀：“謙虛。最好的開(kāi)發(fā)人員應(yīng)該是謙虛的，承認(rèn)自己不是無(wú)所不知的。事實(shí)上，團(tuán)隊(duì)里的每個(gè)人都各有其專長(zhǎng)，都能為項(xiàng)目做出貢獻(xiàn)。敏捷建模人員要謙虛地承認(rèn)他們需要得到幫助以完成自己的工作，也要謙虛地承認(rèn)，他們要與別人一同工作?！盭P方法給出了如下12個(gè)核心實(shí)踐：完整的團(tuán)隊(duì)(WholeTeam)XP方法要求所有團(tuán)隊(duì)成員應(yīng)在同一工作場(chǎng)所工作。成員中必須有一名現(xiàn)場(chǎng)用戶(On-SiteUser)，由他提出需求，確定需求的優(yōu)先級(jí)，編寫驗(yàn)收測(cè)試用例。通常，團(tuán)隊(duì)還設(shè)一位“教練(Coach)”角色，他指導(dǎo)XP方法的實(shí)施，負(fù)責(zé)與外部溝通和協(xié)調(diào)。計(jì)劃對(duì)策(PlanningGame)在XP方法中需要制訂兩個(gè)計(jì)劃：發(fā)布計(jì)劃和迭代計(jì)劃。計(jì)劃是根據(jù)業(yè)務(wù)的優(yōu)先級(jí)和技術(shù)評(píng)估結(jié)果來(lái)制訂的。早期制訂的計(jì)劃常常是不準(zhǔn)確的，因此要留有足夠的余地，以便在迭代過(guò)程中不斷地修正。系統(tǒng)比喻(Metaphor)系統(tǒng)比喻是對(duì)需開(kāi)發(fā)的軟件的一種形象化的比喻，這種比喻描述了你打算如何構(gòu)建系統(tǒng)，起概念框架的作用。這種比喻必須是每個(gè)團(tuán)隊(duì)成員都熟悉的。小發(fā)布(Smallrelease)經(jīng)常、不斷地發(fā)布可運(yùn)行的、具有商業(yè)價(jià)值的小軟件版本，供現(xiàn)場(chǎng)用戶評(píng)估或最終使用。測(cè)試(testing)XP方法提倡測(cè)試優(yōu)先，即先寫測(cè)試后編代碼。測(cè)試優(yōu)先為開(kāi)發(fā)人員提供編碼前對(duì)代碼進(jìn)行周密思考的機(jī)會(huì)，使開(kāi)發(fā)人員很快發(fā)現(xiàn)他們的想法實(shí)際上是否可行。簡(jiǎn)單設(shè)計(jì)(simpleDesign)任何時(shí)候設(shè)計(jì)都應(yīng)盡可能簡(jiǎn)單，這是指設(shè)計(jì)剛好滿足當(dāng)前定義的功能即可，該設(shè)計(jì)是完成當(dāng)前功能所需的最簡(jiǎn)潔設(shè)計(jì)，即簡(jiǎn)單、易懂、無(wú)冗余、能運(yùn)行所有的測(cè)試、沒(méi)有重復(fù)的邏輯、描述了每個(gè)程序員的重要意圖、使用盡可能少的類和方法。設(shè)計(jì)還應(yīng)符合系統(tǒng)的比喻，便于以后對(duì)它重構(gòu)。結(jié)對(duì)編程(PairProgramming)XP方法強(qiáng)烈推薦結(jié)對(duì)編程，即由兩個(gè)程序員坐在一臺(tái)計(jì)算機(jī)前一起編程，在一個(gè)程序員編程的同時(shí)，另一個(gè)程序員負(fù)責(zé)檢查程序的正確性和可讀性。結(jié)對(duì)的伙伴不是固定不變的，而是可以動(dòng)態(tài)調(diào)整的。結(jié)對(duì)編程能把兩個(gè)程序員的程序設(shè)計(jì)思想?yún)R集在一起，在代碼編出來(lái)時(shí)已通過(guò)了一個(gè)程序員的審查，因此程序的質(zhì)量相對(duì)比較高，從而減少了程序中的錯(cuò)誤，降低了測(cè)試的時(shí)間和成本。同時(shí)，結(jié)對(duì)編程使得軟件中的任何一段代碼至少有兩名程序員非常熟悉，因此，個(gè)別的人員流動(dòng)對(duì)項(xiàng)目進(jìn)展造成的影響會(huì)很小。設(shè)計(jì)改進(jìn)(DesignImprovement)在整個(gè)開(kāi)發(fā)過(guò)程中，應(yīng)對(duì)程序結(jié)構(gòu)進(jìn)行持續(xù)不斷的梳理，在不影響程序的外部可見(jiàn)行為的情況下，按高內(nèi)聚低耦合的原則對(duì)程序內(nèi)部的結(jié)構(gòu)進(jìn)行改進(jìn)，保持代碼的簡(jiǎn)潔、無(wú)冗余。持續(xù)集成(ContinuousIntegration)持續(xù)集成是指每完成一個(gè)模塊的開(kāi)發(fā)(包括該模塊的單元測(cè)試)后，立即將其組裝到系統(tǒng)中，并進(jìn)行集成測(cè)試，完成該集成測(cè)試后才能進(jìn)行下一次集成。這樣的持續(xù)集成在一天中可能要出現(xiàn)多次。持續(xù)集成能保持項(xiàng)目組中所有開(kāi)發(fā)好的模塊始終是組裝完畢、完成集成測(cè)

試且是可執(zhí)行的。代碼全體共有(CollectivecodeOwnership)代碼全體共有是指團(tuán)隊(duì)中的任何人可以在任何時(shí)候修改系統(tǒng)任何位置上的任何代碼。這是建立在小系統(tǒng)開(kāi)發(fā)的前提下的，由于團(tuán)隊(duì)的成員都可以參加模型的開(kāi)發(fā)，又有系統(tǒng)的比喻，因此，總體上每個(gè)成員都對(duì)整個(gè)系統(tǒng)有一定程序的了解。此外，結(jié)對(duì)編程、編碼標(biāo)準(zhǔn)、持續(xù)集成等實(shí)踐都為代碼全體共有提供了支持，能及時(shí)發(fā)現(xiàn)修改代碼而引起的沖突，避免沖突的集中暴發(fā)。11.編碼標(biāo)準(zhǔn)(CodingStandard)XP方法強(qiáng)調(diào)制訂一個(gè)統(tǒng)一的編碼標(biāo)準(zhǔn)，包括命名、注釋、格式等編程風(fēng)格，使得所有的程序代碼就象出自一人之手。12.可持續(xù)步調(diào)(SustainablePace)XP方法強(qiáng)調(diào)每周40小時(shí)工作制。由于人的精力是有限的，敏捷軟件開(kāi)發(fā)要求每個(gè)團(tuán)隊(duì)成員都能始終保持精力充沛，充滿活力。長(zhǎng)時(shí)間超負(fù)荷的工作會(huì)影響工作效率，因此，XP方法要求每周工作時(shí)間不超過(guò)40小時(shí)，即使加班，也不要連續(xù)超過(guò)兩個(gè)星期。15.2.2XP開(kāi)發(fā)過(guò)程圖15.1給出了XP方法的開(kāi)發(fā)過(guò)程，可以將它劃分成五個(gè)階段：探索階段、計(jì)劃階段、迭代到發(fā)布階段、產(chǎn)品化階段和維護(hù)階段。XP方法中階段的概念是很弱的，各階段之間存在來(lái)回往復(fù)，一個(gè)階段的持續(xù)時(shí)間也不一定很長(zhǎng)，如計(jì)劃階段可能只要幾個(gè)小時(shí)即完成。用戶

故事新用戶故錯(cuò)誤測(cè)試用例體系結(jié)

構(gòu)骨架付計(jì)劃探索階段制訂交交付計(jì)劃?1I1I｝確定的用戶

故事新用戶故錯(cuò)誤測(cè)試用例體系結(jié)

構(gòu)骨架付計(jì)劃探索階段制訂交交付計(jì)劃?1I1I｝確定的/估計(jì)■難點(diǎn)’「骨架;計(jì)劃階段 !迭代開(kāi)發(fā).I■ II最新版本驗(yàn)收用戶認(rèn)可?小交付1;下一迭代迭代到發(fā)布階段產(chǎn)品化階段 i:維護(hù)階段;圖15.1XP方法的開(kāi)發(fā)過(guò)程1.探索階段探索階段的主要工作是開(kāi)發(fā)初始的用戶故事(UserStories)和體系結(jié)構(gòu)骨架(architecturespike)。開(kāi)發(fā)工作從用戶講述用戶故事開(kāi)始，用戶故事描述了系統(tǒng)高層的需求，它是制訂發(fā)布計(jì)劃的輸入。XP方法中的用戶故事有點(diǎn)像面向?qū)ο蠓椒ㄖ械挠脹r，但它可能比用況小。一個(gè)XP項(xiàng)目的用戶故事數(shù)目可以從幾個(gè)到幾十個(gè)不等。XP方法中的體系結(jié)構(gòu)不象傳統(tǒng)方法學(xué)那么正規(guī)，在探索階段，試探找到系統(tǒng)中固定不變的部分(體系結(jié)構(gòu)骨架)，并找出一種形象的比喻，這種比喻描述了你打算如何構(gòu)建系統(tǒng)，起到概念框架的作用。例如，我們可以把網(wǎng)上購(gòu)物比喻成一個(gè)到傳統(tǒng)雜貨店去購(gòu)物。訂單比喻成購(gòu)物車，客戶填寫訂單比喻成把貨物放進(jìn)購(gòu)物車中等等。開(kāi)發(fā)團(tuán)隊(duì)可以一起在一塊白板上邊討論邊畫出系統(tǒng)工作的草圖，以對(duì)系統(tǒng)比喻達(dá)成共識(shí)。同樣也可在白板上邊討論邊畫出系統(tǒng)體系結(jié)構(gòu)的骨架。一旦團(tuán)隊(duì)對(duì)系統(tǒng)比喻達(dá)成共識(shí)后，可丟棄臨時(shí)性的模型（如系統(tǒng)比喻草圖），并通過(guò)電子白板印刷出有用的模型（如體系結(jié)構(gòu)骨架草圖）加以保存。在敏捷方法中強(qiáng)調(diào)內(nèi)容比形式重要，因此并不要求繪制工整漂亮的圖。根據(jù)測(cè)試優(yōu)先的思想，探索階段還應(yīng)根據(jù)用戶故事編制相應(yīng)的測(cè)試用例，供以后驗(yàn)收測(cè)試時(shí)使用。2．計(jì)劃階段計(jì)劃階段的任務(wù)是根據(jù)用戶故事描述的需求、系統(tǒng)體系結(jié)構(gòu)骨架和系統(tǒng)比喻來(lái)制訂迭代計(jì)劃和發(fā)布計(jì)劃。在這個(gè)階段，可以用你最熟悉的形式為用戶故事建模，這個(gè)模型描述了用戶故事的任務(wù)以及這些任務(wù)之間的關(guān)系。通常圖形方式（可以是草圖）比文字描述更直觀。然后，盡可能精確地估算它的工作量，這是制訂計(jì)劃的重要依據(jù)。對(duì)于那些不能確切估算其工作量的難點(diǎn)部分，要進(jìn)一步作分析，直至能確定其工作量估算。3．迭代到發(fā)布階段迭代到發(fā)布階段完成了XP方法中的主要開(kāi)發(fā)工作，如建模、編碼、測(cè)試和集成。該階段根據(jù)迭代和發(fā)布計(jì)劃，開(kāi)發(fā)滿足指定用戶故事需求的軟件，并與前面已完成的軟件版本集成，得到軟件的一個(gè)新版本，然而根據(jù)在探索階段編寫的測(cè)試用例，進(jìn)行驗(yàn)收測(cè)試。一旦發(fā)現(xiàn)錯(cuò)誤或者通過(guò)驗(yàn)收測(cè)試想進(jìn)入下一輪迭代時(shí)，就重復(fù)迭代開(kāi)發(fā)的工作。在這一階段當(dāng)客戶提出新的用戶故事，或者根據(jù)項(xiàng)目的進(jìn)展情況認(rèn)為有必要時(shí)，可以回到計(jì)劃階段，對(duì)迭代和發(fā)布計(jì)劃做出修改或調(diào)整。4．產(chǎn)品化階段產(chǎn)品化階段的工作主要是確認(rèn)迭代開(kāi)發(fā)的軟件已經(jīng)做好進(jìn)入產(chǎn)品化的準(zhǔn)備。在此階段可進(jìn)行更多的測(cè)試，如系統(tǒng)測(cè)試、負(fù)載測(cè)試、安裝測(cè)試等。產(chǎn)品化階段的另一個(gè)工作就是整理