引言

誰動了你的“敏捷”

你們的敏捷試點徹底失敗了，大家對敏捷的價值充滿了懷?疑。

你們熱火朝天地敏捷了半年，業務部門依然認為你們沒有敏?捷。

在你們公司，老板把敏捷當作一個讓員工加班的手?段。

多個敏捷小組互相依賴，互相指責，“內卷”嚴?重。

人越招越多，但效率卻越來越低，原來的密切協作氛圍再也找不到?了。

你們的每日站會沒有任何價值，大家每天都在行尸走?肉。

大家認為敏捷就是開會，浪費了大量的時?間。

計劃會開了半天，制訂了一份大家都不認可的計?劃。

每天忙于“救火”，在缺陷中找缺陷，每天都加班，大家疲憊不?堪。

你們的持續集成亮紅燈了，但好久沒人修復，也沒人關?心。

需求優先級不斷調整，相互沖突，每天一個說?法。

你們也在不斷地總結回顧，但是問題依然還有很?多。

你們搭建了工具鏈，強迫大家使用，但敏捷還是老樣?子。

你們花大價錢請了咨詢團隊，他們一走，你們立刻回到老?路。

……

對此，你是否也心有戚戚焉？

你抱怨！

你困惑！

你迷茫！

你失望！

誰動了你的“敏捷”？

也許你自己說不清，也許你更期待高人能指點迷津，或許我們可以先回顧一下敏捷的發展簡史，從敏捷先哲的探索之路中找到答?案。

尋找銀彈

1967年，Conway提出了康威定律（Conway’s Law），他認為“系統的架構受制于產生這些設計的組織的溝通結構”。反過來理解就是“如果系統架構不支持，你無法建立一個高效的組織”。后來這條定律成為劃分敏捷協同團隊及產品架構設計的重要理論依據。[1]

---

[1]摘自頭條號“振振有詞abc”的文章《通過一篇文章來了解“敏捷”的發展歷程》。

1970年，Winston Royce發表“Managing the Development of Large Software Systems”（管理大型軟件系統的開發）論文，第一次正式描述了瀑布模型。如圖0-1所示，瀑布模型將軟件開發的各項活動規定為按照固定順序連接的若干個階段，一級一級，自上而下，形如瀑布流水，因此得名瀑布。

圖0-1　瀑布模型

1974年，E. A. Edmods通過論文介紹了自適應性軟件開發（Adaptive Software Development，ASD），提倡擁抱變化，借助協作和學習來應對復雜系統的開?發。

1975年，Fred Brooks出版《人月神話》，提出軟件開發“沒有銀彈”（No Silver Bullet），與此相關的軟件危機問題激發起軟件行業從業者對輕量級方法的探索。他提出的“Brooks定律”，即“投入更多的人到一項延遲的工作上，可以導致該項工作更加延遲”，雖然沒有得到大多數人認同，但依然抑制不住大家向落后項目中增加人手的沖動。直到后來，動態系統開發方法（Dynamic System Development Method，DSDM）提出了著名的敏捷倒三角形模型，強調有限時間、有限資源情況下，只做有限需求，需要對需求進行優先級排序，方才有所緩?解。

1976年，Glenford Myers的著作Software Reliability（《軟件可靠性》）出版。這本書闡述了一條“公理”——“不應該由開發者來測試自己的代碼”，這意味著需要多個角色協作才能保證質量，這跟后期的“全面質量管理”運動不謀而?合。

1980年，由Harlan Mills主編的文集對增量開發進行了實質性討論。Dyer在文章中明確指出“軟件工程的原則是，每次迭代完成的功能要盡可能地與其他迭代解耦”。

1980年，源于豐田公司生產系統的“可視化控制”（visual control）概念是“信息輻射器”（information radiator）的最早概念，現在我們經常提及的“基于經驗的過程控制”的三大支柱——透明、檢視和調整，其實都跟可視化直接關?聯。

