朋的博客
          

          MySQL資料，Java技術(shù)，管理思想，博弈論，Ajax，XP極限編程，H.264，HEVC，HDR
          

          

          

          隨筆 - 86, 文章 - 59, 評(píng)論 - 1069, 引用 - 0
          

          


          		
	
          

          

          
	
          
		
			
          
				數(shù)據(jù)加載中……
			
          
		          		
		
			
          
				
					
	
          
		
          
			XP實(shí)踐整理(來(lái)自：XPChina BrokenDoor )
		
          
		
          
		1 為什么是XP

          讓我們來(lái)考慮一個(gè)傳統(tǒng)的途徑：用戶(hù)組和開(kāi)發(fā)組協(xié)商讓一個(gè)分析員設(shè)計(jì)一個(gè)項(xiàng)目。在幾周和幾個(gè)月中，分析員和用戶(hù)每天會(huì)面幾個(gè)小時(shí)。分析員生產(chǎn)出一套文檔，可能還包括象一個(gè)可視描述和用例之類(lèi)。用戶(hù)和項(xiàng)目經(jīng)理（也可能是編程團(tuán)隊(duì)）回顧這些文檔并且協(xié)商出一個(gè)發(fā)行版。          程序員使用規(guī)范在幾個(gè)月之后成長(zhǎng)出一個(gè)系統(tǒng)，或多或少的實(shí)現(xiàn)了原來(lái)的想法。在結(jié)束的時(shí)候這通常是一個(gè)閉呼叫系統(tǒng)，當(dāng)人們發(fā)現(xiàn)他們所遺漏的并意識(shí)到自從文檔被寫(xiě)好以來(lái)什么都已經(jīng)改變了。最后，用戶(hù)加入進(jìn)來(lái)作一個(gè)用戶(hù)接受測(cè)試然后系統(tǒng)被發(fā)布。 

          通常整個(gè)過(guò)程所花費(fèi)的時(shí)間比任何人所期望的都長(zhǎng)，會(huì)遺漏一些特征，并且質(zhì)量并不是用戶(hù)想要的。更有甚著，文檔也不再隨日期更新。 

          問(wèn)題總結(jié)： 
          不能完全理解用戶(hù)需求（用戶(hù)自己也經(jīng)常不清楚自己需要什么） 
          用戶(hù)的要求不斷變化 
          技術(shù)更新速度很快 
          開(kāi)發(fā)人員缺乏成功經(jīng)驗(yàn) 
          開(kāi)發(fā)小組不穩(wěn)定 
          沒(méi)有完整的測(cè)試設(shè)計(jì) 


          --------------------------------------------------------------------------------


          2 XP簡(jiǎn)介

          XP全名Extreme Programming ，一種輕量級(jí)，靈活的方法。 
          XP 規(guī)定了一組核心價(jià)值和方法，可以讓軟件開(kāi)發(fā)人員發(fā)揮他們的專(zhuān)長(zhǎng)：編寫(xiě)代碼。XP 消除了大多數(shù)重量型過(guò)程的不必要產(chǎn)物，通過(guò)減慢開(kāi)發(fā)速度、耗費(fèi)開(kāi)發(fā)人員的精力（例如干特圖、狀態(tài)報(bào)告，以及多卷需求文檔）從目標(biāo)偏離。 
          在XP中，在用戶(hù)vs          程序員的角色中有一個(gè)基本的分隔。用戶(hù)擁有*what you get*，而程序員擁有*what it costs*。這顯示了誰(shuí)能作出什么決定。 即用戶(hù)做企業(yè)決策，程序員做技術(shù)決策。 

          2.1 用戶(hù)決定： 

          范圍：什么          系統(tǒng)是必須作的。 

          優(yōu)先級(jí)：對(duì)于企業(yè)價(jià)值什么是最重要的。 

          發(fā)行的組合：什么是必須在發(fā)行版中的，一定是有用的？ 

          發(fā)行的日期：什么時(shí)候需要發(fā)行？ 

          2.2           程序員決定： 

          評(píng)估添加一個(gè)特征的時(shí)間 ，以及每個(gè)特征的風(fēng)險(xiǎn) 

          使用各種技術(shù)選項(xiàng)所花費(fèi)的成本 ：          程序員解釋程序選擇的結(jié)果，但是用戶(hù)作決定 

          過(guò)程：小組怎么樣工作，團(tuán)隊(duì)怎么組織 

          細(xì)節(jié)時(shí)間表：在一個(gè)迭代中特征先開(kāi)發(fā)風(fēng)險(xiǎn)最大的那一個(gè)特征可以減輕風(fēng)險(xiǎn) 

          2.3 XP 的核心價(jià)值為： 

          交流。 項(xiàng)目的問(wèn)題往往可以追溯到某人在某個(gè)時(shí)刻沒(méi)有和其他人一起商量某些重要問(wèn)題上。使用 XP，不交流是不可能的事。 


          簡(jiǎn)單。 XP 建議您總是盡可能?chē)@過(guò)程和編寫(xiě)代碼做最簡(jiǎn)單的事情。按照 Beck 的說(shuō)法，“XP 就是打賭。它打賭今天最好做些簡(jiǎn)單的事...而不是做更復(fù)雜但可能永遠(yuǎn)也不會(huì)用到的事。” 


          反饋。 更早和經(jīng)常來(lái)自客戶(hù)、團(tuán)隊(duì)和實(shí)際最終用戶(hù)的具體反饋意見(jiàn)為您提供更多的機(jī)會(huì)來(lái)調(diào)整您的力量。反饋可以讓您把握住正確的方向，少走彎路。 


          勇氣。 勇氣存在于其它三個(gè)價(jià)值的環(huán)境中。它們相互支持。需要勇氣來(lái)相信一路上具體反饋比預(yù)先知道每樣事物來(lái)得更好。需要勇氣來(lái)在可能暴露您的無(wú)知時(shí)與團(tuán)隊(duì)中其他人交流。需要勇氣來(lái)使          系統(tǒng)盡可能簡(jiǎn)單，將明天的決定推到明天做。而如果沒(méi)有簡(jiǎn)單的系統(tǒng)、沒(méi)有不斷的交流來(lái)擴(kuò)展知識(shí)、沒(méi)有掌握方向所依賴(lài)的反饋，勇氣也就失去了依靠。 


          --------------------------------------------------------------------------------


          3 XP的十二種實(shí)踐方法： 


          重新劃分（Refactoring） 

          系統(tǒng)比喻(Metaphor) 

          簡(jiǎn)單設(shè)計(jì)(Simple design) 

          一周40小時(shí) (40-hour week) 

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

          持續(xù)集成(Continuous integration) 

          成對(duì)編程(pair programming) 

          集體代碼所有權(quán)(Collective ownership) 

          現(xiàn)場(chǎng)客戶(hù)(On-site customer) 

          規(guī)劃策略(Planning game) 

          小發(fā)行版(Small releases) 

          測(cè)試(Testing) 

          3.1 規(guī)劃策略 
          有些人會(huì)指責(zé) XP 是一種美其名的剽竊，只是一群牛仔在沒(méi)有任何規(guī)則的情況下將一個(gè)          系統(tǒng)拼湊在一起。錯(cuò)。XP 是為數(shù)不多的幾種承認(rèn)您在開(kāi)始時(shí)不可能事事通曉的方法之一。無(wú)論是用戶(hù)還是開(kāi)發(fā)人員都是隨著項(xiàng)目的進(jìn)展過(guò)程才逐步了解事物的。只有鼓勵(lì)和信奉這種更改的方法才是有效方法。狀態(tài)限定方法忽視更改。而 XP 則留心更改。它傾聽(tīng)所用的方法就是*規(guī)劃策略*，一個(gè)由 Kent Beck 創(chuàng)造的概念。 
          這一方法背后的主要思想是迅速地制定粗略計(jì)劃，然后隨著事物的不斷清晰來(lái)逐步完善。規(guī)劃策略的產(chǎn)物包括：一堆索引卡，每一張都包含一個(gè)客戶(hù)素材，這些素材驅(qū)動(dòng)項(xiàng)目的迭代；以及對(duì)下一兩個(gè)發(fā)行版的粗略計(jì)劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣。讓這種形式的計(jì)劃得以發(fā)揮作用的關(guān)鍵因素是讓用戶(hù)做企業(yè)決策，讓開(kāi)發(fā)小組做技術(shù)決策。如果沒(méi)有這一前提，整個(gè)過(guò)程就會(huì)土崩瓦解。 

          3.2           系統(tǒng)比喻 
          體系結(jié)構(gòu)是做什么用的？它提供了          系統(tǒng)各種組件以及它們是如何交互的畫(huà)面 -- 一種映射，可以讓開(kāi)發(fā)人員了解新的代碼部分適合放在哪里。 
          XP 中的          系統(tǒng)比喻與大多數(shù)方法稱(chēng)作的體系結(jié)構(gòu)差不多。比喻為團(tuán)隊(duì)提供了一致的畫(huà)面，他們可以用它來(lái)描述現(xiàn)有系統(tǒng)的工作方式、新部件適合的位置，以及它們應(yīng)該采取的形式。 
          重要的是要記住，關(guān)鍵要讓每個(gè)人理解          系統(tǒng)是如何組合在一起的，而不是美麗的比喻。有時(shí)您就是無(wú)法想到一個(gè)好的比喻。想到時(shí)就太好了。　 

          3.3 測(cè)試 
          在 XP 中有兩種測(cè)試： 
          1. 單元測(cè)試 
          2. 驗(yàn)收測(cè)試 
          開(kāi)發(fā)人員在他們編寫(xiě)代碼的同時(shí)編寫(xiě)單元測(cè)試。客戶(hù)在他們定義了素材后編寫(xiě)驗(yàn)收測(cè)試。單元測(cè)試及時(shí)告訴開(kāi)發(fā)人員          系統(tǒng)在某一點(diǎn)上是否*工作*。驗(yàn)收測(cè)試告訴團(tuán)隊(duì)系統(tǒng)是否執(zhí)行用戶(hù)希望它執(zhí)行的操作。 
          假設(shè)團(tuán)隊(duì)使用的是如 Java 這樣的面向?qū)ο笳Z(yǔ)言，開(kāi)發(fā)人員在為一些方法編寫(xiě)代碼之前為每種有可能失敗的方法編寫(xiě)單元測(cè)試。然后他們編寫(xiě)足夠的代碼使之能通過(guò)測(cè)試。有時(shí)人們會(huì)發(fā)現(xiàn)這有點(diǎn)奇怪。答案很簡(jiǎn)單。編寫(xiě)測(cè)試首先為您提供： 

          一組可能最完整的測(cè)試 

          可能能工作的最簡(jiǎn)單的代碼 

          代碼意圖的明確景象 
          開(kāi)發(fā)人員只有在通過(guò)所有單元測(cè)試后才可以將代碼檢入到源代碼資源庫(kù)中。單元測(cè)試使開(kāi)發(fā)人員有信心相信他們的代碼能夠工作。這為其他開(kāi)發(fā)人員留下線索，可以幫助他們理解最早的開(kāi)發(fā)人員的意圖（實(shí)際上，這是我們看到過(guò)的最好的文檔）。單元測(cè)試還給了開(kāi)發(fā)人員勇氣重新劃分代碼，因?yàn)闇y(cè)試失敗可以立刻告訴開(kāi)發(fā)人員存在錯(cuò)誤。應(yīng)該將單元測(cè)試自動(dòng)化，并提供明確的通過(guò)／失敗結(jié)果。xUnit 框架做到的遠(yuǎn)不止這些，因此大多數(shù) XP 小組都使用它們。 
          用戶(hù)負(fù)責(zé)確保每個(gè)素材都有驗(yàn)收測(cè)試來(lái)確認(rèn)它們。用戶(hù)可以自己編寫(xiě)測(cè)試、可以征募組織中的其他成員（例如 QA 人員或業(yè)務(wù)分析員）編寫(xiě)它們，也可以將這兩種方法結(jié)合起來(lái)。測(cè)試告訴他們          系統(tǒng)是否具有應(yīng)該具有的那些特性，以及是否可以正確工作。理想情況下，用戶(hù)在迭代完成之前就應(yīng)該寫(xiě)好迭代中那些素材的驗(yàn)收測(cè)試了。應(yīng)該將驗(yàn)收測(cè)試自動(dòng)化，并要經(jīng)常運(yùn)行來(lái)確保開(kāi)發(fā)人員在實(shí)現(xiàn)新特性時(shí)沒(méi)有破壞任何現(xiàn)有的特性。通常情況下，客戶(hù)需要來(lái)自開(kāi)發(fā)團(tuán)隊(duì)的某些幫助來(lái)編寫(xiě)驗(yàn)收測(cè)試。我們對(duì)一個(gè)項(xiàng)目開(kāi)發(fā)一個(gè)可重用的自動(dòng)驗(yàn)收測(cè)試框架，可以讓用戶(hù)在簡(jiǎn)單編輯器中輸入他們的輸入和所期望的輸出。框架將輸入轉(zhuǎn)換成 XML 文件、運(yùn)行文件中的測(cè)試，然后為每個(gè)測(cè)試顯示*通過(guò)*或*失敗*。客戶(hù)喜歡這一做法。 
          不是所有驗(yàn)收測(cè)試都必須在所有情況下通過(guò)。問(wèn)題是驗(yàn)收測(cè)試幫助客戶(hù)衡量項(xiàng)目*完成*的情況如何。它們還可以讓客戶(hù)獲悉有關(guān)某些事物是否可以發(fā)行的決定。 

          3.4 重構(gòu) 
          重構(gòu)是在不更改功能性的前提下對(duì)代碼加以改進(jìn)。XP 小組在進(jìn)行重構(gòu)時(shí)毫不手軟。 
          開(kāi)發(fā)人員重構(gòu)有兩個(gè)重要時(shí)機(jī)：實(shí)現(xiàn)特性之前和之后。開(kāi)發(fā)人員嘗試確定更改現(xiàn)有代碼是否可以讓新特性的開(kāi)發(fā)更容易。他們查看剛剛寫(xiě)好的代碼，看是否有方法可以對(duì)它進(jìn)行簡(jiǎn)化。例如，如果他們認(rèn)為有抽象的機(jī)會(huì)，就會(huì)進(jìn)行重構(gòu)來(lái)從具體實(shí)現(xiàn)中除去重復(fù)的代碼。 
          XP 建議您應(yīng)該編寫(xiě)可能運(yùn)行的最簡(jiǎn)單的代碼，但同時(shí)也建議您應(yīng)該不斷學(xué)習(xí)。重構(gòu)讓您將學(xué)到的知識(shí)加入到代碼中，同時(shí)又不會(huì)破壞測(cè)試。它使您的代碼簡(jiǎn)練。這意味著它可以存在相當(dāng)長(zhǎng)的時(shí)間、為以后的開(kāi)發(fā)人員引入更少問(wèn)題，并為他們指引正確的方向。 

          3.5 成對(duì)編程 
          使用 XP，成對(duì)的開(kāi)發(fā)人員編寫(xiě)所有產(chǎn)品代碼。這種方式聽(tīng)上去好象缺乏效率。Martin Fowler 說(shuō)，*當(dāng)人們說(shuō)成對(duì)編程降低生產(chǎn)力時(shí)，我回答，'那是因?yàn)榇蠖鄶?shù)耗費(fèi)時(shí)間的編程部分是靠輸入來(lái)完成的。'*實(shí)際上，成對(duì)編程無(wú)論在經(jīng)濟(jì)還是其它方面都提供了許多好處： 

          所有設(shè)計(jì)決策都牽涉到至少兩個(gè)人。 

          至少有兩個(gè)人熟悉          系統(tǒng)的每一部分。 

          幾乎不可能出現(xiàn)兩個(gè)人同時(shí)疏忽測(cè)試或其它任務(wù)。 

          改變各對(duì)的組合在可以在團(tuán)隊(duì)范圍內(nèi)傳播知識(shí)。 

          代碼總是由至少一人復(fù)查。 
          研究還顯示成對(duì)的編程實(shí)際上比單獨(dú)編程更有效。 

          3.6 小發(fā)行版 
          發(fā)行版應(yīng)該盡可能地小，同時(shí)仍然提供足夠的企業(yè)價(jià)值以證明它們值得。 
          只要覺(jué)得有意義就可以發(fā)布          系統(tǒng)。這樣就盡可能早為用戶(hù)提供了價(jià)值（請(qǐng)記住，今天的錢(qián)比明天的錢(qián)來(lái)得值錢(qián)）。小發(fā)行版將為開(kāi)發(fā)人員提供具體的反饋意見(jiàn)，告訴他們哪些符合客戶(hù)需要，哪些不符合客戶(hù)需要。然后，小組可以將這些經(jīng)驗(yàn)教訓(xùn)包括在其下一發(fā)行版的規(guī)劃中。 

          3.7 簡(jiǎn)單的設(shè)計(jì) 
          XP 的誹謗者說(shuō)該過(guò)程忽略了設(shè)計(jì)。事實(shí)不是這樣。問(wèn)題是重量型方法建議您做的不過(guò)是提前完成大部分瑣碎的設(shè)計(jì)任務(wù)。這就象是拍一張靜態(tài)的地平線的照片，靜止不動(dòng)，然后嘗試畫(huà)一張如何到達(dá)那里的完美的地圖。XP 說(shuō)設(shè)計(jì)不應(yīng)該在事物將保持不變的前提下預(yù)先倉(cāng)促進(jìn)行。XP 認(rèn)為設(shè)計(jì)非常重要，因此應(yīng)該是一個(gè)持續(xù)的事務(wù)。我們總是先嘗試使用能夠工作的最簡(jiǎn)單的設(shè)計(jì)，然后隨著現(xiàn)實(shí)的不斷顯現(xiàn)來(lái)更改它。 
          什么是可能工作的最簡(jiǎn)單的設(shè)計(jì)？它是符合以下條件的設(shè)計(jì)： 

          運(yùn)行所有測(cè)試 

          不包含重復(fù)代碼 

          明確陳述          程序員對(duì)所有代碼的意圖 

          包含盡可能最少的類(lèi)和方法 
          對(duì)簡(jiǎn)單設(shè)計(jì)的需求并不是說(shuō)所有設(shè)計(jì)都很小，也不表示它們是無(wú)足輕重的。它們只不過(guò)需要盡可能簡(jiǎn)單，但是仍能工作。不要包括不使用的額外特性。我們稱(chēng)這樣的事物為 YAGNI，表示*您將不需要它（You Aren't Going to Need It）。*不要讓 YAGNI 破壞您成功的機(jī)會(huì)。 

          3.8 集體代碼所有權(quán) 
          小組中的任何人都應(yīng)該有權(quán)對(duì)代碼進(jìn)行更改來(lái)改進(jìn)它。每個(gè)人都擁有全部代碼，這意味著每個(gè)人都對(duì)它負(fù)責(zé)。這種技術(shù)可以讓人們對(duì)部分代碼進(jìn)行必要的更改而不用經(jīng)過(guò)代碼擁有者個(gè)人的瓶頸。每個(gè)人都負(fù)責(zé)這一事實(shí)消除了無(wú)代碼所有權(quán)所帶來(lái)的混亂。 

          每人擁有所有代碼*與*沒(méi)人擁有代碼*的說(shuō)法并不一樣。沒(méi)人擁有代碼時(shí)，人們可以隨處進(jìn)行破壞而不必負(fù)任何責(zé)任。而 XP 說(shuō)，*如果是您破壞的，應(yīng)該您來(lái)彌補(bǔ)。*我們有一些必須在每次集成之前和之后運(yùn)行的單元測(cè)試。如果您破壞了某些事物，您要負(fù)責(zé)進(jìn)行修補(bǔ)，無(wú)論它位于代碼的哪一部分。這需要極端規(guī)則。可能這是名稱(chēng)中帶有*極端*的另一個(gè)原因。 

          3.9 持續(xù)的集成 
          經(jīng)常進(jìn)行代碼集成可以幫助您避免集成夢(mèng)魘。XP 團(tuán)隊(duì)在一天中集成了代碼幾次，每次都在所有單元測(cè)試對(duì)          系統(tǒng)運(yùn)行后執(zhí)行。 
          傳統(tǒng)方法工作方式如下：編寫(xiě)大量代碼后執(zhí)行一次大爆炸式的集成，然后花費(fèi)相當(dāng)長(zhǎng)的時(shí)間來(lái)改正問(wèn)題。這種笨拙的形式的確使項(xiàng)目速度減緩。大爆炸式的集成給團(tuán)隊(duì)立即帶來(lái)大量問(wèn)題，并且這些問(wèn)題通常都有幾百種可能的原因。 
          如果經(jīng)常進(jìn)行集成，任何特定集成失敗的原因都會(huì)非常明顯（以前運(yùn)行過(guò)測(cè)試，因此錯(cuò)誤一定是新事物犯下的）。使用這種方法，當(dāng)遇到問(wèn)題時(shí)，可能的原因就相當(dāng)有限。修改起來(lái)更容易，花的時(shí)間少得多，使團(tuán)隊(duì)保持最快速度前進(jìn)。 

          3.10 現(xiàn)場(chǎng)客戶(hù) 
          要使功能最理想，XP 小組需要在現(xiàn)場(chǎng)有一位客戶(hù)來(lái)明確素材，并做出重要的企業(yè)決策。開(kāi)發(fā)人員是不允許單獨(dú)做這些事情的。讓客戶(hù)隨時(shí)在場(chǎng)可以消除開(kāi)發(fā)人員等待決策時(shí)出現(xiàn)的瓶頸。 
          XP 不會(huì)假裝素材卡是開(kāi)發(fā)人員交付必要代碼所需的唯一指示。素材是對(duì)以后在客戶(hù)和開(kāi)發(fā)人員之間填寫(xiě)細(xì)節(jié)的對(duì)話(huà)的一項(xiàng)承諾。與將所有要求寫(xiě)在一個(gè)靜態(tài)文檔中不同，其思想是進(jìn)行面對(duì)面的交流，減少產(chǎn)生誤解的機(jī)會(huì)。 
          我們發(fā)現(xiàn)讓客戶(hù)在現(xiàn)場(chǎng)是可能最好的一種情形，但這不是解決問(wèn)題的唯一方案。底線是客戶(hù)必須隨時(shí)在需要回答問(wèn)題和根據(jù)企業(yè)價(jià)值為團(tuán)隊(duì)提供指示時(shí)有空。如果客戶(hù)并非在現(xiàn)場(chǎng)專(zhuān)職陪伴團(tuán)隊(duì)的情況下就能做到這些，那很好。如果能和團(tuán)隊(duì)待在一起，這會(huì)更方便，但只是建議而已。 

          3.11 編碼標(biāo)準(zhǔn) 
          擁有編碼標(biāo)準(zhǔn)有兩個(gè)目的： 

          防止團(tuán)隊(duì)被一些例如事物沒(méi)有以最大速度發(fā)展這種無(wú)關(guān)緊要的愚蠢爭(zhēng)論搞得不知所措。 

          它支持其它方法。 
          如果沒(méi)有編碼標(biāo)準(zhǔn)，重新劃分代碼會(huì)更加困難，按應(yīng)當(dāng)?shù)念l度交換對(duì)更困難，快速前進(jìn)也更困難。目標(biāo)應(yīng)該是團(tuán)隊(duì)中沒(méi)有人辨認(rèn)得出是誰(shuí)寫(xiě)的哪一部分代碼。以團(tuán)隊(duì)為單位對(duì)某一標(biāo)準(zhǔn)達(dá)成協(xié)議，然后遵守這一標(biāo)準(zhǔn)。目標(biāo)不是創(chuàng)建一個(gè)事無(wú)巨細(xì)的規(guī)則列表，而是提供將確保您的代碼可以清晰交流的指導(dǎo)方針。編碼標(biāo)準(zhǔn)開(kāi)始時(shí)應(yīng)該很簡(jiǎn)單，然后根據(jù)團(tuán)隊(duì)經(jīng)驗(yàn)逐步進(jìn)化。不要預(yù)先花費(fèi)太多時(shí)間。創(chuàng)建能夠工作的最簡(jiǎn)單標(biāo)準(zhǔn)，然后逐步發(fā)展。 

          3.12 一周 40 小時(shí) 
          Kent Beck 說(shuō)他希望*...每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿(mǎn)足。*一周 40 小時(shí)工作可以讓您做到這一點(diǎn)。確切的小時(shí)數(shù)并不重要，重要的是原則。長(zhǎng)時(shí)間地持續(xù)工作會(huì)扼殺工作績(jī)效。疲勞的開(kāi)發(fā)人員會(huì)犯更多錯(cuò)誤，從長(zhǎng)期來(lái)說(shuō)，將比按*正常*時(shí)間表進(jìn)行的開(kāi)發(fā)慢得多。 
          即使開(kāi)發(fā)人員可以在長(zhǎng)時(shí)間很好工作，這也不意味著他們應(yīng)該這樣。最終他們會(huì)厭倦，會(huì)離開(kāi)他們的工作，或者產(chǎn)生影響他們工作績(jī)效的非工作問(wèn)題。如果您打亂了人們的生活，將會(huì)嘗到它所帶來(lái)的惡果。加班并不是解決項(xiàng)目問(wèn)題的答案。實(shí)際上，它是更大問(wèn)題的癥狀。如果您要走向滅亡，就無(wú)藥可救了。 


          --------------------------------------------------------------------------------


          4 XP過(guò)程中的各個(gè)階段

          作為一個(gè)軟件開(kāi)發(fā)過(guò)程，XP中計(jì)劃，設(shè)計(jì)，編碼和測(cè)試各階段包括的內(nèi)容比較簡(jiǎn)潔，容易實(shí)施。 

          4.1 計(jì)劃 

          User stories的編寫(xiě) 

          識(shí)別需求方面 

          開(kāi)發(fā)計(jì)劃的制定 

          經(jīng)常構(gòu)造版本 

          版本控制 

          Load Factor因子的確定 

          將項(xiàng)目分解為各個(gè)迭代期 

          每個(gè)迭代期開(kāi)始時(shí)制定計(jì)劃 

          人員集中 

          站著開(kāi)每日晨會(huì) 

          當(dāng)實(shí)施遇到困難時(shí)及時(shí)修正 

          4.2 測(cè)試 

          所有代碼均需進(jìn)行單元測(cè)試 

          發(fā)行之前所有代碼必須通過(guò)單元測(cè)試 

          Bug發(fā)現(xiàn)后應(yīng)馬上測(cè)試 　 

          4.3 編碼 

          始終獲得用戶(hù)的支持 

          代碼的書(shū)寫(xiě)必須按照規(guī)范 

          所有代碼均采用配對(duì)開(kāi)發(fā) 

          一次只能有一對(duì)開(kāi)發(fā)人員進(jìn)行發(fā)行 

          代碼經(jīng)常集成 

          代碼共享 

          將優(yōu)化放在最后 

          不要加班 

          4.4 設(shè)計(jì) 

          簡(jiǎn)單化 
          采用編程規(guī)范 
          設(shè)計(jì)時(shí)使用CRC卡片 
          使用Spike Solution 方法 
          不要過(guò)早添加新功能 
          盡可能保持          程序的簡(jiǎn)潔性 
          --------------------------------------------------------------------------------

          5 相關(guān)資料
          Extremeprogramming: http://www.extremeprogramming.org/
          XPdeveloper: http://http://www.xpdeveloper.com/
          Xprogramming: http://www.xprogramming.com/
          Junit: http://www.junit.org/
          
		
          
		
          
			posted on 2006-02-19 21:04 benchensz 閱讀(925) 評(píng)論(0)  編輯  收藏  所屬分類(lèi): XP極限編程體驗(yàn) 
		
          
	
          
	
	


	


          
	    
    




          








          

				
			
          
		          		
	
          
	
          
		
			

		
	
          

          


    







          
        
	




主站蜘蛛池模板：
宣恩县|
合阳县|
敦化市|
台湾省|
衡水市|
屯昌县|
临泉县|
万宁市|
密云县|
凌海市|
沾化县|
岑巩县|
米林县|
斗六市|
且末县|
西宁市|
尖扎县|
沅陵县|
洪江市|
九江县|
佳木斯市|
饶阳县|
金堂县|
邹城市|
休宁县|
隆林|
新密市|
灌南县|
平武县|
巨鹿县|
霍邱县|
镇安县|
龙井市|
习水县|
徐汇区|
博爱县|
赤水市|
瑞丽市|
伽师县|
清水县|
大化|