10.21 《代碼英雄》第一季（3）：敏捷革命

譯自： https://www.redhat.com/en/command-line-heroes/season-1/agile-revolution

代碼英雄(Command Line Heroes)是世界領先的企業開源軟件解決方案供應商 紅帽(Red Hat)精心製作的音頻播客，講述開發人員、程序員、黑客、極客和開源反叛者如何徹底改變技術前景的真實史詩。該音頻博客邀請到了谷歌、NASA 等重量級企業的眾多技術大牛共同講述開源、操作系統、容器、DevOps、混合雲等發展過程中的動人故事。點擊鏈接 https://www.redhat.com/en/command-line-heroes 查看更多信息。

本文是《 代碼英雄 》系列播客 第一季（3）：敏捷革命 的 音頻 腳本。

Saron Yitbarek: 有些故事的走向和結局會重新定義一個行業。在這些故事中也傳唱著，我們來自哪裡，我們是誰，我們正在做什麼。 上一集 中，我們追溯了 Linux® 開源技術的崛起。但這一集我要講的，是緊接著發生的故事。操作系統之戰結束後，開發人員相繼奔赴前線，到火力更為集中的戰場。

在那個新的戰場，意味著開發者們將要重塑自己的工作。[00:00:30] 本集播客，我們將深入瞭解因為關注開發人員而產生的一種全新的軟件開發方法論。這種新穎的工作流程產生了哪些意想不到的影響，遠超我們屏幕上的代碼所能控制的範圍。

我是 Saron Yitbarek，歡迎收聽紅帽的原創播客《代碼英雄 第三集 敏捷革命》。今天的故事始於 2001 年 2 月，發生在美國猶他州的滑雪小屋裡。

Dave Thomas: [00:01:00] 我們面前有個小屋，眼前是松樹梁和壁爐，還有進入屋子的小門。我們是前一天晚上才到達這裡的，然後基本上只是圍坐在一起，談了談我們準備探討的內容。緊接著第二天，我們都如期而至，來到了預定的會議室。先把桌子移到邊上去。然後將椅子擺放成一圈，確切地說是一個橢圓，這樣一來我們就可以面對面交流，一定程度上也讓人感覺到可以敞開心扉，暢所欲言 。

Saron Yitbarek: [00:01:30] 剛才提到的這群人都是開源開發人員，所以保持開放是他們的特點。那是 Dave Thomas 和其他的 16 個人，在那個冬天集聚在 雪鳥(Snowbird)滑雪場。但是他們的目的並不是滑雪，而是探討在 90 年代開發者的世界所面臨的問題。在這裡我用“探討”，但實際上用“辯論”更準確。他們最初在名為 面向對象編程、語言及系統(Object-Oriented Programming, Languages and Systems)（OOPSLA）的會議上認識的，這個會議主要議題是面向對象程序設計、編程、語言和系統。[00:02:00] 實際上正是那次會議，讓他們意識到當前的軟件開發很混亂。只是沒有就應該怎麼應對達成一致。

所以此次雪鳥山上的會議，是試圖尋找解決這個問題的方法。那麼究竟是什麼問題？於是我詢問 Dave，開發人員之前的方式到底出現了什麼問題。

Dave Thomas: 所以，我不知道……你有沒有裝飾過房間。

Saron Yitbarek: 我有。

Dave Thomas: ……或者……好吧。如果我先告訴你，“我想讓你坐下來，然後給你一張白紙。接著我希望你能描繪下來這個房間完成後大概的樣子。”[00:02:30] 可以想象嗎？

Saron Yitbarek: 嗯嗯（肯定的語氣）。

Dave Thomas: 你能做到嗎？

Saron Yitbarek: 實際上，我的辦公室就是這麼佈置出來的。首先，我畫了一個簡單的草圖，然後加上一些渲染，最後把所有架子擺放在我覺得合適的位置。這種方式沒有真正起到作用，我的計劃也沒有實現。

Dave Thomas: 但是，即使你那樣去做了，你做了什麼？先把架子放起來，然後說，“哦......這樣放不行，因為會擋道。”所以，你又緊接著把架子移到其它地方，或者你會說，“你知道嗎，我真的不能把地毯放在那裡，因為我的椅子腳會陷進去。”狀況頻發。

[00:03:00] 遇到未知的情況，你總需要一種“迭代”的方式去應對。人類的大腦無法準確地對現實世界進行建模，從而提前預知真正起作用的是什麼因素。所以，軟件開發也是一樣的。不會預先就清楚自己想要的是什麼。對嗎？