1984年，隨著對“瀑布”順序式開發模式的批判，作為替代物的“增量方法”變得越來越突出。一個很好的例子是《軟件工程中基于知識的溝通過程》中的一篇文章倡導使用增量開發，具體原因是“不存在完整和穩定的需求規格”。

1985年，Tom Gilb提出了首個有明確命名的、用于替代“瀑布”的增量開發方法——進化交付模型（Evolutionary Delivery Model），綽號是“進化”（Evo）。

1986年，Barry Boehm提出了“軟件開發和優化的螺旋模型”，提倡通過合適的方法（盡管展示的“典型”例子是基于原型，但不僅限于原型法）來識別和減少風?險。

1986年，竹內弘高和野中郁次郎在《哈佛商業評論》發表了他們的文章“The New New Product Development Game”（新新產品開發游戲）。這篇文章描述了一種類似橄欖球隊工作模式的方法，即“產品開發過程是在一個精心挑選的多職能團隊的持續互動中產生的，團隊成員從頭到尾都在一起工作”“這種團隊自我組織、自我管理，有能力決定如何開展工作，并獲得了根據自己決定做事的授權”。據說這篇文章是Scrum框架的靈感來?源。

1987年，Ivar Jacobson成立Objective Systems公司。他吸納了增量迭代的思想，開發出Objectory過程，并且把過程當軟件賣，單份售價達到2.5萬美元[2]。

1988年，“時間盒”（timebox）被描述為Scott Schultz的“快速迭代開發成型”法的基石，這種方法應用于杜邦公司的副業——信息工程協會。現在筆者在講述Scrum框架的起源時會經常提到時間盒。[3]

---

[2]1美元合7.24元人民幣。

[3]參考Cyh的博客文章《敏捷十年簡史回顧——影響敏捷開發歷程的27件事》。

百家爭鳴

1991年，James Martin在其著作《快速應用開發》中描述的RAD（Rapid Application Development，快速應用開發）方法或許是第一種把時間盒和迭代（較寬松意義上的“整個軟件開發過程的一次重復”）緊密結合在一起的方法，第一次對時間盒進行了細節描?述。

1992年，Larry Constantine在一次拜訪Whitesmiths公司的過程中創造和報道了“活力二人組”（Dynamic Duo）這個術語，即“每一臺終端前有兩位程序員。當然，實際上只能由一位程序員操作鍵盤來編輯代碼，但他們兩個是并肩作戰的”。這其實是關于結對編程最早的記錄，現在我們經常用“你開車，我導航”來比喻，但是其中的核心是“并肩作戰”。

1994年，在Rational公司工作的Rumbaugh和Booch開始合并OMT和Booch方法。隨后，Jacobson帶著他的OOSE方法學也加入了Rational公司，一同參與這項工作。他們3個人被稱為“三友”（three amigo），一起開發UML，最終提出了“Rational Unified Process”（RUP，Rational統一過程）及4+1視圖模型。RUP的中心思想是用例驅動、架構為中心、迭代和增量。RUP過程如圖0-2所示，共分成4個階段—初始（Inception）、細化（Elaboration）、構造（Construction）和交付（Transition）。這項工作對整個業界造成了很大的沖擊，因為在此之前，各種方法學的擁護者都覺得沒有必要放棄自己已經采用的方法，而接受統一的流程，但RUP在國內外還是影響了很大一批人。這也是吸引我后來加入IBM Rational團隊的關鍵點。畢竟在軟件工程領域，雖然RUP最終敗給了敏捷，但IBM Rational團隊在方法論及工具方面的沉淀，還是獨領風騷很多年，因此，RUP成為軟件開發團隊中流傳最廣的軟件過程模型，也成為團隊學習軟件工程和實施過程改進的重要資?料。

圖0-2　RUP過程

1995年，Alistair Cockburn發表文章“Growth of Human Factors in Application Development”（應用開發中人類因素的增長），提出迭代方法會逐漸被接受的主要原因之一是軟件開發的瓶頸正在轉向（個人和組織）學習，并且人類學習本質上是一個迭代和試錯的過?程。

