敏捷軟件開發有感
1.個體和交互勝過過程和工具
一個優秀的團隊成員未必是一個技術一流的程序員，可能是技術一般的程序員，但他能很好的與他人合作，溝通，合作，良好的溝通以及交互能力比單純的編程更重要。
2.可以工作的軟件勝過面面俱到的文檔
一個可以工作的軟件需要具有文檔，用文檔可以傳達系統的原理及結構，以及對系統及設計決策進行描述。但過多的文檔也并不是一件好事，首先編制需要花大量的時間，保持各文檔同步，文檔與代碼之間的同步更是一件難事，如果沒有做到同步，那么會形成誤導，后果將更嚴重。
對于團隊來說，需要編寫和維護一份描述系統原理及結構的文檔，描述系統原理，結構和設計原理。關于培訓新員工，則將其與業務及軟件均熟悉的老員工坐在一起，實時指導，并結合代碼。
3.客戶合作勝過合同談判
與客戶緊密的結合在一起，短周期的向客戶演示軟件的運行情況。得到客戶的反饋并及時跟進進行更改。
4.響應變化勝過遵循計劃
做短時間的詳細計劃，長時間的粗略計劃，時間越長計劃越粗略
短周期，持續的交付能工作軟件給客戶，得到客戶的反饋。
以人為本，給成員自信，激勵成員來溝建項目，信任每個人都成完成。
以能夠滿足客戶需求的數量來度量軟件的進度。
使團隊成員保持高度集中的精力，飽滿的精神，不要為了多做一點工作而借用明于的精力。
最好的架構，需求，設計出自于團隊。
每隔一段時間，團隊對更有效的工作進行反省，對組織方式，規則，關系等進行調整，達到更有效的工作方式
極限編程
1.客戶做為團隊開發人員，客戶可以是和開發團隊同一家公司的一組業務分析師或市場專家，可以是用戶團體委派的用戶代表。
2.每兩周交付一次可以工作的軟件，迭代計劃（兩周做一次，重復周期），發布計劃，一次做大概三個月的發布計劃，做一次長周期的交付。
3.驗收測試
4.結對編程，兩個人使用一臺電腦，一個控制鍵盤，一個檢查代碼的錯誤及可以改進的地方，結對的關系每天改變一次，每個團隊成員應該和其他所有團隊成在一起工作過，這樣能夠促進業務知識及技術知識在團隊中的快速傳播，且能大大減少缺陷率。
5.測試驅動的開發，編寫所有產品代碼的目的都是為了使測試通過，測試用例和代碼一起演化，基本是幾分鐘一次。結果，一個非常完整的測試用例集就和代碼一起生成起來。
6.每個結對都有對任何一個模塊的檢出（check out）權，及修改權力，沒有程序員對某一個特定的模塊單獨負責。
7.團隊人員保持穩定適中的開發速度，不允許加班。
8.開放的工作空間，積極討論的工作環境。生產率會成倍的提高。
9.簡單的設計開發，考慮能夠工作的最簡單的方式，如能夠能頁面完成的就不能EJB，不用數據庫。不能出現重復的代碼，一次就夠。
10.團隊經常性地對代碼進行重構。