Saron Yitbarek: 嗯嗯（肯定的語氣）。

Dave Thomas: 我經歷過太多這樣的情況，當我從客戶那裡拿到了一個要求細則，然後我已經很好地按照要求完成了每一條細則上的要求。[00:03:30] 結局卻總是不歡而散 ，“這不是我們想要的。” 算了吧，“但我想說的是，這就是你要求的啊。”他們說，“是的，但這不是我的意思。”你懂嗎？

Saron Yitbarek:

嗯嗯（肯定的語氣）。

Dave Thomas: 所以說，這整個流程就好像是你可以詳細說明每一步，然後通過非常機械的步驟，然後終於完成了。

Saron Yitbarek: 是啊。

Dave Thomas: 但是在軟件行業可行不通。這種方式不適用於有任何模稜兩可的情況。也不適用於需要有判斷的情況。[00:04:00] 就像任何藝術嘗試一樣，這種方式就是行不通。總是缺失了關鍵的一步：反饋。

Saron Yitbarek: 也許你已經聽說過 90 年代的軟件危機。當時的軟件開發一團糟。相比於開發軟件的費用，公司在修復軟件上的錢花的多得多。與此同時，對於你我這樣的開發人員來說，進退不得。有時候，我們每隔好幾年時間才能推出新的軟件。

[00:04:30] 我們疲於應付這些緩慢、陳舊、瀑布式開發的工作流程。從 A 到 B 到 C，完全都是提前確定好的。因此，那時的時間都消耗在尋找新的流程，尋找更好的軟件開發方式上了。事實上，每個月似乎都有新入行的開發者對如何改善軟件開發的過程提出宏偉的設想。

其中就有極限編程、有 Kanban、還有統一軟件開發過程等，不勝枚舉。[00:05:00] 在這些方法論的激烈競爭中，也催生出了新的視野和改進方法。那就是 Dave Thomas 和他在雪鳥滑雪場的朋友們迫不及待開始探討的領域。

值得讓這群人齊聲歡呼喝彩的就是《 敏捷軟件開發宣言 (manifesto for agile software development)》。當時的開發速度正在以前所未有的速度保持增長 —— 而開源使開發人員變得更強大。另一方面，開發人員也需要一種新的敏捷的開發模式。

順便提一下，那些在雪鳥滑雪場會面的人，在經過一番你來我往的爭論後，才落實到這個詞。[00:05:30] 敏捷(Agile)。這個詞非常切題。這種方式就好像你在國家地理中看到的，類似描述大型貓科動物的方式。一個與瀑布式開發預設路徑正好相反的詞。隨著新的信息層出不窮，這個詞讓那些願意改變航向的人看到了一線曙光。請注意這可不是一個名詞而是一個形容詞。

敏捷將會是一種習慣，而不是一種具體的說辭。那麼，那些採用敏捷的開發者提供了什麼呢？[00:06:00] 他們的總體解決方案是什麼？現在很多人都以為敏捷是一個複雜的集合，不同的角色亦或是系統。 會有一個 項目經理(scrum master)，一個 項目 (scrum)團隊，一個產品負責人。同時他們都要進行一到兩週的衝刺工作。

與此同時，工作都堆積在”冰盒“和”沙盒”中。好吧，聽起來感覺流程很多。但一開始的時候是沒有這些流程的。[00:06:30] 撰寫該敏捷宣言的人目標是簡單和清晰的。實際上，他的願景是如此簡單，以至於它具有定義從那時起幾乎每個開發人員命運之路的能力。

Dave Thomas: 我們已經提到了表達價值觀的方式，我們更喜歡某種方式，而不是另一種方式。事實上，在午餐這段時間，我們就寫下了幾乎所有的價值觀，現在都是敏捷宣言的一部分。

Saron Yitbarek: 這是可以管理開發的四個奇思妙想。如果你尚且還不熟悉那些敏捷的誡命，他們會這樣解釋：

[00:07:00] 個體和互動勝過流程和工具；可工作的軟件勝過文檔；客戶協作勝過合同談判；響應變化勝過遵循計劃 。

Saron Yitbarek: 我記得第一次看到這個宣言時的情形。我剛開始學習編程，老實說，當時我並沒有覺得這個想法有多棒。[00:07:30] 一直到我瞭解到那些使敏捷行得通的工具和平臺。對我來說，這只是一些模糊的概念。但是，對於長期以來一直在努力解決這些問題的開發人員來說，這是一個很好的行動方案。

