編者按：“敏捷”（Agile）這個對于開發真來說不在陌生的概念，已經提出了近17年了，其背后的哲學理念也慢慢進入到了各行各業。它背后有什么故事？與“瀑布模型”相比又有什么不同？又遇到了哪些問題？近日，《大西洋月刊》發表了一篇文章詳細介紹了“敏捷”背后的故事，及其帶來的影響。

猶他州（Utah）的雪鳥城（Snowbird）是一個不太可能發生軟件革命的地方，它位于鹽湖城外約25英里的地方，一點都不像硅谷：既不以陽光和溫和的氣候聞名，也不是什么科技創新中心，更沒有那么多充滿熱情的企業家。但就在這里，一個滑雪勝地，一群具有反叛性的軟件開發人員于2001年聚集在一起，制定并簽署了行業歷史上最重要的文件之一：關于編碼集的獨立宣言。這個為期三天的小型會議塑造出了許多關于軟件的構想、開發和交付的方式，甚至是世界是如何運作的方式。

不管你是否承認它的名字，你可能已經或多或少使用過“敏捷”方法，或者是接觸到過那些正在使用它的公司。來自Spotify和eBay的代表證實，這兩家公司目前都在使用敏捷方法，而且在Twitter的網站上有一份招聘“敏捷教練”的工作。互聯網上的“面包屑”足跡表明，許多其他知名的科技公司過去也曾嘗試過這種做法。而且不僅僅是硅谷：據報道，沃爾瑪早在幾年前就開始嘗試敏捷方法了。敏捷聯盟是一個提倡使用敏捷方法的非營利組織，它的公司成員包括洛克希德馬丁公司、埃克森美孚公司和威訊公司在內的各種巨頭。

敏捷方法的追隨者似乎無處不在，帶著一整套工具和技巧讓工作場所變得更有效率。從表面上看，它可能看起來像項目管理類型使用的另一種毫無意義的企業流行語。但它實際上是一種非常具體的哲學，在雪鳥城簽署的一份68字的文件中對其進行了概述。

在軟件能夠吞噬世界之前，人們需要從洪流中抽身出來。硅谷可能是世界上唯一一個“瀑布”（Waterfall）一詞帶有些許負面含義的地方。在編程中，“瀑布”被用來描述一種構建軟件的方式——思考一個緩慢的、逐步的、分階段的過程。在“瀑布”模型下，軟件項目的設計非常嚴格，就像人們制造腕表的方式一樣。

它的工作原理是這樣的：有人會提出一個他們想要開發的軟件。在寫完一行代碼之前，需求者/產品經理們會寫出他們想要構建的內容，以及一系列冗長而詳細的計劃。他們制作所謂的“需求文檔”，在上面列出他們想要軟件做的所有事情。然后項目會流向下游，從一個階段到下一個階段，從一個團隊到另一個團隊，直到完成。最后，整個新軟件都經過了測試，反饋給了客戶，然后就交付出去了。

?

許多人把這種模式的起源歸功于Winston?W.?Royce?1970年的一篇論文，但有一個很大的問題：盡管在論文的第二頁出現了一個類似“瀑布”的圖表，但Winston?W.Royce的論文實際上并不支持以這種方式構建軟件。

當你確切地知道你想要構建什么東西時，線性方法可能會奏效，但對于一些項目來說，它可能會有太大的限制——正如麻省理工學院斯隆管理評論的杰出教授Michael?A.Cusumano所言，軟件開發是“真正的發明過程”。Cusumano說：“軟件工程師或程序員喜歡在不同的步驟之間來回切換。它們并不是按照順序來排的。”

Cusumano指出：在一個項目的最后階段，要測試整個項目，就會有這么一個問題：如果你在最后一個階段發現了一個bug，那么嘗試回去修復它可能會很混亂，甚至是致命的。一些軟件項目會陷入困境，根本不可能去交付了。

