互聯網企業的敏捷開發之道

版權聲明：本文由韓偉原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/236

來源：騰雲閣 https://www.qcloud.com/community

做者介紹：韓偉，1999年大學實習期加入初創期的網易，成爲第30號員工，8年間從程序員開始，歷任項目經理、產品總監。2007年後創業4年，開發過視頻直播社區，及多款頁遊產品。2011年後就任於騰訊遊戲研發部公共技術中心架構規劃組，專一於通用遊戲技術底層的研發。

在互聯網時代，軟件工程經歷了從瀑布式到敏捷式開發模式，並不斷的討論和實踐。而一些軟件公司，在面對項目進度壓力時，每每都會用上「敏捷」類的開發模式來擺脫壓力的侵襲。

一.老闆最喜好的員工是最使人頭疼的

有不少公司的老闆在進度會議上都會大力提倡「敏捷」。敏捷自己就有「快」的意思。我以爲「敏捷」這個詞真的很討老闆喜歡。加上這個開發模式講究快速修改產品，快速發佈產品內容。所以互聯網公司的老闆們都以爲這個敏捷模式是最合適的軟件開發模式，紛紛要求開發團隊學習而且執行。

開發團隊也但願學習這種敏捷模式，他們看了不少書，開了不少會，而後真正的執行起來，卻發現只是額外多了許多工做，而真正的開發進度並無以爲有很大的進展。今後老闆一說敏捷，給你們的感受就是：要加班了。

所以，咱們有必要從新從本源上來了解一下「敏捷」。敏捷一詞來源於2001年初美國猶他州雪鳥滑雪聖地的一次「敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）」的聚會。然而，這是一個軟件開發方法的名字，不表示用了就必定會加快開發進度。敏捷開發方法自己並未規定任何的開發流程，也沒有模板文檔，他是一個宣言。

1. 人和（人與人的）交互 優先於過程和工具

咱們是否習慣經過無數的評審、郵件、工單來溝通工做上的事情？甚至是QQ的留言？咱們可否真正的改變本身的溝通習慣，面對面的，或者共同的看一個屏幕的去談工做。我認可舒服的轉椅有極大的粘性，讓人的屁股不肯意離開，可是若是你嘗試去面對面溝通，你會馬上唾棄QQ和郵件。對於我來講，任何來往回覆文字少於100字的郵件和QQ，都是沒價值的。用這些打字的十分之一時間，就已經能把事情溝通的很好了。有些公司裏面使用冗長的「流程」管理來推動工做，這些工做須要按流程規定逐級批覆，這簡直就是皇上批摺子的工做做風——緩慢、閉塞、脫離實際。

2. 「能夠工做的軟件」優於「求全責備的文檔」

有一些概要設計的模板有10來頁的框架和目錄，就算你把文檔寫的面面俱到，你仍是可能在開發的時候碰到一個能困擾你10來天的邏輯BUG。與其要求文檔把全部的事情都預計到，還不如早點讓軟件跑起來，而後有什麼問題馬上解決。更重要的是，客戶是看不懂你的概要設計文檔，在你滿頭大汗的作完以後，可能發現徹底不是他要的東西。可是若是你有一個很簡陋的但可運行的軟件，客戶立刻就能理解你想要作的東西，而且提供有價值的意見。既然如此，你何苦去寫那些既沒人看，也沒人看的懂的長篇大論呢？

3. 客戶協做 優先於合同談判

咱們作的每件事都有成本，這個是顯而易見的，可是若是咱們作的是無用的東西，客戶也不會爲此買單。就算咱們能經過各類手段，把合同談下來，那也不表明客戶會真心實意的成爲咱們的長期夥伴。他們在付款後可能會以爲被騙了，而後不再願意去投資了。所以軟件開發要實現真正的價值，除了客戶付款外，還要和客戶一塊兒來作這個軟件。只有客戶參與，軟件才能真正知足需求。而軟件需求是如此的變化無窮，在開發者和用戶之間的理解又有着深深的鴻溝，只有敢於去填平那些鴻溝，精準的找出需求，才能開發出真正有用的軟件。對於通常的企業應用軟件，咱們每每能和咱們的客戶面對面的討價還價，可是在互聯網軟件領域，更多時候根本沒有可供談判的客戶，要找到願意協做的用戶，還要額外付出成本。