該宣言是一盞燈，可以激發更多奇思妙想的道路。這四點宣言和一些支持材料都發布在 Agilemanifesto.org 網站上，並且呼籲其他開發者簽名以表示支持。

Dave Thomas: [00:08:00] 很快獲得了 1000 個簽名，接著 10,000 個，然後簽名數一直在增長，我想我們都驚呆了。這基本上變成了一場革新運動。

Saron Yitbarek: 他們從來沒有計劃過把這份敏捷宣言帶出滑雪小屋。這只是一群熱衷於軟件開發的人，並且對幫助他人更好地發展充滿熱情。但很明顯，“敏捷” 本身像長了腿一樣。紅帽公司首席開發倡導者 Burr Sutter 談到了“敏捷”對於還困在“瀑布”中的開發人員來說是一種解脫。

Burr Sutter: [00:08:30] 因此，敏捷的概念從根本上引起了人們的共鳴，基本上是在說：“看，我們專注於人員而不是流程。我們專注於交互和協作而不是工具和文檔。我們認為工作軟件高於一切，我們寧願人們通過小批量的工作，實現高度互動、快速迭代。”

Saron Yitbarek: [00:09:00] 而對於一些人來說，這個開發者的革新走得太遠。敏捷甚至被視為是給那些不負責任的黑客心態的合理說辭。早期反對敏捷最重要的聲音之一是 Steve Rakitin。他是一名軟件工程師，擁有超過 40 年的行業經驗。

當他大學畢業時，Rakitin 就開始建造第一個核電站數字控制系統。幾十年來，他一直致力於研發電力軟件和醫療設備軟件。這些都是對安全很注重的軟件。[00:09:30] 沒錯。你可以預料到，他可不會對這種手忙腳亂的開發方式感興趣。

因此，在方法論戰爭的尾聲，敏捷橫空出世，Rakitin 對此翻了個白眼。

Steve Rakitin: 就像是，“好吧，我們換種方式說，如同一群人圍坐著喝著啤酒，就想出了開發軟件的其他辦法。”順便提一下，其中許多已經得到進一步發展，並應用於早期的開發方法裡了。

Saron Yitbarek: [00:10:00] 他這麼想其實也沒有什麼錯。實際上你可以在”雪鳥峰會” 前幾十年就追溯到敏捷哲學。例如，像 Kanban 這樣的精益工作方法可以追溯到 20 世紀 40 年代，當時豐田受到超市貨架存貨技術的啟發發展而來的。

他們的精益製造理念最終被用於軟件開發。Rakitin 有另外一個擔憂。

Steve Rakitin: [00:10:30] 這篇宣言發表時我非常懷疑，因為它基本上是為了讓軟件工程師花更多的時間編寫代碼，花更少的時間搞清楚需要做什麼，同時記錄文檔的時間少了很多。

Saron Yitbarek: 對於 Rakitin 來說，這不僅僅是提出新的工作流程創意。這也關乎到他正直的職業觀念。

Steve Rakitin: [00:11:00] 長期以來，相比於電氣工程和所有其他工程學科，軟件工程並未被視為正規的工程學科。在我看來，部分原因是因為普遍缺乏軟件工程師認可的公認實踐。當我們經歷了 90 年代的十年，並且我們逐漸開始明晰其中的一些流程時，[00:11:30] 似乎其中一些事實上已佔據上風，而且其中許多都很有意義。

然後隨著敏捷宣言的出現。如果軟件工程將成為正規的工程學科，那麼你就需要流程化的東西。 其他所有工程學科都有流程，為什麼軟件工程就沒有？

Saron Yitbarek: [00:12:00] 我是 Saron Yitbarek，你正在收聽的是紅帽的原創播客代碼英雄。那麼，如果我們把在核電站工作的人士的觀點放在一邊，轉而關注更廣闊的企業界，我們發現敏捷已經逐漸廣受認可。但不是自然而然，沒有絲毫企業阻力就發生了。

Darrell Rigby: 我想我們在敏捷採用中看到的最大阻力來自中高級管理層。

Saron Yitbarek: [00:12:30] 這位是 Bain＆Company 的合夥人 Darrell Rigby。他們一直嘗試在軟件開發公司中推行敏捷開發。不僅如此，還包括產品開發、新聞服務開發、廣告計劃和忠誠度計劃等。不管他們去哪裡推行，管理者都有可能會有點緊張。