“人們會拿出詳細的清單，列出應該做什么、他們應該怎么做，以及應該完成哪些任務，”曾參加過“雪鳥城會議”的ThoughtWorks首席科學家Martin?Fowler回憶道。“一個軟件和另一個項目之間的差異如此之大，以至于你無法按照那樣的標準提前規劃出所有的事情。”在某些情況下，文檔本身也會變得笨拙起來。我采訪過的人中，有幾個人都有過類似的“恐怖”故事：書架上放著裝訂好的書或一份長達800頁的文件，而且被翻譯成了三種不同的語言。

另一位雪鳥城會議的參與者，Ken?Schwaber——Scrum的聯合創始人和Scrum.org創始人——說瀑布模型“簡直毀了我們的職業”。“它使得人們被視為資源，而不是有價值的參與者。”由于事先做了這么多的計劃，員工們就變成了機器上的一個齒輪。

在上世紀80年代和90年代初，純粹的順序模式出現了動搖，一些公司開始嘗試不同的方法來完成項目，創建流程。

在1997年一篇微軟的論文中，Cusumano和他的合著者Richard?W.Selby描述了“瀑布”是“如何逐漸失去了青睞……因為企業通常會開發更好的產品，如果他們能夠改變規格和設計，從客戶那里獲得反饋，并在產品不斷發展時不斷測試組件。”

在這個世紀交替之際，軟件行業的一些人開始了真正地反擊。他們想要創造一些流程，讓他們有更多的靈活性，并允許他們按時交付。其中誕生了一些過程，如Scrum和極限編程（XP），被稱為“輕級”或“輕量級”過程。但沒有一個真正流行起來。因此，在2001年，這些倡導輕量級的人決定聯合起來。

“我認為，在這一點上，我們都在尋求合法性，我們自己也在做類似的事情，但它并沒有在社區中真正取得成功，”Jim?Highsmith說，他是ThoughtWorks的一名執行顧問。

目前還不清楚是誰想出了這個最終會在雪鳥城舉行會議的想法。許多參與者都是軟件社區的領導者，一些人還記得在行業聚會上被拋出的想法。當邀請函最終到達時，它是通過一封電子郵件發來的，郵件來自Bob?Martin。Martin是一名業界資深人士，也是Uncle?Bob咨詢公司的創始人。他經營著“Clean?Code”博客，具有一種書呆子式幽默：在他的網站上嵌入了一段YouTube視頻，其中包括Martin，以及其他的一些東西，比如在小行星上爆炸。Martin說，他和Fowler是在芝加哥的一家咖啡店相識的，他們在那里編輯并發送了電子郵件。

在斟酌了幾個選擇之后——比如芝加哥（“寒冷，沒有什么好玩的事”，2001年Highsmith寫道）和安圭拉（“溫暖而有趣，但卻很費時間”）——這群人在猶他州（“寒冷但有趣的事情”），規劃了一場在雪鳥城的旅行。在那里，從2001年2月11日開始，這些人——他們都是男性——會去山坡上談論怎樣開發軟件程序。

我采訪了17名與會者中的16人。（Facebook的技術教練Kent?Beck拒絕就本文接受采訪。）十多年后的今天，他們回憶了自己的參會過程。“你會想，‘你知道，讓一群人待在一個房間里，他們會聊天，什么事也不會發生。’”馬丁說。但事實并非如此。這群人安排好了會議，組織了活動，并發表了這個宣言。這真的是一種令人驚異的觀察。”

他們在雪鳥城安頓下來，開始說出他們的共同之處。Schwaber回憶說：“當我們比較我們如何做我們的工作時，我們對同樣的事情感到驚訝。”

與其他歷史文獻不同的是，“敏捷宣言”并沒有宣稱真理是不言而喻的。相反，我們更看重這一點。一些起草者說，這種建設性是該文件的重要特征之一。當然，目前還不清楚誰提出了這個問題，盡管文件的幾位起草者都有自己的理論。

