原則一
我們最先要做的是通過盡早的持續的交付，有價值的軟體來時客戶滿意，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高，交付的越頻繁，最終產品的質量就越高。
原則二即使到了開發的後期也歡迎改變需求敏捷過程，利用變化來為客戶創造競爭優勢。
原則三經常性的交付，可以工作的軟體交付的間隔可以從幾周到幾月交付的時間間隔越短越好。
原則四在整個專案開發期間業務人員和開發人員必須天天都在一起工作。
原則五圍繞被激勵起來的個人來構建專案給他們提供所需要的環境和支援，並且信任他們能夠完成工作。在敏捷專案中仍被認為是專案取得成功的最重要的因素，其他因素對於人有負面影響時，就要對他們進行改變。
原則六團隊內部最有效的傳遞資訊方式就是面對面的交談。
原則七工作的軟體是首要的，進度度量標準，明年專案通過度量，當前軟體滿足客戶需求的數量來度量開發進度，他們不是根據所處的開發階段已經編寫的文件多少或者已經建立的基礎結構**的數量來度量開發進度。
原則八敏捷過程提倡可持續的開發速度。
原則九不斷的關注優秀的技能和好的設計會增強敏捷能力。
原則十簡單是根本，敏捷團隊不會是出去構建那些華而不實的系統，他們總是更願意採用和目標一致的最簡單的方法。
原則十一
最好的架構需求和設計出自於自組織的團隊，明天團隊是自組織的團隊任務，不是從外部分配給單個團隊成員，而是分配給整個團隊，然後再由團隊來確定完成任務的最好方法。
原則十二
每隔一定時間團隊會在如何才能更有效的工作方面進行反省，然後相應的對自己的行為進行調整。
——摘自《敏捷軟體開發：原則模式與實踐》by robert c.martin
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...
敏捷開發的原則
一 單一職責原則 the single responsibility principal srp 就是說盡量的單一化類的功能，不要使類具有多個功能。如果類具有多個功能時，任意乙個功能的修改都需要改寫這個類，也就會影響其他的類，而這些類根本沒有使用修改的這個功能。如果單一化功能，這種情況就可以避免。例...
敏捷開發原則（1）
1.我們最優先要做的是通過盡早地 持續地交付有價值的軟體來使客戶滿意。2.我們歡迎需求的變化，即使到了開發後期。敏捷過程能夠駕馭變化，為客戶創造競爭優勢。3.經常交付可以工作的軟體 從幾個星期到 幾個月，時間間隔越短越好。4.在整個專案開發期間，業務人員和開發人員必須朝夕工作在一起。5.圍繞鬥志昂揚...