Darrell Rigby: 敏捷改變了他們認為自己如何增加價值的觀念，因為他們正在逐步退出細節上的管理或干預，並給這些團隊賦予權力，加以指導。

Saron Yitbarek: [00:13:00] 現在，敏捷並不能保證阻止中間輕微的干預。我承認，我第一次看到一個敏捷管理委員會時，我認為這是一個永無止境的待辦事項清單。有點壓迫感。但後來直到我開始真正使用敏捷產品管理工具。我完全變成了粉絲。我是一個編碼培訓營的新人，我試圖弄清楚如何確定功能的優先級並做出產品決策。

那些看起來很可怕的工具讓我有了所有這些想法，然後給它們命名、順序和結構。從而可以幫助我更好地管理我的項目。[00:13:30] 所以，我確實同意 Rigby 的觀點。有些人可能會看到這些工具的效果，並認為，如果敏捷賦予開發人員權力，那麼就會剝奪經理們的管理權。

但是，它的價值比任何一個職位都要大。敏捷的發展勢如破竹。更重要的是，敏捷正在證明自己。

Darrell Rigby: [00:14:00] 目前，成千上萬的團隊已經採用敏捷。因此，我們有很多關於敏捷可以使用的數據。答案是，無論何時你開始考慮創新，相比你現在使用的創新方式，敏捷團隊能做得更好。

有許多更大的、知名的公司都在變革自身。亞馬遜是敏捷方法的重要用戶。[00:14:30] 奈飛、Facebook 和 Salesforce ——他們都是敏捷的重度用戶，實際上敏捷方法不僅重新定義了工作方式，更是重新定義了行業的運作方式。

Saron Yitbarek: 當 Rigby 第一次聽說敏捷時，他認為這是一種奇怪的語言。他當時正在與許多大型零售商的 IT 部門合作。無意間聽到他們談論 “time boxes”、“sprint” 和 “scrum master” 。起初，他並不懂他們在說什麼。他告訴我他實際上是試圖忽略任何有關敏捷的字眼，就像這是他不需要學習的另一種語言。畢竟，他本人不是開發人員。

[00:15:00] 但是如今，他卻成為了敏捷信徒，把敏捷帶到他的家裡，帶入他的教堂。

Darrell Rigby: 我不一定每天早上都和家人坐在一起，和他們一起參加敏捷會議。但是，我已經非常擅長優先考慮我要做的事情。

Saron Yitbarek: [00:15:30] 十多年來，敏捷已經從邊緣走向主流。但是，企業同化還是有代價的。在某些情況下，這種同化甚至會使敏捷宣言的最初意圖變得模糊。Dave Thomas 讓我想起了這一點。 他說，當他和其他 16 位雪鳥會議上的夥伴第一次寫下宣言時，根本沒有真正的處方。

因此，即使宣言中沒有告訴你如何應用價值觀，[00:16:00] 我猜想你已經對大概會發生什麼，還有人們會怎麼做有一些大概的思路了。

Dave Thomas: 老實說啊，我還真沒有。

Saron Yitbarek: 聽到這裡，你可能會感到驚訝。因為敏捷現在看起來很有說服力。有書籍、認證、工具、課程和產品的整個市場，向你展示如何“實現敏捷”。

Dave Thomas 表示，儘管有成千上萬的手冊和專業人士想要向你展示一種真正的方式，他們卻錯過了重點。

Dave Thomas: 實際上它是一組價值觀。

Saron Yitbarek: [00:16:30] 嗯嗯（肯定的語氣）。

Dave Thomas: 我想這就像黃金法則。你知道，如果你要做一些邪惡和惡毒的事情，你會想，“好吧，如果有人這樣做，我又怎麼會喜歡。”你知道嗎？黃金法則仍然適用。

好吧，敏捷宣言也是如此。它並沒有告訴你該做什麼，不該做什麼，它只是告訴你如何評估你做的是否與這種做事方式一致。

Saron Yitbarek: [00:17:00] 是的。我想只要回到敏捷軟件開發宣言的名稱、真正脫穎而出並且經久不衰的一個詞，也是人們真正關注的就是“敏捷”。那麼現在使用“敏捷”這個詞又出了什麼問題呢？

Dave Thomas: [00:17:30] “敏捷”這個詞的問題在於，在我們提出的標題中，它是描述軟件開發的形容詞。但接下來發生的事情就是人們說：“我該怎麼著手敏捷呢？”

