敏捷式軟體開發 (Agile Software Development)（摘錄）

文章目錄

• 敏捷原則
• 關于敏捷實踐（Paul Oldfield）
• 極限編程
• 極限編程的有效實踐

 

什麼是敏捷式軟體開發 (Agile Software Development)？

敏捷式軟體開發 (Agile Software Development)是一個處理軟體工程項目的概念性架構，它擁抱並促進在項目的整個生命週期中產生的演化式變化。Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. （wikipedia）請注意其中的三個關鍵詞：在項目的整個生命週期中：這就涉及到了【敏捷專案管理】、【敏捷需求萃取】、狹義的【敏捷式軟體開發 (Agile Software Development)】三個主要的領域和過程。要注意的是，上述三個過程並不是互相分開的，而是你中有我，我中有你。擁抱並促進變化：世界上唯一不變的是變化。不論在任何領域，漠視、甚至否認、抗拒變化，都不是一個理性，嚴肅的人所應有的態度。學會如何識別變化的大勢，並在可能的時候，促使變化向好的方向發展。這才是面對變化的正確應對之法。演化式：雖然上面提到促進變化的發展，但是軟體的演化過程，我相信是有其自身內在邏輯的，存在一些根本規律和指導方針；並不是完全以人的主觀意識為主導。老子講“順勢而為，無為無不為”，我認為是對上述後兩點的精確概括與指導。 

敏捷式軟體開發 (Agile Software Development)宣言

《敏捷式軟體開發 (Agile Software Development)宣言》(Manifesto for Agile Software Development)制定了4個核心價值觀，其核心就是一個詞：變革，這些價值觀組成了敏捷專案管理的核心價值觀：We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ☆     Individuals and interactions over processes and tools ☆     Working software over comprehensive documentation ☆     Customer collaboration over contract negotiation ☆     Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 我們正在通過實踐和協助其他人實踐，揭示更好的開發軟體的方法。我們從實踐中得出的價值觀是：☆     人和互動重於過程和工具。☆     可以工作的軟體重於面面俱到的文檔。☆     客戶合作重於合約談判。☆     隨時應對變化重於循規蹈矩。 我們通過實踐和協助他人實踐，發掘出更好的[產品]開發方法，通過上述工作，我們形成如下價值觀：☆     人和相互交流勝於流程和工具☆     致力於[產品]勝於編製綜合性文檔☆     與客戶協作勝於合約談判☆     適應變化勝於遵循計劃也就是說，雖然右邊的條目有價值，但我們更看重左邊的條目。 

關於“敏捷式軟體開發 (Agile Software Development)宣言”的爭論

 Simon Baker的想法是，敏捷宣言中的一些概念是商務群體很難理解的，如果把精益開發中的一些概念（諸如追求卓越，理解並消除浪費，整體最佳化和排隊理論）加入到敏捷宣言中，就可以解決這個問題。 Brian Marick接著給出了宣言中所缺少的四種理念：技能、紀律、舒適和快樂。 這並不是“另一類Agile”。這實際上是一個工作間，人們通過觀看我和Chet協同工作，可以以特殊的方式來瞭解敏捷，並對它產生興趣。我們認為完善的軟體開發過程應當包括優秀的開發技能和嚴格的紀律約束，同時還需要大家在輕鬆的環境下全心投入——這就是我們所說的“時尚優雅”。我們的計劃是協助人們理解我們的目標和完成目標的方式，並且讓他們能夠通過充分的親身體驗來判斷這種方式是否適用於他們自己的開發過程。（Ron Jeffries和Chet Hendrickson）Jason Yip的觀點則相反，他給出了重構宣言後的一個精簡且風趣的版本：

• 讓我們互相交談
• 讓我們構建軟體給你看
• 讓我們彼此信任
• 讓我們對正在發生的一切和我們所學到的東西做出響應

Petit最後總結說： “ 捷徑就是兩點之間最遠的路線。” 看上去半途而廢的敏捷實施甚至比它想要取而代之的完整流程還要更壞。 敏捷原則下列敏捷原則構成了敏捷宣言的基礎，也是最佳實務的來源。1.         我們首要目標是通過更早地持續傳遞有價值的軟體來滿足客戶的需求.2.         歡迎需求變更，即使是在項目開發的晚期也是這樣。敏捷過程適應變化的特性使得客戶在競爭中更具優勢。3.         頻繁交付可以工作的軟體，從幾周到幾個月，較短的交付周期有更大的優勢。4.         業務人員和開發人員必須在項目過程中每天協同工作。5.         調動個人積極性，給他們需要的環境和支援，並信任他們完成任務的能力。6.         面對面的交談，是最有效和效率最高的項目組內及組間資訊傳輸方式。7.         可工作的軟體是衡量項目進展的主要依據。8.         敏捷過程提倡，開發是一個持續的過程。項目召集人，開發人員和客戶應該維持穩定的項目進展速度。9.         持續對技術和設計進行最佳化，使項目有更高的敏捷性.10.     盡量簡化，不做目前不需要的工作，這是一條基本原則.11.     最好的架構，最好的需求和設計從有自我組織能力的團隊中產生.。12.     項目組要定期總結回顧，思考怎樣讓團隊變得更加有效,並作出相應調整。  

