參與公司的敏捷開發也有一段時間了，還沒有系統的學習過敏捷開發。比如早上的站會，每個月的迭代會，還有自己領取任務去開發故事，這些都是敏捷開發的流程之一。敏捷開發需要不斷的學習，不斷的實踐。現在開始寫一些關於敏捷開發的部落格。
一 敏捷聯盟
1 個體和互動勝過過程和工具
乙個優秀的團隊成員未必是乙個一流的程式設計師，可能他只是乙個平均水平的程式設計師，但是卻能夠很好地與他人合作。合作、溝通以及互動能力要比單純的程式設計能力更為重要。
合適的工具對於成功來說是非常重要的。建議從小工具開始，直到發現它不再適用才去更換它。不要急著去購買哪些昂貴的**控制系統，在使用龐大、高效能的資料庫系統前，先適用平面檔案（
flat file
）。不要認為更大、更好的工具能夠自動幫你做的更好，它們往往造成的障礙要遠遠大於幫助。
記住，團隊的建設要比環境的搭建重要的多。
2 可以工作的軟體勝過面面俱到的文件
直到迫切需要並且意義重大時，才去編寫文件。
沒有文件的軟體是一種災難。**不是傳達系統原理和結構的理想媒介。團隊更需要編制易於閱讀的文件，來對系統及其設計決策的依據進行描述。然而，過多的文件比過少的文件更糟。編制更多的文件需要花費大量的時機，並且要是這些文件和**保持同步，就要花費更多的時間。如果文件和**之間失去同步，文件就會變成龐大的、複雜的謊言，會造成誤導。
3 客戶合作勝過合同談判
為開發團隊和客戶提供的協同方式提供指導的合同才是最好的合同。舉個例子，在專案開發期間，我們和客戶緊密的在一起工作。幾乎每個周五，我們都會把軟體提交給客戶。到寫乙個周的周一或周二，客戶會給我們乙份關於軟體的變更列表。我們會把這些變更放在一起排定優先順序，然後把他們安排在隨後幾周的工作中。客戶和我們如此緊密地在一起工作，以至於驗收測試根本不是問題。因為他們周復一周的觀察著每乙個功能塊的演進，所以他們知道何時這個功能塊能滿足他們的需要。
4 響應變化勝過遵循計畫
較好的計畫策略是：為下週做詳細的計畫，為下三個月做粗略的計畫，在以後就做極為粗糙的計畫。我們應該清楚的知道下兩周完成的任務，粗略的了解以後三個月要實現的需求。至於系統一年後將要做什麼，有乙個模糊的想法就行。
二 12項原則
敏捷軟體開發（原則，模式與實踐）
教堂尖頂上的風標，即使由鋼鐵製成，如果不懂得順應風勢的藝術，一樣會被風暴立即摧毀。海因里希.海涅 一 敏捷軟體開發宣言 1 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。合作 溝通以及互動能力要比單純的程式設計能力更為重要。乙個由平均水平程式設計師組成的團隊，如果具有良好的溝通能力，將比那...
敏捷軟體開發 原則 模式與實踐 （一）
為了達到敏捷開發，我們需要使用一些實踐提供必要的準則和反饋，需要使用一些設計原則使我們的軟體保持靈活且可維護，還需要理解一些已經被證明在特定問題中可以權衡這些原則的設計模式。敏捷軟體開發宣言 人和互動 重於 過程和工具 可以工作的軟體 重於 面面俱到的文件 客戶合作 重於 合同談判 隨時應對變化 重...
敏捷軟體開發原則，模式與實踐書摘
敏捷軟體開發原則，模式與實踐書摘。拙劣設計的症狀 物件導向設計原則 例子1 圖示 liskov替換原則 the liskov subsitution principle,簡稱lsp 例子1 圖示1 例子1 圖示2 程式示例 template void persistentset add const ...