靈活其實很簡單（2）--了解靈活12原則

在上篇文章中，我們重新了解了靈活宣言，其中包括往往被人們忽視的前兩句話。那麼接下來這篇文章我們會看一下靈活宣言的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的使用者故事，讓專門的人進行改進或者提高，經過幾個疊代之後發現，這些問題解決之後，團隊的傳遞能力大大提高，而且也進入了一個高效的開發狀态。