在上篇文章中，我們重新理解了敏捷宣言，其中包括往往被人們忽視的前兩句話。那麼接下來這篇文章我們會看一下敏捷宣言的12原則。理解一下這12原則對敏捷開發在實踐中的指導意義。
12原則作爲敏捷開發對於軟件開發流程的指導性綱領，其實是對敏捷宣言進行了具有實際操作意義的解釋。下面是敏捷宣言12原則：
我們遵循以下準則：
1、我們的最高目標是，通過儘早和持續地交付有價值的軟件來滿足客戶。
2、歡迎對需求提出變更——即使是在項目開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
3、要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
4、項目過程中，業務人員與開發人員必須在一起工作。
5、要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
6、無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
7、可用的軟件是衡量進度的主要指標。
8、敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。
9、對技術的精益求精以及對設計的不斷完善將提升敏捷性。
10、要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
11、最佳的架構、需求和設計出自於自組織的團隊。
12、團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行爲。
第一條準則：講明瞭敏捷開發的最高目標，就是儘早和持續交付有價值的軟件來滿足客戶，這裏我們要注意幾個關鍵詞，儘早，持續，有價值和滿足，通過這幾個詞，我們實際上是可以理解第一條原則的意義，那就是將產品對於客戶的價值放在首位，整個產品的交付和開發週期都是爲了滿足客戶對於產品價值的滿意度。這也是爲了解決傳統軟件開發中沒有將產品對於客戶的價值作爲產品開發的目標的問題而提出的，只有將產品價值作爲軟件開發的目標，才能保證團隊理解開發工作的目標，這樣團隊和個人才能夠不斷調整自己，爲了這個目標而去工作，才能保證產品的持續交付。
案例：某公司新建敏捷開發團隊，但是並沒有進行相關培訓，團隊開發人員不知道敏捷開發的意義，僅僅是感覺換了一種開發模式，對此非常牴觸。後來經過培訓，瞭解到敏捷開發核心意義，知道自己在團隊中的角色，也對團隊的目標統一起來，並且從功能開發的傳統理念轉變爲價值交付中來，從而在後面的開發中，能夠不斷調整自己，爲團隊目標服務。
第二條準則：需求變更可能是軟件開發人員最討厭的，軟件開發人員的理想狀態應該是，設計、接口定義好了，然後我做好就行了，也就是“雞犬之聲相聞老死不相往來”。但是實際情況則是需求變更永遠是存在的，所以敏捷開發提出來的這條準則是，既然我們無法阻止變更，那麼我們就應該抱着歡迎的態度，看看能不能從需求變更中找到機會，化風險爲機遇，從而製造更大的價值給客戶。
案例：某公司在開發產品的時候，客戶經常提出變更需求，要求改變軟件功能，但是該團隊成員始終保持耐心，和客戶溝通，分析變更需求，將變更需求分類識別，最後使得其中部分變更取消，而部分變更導入到現有功能中，而且從變更中發掘了一些新的功能，爲客戶增加了盈利點。
第三條準則：傳統軟件開發流程中，因爲有從需求分析-設計-編碼-單元測試-集成測試-系統測試等控制流程的存在，而且各個流程可能由不同部門和團隊來分擔，導致內耗和效率較低，從而交付時間很容易不受控制，但是敏捷則希望軟件團隊能夠不斷持續的交付軟件，也就是小步快跑的過程，讓客戶不斷的看到項目進展，從而增強客戶對於團隊產品交付能力的信心和滿意度。
案例：某通信企業，以前交付產品，往往都是到了release結束的時候，客戶才能夠看到能夠工作的產品，這個時候發現問題，往往需要加班維護，客戶和開發人員都苦不堪言。後來在接受了敏捷理論之後，將軟件功能拆分成非常小的用戶故事，每個迭代按優先級實現用戶故事，同時也demo給客戶看，客戶每個迭代都能夠看到產品在不斷完善，同時也能夠不斷的進行反饋。用戶滿意度大大提升。
第四條準則：敏捷宣言中地調就強調協作和溝通，那麼這條準則也是希望團隊成員能夠有一個適合溝通的環境，特別是業務人員，他們是接觸客戶的第一責任人，任何客戶的需求都是通過他們傳遞給開發團隊的，只有大家在一起不停的溝通協作，才能保證開發團隊開發出來的產品真正是客戶想要的。
案例：在傳統開發模式中，需求經過市場人員--BA--system analysis--system engineer ---developer,而且期間可能通過文檔來進行溝通，這個時候開發人員往往不知道客戶真正需要的是什麼，所以只能依照自己的理解去開發產品，這樣的產品很難說是滿足客戶需求的。
第五條準則：在敏捷開發流程中，團隊的組建是非常重要的，首先我們要相信團隊成員，相信他們是願意爲了團隊的目標而工作，有能力完成當前的開發任務的。然後給予團隊成員支持，鼓勵。而不是一味的傳遞壓力。
案例：本人在組建敏捷開發團隊的時候，會召集團隊成員開一個小的kick off會議，在該會議上會讓團隊成員討論我們團隊的幾條約定，而第一條就是“相信團隊的每一個成員都會爲團隊當前的開發目標而努力工作”，這是敏捷團隊組成基本原則，這樣才能夠使團隊的成員互相信任，相互幫助，從而和諧統一的向一個目標而工作。
第六條準則：敏捷非常強調面對面溝通，因爲面對面溝通是所有溝通方式中最高效的方法，大家可以通過直接的溝通第一時間把問題解決。
案例：郵件/視頻/即時通信/電話/面對面溝通，其中文檔和郵件是效率最低的方式，而在很多開發人員卻非常喜歡用郵件進行溝通，雖然這樣效率極低。而在敏捷中，站會和看板則是製造一個每天讓團隊開發人員面對面交流的機會，從而將團隊溝通成本降低，減少因溝通造成的項目問題。
第七條準則：敏捷強調即時交付，但是交付產品的衡量則是可以工作的軟件，傳統開發方式中，不同開發階段的交付可能不一樣，導致可能在相當長一段時間，客戶無法看到我們的軟件產品。而敏捷則強調交付一定是可以工作的軟件，這樣的話客戶可以從一開始就看到我們的產品，對產品有一個直觀的感受，從而可以不斷的提出反饋和建立信心。
案例：某通信企業開發一個產品，有6個月的週期，其中前2個月都在做需求分析，文檔設計，提交了大量的設計文檔，而到了後4個月才真正的開發產品，到最後一個月的時候客戶才能看到一些工作的軟件。而用了敏捷開發之後，從第一個月開始，每隔2周，都會交付一個小的功能給客戶看，一開始可能不是很完善，但是到了後來越來越完善，客戶也很驚訝，該企業能做到這樣，而且也有信心了。
第八條準則：可持續開發，一直是敏捷強調的軟件開發節奏。敏捷不只是一味強調快速交付，而是強調一個開發節奏，這個節奏能夠讓項目管理人員和客戶對於這個團隊有信心，就是我們交付給這個團隊的開發任務，他們能夠在多久完成，並且是保證質量的。
案例：一個敏捷開發團隊，一開始的交付能力是逐漸增長的，而PO往往希望團隊能交付的產品越多越好，所以在每個迭代開始都安排了超過上個月迭代10%的工作，但是後來發現，團隊交付能力在到達一定程度上無法再增長了，這個時候如果再增加任務的話，要不無法完成，要不完成不能保證質量，最後根據團隊的交付能力評估，PO每個月只交給團隊能夠完成的任務，這樣團隊的交付能力剛好可以保證交付並且質量。
第九條準則：敏捷開發非常重視技術提升，因爲它相信團隊技術能力的擴展和提升能夠提高產品質量，交付能力等，從而提高團隊的敏捷性。
案例：某敏捷團隊由開發和測試人員組成，一開始開發只管開發軟件，測試負責測試和自動化，但是後來發現由於測試人員較少，很多自動化功能無法完成，導致無法進行足夠的自動化測試，發現了很多由於新代碼導致原有功能被破壞的例子。後來團隊經過協商，希望開發人員也能夠承擔一部分自動化工作，並且將這個作爲團隊和個人的工作考覈之一，經過一段時間運行，發現所有的開發人員都能夠進行自動化測試開發，而且基本上所有的測試工作都可以用自動化來進行，增加了團隊工作效率，並且保證了產品質量。
第十條原則：只做需要做的事，這是敏捷的核心之一。有一句話，剛好最好。
案例：某敏捷團隊在運行一段時間，總是發現有用戶故事無法交付，後來發現是在分解用戶故事的時候，加入了大量的健壯性，穩定性等功能，導致用戶故事變大變多。後來經過和客戶溝通，知道了客戶需要的核心功能，後來便決定在下個迭代只實現這些基本功能，結構發現按時交付能力大大提高。
第十一條原則：敏捷相信好的架構設計是出自自組織的團隊。敏捷的最終目標也就是打造一個自組織團隊，就是該團隊能夠通過高效協作，進行需求分析，架構設計等工作。
案例：某通信企業，原來的設計架構都是有系統工程師來進行，但是系統工程師不在團隊中，不實際編寫代碼，後來在運行中發現往往會出現一些設計問題，比如說不符合當前實現等。後來該企業讓系統工程師和團隊坐到一起，共同進行軟件架構設計。經過一段時間，發現軟件設計比以前好多了，出現的設計相關問題也少了很多。
第十二條準則：我個人認爲回顧會議是敏捷活動中最重要的一個，因爲只有通過回顧會議，找出團隊需要保持的和不足之處，在下個迭代進行改進，才能夠達到團隊不斷改進，不斷前進，提供交付能力和縮短交付時間的目的。
案例：某大型企業，組建SCRUM團隊，開始的回顧會議，大家暢所欲言，但是提出的問題就放在那裏，也沒有什麼改進計劃，或者是時間緊，就不管了，後來發現團隊進步很慢，交付能力停滯不前。後來在SM的引導下，將回顧會議中發現的問題變成下個sprint的用戶故事，讓專門的人進行改進或者提高，經過幾個迭代之後發現，這些問題解決之後，團隊的交付能力大大提高，而且也進入了一個高效的開發狀態。