敏捷開發方法綜述

實施SCRUM，必然會存在不少問題，SCRUM不是解除一切困難的仙丹。是否是先分析一下開發中存在的主要問題，再看看SCRUM可否針對性的解決問題，這樣有目的性的實施SCRUM才能體現其優勢。  
另外：SCRUM強調的精神在於擁抱變化，而不是強調可以嚴格的按照計劃實施進度，每個SPRINT完結時，都或多或少會存在一些沒法按時完成的story，這是正常的，尤爲是在第一次實施SCRUM的團隊中，這種不許確性，尤爲明顯。通常來講，經過3到5個SPRINT，這種狀況會有所好轉，但不會徹底消失，請記住scrum不是解決進度問題的完美開發方式。SCRUM的精神在於，經過逐步的，漸進的方式，有序的搭建一個系統的一部分，在這一部分穩固，牢靠的基礎上再對第二部分，第三部分進行構建，同時在構建的過程當中，不斷根據新的狀況，對舊的代碼進行修訂、重構。 
因此，在實施SCRUM的過程當中，首要強調的是質量，不會承諾過多的story，能夠要求member，能夠不按時完成，可是一旦完成的代碼，必須是0 BUG（固然不可能徹底作到，是一個目標）。  
對於BUG問題，SCRUM的一些輔助手段，是否有嚴格的執行呢？好比，code review, daily build, unit tests. 
我提供我所在團隊的一些保證質量的小手段： 1. 每位成員的代碼，「必須」通過2到多位成員的審覈並取得贊成，方可提交。這種作法比較有爭議，短時間來講，reviewer和reviewee兩方面的工做量都會增長，致使表面上的效率降低。可是從長期來講，通過實踐證實，是有利的，大大減小了錯誤的發生，尤爲是一些對系統結構有重大影響的問題，通常都能經過審覈發現。而且，這種審覈是事前的、零碎的、不間斷的，就咱們來講，通常完成一個task後，而不是一個story，相應的代碼提交以前，就會有這種審覈。頻度最長不超過3天就會有一次。比起某些大塊「代碼走讀」式的審覈，更有效率。 
2. 嚴格執行單元測試。你們都知道須要作單元測試，可是是否定真對待了？是真的想盡辦法構建測試案例，仍是應付了事？認真對待單元測試，無單元測試的代碼嚴禁提交。甚至於在條件容許的狀況下，實施測試驅動開發。即先有單元測試，後有代碼。 
3. 一個良好的每日構建、每日運行工具。這種工具備不少開源的，很是好用。條件容許的狀況下，儘可能作到每提交構建，每提交測試。 
隨着Agile敏捷開發的流行，愈來愈多的公司採用敏捷開發用於軟件產品和應用的開發。筆者的產品開發團隊在兩年前開始採用敏捷開發方法，一直實踐到如今，並取得不錯的成果，包括：產品功能更加符合市場和業務人員的需求，開發效率得到提升。本文從實踐的角度介紹筆者所在團隊的產品敏捷開發過程和做者的敏捷開發體會。 

 1) 注重概念和架構設計，而輕詳細設計       敏捷開發中，注重概念和架構設計，而輕詳細設計。這裏的概念設計，能夠當作是爲何要作這個產品或模塊，強調的是產品的路線規劃、市場趨勢、客戶價值、技 術趨勢等。架構設計，能夠當作從總體上看，概念設計應該用什麼方式實現、分幾個層次、多少組件、不一樣層次和組件之間關係是什麼。詳細設計，則是具體的設計 和作法、API接口等。       一個產品，特別是面向行業的產品，概念設計和架構設計很是重要，須要考慮行業將來的發展方向，產品在市場中橫向和縱向的比較，技術的發展方向，和每一個模塊 的投入和收益的比例等，這樣才能儘量保證產品沿着正確的方向前進。在產品中新增或刪除一個模塊須要很是謹慎，由於一旦新增模塊被客戶使用，之後就很難在 產品中去掉這個模塊。還須要考慮產品各個版本之間的兼容性，以及客戶的升級遷移。因此，在開始正式開發以前，經過概念設計和架構設計，梳理思路是很是必要 的。       之前在作項目時，大可能是從技術角度來考慮哪一些功能模塊須要作，哪一些功能模塊先作，而沒有一個系統化的分析方法。形成的結果是有一些功能模塊投入不少資源，卻並不必定是客戶最想要的。       

2）在敏捷開發中，更加註重客戶需求。若是對產品進行SWOT分析，就能選出付出最小工做量，但能得到最大價值的模塊。       SWOT分析階段會在概念設計和架構設計以後進行，輸入是概念設計和架構設計，輸出是模塊的重要度和須要的時間。這樣按照性價比能夠進行排序，選出最能符合市場的模塊。       一款產品哪一個模塊重要，哪一個先作，須要花多少資源和時間投入，花這麼多時間和資源的模塊是否在客戶心中有相應的重要程度等，這些都是由這款產品的市場策略來決定。全部產品都是爲了市場和贏利爲目的，Agile方法更好地幫助企業實現了這一點。      

 3) 業務和客戶驅動，而非技術驅動       這點說是體會，也能夠說是教訓。在咱們的產品開發過程當中，在某一新版本中從新設計了老版本的某一個重要模塊，而引起了幾個問題：一是，新版本的模塊和老版 本模塊的兼容性問題，致使老版本客戶沒法平滑的遷移到新版本；二是，新版本的改進是純技術方面的從新實現，無論對客戶而言，仍是對內部的架構而言，都沒有 明顯好處；最後致使的結果是咱們花了不少資源和人力去從新實現，可是在最後因爲種種考慮仍是廢棄了從新實現的模塊，依然沿用老模塊。       在產品的敏捷開發中，雖然說擁抱變化，但不盲目變化。產品的改動須要通過概念設計、架構設計以及SWOT分析後，三思然後行。敏捷開發中也強調"在整個項目開發期間，業務人員和開發人員必須每天都在一塊兒工做"，確保技術人員可以開發出客戶須要的產品。       

4) 時刻考慮版本兼容性       敏捷開發，廢除了過多冗餘的文檔和繁雜的設計，強調擁抱變化。但做爲產品，敏捷開發不意味着盲目地去變化。       當設計變更、API接口重構、配置文件變動時，要時刻考慮產品的架構、規劃路線圖，老版本的兼容性，及遷移平滑性。不然，隨着版本的增多，必將面對着大量的維護工做。       

5) 輕文檔，但非無文檔       敏捷開發強調溝通的重要性，而輕冗餘文檔。但敏捷開發並不意味着無文檔。在敏捷開發過程當中，適量的文檔仍是頗有幫助，有助於整理思路，加快溝通和討論。       咱們產品中的文檔包括：概念設計文檔、架構圖、當前版本要實現的功能列表，以及SWOT分析。       這些文檔在每一個產品版本開始以前會有產生，在每一個迭代的過程當中根據業務人員和市場的反饋也會有一些變動。經過咱們實踐證實，這對產品的思路、溝通討論都很是有幫助。       並且這些文檔，大可能是幾頁PPT，書寫和維護工做都很小。   敏捷開發過程       敏捷開發改進了產品的開發流程，提升了整個團隊的效率。下面分析敏捷開發前和敏捷開發後的產品開發的各個階段。