1。我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意
規劃迭代故事時必須按照優先順序安排，為客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷小組關注完成和交付具有使用者價值的功能，而不是孤立的任務。以前我們都用需求規格說明書或者用例來編寫詳細的需求，敏捷使用使用者故事來羅列需求。使用者故事是一種表示需求的輕量級技術，它沒有固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：「作為【使用者的型別】，我希望可以【能力】以便【業務價值】「。使用基於使用者故事的需求分析方法時，仍可能需要原型和編寫文件，只是工作重點更多的轉移到了口頭交流。
2。即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味著我們更了解市場需求。
3。經常性的交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
迭代是受實踐框限制的，意味著即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟體可以很好的工作，那麼交付時間越短，我們和客戶協作就越緊密，對產品質量就更有益。雖然我們多次迭代，但並不是每次迭代的結果都需要交付給使用者，敏捷開發的目標是讓他們可以交付。這意味著開發小組在每次迭代中都會增加一些功能，增加的每個功能都是經過編碼、測試，達到了可發布的質量標準的。
另外敏捷開發專案中對開發階段沒有什麼重要的分割，沒有先期的需求階段，然後是分析階段，架構設計階段，編碼測試階段等，在專案真正開始後，每次迭代中都會同時進行所有的上述階段工作。
4。在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
軟體專案不會依照之前設定的計畫原路執行，中間對業務的理解、軟體的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義的、頻繁 的互動，這樣就可以在早期及時的發現並解決問題。
5。圍繞被激勵起來的人個來構建專案。給他們提供所需要的環境和支援，並且信任他們能夠完成工作。
業務和技術是引起不確定的二個主要方面，人是第三個方面。而業務和技術又必須由人來執行，所以能夠激勵人來解決這些問題是解決不確定性的關鍵。只要個人的目標和團隊的目標一致，我們就需要鼓舞起每個人的積極性，以個人為中心構建專案，提供所需的環境、支援與信任。
6。在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
在十幾或者二十幾個人組成的大團隊中，文件是一種比較合適的傳遞知識和交流的途徑。而敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），所以大量的文件交流其實並不是很經濟的做法。此時面對面的交談反而更快速有效。
7。工作的軟體是首要進度度量標準。
一般的工作都比較容易衡量任務進展，比如讓你去搬運1噸的石頭，我只要去稱一下你已經搬運的石頭重量就知道你完成多少了。而對於軟體來說，在軟體沒有編碼、測試完成之前，我們都不能因為**編寫了多少行，測試用例跑了多少個就去度量這個功能是否完成了。衡量這個功能是否完成的首要標準就是這個功能可以工作了，對使用者來說已經可以應用了。
8。敏捷過程提可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
很多人都認為軟體開發中加班是很正常的，不加班反而不正常，我對此有點不理解，這個可能是國情所致吧。敏捷過程希望能夠可持續的進行開發，開發速度不會隨著迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態度，開發工作不應該是突擊行為。我們不能指望說突擊這個專案後就可以輕鬆了，因為完成乙個專案後會接踵而來下乙個專案，而只要還是拼拼的態度，下乙個專案依舊會讓你的組員再次突擊。這時不知道有人會不會說，那我們就一直加班，也是「持續的開發速度」啊，這時可要注意了，持續加班智慧型導致人疲勞、厭倦，保持長期恆定的速度也只是一種理想而已。
9。不斷地關注優秀的技能和好的設計會增強敏捷能力。
敏捷過程有很多好的技術實踐可以加強產品敏捷能力，很多原則、模式和實踐也可以增強敏捷開發能力。 《敏捷軟體開發－原則、模式與實踐》一書中介紹了很多設計，感興趣的可以去仔細看看。
10。簡單----使未完成的工作最大化的藝術----是根本的。
我們不可能預期後面需求會如何變化，所以不可能一開始就構建乙個完美的架構來適應以後的所有變化。敏捷團隊不會去構建明天的軟體，而把注意力放在如何通過最簡單的方法完成現在需要解決的問題。這時有人會說，我已經預計到了肯定存在哪些需求擴充套件點，我們在一開始是否需要考慮呢？這時團隊需要根據自己的理解去決定是否考慮，如果深信在明天發生了這個問題也可以輕易處理的話，那麼就最好先不考慮。
11。最好的構架、需求和設計出自與自組織的團隊。
敏捷中有很多種實踐，大家都知道，迭代式開發是主要的實踐方法，而自組織團隊也是主要的實踐之一。在自組織團隊中，管理者不再發號施令，而是讓團隊自身尋找最佳的工作方式來完成工作。要形成乙個自組織團隊其實比較難。csdn採訪mishkin berteig中說到 自組織團隊的第乙個要素就是必須有乙個團隊，而不僅僅是一群人。一群人是一幫在一起工作的人，他們彼此之間並沒有太多的溝通，他們也並不視彼此為一體。專案一開始，我們就會組建「團隊」，但很多時候由構架師、需求人員、開發人員和測試人員組成的是一群人而已。他還認為，團隊的形成必須經歷幾個時期。在經歷了初期的磨合後，成員才會開始對團隊共同的工作理念與文化形成乙個基本的認識和理解。團隊內會逐漸形成規矩，而且這些規矩是不言而喻的。比如，每個人都知道上午九點來上班，都會主動詢問別人是否需要幫助，也都會去主動和別人**問題。如果團隊成員之間能夠達成這樣的默契，那麼這個團隊將成為乙個真正高效的工作團隊。在這樣的團隊中，成員之間相互理解，工作效率非常高。在自組織團隊中，團隊成員不需要遵從別人的詳細指令。他們需要更高層次的指導，這種指導更像是乙個目標，乙個致力於開發出更好的軟體的目標。總之，自組織團隊是乙個自動自發、有著共同目標和工作文化的團隊，這樣的團隊總是在向它的組織做出承諾。但是，實現這些承諾對於自組織團隊來說非常重要。否則，一旦出現問題，團隊成員之間就會出現信任危機。
12。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
由於很多不確定性因素會導致計畫失效，比如專案成員增減、技術應用效果、使用者需求的改變、競爭者對我們的影響等都會讓我們作出不同的反應。 敏捷不是基於預定義的工作方式，而是基於經驗性的方式，對以上這些變化，小組通過不斷的反省調整來保持團隊的敏捷性。
敏捷開發之 12條敏捷原則
1 我們最優先要做的是通過盡早的 持續的 交付有價值 的軟體來使 客戶滿意。2 即使到了開發的後期，也 歡迎改變需求 敏捷過程利用變化來為客戶創造競爭優勢。3 經常性的交付 可以工作 的軟體，交付的間隔可以從幾周到幾個月，交付的 時間間隔越短越好 4 在整個專案開發期間，業務人員和開發人員必須天天都...
敏捷開發12個原則
1 我們最優先要做的是通過盡早的 持續的交付有價值的軟體來使客戶滿意。2 即使到了開發的後期，也歡迎改變需求。3 經常性地交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好 4 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。5 圍繞被激勵起來的個人來構建專案。6 ...
敏捷軟體開發的12條原則
1.最優先要做的事盡早，持續地交付有價值的軟體，讓客戶滿意 2.欣然面對需求變化，即使是在開發後期。敏捷過程利用變化為客戶維持競爭優勢 3.頻繁地交付可工作的軟體，從數週到數月，交付週期越短越好。4.在團隊內，面對面交談是最有效，也是最高效的溝通方式。5.在整個專案過程中，業務人員和開發人員必須每天...