極端程式設計（eXtreme Programming，XP）的特點及討論

XP在很多方面都和我們傳統意義上得軟體工程不同，同時，它也和傳統得管理和專案計劃得方法不同。這些方法在軟體工程和其他管理活動中都有借鑑意義。 

特點如下： 

不採用瀑布式得軟體工程方法，而採用原型法。將一個軟體開發專案分為多個迭代週期，每個週期實現部分軟體功能。在每個週期都進行提出需求、設計軟體架構、編碼、測試、釋出得軟體開發的全過程。每個週期都進行充分的測試和整合。這樣的好處是可以不斷的從客戶方面得到反饋，更逼近實際的軟體需求。通過頻繁的重新編碼的過程，可以非常適應功能更改的需求，同時增加軟體的易維護性。在不斷的迭代中，避免架構設計的重大失誤造成的軟體不能如期交工，避免了軟體設計的風險。 

在軟體設計中，強調簡單性，就是堅決不作用不到的通用功能。同時，也不刻意避免重新編碼，只有不斷得重新編碼才能保證軟體得合理性。不害怕對整個軟體推倒重做。認為重新編碼是很正常得現象。每次得重新編碼都會大大減少軟體中得熵值。 

在專業分工中，提出在開發團隊中要有全職的客戶人員的參與，同時在軟體團隊中也要有自己的領域專家。這樣，可以和客戶充分交流，徹底瞭解應用需求。這種軟體需求的提出不是一次性的，而是不斷的交流。 

也有專門的軟體架構的設計師，首先進行軟體整體架構的設計。這種設計一般使用UML語言。 

在軟體開發的順序上，和傳統方法完全相反。傳統方法是按照整體設計、編寫程式碼、進行測試、交付客戶的方法。而XP是按照交付客戶、測試、編碼、設計的順序來開發。首先將要交付客戶的軟體的介面作出來，先讓客戶對軟體有實際體驗，這樣，可以獲得客戶的更多的反饋，使需求可以在開發前確定。在編碼前就先把測試程式做好，這樣，編碼完成後就可以馬上進行測試。通過不斷的測試來保證軟體的質量。在進行軟體架構設計之前就進行編碼，可以使問題更早暴露，可以使最後的軟體設計更體現編碼的特點，更符合實際，更容易實現，也保證了設計的合理，保證了軟體設計的大量決定的正確性。 

在專案計劃的實現上，每次的計劃都是技術人員對客戶提出時間表，由最後的開發人員對專案經理提出編碼的時間表。這種計劃都是從下而上的，不是從上到下的，更容易保證計劃的按時完成。同時，多個迭代週期也使工期的估計越來越精確。 


在分工上，強調角色輪換，專案的集體負責，分工的自願性。分工的自願性就是每個人的工作內容不是由專案經理分派，而是由每個人自願領取，這樣保證了每個人可以發揮自己的特長，適應自己的情況。當然，在每個問題上都要有唯一的決策人，同時，也要經過充分的交流和溝通。角色輪換就是在專案中，一個人在不同的週期中擔任不同的角色，可以保證每個人對專案的整體把握，方便專案中的溝通和理解。專案的集體負責，就是每個人不是完成自己的工作就可以了，要對整個專案的完成負責，任何人都可以對工作的任何部分提出自己的建議。任何人都可以從事任何工作。任何人都要對整個專案熟悉。這樣做的優點是可以充分的鍛鍊人、可以發揮每個人的積極性、可以使專案不依賴於某個特定的人，方便今後的軟體的維護，通過工作內容的變換可以提高人工作的興趣。通過角色輪換還可以使每個人都勞逸結合，方便相互理解，避免由於不理解而造成的各種配合問題。 

保證8小時工作制，避免加班。 

（我加幾條：要有充分的培訓、要有每個人的提升空間、制定報酬要根據對企業的貢獻大小，而不是職位的高低，允許下屬比上級薪酬更高，薪酬的高低取決於績效評定，同時績效評定要儘可能量化。並且推行淘汰制。同時有有效的招聘制度。有強有力的後勤保障制度和輕鬆的企業文化。） 

提出了成對程式設計的思路，就是每個模組的編碼都是兩個人一起幹，共用一臺電腦。這樣，一個人編碼時，令一個人就可以檢查程式碼，或對編碼的思路進行思考，寫文件等。不再有另外的測試人員，兩個人同時完成程式碼的測試，並且使先寫測試程式然後再程式設計。這樣避免了程式設計人員和測試人員的矛盾。也解決了一個人自己檢查的侷限性。兩個人共同檢查可以避免大多數的錯誤。在共同程式設計中還可以進行經驗的交流和傳授。也避免了將一個工作一直幹下去的無聊，交流增加了情趣。並且兩個人共同工作也增加了工作量的彈性，使專案計劃的瓶頸工作能儘快解決。根據成對程式設計的思路，開發小組也可以分為兩個小組，一個小組進行開發，另一個小組作改進和bug修正等工作。也有同樣的效果。 

在人員的分工上要靈活，要保證軟體開發中的角色的齊全，但每個角色可以由幾個人共同擔任，也可以一個人擔任幾個角色，並且在專案的不同時期，不同角色的人員數量會不斷變化。 