1995年，在OOPSLA’95會議上，Sutherland和Schwaber聯合發表了一篇論文。該論文系統地介紹了Scrum方法，這標志了Scrum的誕生。Scrum框架目前能夠成為團隊級敏捷的主流框架，跟它對各種關鍵實踐的兼收并蓄有著極大關?系。

1996年，Kent Beck為了挽救Chrysler Comprehensive Compensation（簡稱C3）項目而創建了XP（eXtreme Programming，極限編程）過程。雖然Chrysler最終取消了該項目，但是隨著Ron Jeffries和Ward Cunningham等人參與到XP的工作中，從此奠定了XP的歷史地?位。

1997年，Ken Schwaber描述了“每日Scrum站會”（Daily Scrum）〔這在其早期的著作中并未出現，如1995年的文章“SCRUM Development Process”（Scrum開發過程），這項活動后來被Mike Beedle重新整理到第一本Scrum圖書中，成為現在廣為流傳的實?踐。〕

1997年，Alistair Cockburn受IBM公司委托，開展了一個關于團隊規模的研究項目，正式提出了Crystal（水晶）方法。Alistair建立了一個二維坐標系，其中，垂直因素是舒適度（C）、可自由支配資金（D）、基本資金（E）和項目壽命（L），水平因素是“團隊規模”，劃分出不同顏色的水晶，用于代表不同的團隊規模。對水晶方法的細分能夠幫助團隊更加高效地完成軟件開發與項目管理，其中透明水晶（Crystal Clear）是敏捷小團隊的適宜模?式。

1998年，Jeff De Luca和Peter Code正式提出FDD（Feature Driven Development，特性驅動開發）方法。FDD方法非常適用于團隊成員水平參差不齊的情況，因為最有經驗的可以做主要編程人員。不過，如果一個小團隊中大家的水平都差不多，可能會出現資源浪費的情?況。

1998年，持續集成和“每日站立”（daily stand-up）被列入極限編程的核心實?踐。

1999年，Martin Fowler的著作Refactoring: Improving the Design of Existing Code（《重構：改善既有代碼的設計》）[4]出版，對敏捷開發中的“重構”實踐首次進行系統化闡?述。

---

[4]該書由人民郵電出版社引進出版，ISBN：978-7-115-36909-3。

1999年，Kent Beck在其著作Extreme Programming Explained（《解析極限編程》）中創造了術語“大可視化圖表”（Big Visible Chart），盡管后來他把此歸結于Martin Fowler。

2000年，Ken Schwaber在美國富達投資集團工作時，試圖為Scrum團隊提供一個簡單的工具包，于是發明了“燃盡圖”（burndown chart），并在其網站上正式描?述相關概念。

2000年，術語“團隊速率”（velocity）被添加到極限編程，用于替代先前被認為過于復雜的概念——“負載系數”（load factor）。

敏捷誕生

2000年春，Kent Beck組織了一次會議，地點是美國俄勒岡州的羅格里夫酒店，參會者包括極限編程的支持者和一些“圈外人”，正是這次會議促進了后來在雪鳥滑雪場舉辦的聚會。在羅格里夫酒店的會議上，參會者宣稱對一系列“輕量”方法論的支持，但沒有發表正式聲明。2000年期間一系列論文都被歸類到“輕”或“輕量”流程，其中很多都提到“輕量級方法論，如極限編程、適應性軟件開發、水晶系列和Scrum”。大家交流后發現，沒人真正喜歡“輕”這個名號，但這似乎是當時約定俗成的稱?呼。