敏捷究竟是什嗎？（Ivar Jacobson）

敏捷是關於以下三件事情的：1.       最重要的，敏捷是一門社交工程學。這是敏捷最大的特點。它關注的是，如何以一個團隊的形式開展工作，如何激勵團隊成員，如何相互合作等等。2.       敏捷是輕量級的。RUP完全依賴顯性知識，與此不同，敏捷還依賴隱性知識。在RUP中，我們設法把我們認為是最佳的實踐記錄下來。然而，人們根本不閱讀關於開發過程方面的書，寫下這些書也就毫無意義了。相反，敏捷認為，只要有掌握足夠知識的人，就可以開發出優秀的軟體。當然，這個觀點倍受質疑，但是事實的確如此。3.       敏捷提供技術實踐。這其實是敏捷中貢獻最微弱的部分。它所提供的技術實踐幾乎沒有包括新技術。迭代與增量式開發，都是存在很久的觀點。使用者故事，則是某種特殊類型的簡化版用例。最為有趣的新想法就是測試驅動的開發。我並不是說敏捷技術實踐毫無價值，而只是強調，如果它僅僅就是這些內容的話，我們就不會為敏捷如此癡迷了。正如你們所看到的，軟體工程與敏捷抓住了軟體開發的不同方面。軟體工程的強處在於技術性實踐；而敏捷的優勢則是社交工程。因此它們是相輔相成的。軟體工程就像是件緊身衣，束手束腳，而敏捷則十分輕巧，但更難駕馭。問題在於，我們能否從兩個世界中取其精華。當然，我們能！最終，軟體工程陣營有一系列技術實踐，不同的敏捷方法也有另一些略帶重複的實踐。那麼，我們能找到兩者共存的方式嗎？當然，我們能!要做到這些，我們必須用新的觀念來看待實踐。我們不再談論過程，實踐已經取而代之，成為一等公民。過程僅僅是實踐的組合。 關于敏捷實踐（Paul Oldfield）我常常遇到那些不將製造業和軟體開發加以區分的人，他們看到了最佳實務以及高度自動化的生產流程，並希望將其應用在軟體開發中。在這裡我不會提及他們的名字，我遇到過按照時間和原材料支付工資，利潤與人數多少相關的情況，在這裡，所謂效率意味著利潤的減少，而且客戶直到接受不再需要這麼多工人的事實才會承認效率的提升。  有時候我會想起剛剛接觸到敏捷實踐的時候，某些實踐挑戰著我的世界觀，幸運的是，我的處世哲學讓我樂意探索這些對我的世界觀產生挑戰的部分，萬一在這些問題上我犯了錯誤呢，萬一別人才是對的呢。每一處挑戰開始的時候就像一個新的宗教，但是進行探索就會破除盲目崇信。就我所看到的，大多數的人選擇符合其已有觀念的意見。他們以近乎宗教的方式接受或者拒絕新的觀點。他們或許會進行某些膚淺的推理，但他們認為進行詳細論證是在浪費時間。這對敏捷的盲目接受者和詆毀者同樣適用。  Emergent Architecture是最初我認為不符合我世界觀的部分。最終我發現其倡議者所建議的正是我在研究項目上7年間所做的。在這個項目中， Emergent Architecture逐漸層為成型的解決方案。當然，與過去相比，敏捷的倡議者提出了更多的規程。應用規程勢必會影響靈活性，這些規程之所以有效是因為在現代系統中創新的程度較過去大大降低了。敏捷的倡導者所創造的規程是從完全不同的，非製造業的角度展開的，這樣它依然保持著靈活性。 我花了很長的時間才明白沒有哪個敏捷實踐是可以脫離其他實踐單獨運作的。在試圖瞭解某一個實踐如何指導開發工作之前，我需要對全域有一個清醒的認識。  極限編程極限編程（Extreme Programming，XP）是敏捷方法中的一種。極限編程中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和勇氣（Courage）。極限編程的有效實踐 1、完整團隊 XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。 2、計劃遊戲       計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。 3、客戶測試       作為選擇每個所期望的特性的一部分，客戶可以根據指令碼語言來定義出自動驗收測試來表明該特性可以工作。  4、簡單設計       團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含儘可能少的代碼。  5、結對程式設計       所有的產品軟體都是由兩個程式員、並排坐在一起在同一台機器上構建的。  6、測試驅動開發       編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋迴圈，尤其是功功能能驗證方面的反饋迴圈。程式員以非常短的重複持續時間工作，他們先增加一個失敗的測試，然後使之通過。  7、改進設計       隨時利用重構方法改進已經腐化的代碼，保持代碼儘可能的乾淨、具有表達力。  8、持續整合       團隊總是使系統完整地被整合。一個人拆入（Check in）後，其它所有人責任代碼整合。  9、集體代碼所有權        任何結對的程式員都可以在任何時候改進任何代碼。沒有程式員對任何一個特定的模組或技術單獨負責，每個人都可以參與任何其它方面的開發。  10、編碼通訊協定        系統中所有的代碼看起來就好像是被單獨一人編寫的。  11、隱喻        將整個系統聯絡在一起的全域視圖；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。  12、可持續的速度        團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們儲存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。