突然之間，好像就“木工活”而言，湧出了一大批諮詢顧問，他們看到了 極限編程(Extreme Programming)（XP）的成功，看到了宣言的成功，說：“嘿，那裡有座金山。” 然後就開始告訴人們如何“做敏捷”。[00:18:00] 這是一個問題，因為你不能“做”敏捷。敏捷不是你要“做”的事情，而是你如何做事情的方式。

然而，有些公司會樂意在盒子裡賣給你敏捷的東西。我覺得這很諷刺。這裡的諮詢就好像是進入一家財富 1000 強企業，然後幫助他們設定“敏捷”。然後帶走了 500 萬美元。你懂嗎？ 太棒了，錢真好賺。

[00:18:30] 但是，現實情況是，這就像告訴要老虎敏捷一樣，說：“先走七步，然後左腳邁出來，然後再走兩步，然後邁出右腳。”嗯，實際上只有瞪羚做同樣的事情才會有用的。你猜怎麼著？沒有人告訴瞪羚這樣敏捷。瞪羚基本都會跑到地平線的盡頭上大笑起來，因為老虎在“邯鄲學步”。

[00:19:00] 當你告訴團隊如何敏捷時，會發生同樣的事情。如果你對他們說，“這是你必須遵循的規則，這是你必須遵循的過程”，然後他們擁有的最後一件事就是責任，因為他們已被設定好該執行的程序。管理層將根據他們遵循這些原則或那些程序的程度來判斷表現。不是他們開發軟件的水平如何。

Saron Yitbarek: [00:19:30] 所以，回顧一下，宣言之前的開發者的角色，與之後開發者的角色，是如何改變或擴展的呢？

Dave Thomas: 值得肯定的是，我認為那裡的大多數程序員都能理解到關鍵點。我覺得敏捷宣言已經授權許多開發人員開始遵循這樣的做法，這些方法在某種程度上是他們知道並且應該做的，但他們從來沒有真正有權利這樣做。[00:20:00] 像測試這樣的事情，例如收集反饋，諸如縮短迭代週期之類的事情。因此，在許多方面，工作變得更有趣，更充實。

同時我認為，程序員也可能會感到有點害怕，因為現在他們有了責任。過去，他們只是遵循命令。為什麼這個程序不起作用？ 好吧，我遵循了規範。而如今，你肩負著責任。

[00:20:30] 所以，我覺得工作因敏捷宣言而有所成長。我認為人們開始意識到他們對自己所開發東西負有點對點的責任。

Saron Yitbarek: 敏捷取得了如此廣泛得成功，改變了工作流程和態度，遠遠超出了開發者世界的範疇——當然也超越了雪鳥會議召開的小木屋。 我們不禁要問，[00:21:00] “相比於 2001 年撰寫宣言時，今天成為敏捷開發人員意味著什麼？”

最初的敏捷精神是否仍然存在？如果確實發生了變化，這是一件壞事嗎？對於谷歌的多元化業務合作伙伴 Ruha Devanesan 來說，敏捷的思維方式可能已經發展到現在正在影響公平性和工作場所基本的平等。

Ruha Devanesan: [00:21:30] 使團隊具有包容性的部分原因是能夠評估和反思如何在一個非常基礎的層面上一起工作。大多數團隊，當他們一起工作時，沒有足夠的空間這麼做。沒有足夠的空間停下來思考他們的團隊動力，這就關乎到每個人是否在能桌上發表意見，關於是否有人在推動其他人，或者是否有人在整個時間都保持沉默。如果他們保持沉默，為什麼他們保持沉默？

因此，在考慮包容性時，[00:22:00] 我認為敏捷團隊使用的一些工具在為團隊提供結構或更具包容性的框架方面非常有用。所以多樣性不僅在性別、種族方面，而且在功能多樣性方面。功能多樣性為團隊帶來了複雜性。

Saron Yitbarek: 但是，要讓我們在這裡就做出區分。Ruha 並不是說敏捷就等於多樣性。 她的意思是，“敏捷加多樣性等於更好的團隊。”[00:22:30] Ruha 的想法在她寫的一篇名為《論通過敏捷方法解鎖多樣性》的文章中得到了體現。我們將在演示筆記中添加一個鏈接，這可是值得一讀的。

