[重製版]《代碼英雄》第一季（3）：敏捷革命

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

現在是 21 世紀之交，開源軟體正在改變著科技的格局，現在已經需要一種新的工作模式了。開發者們在尋找一種革命性的方法，讓開源開發蓬勃發展。一群開發者在猶他州的一個滑雪場召開了會議，形成的是一份改變一切的宣言。

《 敏捷軟體開發宣言 Manifesto for Agile Software Development 》的作者之一 戴夫·托馬斯 Dave Thomas 將我們帶回了那個現在著名的靜修之地，敏捷革命就是在那裡第一次組織起來的。不過，並不是每個人都那麼快就簽下了這種新方法，在這一集里，我們聽聽原因。

Saron Yitbarek： 有些故事的走向和結局會重新定義一個行業。在這些故事中也傳唱著，我們來自哪裡，我們是誰，我們正在做什麼。上一集中，我們追溯了 Linux ^® 開源技術的崛起。但這一集我要講的，是緊接著發生的故事。操作系統之戰結束後，開發者們成為了戰爭爭奪的對象和核心。

00:00:30： 在那個新的戰場，開發者們將要重塑自己的工作。本集播客，我們將深入了解以開發人員為核心，產生的一種全新的軟體開發方法論。這種新穎的工作流程產生了哪些遠超我們屏幕上顯示的代碼所能控制的、意想不到的事情。

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

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

00:01:30 - Saron Yitbarek： 剛才提到的這群人都是開源開發人員，所以保持開放是他們的特點。Dave Thomas 和其他的 16 個人，在那個冬天集聚在雪鳥滑雪場。但是他們的目的並不是滑雪，而是探討在 90 年代開發者的世界所面臨的問題。在這裡我用「探討」，但實際上用「辯論」更準確。他們最初是在 面向對象編程、語言及系統 Object-Oriented Programming, Languages and Systems （OOPSLA）的會議上認識的，這個會議主要議題是面向對象程序設計、編程、語言和系統。

00:02:00： 實際上正是那次會議，讓他們意識到當前的軟體開發方式很混亂，只是對於該怎麼辦沒有達成一致。

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

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

Saron Yitbarek： 我有。

00:02:30 - Dave Thomas： ……好。如果我先告訴你，「我想讓你坐下來，然後給你一張白紙。接著我希望你能描繪下來這個房間完成後大概的樣子。」可以想像嗎？

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

Dave Thomas： 你能做到嗎？

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

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

00:03:00 -Dave Thomas： 遇到未知的情況，你總需要一種「迭代」的方式去應對。人類的大腦無法準確地對現實世界的發展進行預判，從而提前預知哪裡需要改變。所以，軟體開發也是一樣的，人們不知道他們的需求會怎麼改變。對嗎？

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

00:03:30 - Dave Thomas： 我經歷過太多這樣的情況，當我從客戶那裡拿到了詳細的要求，然後我已經很好地完成了每一條細則，但卻總是吵得不歡而散。「這不是我們想要的。」 但我想說的是，「這就是你要求的啊。」他們說，「是的，但這不是我的意思。」你懂這種情況嗎？

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

Dave Thomas： 所以說，理想情況是，你可以詳細說明流程的每一步，然後通過非常機械的步驟就可以完成一切。

Saron Yitbarek： 是啊。

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

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

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

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

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

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

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

00:06:30： 與此同時，工作都堆積在「冰盒」和「沙盒」中。好吧，聽起來感覺流程很多。但一開始的時候是沒有這些流程的。撰寫該敏捷宣言的人,目標是簡單和清晰。實際上，簡單是它制勝的法寶。從那時起，它就具有定義幾乎每個開發人員命運之路的能力。

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

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

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

00:07:30： 我記得第一次看到這個宣言時的情形。我剛開始學習編程，老實說，當時我並沒有覺得這個想法有多棒。一直到我了解到那些支持敏捷開發的工具和平台。對我來說，這只是一些模糊的概念。但是，對於長期以來一直被這些問題糾纏的開發人員來說，這是一個很好的行動方案。

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

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

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

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

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

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

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

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

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

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

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

Saron Yitbarek： 對於 Rakitin 來說，這不僅僅是提出新的工作流程創意。這也關乎到他職業生涯的清白聲譽。

00:11:00 - Steve Rakitin： 長期以來，相比於電氣工程和所有其他工程學科，軟體工程並未被視為正規的工程學科。在我看來，部分原因是因為普遍缺乏軟體工程師認可的公認實踐。

00:11:30： 當我們經歷了 90 年代的十年，逐漸開始明晰其中的一些流程。似乎其中一些已經在事實上被實施，而且也很合理。

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

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

Darrell Rigby： 我想我們在採用敏捷開發中，受到的最大阻力來自中高級管理層。

00:12:30 - Saron Yitbarek： 這位是 Bain＆Company 的合伙人 Darrell Rigby。他們一直嘗試在軟體開發公司中推行敏捷開發。不僅如此，還包括產品開發、新聞服務開發、廣告計劃和忠誠度計劃等。不管他們要做什麼，項目管理者都會面臨點壓力。