4. 隨時應對變化 優先於循規蹈矩

變化是惟一不變的東西。這是一個哲學命題，可是在軟件開發行業裏面，倒是一個平常可見的真理。咱們懼怕變化，詛咒變化，努力抵制、削弱變化，心理想着客戶永遠別再提新的想法，這實際上是很愚蠢的。由於變化纔是商機，有變化，就須要開發人員的工做。誰最能適應變化，誰就能在競爭中脫穎而出。適應變化，是軟件開發人員技術水平的最高標準。

宣言還包括瞭如下一些原則：

1. 對咱們而言，最重要的是經過不斷交付有價值的軟件來知足客戶須要

   不斷交付軟件，不斷更新版本，這不只是最有效的得到準確需求的手段，仍是市場競爭中最有力的手段。客戶會由於你的努力而對這個軟件和團隊產生期待，從而願意繼續支付費用。所以無論什麼藉口，都不該該影響咱們儘快放出新版本的程序。有些團隊喜歡「作精品」「憋大招」，實際上若是缺少用戶的參與，也不可能作出精品來。

2. 咱們歡迎需求的變化，即便是在開發後期

   需求變化多了，表示咱們的軟件有更多的市場需求。而咱們工做就是有針對性的去適應和控制變化。做爲開發人員，應該勇敢的去面對變化。由於只有變化才能提升咱們的競爭力，也能讓客戶變得強大，進而讓咱們得到更多的利潤。

3. 常常交付或者發佈能夠工做的軟件，從幾星期到幾個月，時間尺度越短越好
   之前咱們習慣於按月安排工做計劃，後來咱們發現，那些每週都更新的產品，更加容易抓住用戶。對於工做進度的把握，則是天天都發布是更有效的。日版本測試，周版本發佈，這是我認爲互聯網軟件應該追求，並且也應該能達到的目標。更頻繁的發佈軟件，可以更快速的佔領互聯網市場，也能讓產品更快的接受市場的檢驗，對於產品設計和市場運營來講，都能爭取寶貴的時間。人生苦短，咱們應該儘快把全部的工做成果，都儘快的投放到市場上。

4. 業務人員和開發者應該在整個項目過程當中必須在一塊兒工做

   需求的溝通始終貫穿整個工做歷程，若是開發人員找不到需求的表明，他們每每就會按照本身的理解去假設需求。而這些假設一旦有誤差，就表明着程序須要修改，甚至重寫。然而，若是這個問題在落筆之初，扭過頭問相關人員一聲，結果可能就徹底不一樣。遊戲開發中有一句話叫作：「策劃陪技術加班」。意思就是這個原則的自我說明，全部的遊戲策劃，在工做中都發現，只有「在一塊兒」，才能讓產品作的快，作的好。這對已經支付費用的客戶來講，彷佛是額外的成本，可是軟件開發就是這樣一個事情：用戶必需要參與開發，才能獲得真正有用的軟件。咱們必須認可軟件開發的風險性，也必須接受這種必要的成本，不然咱們只是在虛擲金錢和光陰。

5. 給開發者提供適宜的環境，知足他們的須要，讓他們鬥志高昂，並相信他們可以完成任務

   學習軟件開發自己就是一項很是艱苦的活動，而程序員們基本上是靠自學來完成。不知道你們注意到沒有，有不少軟件開發者都是在黑網吧裏工做工做的。對此，有些老闆認爲他們多是一羣貪圖享受，隨時準備磨洋工的小混混。無論是在網吧裏當小混混也好，仍是在坐在明亮辦公室裏的程序員也罷，程序員自己就表明着一種自律的能力。若是，你瞭解軟件開發這項行業，天然就不會有這樣歧視的想法。
   寬敞、明亮、安靜的空間，實際上是和全部腦力工做者同樣的需求而已。高昂的情緒，更是能讓腦力活動的速度加倍。每一個軟件開發者，實際上都指望本身的做品能變得有價值，並且他們本身也但願能儘快完成，前提是本身的生理和心理都能承擔工做的勞累。由於開發工做是他們的價值所在，若是作的更好更快，是開發者自己就在追求的目標。然而由於咱們對軟件開發的無知，讓咱們在管理軟件開發的時候，經常提出一些不合理的評價和預估，這會讓他們放棄對工做效率的追求，這對於投資者和客戶來講，都是一個雙輸的結果。

