極端編程（eXtreme Programming，XP）的特點及討論
轉摘自XPchina.com
XP在很多方面都和我們傳統意義上得軟件工程不同，同時，它也和傳統得管理和項目計劃得方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。
特點如下：
不采用瀑布式得軟件工程方法，而采用原型法。將一個軟件開發項目分為多個迭代周期，每個周期實現部分軟件功能。在每個周期都進行提出需求、設計軟件架構、編碼、測試、發布得軟件開發的全過程。每個周期都進行充分的測試和集成。這樣的好處是可以不斷的從客戶方面得到反饋，更逼近實際的軟件需求。通過頻繁的重新編碼的過程，可以非常適應功能更改的需求，同時增加軟件的易維護性。在不斷的迭代中，避免架構設計的重大失誤造成的軟件不能如期交工，避免了軟件設計的風險。
在軟件設計中，強調簡單性，就是堅決不作用不到的通用功能。同時，也不刻意避免重新編碼，只有不斷得重新編碼才能保證軟件得合理性。不害怕對整個軟件推倒重做。認為重新編碼是很正常得現象。每次得重新編碼都會大大減少軟件中得熵值。
在專業分工中，提出在開發團隊中要有全職的客戶人員的參與，同時在軟件團隊中也要有自己的領域專家。這樣，可以和客戶充分交流，徹底了解應用需求。這種軟件需求的提出不是一次性的，而是不斷的交流。
也有專門的軟件架構的設計師，首先進行軟件整體架構的設計。這種設計一般使用UML語言。
在軟件開發的順序上，和傳統方法完全相反。傳統方法是按照整體設計、編寫代碼、進行測試、交付客戶的方法。而XP是按照交付客戶、測試、編碼、設計的順序來開發。首先將要交付客戶的軟件的界面作出來，先讓客戶對軟件有實際體驗，這樣，可以獲得客戶的更多的反饋，使需求可以在開發前確定。在編碼前就先把測試程序做好，這樣，編碼完成后就可以馬上進行測試。通過不斷的測試來保證軟件的質量。在進行軟件架構設計之前就進行編碼，可以使問題更早暴露，可以使最后的軟件設計更體現編碼的特點，更符合實際，更容易實現，也保證了設計的合理，保證了軟件設計的大量決定的正確性。
在項目計劃的實現上，每次的計劃都是技術人員對客戶提出時間表，由最后的開發人員對項目經理提出編碼的時間表。這種計劃都是從下而上的，不是從上到下的，更容易保證計劃的按時完成。同時，多個迭代周期也使工期的估計越來越精確。
在分工上，強調角色輪換，項目的集體負責，分工的自愿性。分工的自愿性就是每個人的工作內容不是由項目經理分派，而是由每個人自愿領取，這樣保證了每個人可以發揮自己的特長，適應自己的情況。當然，在每個問題上都要有唯一的決策人，同時，也要經過充分的交流和溝通。角色輪換就是在項目中，一個人在不同的周期中擔任不同的角色，可以保證每個人對項目的整體把握，方便項目中的溝通和理解。項目的集體負責，就是每個人不是完成自己的工作就可以了，要對整個項目的完成負責，任何人都可以對工作的任何部分提出自己的建議。任何人都可以從事任何工作。任何人都要對整個項目熟悉。這樣做的優點是可以充分的鍛煉人、可以發揮每個人的積極性、可以使項目不依賴于某個特定的人，方便今后的軟件的維護，通過工作內容的變換可以提高人工作的興趣。通過角色輪換還可以使每個人都勞逸結合，方便相互理解，避免由于不理解而造成的各種配合問題。
保證8小時工作制，避免加班。
（我加幾條：要有充分的培訓、要有每個人的提升空間、制定報酬要根據對企業的貢獻大小，而不是職位的高低，允許下屬比上級薪酬更高，薪酬的高低取決于績效評定，同時績效評定要盡可能量化。并且推行淘汰制。同時有有效的招聘制度。有強有力的后勤保障制度和輕松的企業文化。）
提出了成對編程的思路，就是每個模塊的編碼都是兩個人一起干，共用一臺電腦。這樣，一個人編碼時，令一個人就可以檢查代碼，或對編碼的思路進行思考，寫文檔等。不再有另外的測試人員，兩個人同時完成代碼的測試，并且使先寫測試程序然后再編程。這樣避免了編程人員和測試人員的矛盾。也解決了一個人自己檢查的局限性。兩個人共同檢查可以避免大多數的錯誤。在共同編程中還可以進行經驗的交流和傳授。也避免了將一個工作一直干下去的無聊，交流增加了情趣。并且兩個人共同工作也增加了工作量的彈性，使項目計劃的瓶頸工作能盡快解決。根據成對編程的思路，開發小組也可以分為兩個小組，一個小組進行開發，另一個小組作改進和bug修正等工作。也有同樣的效果。
在人員的分工上要靈活，要保證軟件開發中的角色的齊全，但每個角色可以由幾個人共同擔任，也可以一個人擔任幾個角色，并且在項目的不同時期，不同角色的人員數量會不斷變化。
每天或隔天，開一個站立會議（保證開會時間盡量短），來解決工作時間不一致和相互打擾工作的情況。在每個迭代周期也有一個計劃和分工等的全體大會。
XP的實施方法就要求能適應工作中出現的問題，不斷對xP進行改進，而不能照搬套用。
XP的目標就是發揮人的最大積極性，保證充分的交流。
XP得優勢是能很好得適應需求得更改、設計框架得更改。
XP采用和建立一個通�？蚣芟喾吹梅椒▉磉m應需求，而是盡量簡單。
--------------------------------------------------------------------------------
問題：
有沒有感覺實施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
極端編程屬于輕量級的方法，認為文檔、架構不如直接編程來的直接，前兩者容易和最終編程產品脫節，容易做很多無用工，而對編程者來說，代碼是最好的表達工具，所有的結構設計思想都馬上可以用代碼來表達，因此，不需要先對別人描述架構，只要編出來，別人自然懂了。
使用架構來表達畢竟了用編程直接表達在結構上會有脫節的地方。
另外，極端編程不明確區分設計者和編程者，編程者就是設計者，自然，程序代碼就成了比較方便的架構表達工具。將兩步并作一步，自然節省設計時間。
當然，并不是事先沒有溝通，而是極端編程認為口頭交流是最有效的，因此，就用不到架構描述工具。
文章來源于領測軟件測試網 http://www.kjueaiud.com/