Darrell Rigby： 敏捷改變了他們的價值，因為他們正在逐步退出細節上的管理或干預。現在團隊被賦予權力，對他們加以指導。

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

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

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

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

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

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

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

Darrell Rigby： 我不一定每天早上都和家人坐在一起，和他們一起參加敏捷開發式的會議。但是，我已經非常擅長為我要做的事情排優先順序。

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

00:16:00： 因此，即使宣言中沒有告訴你如何應用這些條例，我猜想你已經對大概會發生什麼，還有人們會怎麼做，有一些大概的思路了吧？

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

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

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

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

00:16:30 - Saron Yitbarek： 嗯嗯（肯定的語氣）。

Dave Thomas： 我想這就像黃金法則。你知道，如果你要做一些邪惡惡毒的事情，你會想，「好吧，如果有人這樣做，我又怎麼會喜歡。」你知道嗎，這種場合也適合用黃金法則。

好吧，敏捷宣言也是如此。它並沒有告訴你該做什麼，不該做什麼，它只是告訴你，你做的一切是否符合這個價值觀。

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

00:17:30 - Dave Thomas： 「敏捷」這個詞的問題在於，在我們剛開始提出的時候，它是描述軟體開發的形容詞。但接下來人們就產生了疑問：「我該怎麼著手實施敏捷呢？」

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

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

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

00:19:00： 當你告訴團隊如何敏捷時，會發生同樣的事情。如果你對他們說，「這是你必須遵循的規則，這是你必須遵循的流程」，然後他們唯一能做的就是跟隨職責，因為他們已被設定好該執行的程序。管理層將根據他們服從原則或程序的程度，而不是開發軟體的水平來判斷表現如何。

00:19:30 - Saron Yitbarek： 所以，回顧一下，宣言發布之前和之後的開發者的角色，是如何因為你的宣言本身改變或擴展的呢？

00:20:00 - Dave Thomas：我認為大多數程序員都能理解到關鍵點，這值得肯定。我覺得敏捷宣言給了許多開發人員按照這種方法去做的授權，某種程度上是他們以前就知道該如何，但從來沒有權利這樣做。像測試收集反饋，縮短迭代周期之類的事情。因此，在許多方面，工作變得更有趣，更充實。

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

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

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

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

00:21:30 - Ruha Devanesan：讓團隊具有包容性的部分原因，是他們在進行非常基礎的工作時，可以評價和反思自己。當大多數團隊一起工作時，他們沒有足夠的時間這麼做。沒有足夠的動力停下來思考他們團隊宗旨，是否每個人都在能桌上發表意見，關於是否有人在推動其他人，或者是否有人在一直都保持沉默。如果他們保持沉默，為什麼他們保持沉默？

00:22:00： 因此，在考慮包容性時，我認為敏捷團隊使用的一些工具在為團隊創建架構，或更具包容性的框架方面非常有用。所以多樣性包括性別、種族，還有功能多樣性。功能多樣性為團隊帶來了複雜性。

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

在這篇文章中，她會引導你去了解，多元化不僅僅是人力資源部門一直在談論的模糊概念。這裡提供了一個強有力的商業案例。利用敏捷工具，可以創建一個包容性的工作場所，和創新效率提升。多樣性可以與敏捷相輔相成。

00:23:00 - Ruha Devanesan： 這篇介紹複雜性的文章，最終目的是讓大家從不同的角度看待你的結果或產品。當我們說為團隊增加多樣性可以帶來更好的結果，帶來更多的創新和創造力時，我們持有的是基本同樣的觀點。因為當你從多個角度去看待並協作解決工作中的問題時，你更有可能得出一個更好的結果。

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

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

00:24:00： 但是，我覺得，「停止並反饋」這種價值觀非常重要。這對於團隊的包容性增加也非常重要，因為讓大家都能提出工作反饋，並藉此不斷改善，這是團隊能夠包容的基本表現。

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

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

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

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

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

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

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

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

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

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

我是 Saron Yitbarek，感謝收聽，請堅持編程。

什麼是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特別興趣小組 Special Interest Group ，LCTT SIG 是針對特定領域、特定內容的翻譯小組，翻譯組成員將遵循 LCTT 流程和規範，參與翻譯，並獲得相應的獎勵。LCRH SIG 是 LCTT 聯合紅帽（Red Hat）發起的 SIG，當前專註任務是《代碼英雄》系列播客的腳本漢化，已有數十位貢獻者加入。敬請每周三、周五期待經過我們精心翻譯、校對和發布的譯文。

歡迎加入 LCRH SIG 一同參與貢獻，並領取紅帽（Red Hat）和我們聯合頒發的專屬貢獻者證書。

關於重製版

本系列第一季的前三篇我們已經發布過，這次根據新的 SIG 規範重新修訂發布。

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

作者：RedHat 選題：bestony 譯者：redhat 校對：acyanbird

本文由 LCRH 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive