1.  任何情況下，變化是絕對的，不變是相對的，我們不要抱怨變化的發(fā)生，重要的時要有應(yīng)付變化的能

力。但是那絕對不是聽從別人來變化，而是自適應(yīng)形勢的變化。

2.  四個變量：成本、時間、質(zhì)量、范圍

3.  四個原則：溝通、簡單、反饋、勇氣

4.  所有的實踐：

a)  計劃游戲

 i.   業(yè)務(wù)人員需要決定的內(nèi)容：

1.    范圍

2.    優(yōu)先級

3.    版本的組成

4.    發(fā)布的日期

ii.    技術(shù)人員決定的內(nèi)容：

1.    估算

2.    后果

3.    過程

4.    詳細(xì)的日程計劃

b)    小版本

包含最有價值的業(yè)務(wù)需求。

c)    隱喻

每個XP軟件項目都是由一個全面的隱喻指導(dǎo)的。

d)    簡單設(shè)計 任何時候，正確的軟件設(shè)計都具有下面的特征：

i.     能夠運行所有測試

ii.    沒有重復(fù)的邏輯

iii.   陳述每個對程序員重要的意圖。

iv.   有盡可能少的類別和方法

e)    測試

測試有助于增強程序員的信心；只對有可能出錯的方法編寫測試代碼。

f)     重構(gòu)

g)    結(jié)對編程

一個人思考實現(xiàn)此方法的最佳途徑，另一個應(yīng)更加偏重于戰(zhàn)略性的角度進(jìn)行思考。

h)    集體所有權(quán)

只有代碼的正式所有者才可以更改代碼

i)     持續(xù)集成

用一臺計算機專門作集成工作

j)     每周工作40小時

加班時項目存在嚴(yán)重問題的征兆

k)     現(xiàn)場客戶

指的是在系統(tǒng)投產(chǎn)后真正使用系統(tǒng)的人

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

標(biāo)準(zhǔn)應(yīng)強調(diào)溝通，并必須被整個團(tuán)隊自愿地采納。

5.   環(huán)境可能是最后被考慮到的東西，但是往往是非常重要的。

6.    一定要保證一個小組在工作的時候不被干擾，否則就無法真正集中精力工作。

7.    業(yè)務(wù)人員應(yīng)該選擇：

a)    發(fā)布的范圍或時間

b)    提出的功能的相對優(yōu)先權(quán)

c)        提出的功能的確切范圍。

8.         開發(fā)組織必須確定：

a)         實現(xiàn)各種功能所需的時間估算

b)        各種可選的技術(shù)方案的后果估算

c)        適合他們的個性、業(yè)務(wù)環(huán)境和公司文化的開發(fā)過程。

d)        使用哪組時間來開始，即以使用什么樣的進(jìn)程來評審實踐的效果和對變化進(jìn)行試驗。

9.         制定計劃的目的：

a)         團(tuán)結(jié)和組織開發(fā)團(tuán)隊

b)        決定范圍和優(yōu)先級

c)        估算成本和日程

d)        讓大家對系統(tǒng)的成功信心百倍

e)         為反饋提供一個基準(zhǔn)

10.     制定計劃的原則：

a)         只制定下一個階段所需的計劃（計劃需要不停的進(jìn)行迭代）

b)        接受的責(zé)任（責(zé)任只能被接受，而不能被強加）

c)        負(fù)責(zé)實現(xiàn)的人進(jìn)行估算

d)        忽略個部分之間的依賴關(guān)系

e)         為優(yōu)先級作計劃與為開發(fā)作計劃的比較—謹(jǐn)記計劃的目的

11.     首要的一個問題是如何處理好人與人之間的關(guān)系，如果大家都能夠做到權(quán)責(zé)明確，并且和睦相處

，那么就具備了一個好團(tuán)隊所必須的一點。

12.     業(yè)務(wù)方和開發(fā)方一定要做到相互信任，相互尊重。

13.     如果能夠把一項工作做的像是大家在共同進(jìn)行一個游戲的話，大多數(shù)人都會樂意去做，而且很快

樂。

14.     配對編程是一種非常值得嘗試的方式，可能一旦使用就會永遠(yuǎn)喜歡上這種方式。

15.     最佳設(shè)計：能運行所有測試用例的最簡單的設(shè)計

16.     最簡單的四種約束：

a)         系統(tǒng)必須能夠溝通任何你希望溝通的內(nèi)容

b)        系統(tǒng)不能夠包含重復(fù)的代碼

c)        系統(tǒng)擁有盡可能少的類

d)        系統(tǒng)擁有盡可能少的方法

17.     軟件的設(shè)計不可能沒有變化，我們要做的是如何來面對并處理這些變化。在極限編程中，對于變

化我們會返工，但是那就像是修改一篇文章一樣，是一件令人快樂的事情。

18.     不停的進(jìn)行測試的方法似乎與制作網(wǎng)頁的過程有些類似，在制作網(wǎng)頁的過程中我們會不斷的進(jìn)行

預(yù)覽，查看在瀏覽其中實際的效果，而且所有的網(wǎng)頁都是在持續(xù)集成的過程中完成的。

19.     測試先行并不意味著我們在什么情況下都要先編寫測試，然后編寫代碼。在Eclipse中，如果沒有

一定的代碼，測試程序根本就是無法通過的，又來的什么正確不正確呢。而且，在編好了基本的類之后

，使用自動化的工具來生成測試程序，在一定程度上也可以提高工作的效率，何樂而不為呢？

20.     當(dāng)一個人編寫的程序里面Bug太多的時候，并不意味著他沒有重視測試，大多時候是因為他還沒有

掌握測試的方法和工具。不知道怎樣來測試，怎么可能做好呢？

21.     在保存項目的時候，如果使用極限編程，應(yīng)該不僅保存項目的源代碼，而且要保存所有的測試用

例。而且在寫注釋的時候，不僅在程序的源代碼里面要有詳盡的注釋，在測試用例的代碼中也應(yīng)該做到