2000年9月，來自芝加哥Object Mentor公司的Bob大叔用一封電子郵件吹響了下次會議的集合哨。“我想召集一個為期兩天的小型會議，時間是2001年1月或2月，地點在芝加哥，目的是讓所有輕量級方法論的領袖匯聚一堂。你們都被邀請了。如果你們覺得還有誰該來，請告訴我。”Bob建立了一個Wiki網站，大家開始在上面熱烈討論。很快，Alistair Cockburn通過一封書信加入了討論，他表達了對“輕”這種提法的不滿：“我不介意用‘輕’來描述方法論的輕重程度，但我并不愿意因參加一個輕量級方法學的會議而被看作輕量級的。這聽起來有點像一群干瘦、低能且無足輕重的人在試圖回憶起某個特定的日子。”關于會議地點的爭論最為激烈。芝加哥讓人不爽，既冷又無趣；猶他州的雪鳥，雖然也冷，但至少對那些想滑雪的人來說還挺有意思，像Martin Fowler，他在第一天滑雪時就摔了個腳朝天；加勒比的安圭拉島，暖和又好玩，但路途太遠。最后，還是可以滑雪的雪鳥勝出，不過有些人（例如Ron Jeffries）還是希望下次能去個暖和點的地?方。

2001年2月11日至13日，在美國猶他州瓦薩奇山雪鳥滑雪勝地，17位從事軟件開發或者幫助他人從事軟件開發的人相聚一堂，交談、滑雪、休閑，當然還有聚餐。他們試圖找到共識，最終的成果就是Manifesto for Agile Software Development（《敏捷軟件開發宣言》）。參會者包括來自極限編程、Scrum、DSDM、自適應軟件開發、水晶系列、特性驅動開發、實效編程的代表們，還包括一些希望找到文檔驅動、重型軟件開發過程的替代品的推動者。如圖0-3所示，由全體參會者簽署的《敏捷軟件開發宣言》成為重要標志，因為這么大一幫人能聚到一起實在不容易。只有英國人Martin Fowler表達了對“敏捷”這個詞的擔心，他認為多數美國人都不知道“敏捷”這個詞如何發音。Alistair Cockburn和很多參會者一樣，最初有很大的擔憂。“我個人沒有期望本次敏捷達人們的聚會能夠達成任何實質性共識。”會后，他再次分享了自己的感受。“對我來說，很開心‘宣言’能夠最終定稿。而讓我感到驚訝的是其他人也同樣開心，因此我們的確達成了某種實質性共識。”從此，敏捷方法正式誕生。[5]

---

[5]摘自Scrum中文網的文章《敏捷宣言誕生記》。

圖0-3　《敏捷軟件開發宣言》內容（來源：敏捷宣言網站）

百花齊放

2001年，Ken Schwaber和Mike Beedle出版第一本Scrum圖書《Scrum敏捷軟件開發》。該書系統地介紹了Scrum開發方法，這標志著Scrum方法得到完善。回想2004年，筆者也是一邊讀這本書，一邊帶著團隊嘗試Scrum，可謂無知者無?畏。

2001年，Cruise Control作為第一款“持續集成服務器”（continuous integration server）在開源許可協議下發布。它能自動監測源代碼倉庫，觸發構建和測試過程，并把執行結果和測試報告檔案發送給開發人員。（注：雖然Jenkins目前更流行，但是Cruise Control代表著持續集成實踐的真正落地，在后面內容中會展開介紹。）

2001年，Bill Wake在一篇文章中指出敏捷團隊所使用的兩種不同喜好的估算——相對估算（relative estimation）和絕對估算（absolute estimation）。

2002年，計劃撲克的當前形式在James Grenning的一篇文章中被列出，這正是2001年相對估算方式的落地實?踐。

2002年，Bill Wake的早期文章提到團隊成員對于一些常用術語的理解可能不一致的問題，例如“完成”（Done）。這一概念后來被擴展為“完成的定義”（Definition of Done）。

2003年，Mary和Tom Poppendieck夫婦的著作《精益軟件開發》將“敏捷任務板”（Agile task board）描述為“軟件看板系統”（software kanban system）。同時，他們提出了精益軟件開發的7項原則（消除浪費、內建質量、創建知識、推遲決策、快速交付、對人尊重和整體優化），第一次將精益理念系統地引入軟件開發?中。