在這篇文章中，她會引導你去了解多元化不僅僅是人力資源部門一直在談論的模糊概念。這實際上是一個強大的商業案例。通過利用敏捷工具有意創建一個包容性的工作場所，可以提高創新率。多樣性可以與敏捷相吻合。

Ruha Devanesan: [00:23:00] 因此，給最終的目標帶來了複雜性，從不同的角度獲得結果或產品。當我們說為團隊增加多樣性可以帶來更好的結果，帶來更多的創新和更多的創造力時，我們持有的是同樣的基本觀點，因為當你有多個角度去看待問題、協作解決工作問題時，你更有可能得出一個更好結果。

Saron Yitbarek: [00:23:30] 甚至像日常會議這樣簡單的事情，團隊中的每個人都可以提出反饋，這會讓內向的人或其他不愛說話的人發表自己的見解。

Ruha Devanesan: 我真正喜歡敏捷的原因是有一些內置的機制來幫助團隊停下來思考。這可能是因為敏捷是如此之快，並且有兩週的衝刺任務，如果你沒有建立這些機制，你可能會偏離軌道而沒有意識再回到正軌。

[00:24:00] 但是，我覺得，“停止並反映”這種價值非常重要。這對於包容非常重要，因為只考慮我們如何一起工作，我們如何才能不斷改善，這是團隊能夠包容的基本方式之一。

Saron Yitbarek: 既然我們談論的是包容性，現在可能是指出那些敏捷宣言的 17 位創始人的好時機，是的……他們都是白人。

Dave Thomas: [00:24:30] 實際上那個房間沒有多樣性。這是對該組織的一種非常普遍的批評。而且我對此深表同情。

Saron Yitbarek: 如果敏捷宣言創始人採用了這些敏捷原則，並將其應用於他們自己的會議，那麼他們可能在完成部分工作後，會問他們自己……“嘿，你注意到我們沒有邀請任何女性參加這次會議嗎？”我在想會不會有一個有色人種會持有不同意見。

Ruha Devanesan: [00:25:00] 物以類聚，人以群分。所以，如果考慮敏捷宣言的第一個人是白人，他邀請到桌上的人也是白人也就不足為奇了。但是，我們有機會在那方面做得更好，我們有機會停下來說：“讓我們退後一步，讓我們擴大我們的鏡頭，尋找我現在擁有的關係網絡之外的人，誰可以帶來不同的視角並幫助我們將這種方法改進到更好的狀態。”

Saron Yitbarek: [00:25:30] 對我來說這是有道理的，因為敏捷正是如此……好吧，敏捷，我們可以將它應用於不同的問題和行業。敏捷的應用，以及其在現實生活中出現時候的樣子，是不斷變化、不斷擴展的。我想它正在將宣揚的內容付諸實踐。沒有更微妙的答案，沒有更微妙的終點。這是我們有時會忘記的事情：硬規則是敏捷的敵人。

因此，如果一個敏捷團隊告訴你敏捷的一部分意味著你必須每兩週開發一個新的版本，[00:26:00] 或者你必須這樣做，那麼，根據定義，這可不是敏捷。你老是說“總是”，你也不再是敏捷了。

那些在猶他州雪鳥會議碰面的 17 名男子，最後宣稱自己是敏捷聯盟。該聯盟成為一個非營利組織，每年都舉辦一次會議。[00:26:30] 這個聯盟的的成長和發展，催生了更多全新的理論和方法。

這正是我感覺非常有趣的東西。在 2008 年的會議上，比利時開發人員 Patrick Debois 參加了並開始引領一條道路，他發明了一種全新的軟件開發實踐 DevOps。我從未想到敏捷，一系列原則、DevOps 和整個行業是緊密相關的。

但是，現在我在想，“敏捷的興起與 DevOps 的發明之間聯繫有多少？[00:27:00] 一個突破是否有機地孕育了另一個突破？”我們會一起去探索，因為我們的下一集是正是 DevOps，對！一整集的內容。

《代碼英雄》是紅帽的原創播客。有關我們的播客和其他更多信息，請訪問 RedHat.com/CommandLineHeroes 。在那裡，你也可以關注我們的消息訂閱。[00:27:30] 想要免費聽取最新內容，請訂閱我們的節目。也可以在 Apple Podcast、Spotify、 Google Play、CastBox 中搜索 “Command Line Heroes”，然後點擊“訂閱”，你將在第一時間獲得我們的內容更新。

我是 Saron Yitbarek，感謝收聽，繼續編碼。