敏捷開發之12條敏捷原則(摘錄)

1.我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
規劃迭代故事時必須按照優先級安排，為客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷小組關注完成和交付具有用戶價值的功能，而不是孤立的任務。以前我們都用需求規格說明書或者用例來編寫詳細的需求，敏捷使用用戶故事來羅列需求。用戶故事是一種表示需求的輕量級技術，它沒有固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：“作為【用戶的類型】，我希望可以【能力】以便【業務價值】“。使用基于用戶故事的需求分析方法時，仍可能需要原型和編寫文檔，只是工作重點更多的轉移到了口頭交流。
2.即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味著我們更了解市場需求。
3.經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
迭代是受實踐框限制的，意味著即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟件可以很好的工作，那么交付時間越短，我們和客戶協作就越緊密，對產品質量就更有益。雖然我們多次迭代，但并不是每次迭代的結果都需要交付給用戶，敏捷開發的目標是讓他們可以交付。這意味著開發小組在每次迭代中都會增加一些功能，增加的每個功能都是經過編碼、測試，達到了可發布的質量標準的。
另外敏捷開發項目中對開發階段沒有什么重要的分割，沒有先期的需求階段，然后是分析階段，架構設計階段，編碼測試階段等，在項目真正開始后，每次迭代中都會同時進行所有的上述階段工作。
4.在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
軟件項目不會依照之前設定的計劃原路執行，中間對業務的理解、軟件的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義的、頻繁 的交互，這樣就可以在早期及時的發現并解決問題。