2003年，Bill Wake在一篇文章中介紹了可以用于快速評估用戶故事的INVEST（Independent，獨立的；Negotiable，可協商的；Valuable，有價值的；Estimatable，可評估的；Small，小的；Testable，可測試的）檢查單。該文章還為用戶故事分解得到的技術任務改寫了SMART的縮寫（Specific，具體的；Measurable，可衡量的；Achievable，可實現的；Relevant，相關的；Time-boxed，時間盒的）。（需要注意的是，這里的T與一般的SMART中的T不一樣。）

2004年，Kent Beck將“完整團隊”（Whole Team）作為之前名為“現場客戶”的實踐的新名稱。這應該是把“現場客戶”納入完整團隊來看待?了。

2004年，INVEST準則成為Mike Cohn的著作User Stories applied（《用戶故事與敏捷方法》）中推薦的技術之一。

2004年，David Aderson的第一個軟件看板系統在微軟公司XIT軟件維護團隊中實施。這為后續看板方法的提出奠定了實踐基?礎。

2005年，計劃撲克技術在Scrum社區中開始流行，這歸功于Mike Cohn的著作Agile Estimating and Planning（《敏捷估算與規劃》）。這是制訂敏捷計劃的技術之?一。

2005年，術語“Backlog梳理”（backlog grooming）開始流行。該術語最早的使用記錄源自Mike Cohn在“Scrum開發郵件列表”上的觀點。幾年之后，這個實踐才被正式描?述。

2005年，Alistair Cockburn和Jim Highsmith領導的小組撰寫了項目經理原則的增補版《敏捷項目管理》，向項目經理介紹敏捷開發方法。這本書對于敏捷社區的影響還是很大的，現在被美國項目管理協會（Project Management Institute，PMI）列為官方ACP（敏捷專業人士認證）參考資料之?一。

2005年，Jeff Patton在文章“It’s All in How You Slice It”（這完全取決于你如何分割它）中明確表達了“故事地圖”（story mapping）的概念，但當時并沒有給出這個現在廣為流傳的名?字。

2006年，Esther Derby和Diana Larsen創作的Agile Retrospectives（《敏捷回顧》）填補了敏捷回顧實踐的空?白。

2007年，敏捷社區發布了看板團隊的幾份實踐報告。這些團隊使用了一套稱為“看板”（KANBAN）的特別修訂方案：沒有迭代，沒有估算，持續地帶著在制品限制的任務板。這些報告包括來自Corbis（David Anderson）和BueTech（Arlo Belshee）的報告。這其實也是對基于迭代的敏捷方法的極大補充，畢竟之前的方法論都是以迭代為主的。KANBAN方式提出這種基于流的工作方式，更加靈活，增量可大可小。對于不好制訂計劃的敏捷項目，這是一個福?音。

2008年，Cem Kaner給出了“探索性測試”（Exploratory Testing）的一個新定義。這反映出這種測試方法在不斷完?善。

2008年，Agile 2008大會專門設置了一個論壇來討論“用戶體驗”（User Experience）的相關實踐，例如可用性測試（usability testing）、用戶畫像（personas）及紙上原型（paper prototyping）。

2008年，Jeff Patton的文章“The New User Story Backlog is a Map”（新的用戶故事待辦事項是一幅地圖）圖文并茂地描述了“故事地圖”實?踐。

2008年，雖然最初提到團隊開始使用“就緒的定義”（Definition of Ready）的時間是在年初，但第一次正式的說明似乎是從10月開始的，并且該術語很快就被納入了“官方”的Scrum培訓材?料。

2009年，我攜手許舟平老師，創作了國內第一本小說體敏捷著作《敏捷無敵》。該書以主人公阿捷學習敏捷的艱難歷程為主線，展示了一個團隊實現敏捷轉型的全過?程。

持續交付

