我的敏捷開發實踐
—— 擁抱變化的產品開發流程
【IT168 專稿】
隨着Agile敏捷開發的流行，越來越多的公司採用敏捷開發用於軟件產品和應用的開發。筆者的產品開發團隊在兩年前開始採用敏捷開發方法，一直實踐到現在，並取得不錯的成果，包括：產品功能更加符合市場和業務人員的需求，開發效率獲得提高。本文從實踐的角度介紹筆者所在團隊的產品敏捷開發過程和作者的敏捷開發體會。
敏捷開發體會
實施敏捷開發近兩年來，我對在產品開發中應用敏捷方法有着深刻的體會。首先說下產品背景。我參與的產品是面向行業的產品，在全世界都有客戶，有10年曆史，和一百多個基於不同版本的客戶，我們的團隊完全負責產品的未來發展方向、發佈計劃、架構、設計、開發進度、測試、客戶支持等。在這樣一個面向全球的產品和自主的團隊環境中進行敏捷開發體會尤其深刻。
1) 注重概念和架構設計，而輕詳細設計
敏捷開發中，注重概念和架構設計，而輕詳細設計。這裏的：
概念設計，可以看成是爲什麼要做這個產品或模塊，強調的是產品的路線規劃、市場趨勢、客戶價值、技術趨勢等。
架構設計，可以看成從整體上看，概念設計應該用什麼方式實現、分幾個層次、多少組件、不同層次和組件之間關係是什麼。
詳細設計，則是具體的設計和做法、API接口等。
一個產品，特別是面向行業的產品，概念設計和架構設計非常重要，需要考慮行業未來的發展方向，產品在市場中橫向和縱向的比較，技術的發展方向，和每個模塊的投入和收益的比例等，這樣才能儘可能保證產品沿着正確的方向前進。在產品中新增或刪除一個模塊需要非常謹慎，因爲一旦新增模塊被客戶使用，以後就很難在產品中去掉這個模塊。還需要考慮產品各個版本之間的兼容性，以及客戶的升級遷移。所以，在開始正式開發之前，通過概念設計和架構設計，梳理思路是非常必要的。
2) SWOT分析
以前在做項目時，大多是從技術角度來考慮哪一些功能模塊需要做，哪一些功能模塊先做，而沒有一個系統化的分析方法。造成的結果是有一些功能模塊投入很多資源，卻並不一定是客戶最想要的。
在敏捷開發中，更加註重客戶需求。如果對產品進行SWOT分析，就能選出付出最小工作量，但能獲得最大價值的模塊。
SWOT分析階段會在概念設計和架構設計之後進行，輸入是概念設計和架構設計，輸出是模塊的重要度和需要的時間。這樣按照性價比可以進行排序，選出最能符合市場的模塊。
一款產品哪個模塊重要，哪個先做，需要花多少資源和時間投入，花這麼多時間和資源的模塊是否在客戶心中有相應的重要程度等，這些都是由這款產品的市場策略（客戶價值）來決定。所有產品都是爲了市場和贏利爲目的，Agile方法更好地幫助企業實現了這一點。
3) 業務和客戶驅動，而非技術驅動
這點說是體會，也可以說是教訓。在我們的產品開發過程中，在某一新版本中重新設計了老版本的某一個重要模塊，而引發了幾個問題：一是，新版本的模塊和老版本模塊的兼容性問題，導致老版本客戶無法平滑的遷移到新版本；二是，新版本的改進是純技術方面的重新實現，不管對客戶而言，還是對內部的架構而言，都沒有明顯好處；最後導致的結果是我們花了很多資源和人力去重新實現，但是在最後由於種種考慮還是廢棄了重新實現的模塊，依然沿用老模塊。
在產品的敏捷開發中，雖說擁抱變化，但不盲目變化。產品的改動需要經過概念設計、架構設計以及SWOT分析後，三思而後行。敏捷開發中也強調"在整個項目開發期間，業務人員和開發人員必須天天都在一起工作"，確保技術人員能夠開發出客戶需要的產品。
4) 時刻考慮版本兼容性
敏捷開發，廢除了過多冗餘的文檔和繁雜的設計，強調擁抱變化。但作爲產品，敏捷開發不意味着盲目地去變化。
當設計變動、API接口重構、配置文件變更時，要時刻考慮產品的架構、規劃路線圖，老版本的兼容性，及遷移平滑性。否則，隨着版本的增多，必將面對着大量的維護工作。
5) 輕文檔，但非無文檔
敏捷開發強調溝通的重要性，而輕冗餘文檔。但敏捷開發並不意味着無文檔。在敏捷開發過程中，適量的文檔還是很有幫助，有助於整理思路，加快溝通和討論。
我們產品中的文檔包括：《概念設計文檔》、《架構圖》、《當前版本要實現的功能列表》，以及《SWOT分析》
這些文檔在每個產品版本開始之前會有產生，在每個迭代的過程中根據業務人員和市場的反饋也會有一些變更。通過我們實踐證明，這對產品的思路、溝通討論都非常有幫助。
而且這些文檔，大多是幾頁PPT，書寫和維護工作都很小。
敏捷開發過程
敏捷開發改進了產品的開發流程，提高了整個團隊的效率。下面分析敏捷開發前和敏捷開發後的產品開發的各個階段。
1) 敏捷開發"前"的產品開發過程
圖1 敏捷前開發流程
上圖是敏捷開發前我們產品一個版本的開發流程，整個開發大概持續一年左右。從圖中可以看出，流程中的大多數活動都是串行進行。這樣的一種類似瀑布的開發流程，前提是需求在產品的初始階段就完整的被捕獲並正確的分析，這樣才能保證最後交付的產品是客戶所需要的產品，但通常這樣的理想狀況很難實現。
類瀑布的開發流程缺乏靈活性，無法通過開發活動來發現不夠確切的需求，導致產品無法隨着業務人員和市場的反饋而隨需應變，開發出符合業務人員需求的產品。
2) 敏捷開發"後"的產品開發過程
圖2 敏捷後開發流程
上圖是敏捷開發"後"我們產品一個版本的開發流程，整個開發大概也是持續一年左右，但每個迭代都是1個月時間。和敏捷開發前相比，有很多的區別和優點，下面是其中幾點：
市場和需求驅動，擁抱變化
在我們產品敏捷開發中，每個迭代結束，都會有一個產品迭代演示大會，把這個月的開發結果演示給組員、業務人員、售前，甚至客戶，並收集反饋。此外，在開發的過程中，產品的業務人員和售前時刻保持與產品開發團隊的溝通和工作，保證開發出來的產品是符合業務需求。
充分利用資源和時間
敏捷開發前，產品的需求設計階段佔用整個開發流程35%左右的時間，這段時間只需要幾個核心的架構師和設計人員，無法充分地利用開發和測試人員。敏捷開發後，迭代開發、強調溝通、縮減文檔，在每個迭代初期就可以充分地利用開發、測試人員的時間，達到效率最大化。
每日交付
產品開發過程中，每天都會做自動化Build，並生成可以交付的產品。業務人員、客戶都可以試用並提供反饋和新需求。
充分自動化
敏捷開發強調擁抱變化，這必然帶來動盪的產品代碼變更。每一個新的功能和修改的功能，都可以影響到其他功能，造成副作用。所以，需要自動化去支持變化，在變化的同時保證質量和開發速度，包括編譯自動化、單元測試自動化、功能測試自動化、UI測試自動化、集成測試自動化等。
架構師和Scrum Master的重要性
流程的變化必將帶來崗位和職責的變化，架構師和Scrum Master是在敏捷開發中兩個重要的人物角色：
1) 產品架構師
在產品的敏捷開發中，特別是我所參與的產品是面向行業的產品，架構師是個舉足輕重的角色，需要有深厚的行業背景、創新能力，以及架構能力。
產品是爲了解決一類客戶需求而存在。但是，客戶的需求往往是會隨着業務的發展而變化，而且競爭對手也會有類似產品的推出。所以一個產品推出市場後，所具有的功能模塊慢慢地會越來越成熟，並擁有越來越多的競爭對手，慢慢地失去競爭力。一個好的產品，特別是面向行業的產品，要具有長期的生命力，需要具有下圖所示的產品模型：
成熟的模塊：指的是推出市場有一段時間，這些功能模塊因滿足客戶的需求而被廣泛使用。隨着市場趨於穩定，大量競爭對手的產品也推出類似的功能。這些成熟模塊都是產品的基本模塊，不代表產品的競爭力。產品中如果只具有這些功能模塊，隨着需求和競爭的激烈，慢慢會走向滅亡。如90年代的BP機一樣，當手機一旦推出，這個產品也就走向滅亡。
發展中的模塊：指的是剛推出市場並且具有強勁的市場生命力、符合客戶當前幾年的業務發展需求，正在被大客戶所接受的功能模塊。這些功能模塊是產品佔領市場的動力，是繼成熟的功能模塊後，產品的新的增長動力。
研究中的下一代產品方向：指的是還沒有推出市場、正在研究中的、符合未來行業五到十年發展方向的模塊。當然如果能創造出未來的發展方向，則是最高境界。如任天堂的Wii、蘋果公司的iPhone。
一個行業軟件產品要保持長期的生命力，在整個產品的生命週期架構規劃中，需要考慮到這三種模塊和特性，只有這樣才能保持產品的先進性和長久生命力。
敏捷開發也強調擁抱市場變化，這對產品架構師提出了很高的要求——深厚的業務背景、創新能力、技術洞察力和架構思想。
2) Scrum Master
Scrum Master雖然是敏捷開發的新名詞，但其工作內容和開發組長沒什麼太大的區別：安排任務、協調資源、控制進度和解決難題。
架構師根據對行業的理解和創新，設計出產品的架構。Scrum Master則是進一步分解和實現這個架構中的每個組件。如果形容"奧運會開幕式"是一個產品，架構師則設計整個開幕式的主題、創意、架構和包含的主要環節，而Scrum Master就是整個龐大工程的詳細設計者和協調者。
在我們產品中有三個Scrum Master，各自負責架構中的不同模塊，並和開發人員一起把模塊分解成一個個單獨的、可以衡量的用例，然後協調開發人員高質量的完成任務。
此外，每天早上需要主持小組成員進行一個10分鐘左右Scrum會議。每個組員彙報昨天完成的任務，是否完成任務以及碰到的問題，最後是今天打算完成的任務。Scrum Master會協調解決每天碰到的問題，確保產品進度和質量。
總結
在筆者的理解中，敏捷開發是一種思維方式和軟件過程方法論，以及一系列的最佳實踐，它能幫助團隊開發出更加符合市場需求的產品。我們的團隊在產品兩個版本的敏捷開發歷程中，不斷摸索，找到了一條適合自己的產品敏捷開發流程，我們還將繼續用敏捷的思想改進我們的敏捷開發流程，希望能與大家討論探索，持續改進。