6. 小組中最有效率的信息傳達方式是面對面的交談

   面對面的交談，能力利用雙方交談期間的100%時間和精力。無論是別的任何方式，都難以達到這個效果。並且面對面，還能夠用畫圖、共同操做等方式來輔助溝通。若是溝通是以QQ、郵箱、電話等溝通方式，那麼溝通效果未必就如人意。另外一方面，面對面表明了重視和尊重，每一個人都會對重視本身的人所提出的意見額外關注，這也提升了溝通內容的準確性。

7. 「能夠工做的軟件」是進度的主要度量標準

   你能夠號稱完成了項目的50%，可是你沒法預料在你認爲你完成了90%的時候，會碰到一個難纏的BUG，或者接到一個「變態」的新需求，從而讓你的項目要多花一倍的時間去作。所以你說的「50%」或者「90%」都是毫無心義的，這些數字既沒法表明工做消耗的時間比例，也沒法表明軟件代碼的數量比率。若是軟件還沒能運行，就是進度還沒真正走到那一步，別的預估基本都是瞎扯。爲了能更準確的評估進度，就必定要能儘快，儘可能小步伐的發佈新版本軟件。我再次提到每日發版，用這個來代替該死的每日工做報告吧！

8. 提倡可持續開發。出資人、開發人員和用戶應該老是維持不變的節奏

   軟件出自咱們人類的大腦，他是一種和人們共生的奇特事物，咱們應該去持續的「培養」他。不要指望某個想法能放之四海而共通，也不要指望什麼手段在任什麼時候候都有用，因此軟件也應該「與時俱進」，不斷變化，不斷開發的軟件，才能不斷的知足需求。若是軟件不是這種事物，微軟、IBM、蘋果公司十年前就應該關門大吉了。

9. 對卓越技術與良好設計的不斷追求將有助於提升敏捷性

   應對變化是須要成本的，最蠢笨的方法就是不斷從新作。大部分的加班實際上都是在從新作一些事情。而卓越的技術讓咱們能更快速的去開發，所以無論是開發新功能，仍是重寫舊模塊，都能縮短期，從而下降變化的成本。卓越的技術自己還帶來了硬件性能的好處，避免咱們爲了提升軟件的性能而耗費更多的時間。自動化部署發佈、自動化測試、優秀的代碼編輯器，都能幫助咱們更快的完成工做。良好的設計則會幫咱們減小須要重作的工做，高聚合低耦合的設計，能讓咱們在變化時只修改真正變化的部分，而不是被迫從新作不少別的工做。
   咱們不該該去奢望本身像先知同樣，在每一個功能設計的時候受到天啓，一會兒就想到全部可能的變化。可是咱們能精心設計咱們的系統，讓咱們在須要變動的時候，減小各類傷筋動骨的大修大改。咱們的經驗，能幫咱們一步步積累更多的關於良好設計的知識。實際上，若是沒有技術和設計水平的提升，單靠空口喊「擁抱變化」，是不會真正提升工做效率的。這也是大量公司老闆的誤解，認爲「敏捷」方法自己就是一種「技術」，只要掌握就能增長開發速度，然而「敏捷」更多的是一種軟件開發的「世界觀」，而比較少是「方法論」，仍是須要咱們踏實的去提升技術和設計水平，才能讓「敏捷」的世界觀發揮出真正的價值來。