2009年6月，美國圣何塞，第二屆Velocity大會上一次名為“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”（每天超過10次部署：來自Flick開發和運維人員的協作）的演講轟動世界，后來幾乎所有和DevOps相關的資料都會把這次演講作為DevOps萌發的標志。這次演講提出了DevOps的“一個中心，兩個基本點”，即以業務敏捷為中心，打造能適應快速發布軟件的工具（tools）和文化（culture）。

2009年，持續部署（continuous deployment）實踐開始流行，盡管仍有些爭議，特別是Timothy Fitz的文章“Continuous Deployment at IMVU”（IMVU的持續部署）。爭議是什么不重要，但這篇文章不僅在敏捷領域變得非常重要，在創業圈也很火熱，因為IMVU就是寫出《精益創業》的Eric的創業項?目。

2009年，Don Reinertsen創作的The Principles of Product Development Flow（《產品流式開發的原則》）揭示產品開發流的本質，并提出相匹配的175條原則，討論了排隊論、延遲成本、加權最短作業優先算法等。這本書對于后來很多規模化敏捷方法論都產生了深遠影?響。

2010年，David J. Anderson創作的KANBAN–Successful Evolutionary Change for Your Technology Business（《看板方法：科技企業漸進變革成功之道》）正式出版。該書的出版代表KANBAN方法作為一個正式敏捷方法論日臻完?善。

2010年，《持續交付》的作者Jez Humble參加了第二屆DevOpsDays并做了“持續交付”的演講。從本質上說，《持續交付》中所提到的實踐為開發團隊如何與運維團隊協作提供了最佳實踐。如果《持續交付》早兩年問世，也許就不會出現DevOps這個術語。然而，隨著DevOps理念的傳播，DevOps概念的外延越來越廣，已經超出了持續交付本身所涵蓋的范?疇。

2011年，“Backlog梳理”實踐升級為Scrum的官方元素，并被納入The Scrum Guide（《Scrum指南》）。

2011年圣誕節過后的一場大雪，作為當年的初雪，比以往來得要晚一些，幾個程序員在麥當勞的豪華包間里做出了一個艱難的決定：mv -f hudson jenkins（將Hudson遷移至Jenkins）。于是，影響整個敏捷界的持續集成工具Jenkins誕生了。這段歷史充滿了戲劇性，正所謂惹誰千萬不要惹怒程序員。Jenkins的前身叫作Hudson，最初是由Sun公司在2004年夏天開發的（就是開發Java的那家公司）。2005年2月，Hudson開源并發布了其第一個版本。當時，Cruise Control在持續集成領域占有率排名第一。但是很快，大約在2007年，Hudson的占有率已經超越Cruise Control。2008年5月，在JavaOne大會上，Hudson獲得了開發解決方案類的Duke’s Choice獎項。從此，Hudson成為持續集成的代名詞。然而，2009年6月，Oracle公司收購Sun公司后，發生了一件令所有人都驚呆的事情。2010年9月，Oracle公司將Hudson注冊為商標。這一行為在2010年11月被Hudson社區的核心開發人員發現，引發了他們的強烈不滿。隨后，雙方進行了不太友好的談判，不出意料地談崩了。于是就出現了前面的場景。[6]

---

[6]摘自CSDN網站的文章《Jenkins簡介起源介紹》。

2012年，敏捷大師Gojko Adzi在Impact Mapping（《影響地圖》）一書中提出，通過Why→Who→How→What 4個層次的分析法，以結構化的形式顯示業務目標（Why）和產品功能（What）之間的聯系。這種方法可以幫助團隊清晰地看到每個功能對實現業務目標的具體影響路徑，確保團隊開發的每一個產品功能都是有價值?的。

2014年，Jeff Patton創作《用戶故事地圖》。他在這本書中對用戶故事地圖實踐進行了系統化的闡述，為業界對產品待辦事項的梳理方式打開了一扇新的窗口。該方法促進了不同角色之間的協同工作，并有效解決了長期困擾團隊“只見樹木，不見森林”的問?題。

