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