10. 簡單——儘量減小工做量的藝術相當重要

    簡單就是美，少就是多。這些話對於軟件開發來講，確是金玉良言。簡單的設計容易理解，方便修改。簡單的代碼BUG少。程序的功能越少，適用面就越廣。模塊的功能越單一，能重用他的地方就越多。然而如何讓簡單而不是簡陋，須要的是精煉的思想，須要開發人員去總結和概括，去把握每一個需求的核心和本質。減小工做量自己，也是一項很是重要的腦力工做。去蕪存菁，辨僞求真，這種工做確實難以單憑流程和工具就能完成。而這些能力，正是軟件設計的精華所在，稱之爲藝術一點也不爲過。咱們應該去追求這種創造性能力，而不是去追求機械性的流水線、自動化工廠方式的開發能力。

11. 最好的架構、需求和設計都源自自我組織的團隊

    自我組織的團隊，指那些對項目充滿熱情，願意主動承擔責任，互相信任的團隊。這種團隊的氣氛是積極熱情的，他們視項目爲體現價值的途徑，而不是換取工資的手段。只有這種團隊，纔會努力去想辦法提升工做效率，而不是老是計算投入產出，時刻但願多從訂單、合同裏面多掏出來點錢。培養和打造這樣的團隊，是管理者最重要的工做，也是管理者最有價值的投資。軟件沒法自動從機器上流淌出來，投資在人身上，就如同投資購買先進的生產線同樣重要。

12. 每隔必定時間，團隊都要總結如何提升效率，而後相應地調整本身的行爲

    敏捷的價值觀，是不斷自我提升效率，不斷進化本身的方法，這本質上就是所謂學習型團隊的價值觀。其實，重視工做效率和重視產品質量同樣，這樣才能讓團隊擁有不斷應對變化的能力。

    孤芳自賞抱殘守缺在技術人員中並很多見，願意學習新技術，願意總結問題，不斷改變本身，才能適應不斷的需求變動。這條是「敏捷」當中少有的「方法論」，雖然沒有說每隔多久就要總結，也沒有要總結什麼，可是很明確的就是，要經過開發實踐來總結經驗，以提高工做效率。這和某些公司的「大牛」迷信論是相反的。有些老闆認爲程序員自己就分大牛和菜鳥，必定要大牛才能作出好東西。實際上每一個團隊，每一個程序員，都能經過實踐積累經驗，只要他們願意總結，願意去改變，就算是菜鳥也能作的很好。而某些大牛隻作本身拿手的，反而能提供的價值比較少，由於他的那些拿手菜，不必定是時時都有須要的。

    敏捷方法有時候被誤認爲是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。

不少老闆，嘴裏說着：大家敏捷一點嘛。意思只是「大家快一點作嘛」。潛意識裏面還有讓你們拋棄那些保證質量或者管理的工做，也不要作什麼設計，只求快點交付軟件就好了。而真正的敏捷，是一種貫穿始終的軟件開發方法，是一種價值觀和軟件開發文化。這須要咱們從不少地方去修正原有的開發思路，從而使軟件開發效率獲得長期提升，下降失敗風險，而非一種短時間能夠用來衝刺的手段。

二.敏捷是一種溝通方式

關於「敏捷開發」的書籍也是汗牛充棟，經典論文也不少。敏捷提倡的工做方式有不少是關於「觀點」和「風格」的。其最核心的目標是把開發方式從經典的瀑布式改變成以「迭代」爲核心的方式。其實並無說屢次迭代的開發進度就必定比瀑布方式要快，這裏是不少人望文生義的誤解。

以迭代爲核心的開發方式，最大的好處是能儘快的把功能體如今可用的產品上，而不斷更新的產品，能讓非技術人員——用戶更多的參與到開發過程當中來，而不僅是在需求階段，對着一堆需求或者調查文檔來填文字。由於人的認識規律都是須要經過實踐，若是有可用的產品，無論是多簡陋，能讓用戶的理解的，都遠比開發人員的任何描述都要準確。經過這種方式，開發方向能夠不斷根據用戶的意見來修正，避免作那些不能知足客戶需求的開發。
敏捷，提倡的就是額昂開發者和用戶用產品來溝通。下面列出一些敏捷方法的具體方法論：

