敏捷開發與極限程式設計
陳沛（系摘編）
軟體設計方法可以區別為重量級的方法和輕量級的方法。重量級的方法中產生大量的正式文件。
著名的重量級開發方法包括iso9000，cmm，和統一軟體開發過程（rup）。輕量級的開發過過程沒有對大量正式文件的要求。著名的輕量級開發方法包括敏捷開發(agile management)與極限程式設計(xp)。重量級方法呈現的是一種防禦型的姿態。在應用重量級方法的軟體組織中，由於軟體專案經理不參與或者很少參與程式設計，無法從細節上把握專案進度，因而會對專案產生恐懼感，不得不要求程式設計師不斷撰寫很多「軟體開發文件」。而輕量級方法則呈現「進攻型」的姿態，這一點從xp（極限程式設計）方法特別強調的四個準則—「溝通、簡單、反饋和勇氣」上有所體現。
極限程式設計簡介
在軟體工程概念出現以前，程式設計師們按照自己喜歡的方式開發軟體。程式的質量很難控制，除錯程式很繁瑣，程式設計師之間也很難讀懂對方寫的**。2023年軟體工程的概念誕生。程式設計師們開始摒棄以前的做法，轉而使用更系統、更嚴格的開發方法。為了使控制軟體開發和控制其它產品生產一樣嚴格，人們陸續制定了很多規則和做法，發明了很多軟體工程方法，軟體質量開始得到大幅度提高。隨著遇到的問題更多，規則和流程也越來越精細和複雜。
到了今天，在實際開發過程中，很多規則已經難於遵循，很多流程複雜而難於理解，很多專案中文件的製作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望於更複雜的、功能更強大的輔助開發工具（casetools），但總是不能成功，而且開發規範和流程變得越來越複雜和難以實施。
為了趕進度，程式設計師們經常跳過一些指定的流程，很少人能全面遵循那些重量級開發方法。失敗的原因很簡單，這個世界沒有萬能藥。因此，一些人提出，將重量級開發方法中的規則和流程進行刪減、重整和優化，這樣就產生了很多適應不同需要的輕量級流程。在這些流程中，合乎實際需要的規則被保留下來，不必要的複雜化開發的規被拋棄。而且，和傳統的開發方法相比，輕量級流程不再象流水生產線，而是更加靈活。
extremeprogramming（xp）是一種靈巧的輕量級軟體開發方法。「extreme」（極限）是指，對比傳統的專案開發方式，xp強調把它列出的每個方法和思想做到極限、做到最好；其它xp所不提倡的，則一概忽略（如開發前期的整體設計等）。乙個嚴格實施xp的專案，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延專案進度。
極限程式設計的方法
結對程式設計
xp中，所有的**都是由兩個程式設計師在同一臺機器上一起寫的——這是xp中讓人爭議最多、也是最難實施的一點。這保證了所有的**、設計和單元測試至少被另乙個人複核過，**、設計和測試的質量因此得到提高。看起來這樣象是在浪費人力資源，但是各種研究表明事實恰恰相反。——這種工作方式極大地提高了工作強度和工作效率。
很多程式設計師一開始是被迫嘗試這點的（xp也需要行政命令的支援）。開始時總是不習慣的，而且兩個人的效率不會比乙個人的效率高。這種做法的效果往往要堅持幾個星期或一兩個月後才能很顯著。據統計，在所有剛開始pairprogramming的程式設計師中，90%的人在兩個月以後都很認為這種工作方式更加高效。
專案開發中，每個人會不斷地更換合作程式設計的夥伴。因此，pairprogramming不但提高了軟體質量，還增強了相互之間的知識交流和更新，增強了相互之間的溝通和理解。這不但有利於個人，也有利於整個專案、開發隊伍和公司。從這點看，pairprogramming不僅僅適用於xp，也適用於所有其它的軟體開發方法。
集體擁有**
在很多專案開發過程中，開發人員只維護自己的**，而且很多人不喜歡其他人隨意修改自己的**。因此，即使可能有相應的比較詳細的開發文件，但乙個程式設計師卻很少、也不太願意去讀其他程式設計師的**；而且，因為不清楚其他人的程式到底實現了什麼功能，乙個程式設計師一般也不敢隨便改動其他人的**。同時，因為是自己維護自己的**，可能因為時間緊張或技術水平的侷限性，某些問題一直不能被發現或得到比較好的解決。針對這點，xp提倡大家共同擁有**，每個人都有權利和義務閱讀其他**，發現和糾正錯誤，重整和優化**。這樣，這些**就不僅僅是一兩個人寫的，而是由整個專案開發隊伍共同完成的，錯誤會減少很多，重用性會盡可能地得到提高。
xp開發小組中的所有人都遵循乙個統一的程式設計標準，因此，所有的**看起來好像是乙個人寫的。因為有了統一的程式設計規範，每個程式設計師更加容易讀懂其他人寫的**，這是是實現collectivecodeownership的重要前提之一。xp過程強調通過使用一些形象的比喻讓所有人對系統有個共同的、簡潔的認識。xp認為加班是不正常的，因為這說明關於專案進度的估計和安排有問題。
迭代
我們開發乙個產品，如果不太複雜，會先定義需求，然後構建框架，然後寫**，然後測試，最後發布乙個產品。這樣，幾個月過去了，直到最後一天發布時，大家才能見到乙個產品。
這樣的方式有明顯的缺點，假如我們對使用者的需求判斷的不是很準確時——這是很常見的問題，一點也不少見——你工作了幾個月甚至是幾年，當你把產品拿給客戶看時，客戶往往會大吃一驚，這就是我要的東西嗎？
迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第乙個月就會拿出乙個產品來，當然，這個產品會很不完善，會有很多功能還沒有新增進去，bug很多，還不穩定，但客戶看了以後，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以後，再花乙個月，在上個月所作的需求分析、框架設計、**、測試等等的基礎上，進一步改進，又拿出乙個更完善的產品來，給客戶看，讓他們提意見。就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血後，直到最後發布之時才發現根本不是客戶要的東西。
**：
極限程式設計與敏捷開發
在按照我的理解方式審查了軟體開發的生命週期後，我得出乙個結論 實際上滿足工程設計標準的惟一軟體文件，就是源 清單。jack reeves 極限程式設計 設計和程式設計都是人的活動。忘記這一點，將會失去一切。bjarne stroustrup 極限程式設計 xp 是敏捷方法中最著名的乙個。它是由一系列...
極限程式設計與敏捷開發
徐景周 在按照我的理解方式審查了軟體開發的生命週期後，我得出乙個結論 實際上滿足工程設計標準的惟一軟體文件，就是源 清單。jack reeves 簡介 2001年，為了解決許多公司的軟體團隊陷入不斷增長的過程泥潭，一批業界專家一起概括出了一些可以讓軟體開發團隊具有快速工作 響應變化能力的價值觀和原則...
極限程式設計與敏捷開發
極限程式設計與敏捷開發 自 http vckbase.com document viewdoc id 1027 在按照我的理解方式審查了軟體開發的生命週期後，我得出乙個結論 實際上滿足工程設計標準的惟一軟體文件，就是源 清單。jack reeves 簡介 2001年，為了解決許多公司的軟體團隊陷入不...