那么，什么是“敏捷宣言”呢？序言中寫道，“我們正在發現更好的方法來開發軟件，并幫助其他人做到這一點。”然后，它列出了四個核心價值觀：

這份文件的結論是：“雖然右邊的產品更有價值，但我們更看重左邊的產品。”與任何優秀的原始文件一樣，這些詞語也會有不同的解讀版本，但其基本要點是：將人們置于流程之上。專注于開發可以工作的軟件，而不是軟件的文檔。和你的客戶一起工作，而不是為一份合同而爭吵。在此過程中，要對改變持開放態度。

這些人在會議期間完成了宣言。剩下的時間里，他們都在研究新文件背后的12條原則，以及滑雪。（一些人認為，這些原則被認為是宣言的正式組成部分，其他人則認為宣言本身就是一種價值觀。）

這種新理念需要一個名字，并不是每個人都對“輕量級”名稱感到滿意。最后由一個英國人Martin?Fowler提出了“敏捷”這個詞。

當這些人離開雪鳥城時，沒有人預料到接下來會發生什么。“當我下山的時候，我和其他一些宣言起草者一起，我在想，我不確定有人會注意到這一點，”Mike?Beedle回憶道，他是企業Scrum的首席執行官。“我的感覺是，這就像是一場賭博。這就像一個問號。誰知道呢？我的意思是，也許人們會去我們提議的這個網站。或者，他們可能不會。”

他們做到了。與獨立宣言不同的是，“敏捷宣言”誕生于互聯網時代。最后一份文件發布到了一個簡單的網站上。Cunningham?&?Cunningham的聯合創始人Ward?Cunningham主持這個網站，他說他打算讓人們打印這份文件，并把它作為海報掛起來。但在過去的15年里，這個網站提供一種虛擬的、集體的戰斗口號。網站訪客被邀請簽署宣言，并公開在文件中添加他們的名字。

“我們把它放上去，然后它就爆發了，”Dave?Thomas，他是《The?Pragmatic?Programmer》一書的合著者，同時也是南衛理公會大學的兼職教授。“那個網站實際上是一個焦點，如果你愿意的話，對于那些想說‘是的，我同意這個觀點’的人。”我認為這是它取得快速發展的原因之一。”

Marick同意這一觀點。他說：“我認為，人們之所以能夠發泄他們的不滿，是因為他們引用了Martin?Luther的論文，他們也可以在上面簽名。這才是真正的動力。”

簽署這份文件截至到2016年7月。（Cunningham重新配置了托管服務，并開始像對待歷史文件一樣對待宣言。）但他表示，自首次發布以來的15年里，已有超過2萬人簽署了敏捷宣言。

當然，宣言只是一個開始。“我的天，我希望我能去那里，”Grady?Booch告訴我。Booch是IBM研究軟件工程的首席科學家，他被邀請到雪鳥城的度假勝地，但他說，為了對付一個“討厭的客戶”，他在最后一刻爆發了。Booch并不懷疑“敏捷”的開創性起源，以及隨后的影響。他告訴我，上世紀90年代是“軟件工程發展的一個非常豐富的時期，當時你有幾十個，甚至幾百個，對軟件開發提出了新想法的人。”他說，所有這些，都雪鳥城得到了匯總。

?

與“瀑布”不同的是，“敏捷”強調迭代開發，或以碎片構建軟件。“敏捷”團隊通常在較短的周期內工作——被人稱為“沖刺”——今天是最廣泛使用的“敏捷”形式之一——通常持續兩周。Booch認為，“敏捷”和“瀑布”都是有效的方法，但不同的項目需要不同的方法——重要的是權衡項目的風險和正在執行的團隊的文化。他說，“如果我在建造一座核電站，相信我，我不想使用增量和迭代的方法，因為測試失敗永遠都不是一件好事，它是不可逆轉的。另一方面，如果我要開發一款一次性應用，不管它是什么，那么我肯定會把一些人放在一個房間里，然后去搭建這個應用。”

