歷史:敏捷宣言誕生記

大衛張33發表於2012-12-29

譯者按
本文譯自:http://www.agilemanifesto.org/history.html。要想了解敏捷軟體開發,這篇文章是必讀,對學習敏捷中的不少疑惑都給出瞭解釋。感謝@AgileCoach和@徐毅-Kaveri的審校。

正文
2001年2月11日至13日,在美國猶他州瓦薩奇山雪鳥滑雪勝地,17個人聚到一起,交談、滑雪、休閒,當然還有聚餐。他們試圖找到共識,最終的成果就是《敏捷軟體開發宣言》(Manifesto for Agile Software Development)。參會者們包括來自於極限程式設計、Scrum、DSDM、自適應軟體開發、水晶系列、特徵驅動開發、實效程式設計的代表們,還包括了希望找到文件驅動、重型軟體開發過程的替代品的一些推動者。
由全體參會者簽署的《敏捷軟體開發宣言》(Manifesto for Agile Software Development)成為了重要標誌,因為這麼大一幫無政府主義者能聚到一起實在是太不容易。只有英國人Martin Fowler表達了對“敏捷”這個詞的擔心,他認為多數美國人都不知道“敏捷”這個詞如何發音。
Alistair Cockburn和很多參會者一樣,最初有很大的擔憂。“我個人沒有期望本次敏捷達人們的聚會能夠達成任何實質性共識。”會後,他再次分享了自己的感受。“對我來說,很開心宣言能夠最終定稿。而讓我感到驚訝的是其他人也同樣開心,因此我們的確達成了某種實質性共識。”
這群有時存在相互競爭的軟體開發獨立思考家們共同簽署了展示在網站(http://www.agilemanifesto.org/)首頁的《敏捷軟體開發宣言》,他們稱自己為“敏捷聯盟”。
但多數人(如果不是所有的話)成為聯盟成員的動力不僅僅是因為宣言上列出的那些理由,他們還有著更深層次的考慮。在長達兩天的會議臨近結束的時候,Bob Martin半開玩笑地說他打算談點“虛的”,講講“空話”。Bob這話雖然有玩笑成分,卻得到了幾乎所有人的響應。因為我們都會非常樂於與一群擁有相似價值觀的人一起共事,這些人會相互信任與尊重,會促成以人和協作為本的組織模式,能構建大家都願意為之貢獻的組織社群。本質上講,我相信敏捷方法學家們確實要玩這些“虛的”東西。為了交付好產品給客戶,他們會切實去做,不止是口頭上說“人是我們最重要的資產”,還要從實際中體現出人本身就是最重要的,去掉“資產”這個提法。因此在最後的討論過程中,敏捷方法學家們對價值觀和文化這些“虛的”東西表現出了極大的興趣,有時甚至會進行激烈的爭論。
例如,我認為,極限程式設計呈現出強勁的發展勢頭,其根源不在於結對程式設計或重構等實踐本身,而是從整體上看,極限程式設計能讓開發人員們擺脫“呆伯特”組織中那些腐朽觀念的束縛。Kent Beck分享了他早年的一次親身工作經歷。當時他估算的開發工作量是2個人做6個星期。結果在專案開始的時候,經理臨時換了另一個人和他一起工作,最後他們花了12個星期才完成專案。他的感覺很糟,因為在後面6個星期中間,經理一直喋喋不休,嫌他太慢。Kent有點沮喪,覺得自己作為一個程式設計師實在是太失敗。到最後,他終於意識到最初2個人做6個星期的估計其實是相當準確的。這不是他的失敗,是管理者的失敗(指臨時換人這件事),實際上是那些持續禍害著我們這個行業的,所謂標準化、流程化的“僵化”頭腦的失敗。
同樣的事情每天都在重複發生。市場人員、經理、外部客戶、內部客戶,當然,也包括開發人員,誰都不想難為自己,去做出那些艱難的、需要折衷的決定。於是他們利用組織的權責劃分將難題轉嫁給他人,甚至提出荒謬的要求。這不僅僅是軟體開發的問題,在“呆伯特”組織中它無處不在。
想要在新經濟環境下成功,並引領電子商務和網路時代,那麼公司一定要去除“呆伯特”式的行為表現,不要沒事找事做,不要搞出那些沒人能搞懂的規章制度。敏捷是一種解放,讓人不再虛度時光。這吸引了敏捷方法論的支持者們,卻把傳統主義者嚇得屁滾尿流(專業文章中不能罵娘)。坦率來講,敏捷方法嚇到了組織中的官僚們,尤其是那些樂於為過程而過程,卻不全力為客戶著想,不想履行承諾按時交付可見成果的官僚們,因為這(敏捷)會讓他們無處藏身。
敏捷運動並不是反方法論的,事實上,我們中的大多數人正在試圖恢復方法論的名聲。我們希望能重歸平衡。我們樂於建模,但目的不是給無人問津的企業資源庫增加幾篇圖表存檔。我們要寫文件,但那些從不維護、並很少用到的長篇大論不算在內。我們得做計劃,但同時也要認識到在劇烈變化的環境中計劃的侷限。有些人給XP、Scrum或任何一種敏捷方法論的支持者們打上“黑客”的標籤,這隻表示了他們對方法論和黑客本意的無知。
2000年春,Kent Beck組織了一次會議,地點在俄勒岡州的羅格里夫酒店,參會者包括極限程式設計的支持者們和一些“圈外人”,正是這次會議導致了後來在雪鳥的聚會。在羅格里夫會議上,參會者們宣稱了對一系列“輕量”方法論的支援,但沒有發表什麼正式宣告。2000年期間一系列論文都被歸類到“輕”或“輕量”流程,其中很多都提到“輕量級方法論,如極限程式設計、適應性軟體開發、水晶系列和Scrum”。大家交流後發現,沒人真正喜歡“輕”這個名號,但這似乎是當時約定俗成的稱呼。
2000年9月,來自芝加哥Object Mentor公司的Bob Martin用一封電子郵件吹響了下次會議的集合哨。“我想召集一個為期2天的小型會議,時間是2001年1月或2月,地點在芝加哥,目的是讓所有輕量級方法論的領袖們匯聚一堂。您們都被邀請了。如果您們覺得還有誰該來,請告訴我。”Bob建立了一個Wiki網站,由此開始了熱烈的討論。
很快,Alistair Cockburn就用一封書信加入了討論,他表達了對“輕”這種提法的不滿:“我不介意用‘輕’來描述方法論的輕重程度,但我並不願意因參加一個輕量級方法學家會議而被看作是輕量級的。這聽起來有點像一群乾瘦、低能、並無足輕重的人在試圖回憶起某個特定的日子。”
關於會議地點的爭論最為激烈。芝加哥讓人不爽,既冷又無趣;猶他州的雪鳥,雖然也冷,但至少對那些想滑雪的人來說還挺有意思,像Martin Fowler在第一天滑雪就滑個頭朝地;加勒比的安圭拉島,暖和又好玩,但路途太遠。最後還是可以滑雪的雪鳥勝出,不過有些人(例如Ron Jeffries)還是希望下次能去個暖和點的地方。
我們希望,一起組成的敏捷聯盟能夠幫助到其他同行,幫他們用新的更“敏捷”的方式去思考軟體開發、方法論和組織。做到這一點,我們就得償所願了。

Jim Highsmith,來自敏捷聯盟
©2001 Jim Highsmith

參考
極限程式設計:敏捷軟體開發方法的一種,縮寫XP,英文全稱Extreme Programming。
Scrum:敏捷軟體開發方法的一種。
DSDM:敏捷軟體開發方法的一種,英文全稱Dynamic Systems Development Method。
自適應軟體開發:敏捷軟體開發方法的一種,縮寫ASD,英文全稱Adaptive Software Development。
水晶系列:敏捷軟體開發方法的一個方法系列,都用Crystal開頭。
特徵驅動開發:敏捷軟體開發方法的一種,縮寫FDD,英文全稱Feature-Driven Development。
實效程式設計:不是一個方法論,是一個流派,英文全稱Pragmatic Programming。
呆伯特(又名迪爾伯特):Dilbert,美國 Scott Adams 的有名職場卡通人物。呆伯特法則:Wiki釋義

相關文章