2017年，Janet Gregory和Lisa Crispin重新定義了“敏捷測試”（Agile Testing），這是對該主題首次提出的簡潔定義，并且已經被敏捷社區廣泛接受和認可。

規模化敏捷

1996年，Scrum of Scrums模式首次在IDX Systems（現為GE Healthcare）項目中實施。當時Jeff Sutherland是該公司的工程部高級副總裁，而Ken Schwaber作為顧問，協助推廣Scrum實踐。該項目涉及8個業務部門，每個部門都有多個產品線。每條產品線都有自己的Scrum of Scrums。一些產品線甚至有多個層級的Scrum of Scrums。每條產品線都被要求在3個月或更短的時間內推向市場。所有產品線每6個月必須進行一次完全集成、升級和部署，以滿足像斯坦福醫療系統等區域性醫療保健供應商的需求。由此可以看出，可以存在多個甚至是并行的Scrum of Scrums，而每日Scrum of Scrums站立會議也可以根據各自的焦點劃分為獨立的子會議。[7]

---

[7]摘自CSDN網站的文章《[Scrum模式語言5]Scrum of Scrums》。

2001年，最早提到Scrum of Scrums的出版物是Cutter IT Journal，同時它也出現在2011年的Scrum論文?中。

自2005年以來，Craig Larman和Bas Vodde與多個組織合作，將Scrum、精益和敏捷開發擴展到大型產品組。他們將從這項研究中獲得的經驗和知識轉化為一個名為“大規模Scrum”（LeSS）的敏捷框架草案。雖然許多思想領袖已經提出了這樣的想法，但Craig和Bas認為，Scrum作為一個框架，具有有效采用敏捷所需的所有要素，而不管規模如何。因此，他們制定了LeSS，力求簡潔，沒有額外的術語或復雜的描述。

2011年，Dean Leffingwell作為SAFe（Scaled Agile Framework，規模化敏捷框架）的首席方法論專家，正式發布了SAFe的1.0版。在隨后的幾年內，SAFe融入了敏捷、精益、系統思考、設計思維、精益創業、DevOps等核心理念，形成了四大核心價值觀及十大原則，覆蓋了團隊、項目群、解決方案和投資組合4個層級。特別是敏捷發布火車（Agile Release Train）的概念和項目群增量計劃會議（PI Planning）實踐，在規模化敏捷方向非常具備代表性。（題外話：其實，Dean與RUP是有非常大的淵源的，因為他創立的RequisitePro公司被Rational公司收購，后來他成為IBM Rational的副總裁。在他推出SAFe時，社區有人戲言“曾經的RUP小子又回來了”，借此批評SAFe過于龐大、不夠敏捷，不過這種看法因人而異。）

2012年，還在IBM Rational團隊的Scott Ambler與Mark Lines提出了規范敏捷交付（Disciplined Agile Delivery，DAD）過程框架，這也是一個規模化敏捷框架。是的，你沒看錯，又是出自IBM Rational團隊。當時，行業認為采用DAD方法會比傳統的RUP方式在企業級軟件生產與交付時擁有更高的效率，而且得到了Gartner的特別推?薦。

2012年11月，知名敏捷教練Henrik Kniberg發布了一篇博文“Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”（Spotify的部落、小隊、分會和公會式的大規模敏捷）。這篇文章及后面將介紹的Spotify研發過程、工程文化的另外兩篇文章一起構成了“Spotify模式三部曲”，一時成為坊間要聞。創造了規模化敏捷的Spotify模式成為很多公司競相模仿的一種形?式。

2015年，Ken Schwaber對外發布Nexus規模化敏捷框架，并認為“規模化的Scrum框架（Nexus）仍然是Scrum”。這句話聽起來很熟悉，因為另一個規模化敏捷框架宣稱“LeSS也是Scrum”。

