敏捷開發 之 理論概述篇

1、 敏捷實踐

　　1. 敏捷宣言

　　　　個體與交互　　　　賽過　　過程和工具

　　　　能夠工做的軟件　　賽過　　面面俱到的文檔

　　　　客戶合做　　　　   賽過　　合同談判

　　　　響應變化　　　　   賽過　　遵循計劃

　　　　1.1 個體與交互賽過過程和工具

　　　　　　合做、溝通以及交互能力要比單純的編程能力更爲重要。

　　　　　　工具要選用合適的，不要一開始就盲目選擇所謂強大的。要從小工具開始嘗試，直到沒法適用再去更換。

　　　　1.2 能夠工做的軟件賽過面面俱到的文檔

　　　　　　面面俱到的文檔須要花費大量的時間成原本編寫和維護。過期的文檔比沒有文檔更具危害性。

　　　　　　Martin文檔第必定律：直到迫切須要而且意義重大時，纔來編制文檔。

　　　　1.3 客戶合做賽過合同談判

　　　　　　一個指明瞭需求、進度以及項目成本的合同存在根本上的缺陷。大多數狀況下，合同中指明的條款遠在項目完成以前就會變得沒有意義。

　　　　　　那些爲開發團隊和客戶的協同工做方式提供指導的合同纔是最好的合同。

　　　　1.4 響應變化賽過遵循計劃

　　　　　　需求永遠不會絕對穩定，響應變化的能力經常決定着一個軟件項目的成敗。

　　　　　　較好的作計劃的策略是：爲下兩週作詳細的計劃，爲下三個月作粗略的計劃，再之後就作極爲粗糙的計劃。

　　2. 原則

　　　　從上述價值觀中引出的12條原則，它們是敏捷實踐區別於重型過程的特徵所在。

　　　　2.1  咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。

　　　　2.2  即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點。

　　　　2.3  常常性的交付能夠工做的軟件，交付的間隔能夠從幾周到幾個月，交付的時間間隔越短越好。

　　　　2.4  在整個項目開發期間，業務人員和開發人員必須每天都在一塊兒工做。

　　　　2.5  圍繞被激勵起來的我的開構建項目。給他們提供所須要的環境和支持，而且信任他們可以完成工做。

　　　　2.6  在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。

　　　　2.7  工做的軟件是首要的進度度量標準。

　　　　2.8  敏捷過程提供可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度。

　　　　2.9  不斷的關注優秀的技能和好的設計會加強敏捷能力。

　　　　2.10 簡單--使未完成的工做最大化的技術--是根本的。

　　　　2.11 最好的架構、需求和設計出自於自組織的團隊。

　　　　2.12 每隔一段時間，團隊會在如何才能更有效的工做方面進行檢討，而後相應的對本身的行爲進行調整。

2、 極限編程

　　1. 極限編程實踐

　　　　1.1  客戶做爲團隊成員

　　　　1.2  用戶素材(user stories)

　　　　　　 用戶素材(user stories)，也可叫作 用戶故事，就是正在進行的關於需求談話的助記符。

　　　　　　 它是一個計劃工具，客戶可使用它並根據它的優先級和估算代價來安排實現該需求的時間。

　　　　1.3  短交付週期

　　　　　　 1.3.1 迭代計劃

　　　　　　　　每次迭代一般耗時兩週。這是一次較小的交付。

　　　　　　　　開發人員經過度量在之前的迭代中所完成的工做量來爲本次迭代設定預算。

　　　　　　 1.3.2 發佈計劃

　　　　　　　　XP團隊一般會建立一個計劃來規劃隨後大約6次迭代的內容，這就是所謂的發佈計劃。它表示了一次較大的交付。

　　　　1.4  驗收測試

　　　　　　 用戶素材的驗收測試須要在實現素材錢或者實現素材的過程當中完成。

　　　　　　 驗收測試使用可以讓它們自動而且反覆運行的某種腳本語言編寫。

　　　　1.5  結對編程

　　　　1.6  測試驅動的開發方法

　　　　　　 編寫全部產品代碼的目的都是爲了使失敗的單元測試可以經過。

　　　　　　 測試用例按部就班的對代碼的編寫進行指導。

　　　　　　 編寫測試用例的好處是 能夠用來驗證修改過的代碼，有利於重構；促使你編寫可測試的代碼，可有效的對代碼解耦。

　　　　1.7  集體全部權

　　　　1.8  持續集成

　　　　　　 每次簽入代碼時，須要跟其餘的簽入合併。爲了不合並的時間過長，團隊的成員會很是頻繁的簽入他們的模塊。

　　　　1.9  可持續的開發速度

　　　　1.10 開放的工做空間

　　　　1.11 計劃遊戲

　　　　　　計劃遊戲的本質是劃分業務人員和開發人員之間的職責。業務人員決定特性的重要性，開發人員決定實現一個特性所花費的代價。

　　　　　　在每次發佈和每次迭代的開始，開發人員給予上一次中他們所完成的工做量來爲客戶提供一個預算。客戶在這個預算內選擇用戶素材。

　　　　1.12 簡單的設計

　　　　　　a 考慮可以工做的最簡單的事情

　　　　　　b 你將不須要它：不要對將來考慮的過多。

　　　　　　c  一次，而且只有一次：不要容忍重複的代碼，使用抽象來消除重複。

　　　　1.13 重構

　　　　　　代碼每每會腐化。重構就是在不改變代碼行爲的前提下，對其進行一系列小的改造，旨在改進系統結構的實踐活動。

　　　　　　每次改造以後，要運行單元測試以確保改造沒有形成任何破壞。

　　　　1.14 隱喻

　　　　　　隱喻是將整個系統聯繫在一塊兒的全局試圖。

後記

　　本篇介紹了敏捷開發的一些基本原則，下一篇將針對原則中的 計劃、測試、重構 作詳細的介紹。