每天或隔天，開一個站立會議（保證開會時間儘量短），來解決工作時間不一致和相互打擾工作的情況。在每個迭代週期也有一個計劃和分工等的全體大會。 

XP的實施方法就要求能適應工作中出現的問題，不斷對xP進行改進，而不能照搬套用。 

XP的目標就是發揮人的最大積極性，保證充分的交流。 

XP得優勢是能很好得適應需求得更改、設計框架得更改。 

XP採用和建立一個通常框架相反得方法來適應需求，而是儘量簡單。 

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

問題： 
有沒有感覺實施xp的前提條件很多，如果這些條件不能滿足就不能充分事實xp.例如8小時工作，工作環境等。 

8小時工作可以說即是前提又是結果，如果不能8小時工作，讓開發隊伍有充分休息，大家怎麼能結成pair，高效的開發？而如果開發效率低下，大家有怎麼可能只8小時工作。--notyy 

XP可以說是各種思想的大集合，實際上XP的核心特點就是原型法的軟體開發方法。其它的各種特點可能不一定是XP獨有的，只是針對目前軟體工程中存在的問題，分別提出了很多思路獨特的方法。這些方法並不是一個緊密的整體，相互直接有可能分離、獨立。因此，瞭解了XP的方法，可以只應用它的幾個特點，不一定全部照搬。比如成對程式設計、8小時工作制、輪崗等，都可以單獨實施。－－tomz 

這個觀點不認同，XP核心特點並不是原型法的開發方法。原型法的關鍵是在通過原型獲取需求後，要毫不猶豫的拋棄原型，重新開發，因此原型可以是很粗糙的，程式碼質量可以是很拙劣的。而且因為原型是用來獲取整體需求，所以要求原型要完整，覆蓋到整個專案的各功能點。 而xp是迭代開發，並沒有一個包含所有功能的“原型”版本，而且對每一個“小版本”都有很高的質量要求，比如總共有10個功能點，原型法要求做一個覆蓋所有10個功能點的粗糙版本，而XP要求先做一個有2個功能點的版本，然後再每個開發週期往上面加兩個功能點，並且這包含兩個功能點的版本是要“確實完成”的，是要經過充分的測試，重構、提煉的，讓人放心的小版本。這一點與原型法有很大差別。 ----notyy 

啊，我是門外漢，確實沒有搞清“迭代”和“原型”的區別。用詞有誤。那就是說：“XP的核心特點是迭代”。－－tomz 

我感覺部分崗位的集體主義的軟體開發也是XP的很有用的方法。但不知道在中國是否符合國情。－－tomz 

本文是根據IBM一個開發團隊的XP故事總結的，在www.linuxaid.com.cn網站上看到的。但現在在IBM和linuxaid網站上都找不到這個文章了。－－tomz 

精彩文章，可否轉載？--notyy 

轉載沒問題，這只是我的一個讀書心得，沒有發表過。不過你要轉載到哪裡？這裡不是你的網站嗎？已經貼上來了啊？－－tomz 



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

question: 
“在進行軟體架構設計之前就進行編碼，可以使問題更早暴露，可以使最後的軟體設計更體現編碼的特點，更符合實際，更容易實現，也保證了設計的合理，保證了軟體設計的大量決定的正確性。 ” 
notyy兄，能詳細講一下嗎？ 先編碼後設計，有點不理解他的優點。。你先講一下好嗎？ 踏冰 
世界上並沒有先編碼後設計的開發方法。xp的開發方法是邊設計邊編碼。 
所謂先編碼後設計裡的設計是指軟體架構的設計，指先設計（和編碼）區域性的功能，在進行了幾個週期的開發，有了足夠多的需求和經驗後再提煉出體系架構，是一種自下而上的設計方式。 
好處是避免了先設計軟體架構後編碼的方式中容易出現的設計脫離實際，無法編碼實現等問題。 
缺點是早期設計變化劇烈，不斷的refactoring，可能幾個開發週期後，經過大量修改後設計會和第一個開發週期時所做的設計相差巨大。 但另一方面，這也正好說明，在編碼前先設計軟體架構，是非常困難的，很容易在後期發現難以克服的問題。--notyy 


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

2002-8-30 23:51:13 tomz 
極端程式設計屬於輕量級的方法，認為文件、架構不如直接程式設計來的直接，前兩者容易和最終程式設計產品脫節，容易做很多無用工，而對程式設計者來說，程式碼是最好的表達工具，所有的結構設計思想都馬上可以用程式碼來表達，因此，不需要先對別人描述架構，只要編出來，別人自然懂了。 

使用架構來表達畢竟了用程式設計直接表達在結構上會有脫節的地方。 

另外，極端程式設計不明確區分設計者和程式設計者，程式設計者就是設計者，自然，程式程式碼就成了比較方便的架構表達工具。將兩步並作一步，自然節省設計時間。 

當然，並不是事先沒有溝通，而是極端程式設計認為口頭交流是最有效的，因此，就用不到架構描述工具。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582378/，如需轉載，請註明出處，否則將追究法律責任。