1.水晶方法 Crystal

水晶方法認爲不一樣類型的項目須要不一樣的方法。決定用什麼軟件開發方法，與兩個因素有關：項目參與人數和出錯後果。實際上，大部分互聯網項目都適用於Crystal Clear方法。水晶方法針對不一樣類型的項目，提倡不一樣的方法論，是一種很求實的態度。

2.特性驅動開發 FDD/Feature Driven Development

FDD是一個模型驅動( model-driven)、短時間迭代(short-iteration)的過程。 FDD的起點是建立一個全局的模型輪廓，不要求很精確，得出大概模樣就能夠，而後使用小於兩週的時間在哦爲一個開發迭代，經過一系列的迭代， 逐漸豐富模型功能內容。FDD能讓團隊很清楚如今的完成度是多少，而不是讓開發人員感受沒有一個總體目標。

3.Scrum

Scrum是一種迭代式增量軟件開發過程，一般用於敏捷軟件開發。Scrum在英語的意思是橄欖球裏的爭球。Scrum很務實的定義了團隊中能的主要角色：
敏捷教練或項目經理：確保團隊合理運做Scrum，並幫助團隊移除實施中的障礙；
產品負責人：在遊戲項目中就是主策劃，肯定產品的方向和願景，定義產品發佈的內容、優先級及交付時間；
開發團隊：一個跨職能的小團隊，應該包括美術、運維、測試等全部須要的專業人員。
實施過程是把項目分爲一次次的「衝刺」階段，每次「衝刺」從一週到一個月。工做目標就是產品訂單(product backlog)。每張backlog在全體討論並承諾接受以後，將嚴格執行不得更改。Scrum最大的好處之一是它很是容易學習，並且啓動Scrum應用並不須要太多的投入。

4.極限編程 XP Extreme Programming

XP方法是全部敏捷方法中，規則最清晰和最完整的。包括：

• 團隊協做(Whole Team)
• 規劃策略(The Planning Game)；
• 結對編程(Pair programming)
• 測試驅動開發(Testing-Driven Development)
• 重構(Refractoring)
• 簡單設計(Simple Design)
• 代碼集體全部權(Collective Code Ownership)
• 持續集成(Continuous Integration)
• 客戶測試(Customer Tests)
• 小型發佈（Small Release）
• 每週40小時工做制（40-hour Week）
• 編碼規範（Code Standards）
• 系統隱喻（System Metaphor）

這裏面有不少規則，通常的團隊彷佛比較難以達到，好比結對編程和測試驅動。除告終對編程和測試驅動外，其餘的一些規則則是比較容易作到。XP方法是能提供給咱們清晰的行動指南。

有人把XP方法中的「測試驅動」當作是核心規則，這個確實是很是正確的。由於若是你要造一輛未經嚴格設計的車子，最好的保證他質量的方法就是多跑跑。幸虧軟件是能夠無限自動重複測試的產品，所以利用計算機的能力去模擬現實，從而代替人類不完整的思惟，是一種方法上的進步。事實上就算你不用XP方法，你也應該儘可能的去靠近「測試驅動」的方法去開發系統。

三.敏捷是瓷器活，你得有金剛鑽

既然敏捷的方式有不少好處，爲何不少團隊都以爲實際上用處不大呢？由於敏捷自己不是萬能的。敏捷方法適用於需求萌動而且快速改變的狀況，如系統有比較高的關鍵性、可靠性、安全性等方面的要求，則可能不徹底適合敏捷的開發模式；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。

最重要的因素恐怕是項目的規模。規模增加，面對面的溝通就越發困難，所以敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。大規模的敏捷軟件開發尚處於積極研究的領域。

敏捷適合於不少人對產品提出需求修正的模式，特別是開發人員和需求人員有較大的知識背景差距。而有一些「純技術類需求」的項目，開發人員自己就是需求人員，再去求敏捷的各類確認活動，就顯得畫蛇添足。