2016年，SAFe推出4.0版。該版本從收集到的案例數據中總結出在生產效率、產品上市時間、交付質量、員工滿意度等多方面成效顯?著的方法。

2018年3月，CMMI 2.0明確提出支持敏捷。

2018年，Jeff Sutherland跟Scrum聯盟合作，一起創作并發布了Scrum@Scale。它結合了最小可行的管理機構。這是Mozilla和Spotify推廣的一種敏捷開發方?法。

2019年8月，美國項目管理協會宣布收購DAD，算是在ACP認證之外補全了規模化敏?捷。

2019年12月，SAFe推出5.0版，正式提出了業務敏捷的七大能力。其中，雙操作系統概念令人眼前一亮，受到眾多500強公司的追捧。在國內，SAFe的推廣離不開李建昊老師的杰出貢獻。他不僅最早創立了中國的SAFe社區，還發起了SAFe四季峰會，并培養了多位SPC（SAFe咨詢師）。我也是那會兒成為SPC的。同年，Dean Leffingwell來中國，作為非時空交集的IBM Rational團隊的同事，我、許舟平老師、Dean Leffingwell一起合影留念并交換了對敏捷的看法，如圖0-4所示。與Dean一起回憶IBM Rational團隊的往事和趣聞，我們依然有很多共同的話題。

圖0-4　許舟平（左）、Dean Leffingwel（中）、王立杰（右）合影

2020年4月，Jeremiah Lee（Spotify前員工）在自己的博客中發表了一篇頗具爭議的文章“Spotify doesn’t Use‘the Spotify Model’and Neither should You”（Spotify自己沒有采用Spotify模式，建議大家也不要亂用）。真可謂一石激起千層浪。Lee回憶說，2017年他在斯德哥爾摩總部面試產品管理職位時，招聘人員曾告誡他不要指望Spotify是一個敏捷的“烏托邦”。加入公司后，他親眼見證了公司的規模在18個月內翻倍至3000人。他認識到，Spotify著名的Squad（小隊）模式只是一種理想狀態，而且該模式從來沒有完整實施過。他還觀察到，隨著公司領導逐漸轉向更傳統的管理結構，組織內部出現了混?亂。

2021年7月，備受期待的《項目管理知識體系指南》（PMBOK）第七版正式發布。新版本增加了與敏捷相關的內容。據稱，在新的PMP考試中，敏捷將會占據一半內容。這可以說得上是一次極大的革新與顛覆，打破了唯項目管理講項目管理，納入了許多通用管理學、管理心理學、產品設計理論的知識和理念，例如，新版本中提到了“神奇的數字7”，建議敏捷團隊的成員數量最好控制在7±2。

持續敏捷

敏捷的發展簡史終于回顧完了。我肯定還遺漏了很多內容。不知道你有沒有注意到，許多人為了尋求“敏捷”，一直在堅持不懈地努力，或自己親身實踐，或幫助他人，他們的腳步從未停止。畢竟，“敏捷”只是一個目標，其實，我們所有人都在追求“她”的路上。

Being Agile（持續敏捷）!

現在你明白誰動了你的“敏捷”嗎？

其實沒有其他人，那個人只能是你自己。

在這個不斷變化的世界中，“敏捷”也在不斷演變。無數的人正在創造無數種“敏捷”。

或許你不信，接下來我們會給你講一個叫“敏捷漂流記”的故事，里面有很多有趣的敏捷江湖人物，他們都特別喜歡玩一種叫“漂流瓶”的游戲，每次遇到奇遇，就會用自己的獨家心法寫出來，放入“漂流瓶”，發布于敏捷江湖，以求揚名立?萬。

讓我們一起去撿起這些漂流瓶吧。

屬于你的“敏捷”沒準會出現在這些漂流瓶中，也可能在你自己之后的行動中，還可能來自你自己的思考。無論如何，只要你保持開放的心態，享受求知之路的樂趣，一定會找到屬于自己的“敏捷”。

王立杰

中國DevOps社區第一屆理事會主席