也許“敏捷”，或者類似的東西，是不可避免的：如果軟件項目能夠在靈活的、數字化的未來取得成功，那么他們需要能夠像科技術語一樣，能夠對變化做出反應。網絡深刻地改變了軟件的交付方式，今天的軟件一般不會被錄制到光盤上，放在商店的貨架上;更新可以被推送到你的筆記本電腦或智能手機上。這使得在發布產品后添加功能或修復錯誤變得更加容易。

“為了在新經濟中取得成功，”Highsmith在他2001年的著作總結中寫道，“要積極地進入電子商務、電子社區和網絡時代，企業必須擺脫他們的Dilbert式的工作和晦澀的政策。”這種來自企業生活的不友好的自由吸引了“敏捷”方法論的支持者，讓傳統主義者感到害怕（你不能在專業論文中使用“屎”這個詞）。

Cockburn認為，這是因為“敏捷”成功破譯了純粹的精神和團隊活動——而且“這只是歷史的偶然，是程序員破譯了這一點。”

Fowler說，與“更主流、更像瀑布式的想法”相比，“每個人都在做的事情非常詳細”，而“敏捷”讓從事這項工作的人更有力量。而且，由于它已經被各種各樣的職業所采用，Arie?van?Bennekum甚至建議將“軟件”這個詞改為“解決方案”，以向所有人開放“敏捷”。

盡管就宣言本身是否應該進行修訂進行了討論，但許多最初的簽署者認為這份文件是一份歷史文件，而不是一份活生生的文件。Cockburn說：“這就像美國歷史上的獨立宣言。”“你不會回去重寫它。”

Grenning說：“我認為這四個核心要素仍然是有效的。”“我不認為它們會改變。”

隨著公開簽名的結束，“敏捷”宣言似乎不太可能再有什么改變，但這并不意味著“敏捷”沒有問題。在我們的談話過程中，許多起草者表達了對當下“敏捷”的失望。緊跟“敏捷”之后，“敏捷軟件”、“敏捷教練”、“敏捷培訓”和“敏捷會議”都成為了“敏捷開發”的理念。你可以花錢嘗試讓你的企業或團隊變得“敏捷”，這是不可或缺的。

但這里有一個特別的諷刺：“敏捷”是一種哲學，而不是一套商業慣例。用四顆“子彈”勾勒出一種思維方式，一種將項目的所有復雜部分進行優先排序的框架。他們不會告訴你該買什么軟件，也不會告訴你如何安排每天的團隊會議。

Van?Bennekum現在是Wemanity的一名思想領袖，他說：“我認為那些敏捷教練，絕對不知道他們在說什么，這是令人不安的。”

除了“敏捷”的商業化之外，非技術用戶的大量涌入也造成了一些沖突。Martin堅持認為，“現在最令人討厭的方面”是，“‘敏捷’已經被項目管理人員接管了”，而撇下了“技術人員和技術思想”。

Jeff?Sutherland是Scrum的聯合創始人，也是Scrum公司的首席執行官。他對軟件社區內部的文檔錯誤解讀感到沮喪。Sutherland說，他認為硅谷的團隊聲稱自己是“敏捷”的，但“在短迭代結束時沒有交付工作產品”。他說，這讓他們“違反了宣言的第二個價值”。他指出：“大多數人都在做的事情是，他們無法在任何合理的時間獲得任何工作——他們聲稱自己是‘敏捷’的，因為任何人都可以做他們想做的任何事情——但這與‘敏捷宣言’不一致。”

有一些人甚至宣稱‘敏捷’已經死了。但Cockburn認為，嘗試“敏捷”總是有一些好處，即使它并不完美：“即使做得很糟糕，‘敏捷’也比其他所有的選擇都要出色，或者至少是替代‘瀑布’，它就在那里。”

編譯組出品。

作者為CAROLINE MIMBS NYCE

文章由36氪編譯自https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/。

編輯：郝鵬程