敏捷講究開放的團隊氣氛，是主動負起責任的作法。而咱們不少的團隊自己分工涇渭分明：服務端、客戶端、DBA、運維等等，而這種分工還不只僅是由於傳統或者文化，而是團隊成員自己就不具有那麼多種不一樣的技能。

一樣組織文化必須支持談判，由於敏捷意味着你們都認可，項目的開發是在不斷的對全部人的思惟的整理。因此項目中沒有誰是絕對正確或者權威，必需要互相妥協，還有對妥協結果然心實意的接受。

在團隊中人員的彼此信任也至關重要。敏捷的各項方法並未受到嚴格的檢查，而是強調發動本身的熱情去作事。若是成員不信任彼此，那麼就會出現大量的溝通問題，反而會影響效率的提升。因此人員越少，越精幹。

敏捷方法也要求老闆和投資人接受開發團隊的決定。由於需求是在開發團隊中產生，若是缺少了團隊的密切溝通，而是接受老闆下達的指令，那麼強加在系統中的功能可能就沒人作得好。這類指令越多，就等於越縮減敏捷方法在需求方面能提供的好處。只有團隊有權決定本身作什麼，以及如何作，才能激發團隊的熱情。

敏捷對於環境設施的要求是能知足成員間快速溝通。一些方便辦公溝通的地方，並非咱們如今常見的地方。高聳的格子間隔開每一個人，而稀少的會議室又讓你們難以找到地方溝通。雖然每一個人都有個格子，可是噪音和別人的干擾卻能夠輕易穿透，想到某人的格子裏開會也是不太受歡迎的事情。

筆者曾參加過無數次 的「每日例會」，這個例會的做用除了讓早上你們能準時上班外，真正起到「溝通」的做用很是小。並且時間每每也沒控制好，特別是有領導參與的時候。你們輪流彙報的方式，讓當時不用發言的人都在走神，分工已經分好，也無需去討論別人的進度如何。反而當實行了每日版本發佈後，你們會在早上的時候，一塊兒碰一下昨天發現的問題，如何分工去解決。因此往往日例會的議題應該是每日版本的需求問題，而不是所謂的進度。

可是，要作到每日都有版本發佈，也不是一個簡單的事情。首先團隊要能熟練的使用版本管理軟件的分支功能，好比SVN。其次團隊還要搭建完整的自動構建和自動部署的測試環境。最後還須要有相似JIRA的問題跟蹤系統。

總結來講，一個團隊要真正能啓動「敏捷」，在團隊氣氛上必須是開放和主動的，而不能讓團隊成員得過且過。在技能上團隊成員不能只固守本身的一攤子技術，必需要願意多接觸跨界技術。在開發流程和開發工具上要比較成熟，能作到比較高效的構建、部署、測試。「持續集成」就是專門講這一個環節的。而最重要的，是團隊成員必須明白敏捷的目標——不是提升開發速度，而是避免無效的開發。

我認爲最有效提高工做效率的敏捷方法包括：

• 和需求人員一塊兒辦公，最好能有一間獨立的辦公室，讓開發人員和需求人員坐到一塊兒。
• 測試驅動開發，寫代碼前寫單元測試。
• 重構，安排專門的版本週期進行重構，一般應該在每一個重要版本發佈後，通過總結和討論，安排重構的恩物。
• 代碼審查，在代碼提交前。對比結對編程，這點容易實現的多。
• 持續集成，必定要有自動化編譯、構建、發佈、部署的工具。
• 每日發佈，項目經理以此做爲進度依據。
• 實施編碼規範，用培訓做爲鋪墊，以代碼審查做爲實施措施。
• 每週工做40小時，長期來看，加班自己是下降工做效率的事情，敏捷是一個針對長期目標的方法，只要加班，就非敏捷。

小TIPS：從自動構建和自動發佈開始，作好每日版本能測試，比較容易開始「敏捷」。