敏捷軟體開發（原則，模式與實踐）

教堂尖頂上的風標，即使由鋼鐵製成，如果不懂得順應風勢的藝術，一樣會被風暴立即摧毀。

——海因里希.海涅

一、敏捷軟體開發宣言

1、個體和互動勝過過程和工具

人是獲得成功的最為重要的因素。合作、溝通以及互動能力要比單純的程式設計能力更為重要。乙個由平均水平程式設計師組成的團隊，如果具有良好的溝通能力，將比那些雖然擁有一批高水平程式設計師，但是成員卻不能進行交流的團隊更有可能獲得成功。

選擇合適的工具而不是大而全的工具，使用過多的龐大、笨重的工具就像缺少工具一樣，都是不好的，嘗試使用乙個工具，直到發現他無法適用時才去更換他。

團隊的構建要比環境的構建重要的多。

2、可以工作的軟體勝過面面俱到的文件

沒有文件的軟體是一種災難，過多的文件比過少的文件更糟。對於乙個團隊來說，編寫並維護乙份系統原理和結構方面的文件將總是乙個好主意，文件應該是短小的並且主題突出的，文件是為程式服務的，不要為了寫文件也寫文件。

在給新的團隊成員傳授知識的時候，最好的兩份文件是**和團隊。**真實的表達了他所做的事情。人和人只見的互動是將內容傳遞給他人的最快、最有效的方式。

3、客戶合作勝過合同談判

成功的專案需要有序、頻繁的客戶反饋。不是依賴於合同或者關於工作的陳述，而是讓軟體的客戶和開發團隊密切的工作在一起，並盡量地提供反饋。要讓客戶知道我們和他們是同一戰線上的，需要解決的問題才是我們共同的敵人。

4、響應變化勝過遵循計畫

響應變化的能力常常決定著乙個軟體專案的成敗，當我們構建計畫時，應該確保計畫是靈活的並且易於適應商務和技術方面的變化。

計畫一定要做，但是不能做過長遠的細計畫，對短期任務作詳細計畫，對長期任務作粗略計畫。

原則：1、我們最優先要做的是通過盡早的、持續的交付有價值的軟體使客戶滿意

2、即使到了開發後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢

3、經常**付可以工作的軟體，交付的間隔可從幾周到幾個月，交付的時間間隔越短越好

4、在整個專案開發期間，業務人員和開發必須天天都在一起工作

5、圍繞被激勵起來的個人來構建專案。給他們提供所需要的環境和支援，並且信任他們能夠完成工作

6、在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交流

7、工作的軟體是首要進度的度量標準

8、敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度

9、不斷的關注優秀的技能和好的設計會增強敏捷能力

10、簡單——使未完成的工作最大化的藝術——是根本的

11、最好的構架、需要和設計出自於自組織的團隊

12、每隔一段時間，團隊會在如何才能更好工作方面進行反省，然後相應的對自己的行為進行調整