作為開發人員，我們應該記住，xp並非惟一選擇。--pete mabreen
2.1極限程式設計實踐
極限程式設計（extremeprogramming，簡稱xp）是由kentbeck在2023年提出的。kentbeck在九十年代初期
與wardcunningham共事時，就一直共同探索著新的軟體開發方法，希望能使軟體開發更加簡單而有效。
kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能性以及面臨的困難。2023年三月，kent終於
在為daimlerchrysler所做的乙個專案中引入了新的軟體開發觀念——xp。適用於小團隊開發。
它由一系列簡單卻互相依賴的實踐組成。這些實踐結合在一起形成了乙個勝於部分結合的整體。
2.1.1客戶作為團隊成員
答：作者表示客戶應該是團隊的成員之一，客戶應該和團隊一起工作，如果客戶無法和團隊一起工作，應
該有能夠代替真正客戶的人。
2.1.2使用者素材
答：作者是表達在做計畫時有乙個體現的「事物」。客戶可以使用它並根據它的優先順序和估算代價來安排
實現這個需求的時間。
2.1.3短交付週期
答：1.迭代計畫：每二周乙個迭代，一次較小的交付。可能會加入產品中，也可能不會。
2.發布計畫：計畫6次迭代的內容，就是所謂的發布計畫，通常需要3個月的工作。是一次較大的交付，通
常會加入到產品中。
2.1.4.驗收測試
答：客戶指定驗收測試，測試規則一但通過就應該加入到驗收測試集合中。
2.1.5.結對程式設計
答：同一臺電腦二個人員一起共同使用。乙個進行**輸入，另乙個「監督」**。非但不會降低開發團
隊的效率，而且會大大減少缺陷率。
2.1.6測試驅動的開發方法
答：我沒理解
2.1.7集體所有權
答：每個人員都有權參加其他模組的工作，並且只能做特定功能塊。
2.1.8持續整合
答：我沒理解書上講的是什麼意思，我自己的理解是每天要做多次測試，一但出錯會進行修正，所有測試
通過就宛成了這次工作。
2.1.9可持續的開發速度
答：團隊必須保持旺盛的精力和他敏銳的警覺。必須要有意識地保持穩定、適中的速度。xp的規則是不允
許團隊加班工作。版本發布前一周例外。發布目標就在眼前可以加班。
2.1.10開放的工作空間
答：工作環境應該充滿交談聲，結對程式設計的二人應該是可以方便交流距離。「充滿足積極討論的屋子裡工
作，生產率非但不會降低，反而會成倍地提高」
2.1.11計畫遊戲
答：業務人員（也就是客戶）決定特性的重要性，開發人員決定實現乙個特性所花費的代價。
2.1.12簡單設計
1.考慮能夠工作的最簡單的事情。
答：xp團隊盡量用簡單的設計完成當前使用者素材。
2.你將不需要它
答：可以現在不需要更複雜的處理，但我們不能不考慮複雜情況。
3.一次，並且只有一次
答：發現重複的**，都必須消除它們。
2.1.13重構
答：作者的意思是說，**不停的寫，**會腐化。乙個又乙個特性增加。**結構會退化。必須不停的
改進**。重構不是在發版前，而且每一天都要進行。
2.1.14隱喻
答：就是說在小範圍操作時，同時也要有大局的引導。我是這麼理解的。
敏捷軟體開發 極限程式設計
極限程式設計 1.客戶作為團隊成員 2.使用者素材 為了進行專案計畫，必須要知道和專案需求有關的內容，但是無需知道得太多。看到新系統的問世是關注需求的最好時刻。3.短交付週期 每兩周交付一次可以工作的軟體。每次迭代結束時，會給涉眾演示迭代生成的系統，以得到他們的反饋。4.驗收測試 5.結對程式設計 ...
敏捷軟體開發之敏捷實踐
good 勝過normal 個體和互動 過程和工具 可以工作的軟體 面面俱到的文件 客戶合作 合同談判 響應變化 遵循計畫 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。團隊的構建要比環境的構建重要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力...
敏捷軟體開發實踐 概括
應朋友之邀，我準備寫一組文章關於敏捷軟體開發的實踐，也幫助廣大沒有用過agile的或者只停留在書本內容上的朋友親臨敏捷軟體開發這個驚心動魄的歷程。所謂敏捷，書本上有很多的介紹，我也不想重 明輪子了，反正就我的理解，敏捷的精髓就是面向變化，敏捷這個詞語，我最早遇到是出現在玩各種遊戲中，所謂的 力量型 ...