CODING 敏捷實戰系列課第五講：敏捷中國史
敏捷軟體開發方法自 2001 年傳入中國以來，歷經十多年的發展變遷，目前已經成為中國 IT 企業主流的研發管理方法。敏捷方法的傳播和發展歷程，是中國 IT 行業發展的剪影。CODING 特邀敏捷顧問、MBA，CSD 認證講師、XP工程派敏捷領熊節老師將在《敏捷中國史》課程中通過大量史實材料，用技術史的研究方法縱覽敏捷在中國的傳播、發展、演化，從一個側面呈現 IT 行業、業內領先企業和從業者的成長曆程，為後來者留下理解這段歷史的脈絡。
大家好，今天我來為各位同學梳理一下敏捷進入中國的過程和發展。首先來看一下招商銀行的一項數據。過去講科技創新是一個很神秘的事情，不知道應該怎樣去創新從而得到一個好項目，這個數據講的就是可以通過大量的失敗、大量的試錯，從中發現有效的項目。我覺得招商銀行是這麼多年來在這個行業里對敏捷理解最深刻的一家企業，它真正做到了用敏捷的方式去改變整個經營和創新的思路。在 2018 年至 19 年這個節點上，一家中國的大型銀行能用這樣一個截然不同的思路去看問題，這是一個非常了不起的里程碑，標誌著敏捷在中國取得了很大的成績。那麼站在這個節點我們回顧一下敏捷到底是怎樣進入中國的。
最初敏捷在 2000 年左右進入中國時，就像播種一樣，一些技術雜誌把敏捷最初的思想播種到了行業里。中國的正式出版物首次刊載與敏捷軟體開發相關的內容，是《程式設計師》雜誌 2001 年 12 月刊，當時我在程式設計師雜誌擔任技術編輯，剛好做了「程式碼重構」的技術專題，可以說是無心插柳，當時從我個人的角度來說只是覺得敏捷這個內容非常有意義，並沒有意識到之後會成為這麼宏大的一個潮流。之後在 2002 年，我又做了「極限編程」技術專題，不知不覺跟敏捷結下了十幾年的緣分。
中國的軟體行業其實不是自然生長出來的，並不是說經濟發展到一定程度就一定會有高科技行業自然發展，實際上中國的軟體 IT 行業是由政治、政策催生的。2000 年以後，全國軟體產業市場規模超過 1.3 萬億人民幣，連續十年的年均複合增長率都達到了 40% 以上，這是一個非常可觀的數據，而源頭就是 2000 年 6 月國務院頒發的《鼓勵軟體產業和積體電路產業發展的若干政策》（國發 18 號文），這項政策里有非常多具體的鼓勵、補貼內容，整個扶持了中國軟體行業大發展。但是在這麼大的扶持之下，整個行業並沒有做好準備，沒有足夠的能力去消化如此大的需求，從而催生出了一系列問題，下圖就是 2000 年時一位廣東的官員調研得到的情況。當時廣東省的政府資訊化項目中已經出現了這些軟體開發過程中常見的問題，這反映出當時整個行業的能力，包括個人和企業的能力都是不足的。當時專家認為出現這些問題是因為社會化大生產尚未形成，當然這種觀念本身存在一定的問題，因為這是從工業製造業的角度引申出來的。
說到行業整體能力不足，也就是說「應該具備哪些能力」，2000 年左右 CMM（能力成熟度模型）引進中國時對這個問題給出了一個比較好的答案，CMM 二級-可重複級就很好的定義了一個軟體開發團隊應該具備的基本能力：需求管理、項目管理、配置管理、品質保障。需求管理就是需要弄明白要做什麼；項目管理控制的是以適當的進度完成項目；配置管理解決的是軟體如何一步步達到最終狀態的問題；品質保障解決的是軟體能否符合要求的問題。這幾項就是軟體開發中最核心、最基本的能力。
CMM 雖然提出了整個行業「應該具備哪些能力」，卻一直沒有解決如何具備這些能力的問題。當時中國一線的工作者迫切想解決如何用有效的方式來工作的問題，所以開始在網路上搜索國外同行們的經驗。林星是中國比較早關注敏捷的同行，他 2001 年的文章《需求分析-軟體和需求的實踐》就是關於我們現在說的「用戶故事」，也是從極限編程中抽取出來的。石一楹也是中國最早引進重構相關內容的同行，當時他在 IBM 網站上寫了一系列品質非常高的文章，我本人對重構的了解就是從他這裡得來的，因為受到他的影響，我在《程式設計師》雜誌上做了相關介紹並在之後翻譯了馬丁·福勒的《重構》。《解析極限編程——擁抱變化》這本書是在 02 年引進的，北京當時有一個軟體工程組織叫 PKSpin，唐東銘是這個小組的成員，他給人民郵電出版社推薦了這本書並進行了翻譯。之後 03 年引進了《敏捷軟體開發》這本書，並由中興的工程師鄧輝進行了翻譯，同年 8 月我翻譯的《重構》也引進了中國，那時我們認為關於敏捷的理論體系已經基本搭建完成，接下來就是中國行業去接受、學習的過程，因為之前做敏捷都處於一個非常混沌的狀態，採用了敏捷實踐之後軟體開發過程中應該怎麼做、怎樣做出一個好的軟體就非常清晰了，所以大家都覺得前景十分樂觀，應該在三五年左右能全面實現敏捷，能力會有一個明顯的提升，整個行業會有很好的成長。當然事後證明當時我們過於樂觀，敏捷並沒有那麼快被廣泛接納。
現在回頭看看敏捷是如何嘗試解決 CMM 提出的軟體開發四項能力的。敏捷歸根結底是一個關於怎樣管理需求的問題，是如何以一種迭代的、漸進的方式去交付軟體的問題，它與瀑布式軟體開發最根本的區別在於，當你認為需要採用敏捷開發時，所交付的軟體不是六個月才交付一次，而是以更小的粒度去交付。敏捷的一系列內容都是從需求管理開始，它改變了我們看待需求的方式，需求不再是一個大頭，而是由很多小塊組成。接下來就是項目管理，當我們希望需求以一種小顆粒的形式去逐漸交付時，接下來受影響的就是如何管理項目的問題，項目的整個生命周期都會改變，它不再像以前一樣兩個月分析、兩個月設計、兩個月編碼，而是會完全變成快速的短迭代，不斷生產出可用的軟體，所以我們看待整個項目生命周期的方式會發生變化，會以迭代的周期來管理項目。接下來受衝擊的就是配置管理的方式，配置管理講的是軟體如何被修改的問題：誰在什麼時候以什麼方式修改軟體、如何提交修改、如何把修改分享給整個團隊、如何把源程式碼變成可用的軟體等等。因為我們的目的是要快速、頻繁的交付可用的軟體，那麼配置管理一定會發生根本性的變化，會變成一種持續集成的方式，即每天、每個小時都在不斷地集成可用的軟體。於是緊接著會影響品質保證的方式，因為團隊在不斷的生產軟體並且希望軟體是隨時可用的，所以不可能像以前一樣整個項目做幾次集中的人肉測試，必須加入大量自動化測試，確保每天、每個小時測試都在運行，確保軟體始終處於一個良好健康的狀態。所以沒有大量的、可靠的、快速的測試用例，就一定是偽敏捷，這是一個非常容易判斷的標準。
其實中國軟體業當時並沒有做好準備去迎接敏捷。一方面，在「18 號文」的政策引導下，政企資訊化佔據了很大市場比重，而這類項目預算周期長、用戶話語權低，快速迭代式交付既不可能、也不必要。另一方面，被政府補貼快速加溫的 CMM 認證市場亂象叢生，諮詢、評估、政策補貼形成完整利益輸送鏈，對於業界軟體工程能力的提升效果並不明顯。2006 年馬丁·福勒在中國軟博會做了一個演講，說到給某投資銀行做的項目，通過迭代式開發，兩個月時已經有部分功能可以讓用戶使用，而且為客戶帶來了真正的經濟效益，整個項目所有的投資在這一部分功能上線後的幾個星期就收回來了。這個觀念在當時的中國軟體行業里是非常陌生的，一些學院派的軟體工程專家認為中國軟體業的現狀大概落後於美國 20 年，這個觀點我認同，但是他們認為補齊差距的辦法是軟體學院的教育應該更正規化，學習正統的軟體工程，所謂學習「正楷」，也就是研究 CMM。這個觀念事後證明是一個完全錯誤的選擇。同時一些民間的草根社區也在積極活動推行敏捷，雖然不受主流待見。06 年左右草根社區開始逐漸彙集力量，連續開展了兩年「敏捷中國」開發者大會並建立了線上社區。
直到 07、08 年環境逐漸有了一些轉變。第一個方面，我個人認為中國的互聯網行業大發展，與美國一些網路企業被排除出中國是有很大關係的，這裡不談爭議，就當時的情況來說，中國的互聯網企業比如 BAT，都還處於比較早期的階段，如果這些巨頭沒有被排除出去，中國很可能不會有那麼大的市場空間，所以至少從中國互聯網行業的發展來說是創造了一個機遇。另一方面跟移動互聯網的高速發展也密切相關，華為作為一家設備製造商在當時也開始感受到來自同行，比如諾基亞的壓力，發覺以流程為中心很難應對不以公司為導向的市場環境，於是在 04 年開始研究敏捷，並在 2007 年下半年全面展開研究，08 年初開始全面進入試點階段。而諾基亞當時在杭州的研發中心開展了一個試點項目，就是引入了 Scrum，嘗試敏捷的做法，這個試點項目培養出了許多後來對中國敏捷社區產生巨大影響的人物，比如呂毅、徐毅、申健等等。所以之前提到的中國的極限編程這一分支，很大程度上是從民間生長起來的；而 Scrum 這一分支，基本上是從諾基亞這一項目傳承下來的。還有一方面就是通訊企業和互聯網企業的大發展，開始有敏捷的訴求。06 年左右騰訊的研發規模開始膨脹，開發模式急需規範和標準化，在 IPD（集成產品開發）-CMM 和敏捷間搖擺不定，後來騰訊的研發管理部開始與 ThoughtWorks 公司接觸，在參加了一次 3 天的敏捷入門培訓後，決定沿著敏捷這條路向前走。歷史充滿了偶然性，在一些重要的節點上，其實並不清楚關鍵的決策者到底是受到了什麼影響，最後把騰訊帶到了敏捷的方向上。而阿里也緊跟其後，大概在 08、09 年左右開始試點敏捷，並且證明了技術的根基對於敏捷的實施非常重要。我調研過釘釘這個團隊在當時是如何實施敏捷的，他們團隊當時取得了比較好的效果，一個很重要的原因就是自行開發自動化測試，這就又回到前面講的觀點，判斷一個團隊到底是不是有效的敏捷，就是看有沒有大量的、可靠的、快速的自動化測試。釘釘團隊成功實施敏捷很大程度上得益於極強的技術能力，我認為這種能力在行業里是一個重要分水嶺，有很多企業想學習敏捷，但最後都止步於沒有過硬的技術能力，想要進行自動化測試、持續集成、重構都沒有能力。一些能力不足的項目組長或者 QA（Quality Assurance）不知道如何操作，這時出現的 Scrum 聯盟提供了一個學習考證機會，通過學習 3355 等課程獲得 Scrum Master 認證，這些內容給他們的焦慮找到了一個非常好的出口，但其實敏捷的真偽最終還是要歸結到基礎的技術能力上。
時間來到 2015 年前後，敏捷在中國開始進入收穫的季節。2016 年度中國軟體開發者白皮書中統計有 64% 的團隊使用了敏捷管理工具，當然這裡不是指已經有 64% 的團隊開始實踐敏捷，只是可以理解為有六成的團隊認為宣稱自己使用了敏捷管理工具是一件有面子的事情。阿里雲棲社區在 2017 年發布的數據中，45.6% 的團隊在規模流程模式上採用了 Scrum 敏捷開發，同理也可以理解為有更多人認為 Scrum 敏捷開發是好的。這種數據描述的是一種觀念，表達了當時的行業從業者怎樣看待這些理念，反應的是一種認可。
15 年之後在敏捷的基礎上又有了很多發展，當然國際和中國要分開來看。在美國、澳洲發展的脈絡是開始思考軟體架構怎樣可以更適合小團隊（微服務設計），怎樣讓軟體的生命周期更加完善（DevOps），怎樣將敏捷的快速回饋機制向上延伸到業務（精益、持續交付）等等。而在中國則出現了一些變體，因為中國行業不具備這些能力，在最開始沒有打好基礎，08、09 年一些企業實施的敏捷其實是在「補課」，雖然有一些成效但遠遠沒有到位，變成了中國特色敏捷。由於沒有到位，只好換個名目再立項，搖身一變成微服務，再過一年變成 DevOps，之後又叫精益，結果實際上每年做的都是同樣的事情，還在做最基本的用戶故事、持續集成、自動化測試等等內容。一個行業在剛開始發展時，因為規模還不大，全面提升行業能力比較容易，這樣也利於以後的發展，但是中國軟體業在剛開始起步的時候沒有做到這一點，規模卻越來越大，同行全憑本能在工作，沒有套路和方法，一些大型企業和項目全部陷在泥潭裡，人人都在加班又解決不了問題，那麼既然解決不了問題，就解決提問題的人，於是 Scrum Master 應運而生。正常邏輯應該是程式碼寫的不好就提升自身能力寫好程式碼，Scrum Master 就是引導團隊成員，給成員賦能，雖然能力依然沒有提升，不過至少起到了心理安慰的作用，在泥潭中也要和自己友好相處嘛。
雖然前面說的有點喪，但這麼多年來敏捷對中國的軟體行業也有很大的貢獻，比如對辦公環境就有明顯的影響。03 年左右我們的辦公環境其實是非常糟糕的，都是廉價的隔板和座椅以及很小的空間，而現在可以看到越來越多的企業採用了開放式的辦公環境，更加人性化，同事間會有更多的交流機會，這是正向的影響。
另一方面就要說到加班的問題。我採訪過很多人，大多都認為跟 18 年前相比現在加班更嚴重，雖然從數據上來看加班的小時數並不算多，但實際上壓力比以前更大。一個原因是有更多的通訊工具去控制大家的工作時間，比如說釘釘、騰訊會議、企業微信等；另一個原因我認為跟敏捷有很大關係，就是對任務更細的拆分、更細粒度的有效把控加大了勞動強度，這其實是一個不好的方向，違背了敏捷價值觀。
最後說點題外話，去年可口可樂有一個項目也想用敏捷這種迭代的、快速回饋的方式去研發新的飲料，所以敏捷以後一定會延展至其他行業領域，同時它的邊界也會越來越寬，內涵變得越來越稀薄，可能最後會模糊敏捷的定義，現在已經逐漸有這種趨勢，人人都在說敏捷。我依然堅定地認為狹義的敏捷軟體開發有明確的邊界，至少需要擁有大量的、可靠的、快速的自動化測試套件才是真的敏捷。
