source: http://www.gamasutra.com/features/20070301/schofield_01.shtml (原文發表於gamedev.tw)
極致軟體製程( Extreme Programming or XP)是一種敏捷開發的軟體開發方式，這種方式強調適應變化而非預測變化。XP 這個方法的威力是允許遊戲設計者在面對發行商、管理者和開發者本身所提出的多樣化(甚至是互相衝突)需求時，能夠可靠地製作出絕佳的遊戲
慣例告訴我們，如果一個團隊要面對許多人的要求，那麼符合某人的需要就難以顧及別人的需求。XP挑戰這個慣例，並且允許一個開發團隊可以製作出符合所有利害關係人(stakeholder)需求的高品質成品。
XP 可以更加可靠地製作出好的產品是因為它將其焦點放在快速釋出。快速釋出表示遊戲設計者可以看到優先實做的特色看起來像什麼樣子而不用等到整個大型系統被建 立起來才知道。這允許設計者可以更簡單地找出有趣的遊戲方式，並且 “調校”(steer) 遊戲的方向，讓它以最快的速度擁有更有趣的特色。
所以 XP 鼓勵設計者在開發的過程中去調校遊戲，並且可以改變更多遊戲的設計？這大概是所有程式設計師最不想聽到的了！ 如果你的軟體更改相當困難或是相當痛苦，那麼快速調校大概是你最不想做的一件事。但是現實是為了找到有趣的遊戲玩法，設計者必須隨著他對目前遊戲的了解改 變目前的方向。如果程式設計師的工作就是製作出一套絕佳的遊戲，那麼我們需要讓我們自己的程式可以擁有最大限度的調校彈性。極致軟體製程實際上專注在讓程 式設計師專心地快速製作出成品，並且保持專案的彈性。
這裡論上聽起來很棒，但是你現在一定開始好奇為什麼 XP可以允許專案如此容易地被調校？ 它使用相互支援的實踐方式來讓程式碼保持簡單和健康。簡單來說， XP 需要團隊列出特色的優先權，並且依照順序開始撰寫，實做這些特色唯一需要的就是撰寫程式，並且持續地套用小規模的改進來讓程式碼變得更健康。
這篇文章剩下的部份就是提供五個 XP 的關鍵實做元素的概觀，包含了： 測試導向開發(Test Driven Development)、共同撰寫(Pair Programming)、持續設計(Continuous Design)、真實客戶介入(Real Customer Involvement )和精力充沛的工作(Energized Work)。這些實踐方式，還有其他未被列在此處的實踐方式，允許團隊快速地產生可見的成品。可見的成品可以讓調校這款遊戲的設計師可以將遊戲導至正確的 方向。因為程式設計師撰寫時就保持程式碼的彈性，讓製作下一個循環的可見產品程式可以比較容易加入一些新的功能。
在你觀看這些實踐方式時，很重要的是記住 XP 並不只包含 自動單元測試()、每週四十小時工時()和共同撰寫。當然好的XP團隊這些特色都有，這些單純只是表示製作出好的產品。這就是XP-製作出絕佳的遊戲。
測試導向開發(2)
當實踐 測試導向開發(Test Driven Development)時，程式設計師撰寫小部的程式碼來描述他們希望這個新的特色如何在程式中如何運作。這一小部份的程式被稱作 單元測試，並且一開始這個測試會失敗，因為這個測試所需要的特色尚未被實做出來。程式設計師知道這特色將會隨著測試成功而完成。這種流程有許多好處，但是自動化的單元測試是其中最顯著的一種。
自動化單元測試是一種拿來驗證程式中每個小元素是否依照程式設計師的想法運作的測試。開發者可以簡單地運行這些測試來驗證他們所修改的程式碼是否有破壞已經時做好的功能。這些測試允許他們快速並且安全地修改這個專案的程式。
Regression 是開發團隊中最常遇到的潛伏性問題。在專案的早期只有少數的特色需要實做，但隨著專案的進行，越來越難讓所有的特色同時正常運作(甚至難以知道哪個功能是 正常運作的)。自動化測試給我們一個可以隨著功能成長的框架，這允許我們實做新的特色而不用擔心潛藏的 Regression。
TDD 另一個好處是幫助開發團隊感到開心，在隨著他們越來越接近最後成果的時候，以許多小量的成功(通過這些測試)來獎賞開發團隊。
共同撰寫3
共同撰寫是同時有兩個程式設計師使用同一台電腦來進行同一個程式編碼工作的流程。傳統來說，其中一位擔任駕駛的角色(像是打字或是決定哪些要輸入哪些程式碼)，而另一位則是領航員的角色。
領航員並不專注在駕駛可能犯的策略錯誤。他們反而專注在他們正在工作的內容上。他們會問一些像這樣的問題： ‘這些新的程式碼要如何跟舊的程式碼結合？’ 和 ‘是否有可能把我們剛剛修改過的程式碼變得更簡單或是再改的更棒？’
這兩位程式設計師所一起創造出來的程式碼的品質和簡單程度遠遠超過兩者分開各自撰寫的程式碼，因為分開的時候他們很少有機會去改進他們的程式碼。”兩個比一個好”這概念帶來更高品質的程式碼。這個高品質的程式碼比起一個人撰寫的程式馬來的更簡單和安全。
遊戲程式設計師常常做出小型設計的決定。這些決定可以讓遊戲變得更好(或是更難)玩。讓兩位有創造力的人腦力激盪數分鐘可以帶來極為優秀的結果。共同撰寫鼓勵他們快速地討論而不需要聚集大家或是打斷其他人來做個大型的討論，。
共同撰寫幫助這個團隊建立強固的程式碼，並且透過分享經驗、更多人與人之間的互動和減少因為卡住而導致的挫折感來讓這個團隊的氣氛更好。
持續設計4
持續性設計是保持軟體設計可以跟程式每天的需求保持一致的一項藝術。這表示除非程式需要泛用性，否則你不需要建立泛用的系統，但是你必須確保你為這個系統 所設計的簡單版本必須是良好的設計(well designed)。所寫的程式碼較短並不就一定表示這段程式走捷徑或是使用hack手法; 這僅僅表示你應該單單實做你需要的程式碼，因為當程式碼不那麼複雜的時候，程式碼才好容易修正實做方向。
持續設計的其中一個部份就是重構，重構是一種不改變程式的特色但使程式碼變得更健康的方式。隨著你越來越了解你的設計或是原本簡單的設計不再適用於日漸成長軟體的需求，你時常發現如果程式碼適當的更動會讓整個程式更為健康或是簡單。重構是我們讓程式碼保持彈性的方式。
持續設計帶來簡單的程式碼。越簡單的程式碼越容易了解，並且較不容易令人沮喪。這讓程式設計師感到滿足，有自信和安全，這些帶來一個快樂有活力的團隊。
真實顧客參與 5
簡單來說，真實顧客參與就是讓實際的玩家越早玩到遊戲越好。既然遊戲團隊的目標是可見的結果，那麼這方面就應該放到開發前期。這可以讓團隊決定哪個特色需要優先實做，並且調整更好的開發方向。
另一種這個概念的實做方式就是讓設計者跟程式設計師非常緊密地一起工做。這會讓程式設設計師的努力達到最高限度，並且在現實與理想中達到一個最佳的 平衡，讓設計師會說 “這在目前看起來夠好了。” 當程式設計師努力在提供可見的成果時，設計師可以提供某方面是否有趣的意見或是他們可以一起找出哪部份一點也不有趣。
跟可以讓結果更好的人一起工作，對設計者和程式設計師來說，都是一件令人開心的事。這種協同合作來實做功能的方法同時也帶來團隊中的互信。
精力充沛的工作 6
精力充沛的工作，又稱做Sustainable Pace 或是一禮拜工作40小時，這種法則表示你工作的時間不要超過你有生產力的時間。當你疲倦或是生病的時候工作都會減緩你的工作速度，發生許多錯誤，不開心，或是疲倦跟生病更久。
因為程式設計基本上跟靈感有關，如果他們在正確的時間帶著正確的想法，程式設計師可以就可以在短時間內做出大量的成果。但是有著靈感是最難的部份; 我們的大腦需要100%的運作不然它很難想出最棒的解答。 精力充沛的工作讓我們的大腦保持健康、高興，所以它才能常常傳遞出最佳的靈感
精力充沛的工作支援其他XP的實踐方法，並且讓程式設計可以寫出最棒的程式碼和做出最有趣的遊戲。
結論
在這篇文章的開始，我就說過XP並不只是關於自動化測試、每週工作四十小時，也不是只關於共同撰寫。當然，所有好的XP團隊都會做到這些，這些單純地只是引導出絕佳的產品。這就是XP所關心的-創造出絕佳的遊戲。
XP的力量就是它允許遊戲開發者在面對大量個異、甚至是互相衝突的需求時，可以可靠地製作出絕佳的遊戲：
*發行商的需求被滿足了，因為他們的產品更為有趣，他們更常看到可見的結果，並且當他們的行銷人員需要改變他們的產品時，他們的新需求就可以被滿足。
*管理者也開心了因為團隊的士氣更高昂了，遊戲可以改變來符合新的商業需求，並且可見的過程和回饋讓他們知道這個團隊正在正確的路上。
*團隊成員也開心，因為XP這麼多的實踐方式讓人很開心，有趣和帶給人活力。
最後，使用XP可以讓每個人都很開心，因為我們都想要同樣的東西，”做出絕佳的遊戲”