2018年敏捷軟體的現況

這是我在2018年墨爾本敏捷澳大利亞大會上的演講的轉錄。我當時即興演講，只有大綱指導我。我已經編輯了這段文字，使其讀起來不那麼雜亂，同時保持了演講的脈絡。您可以在InfoQ找到演講的影片。

有多少人以前在澳大利亞敏捷大會上聽過我講話？你竟然回來了？哇，我印象深刻。如果你以前在澳大利亞敏捷大會上聽過我講話，或者在任何一個會議上聽過我講話，你就知道，我幾乎每次演講都會取個模糊的題目，像是“21世紀的軟體設計”，或者類似的：因為這是一個模糊的標題，我可以談論我喜歡的任何事情。我本來也打算在這裡再次這樣做，但我決定我要做一些具體的事情：談談我們所處的地方：2018年的敏捷社區。我決定我不要做一個特別深入計劃的演講，不要有很多幻燈片和巧妙的圖表和漂亮的轉場 - 只是我自言自語。我以前做過這樣的事情，但已經有一段時間了，所以我們將看看我們的表現如何。

當我們看敏捷的狀態時：在很多方面，在某種表面層次上，情況看起來非常好。我的意思是，看看這個人群的規模，舉例來說，我們是巨大的，我們在這個大會場中容納下來 - 實際上並不是很好地容納，因為外面相當擁擠。你去各種地方，你都能看到散佈的敏捷。有人給我寄了一張《哈佛商業評論》封面，上面寫著“敏捷”。我的意思是，它無處不在。這是從10年前的這裡，甚至更久遠的地方，當我們在那個滑雪場在Snowbird討論我們應該叫什麼的時候，發生了一個巨大的轉變。這聽起來像是成功，但你跟很多老一輩的敏捷主義者談過話，那些在90年代末被稱為“敏捷”之前就在做這件事情的人，他們實際上有很多不安，很多失望，空氣中有很多不快樂的情緒。

這實際上並不罕見，因為就我所知，這幾乎整個時間都是這樣[1]。這實際上是一件好事，因為這種不滿是想要改善的一個標誌。但它確實引起了一種“我們為什麼要奮鬥”的感覺？

我們現在所面臨的主要挑戰是什麼？ 十年前，挑戰是人們是否認真對待敏捷。 我記得進入澳大利亞的一家大型Thoughtworks客戶。 他們希望我給他們像往常一樣的“Martin Fowler來給我們講講”的例行公事。 客戶中的某人說：“是的，我們希望你談談你喜歡的任何事情，但不要說敏捷相關的事情。” 當時我在2000年代中期大量談論敏捷，但那時的感覺是這是一種有點不好的東西，你不想談論它。

現在，敏捷無處不在，它很受歡迎，但有了重要的轉變。 我的一位同事很好地總結了這一點，他說：“在過去，當我們談論進行敏捷時，客戶總是從一開始就反對，這將帶出一些重要的對話。現在，他們說，'哦，是的，我們已經在做敏捷了'，但你進去後突然發現，我們預期的事情與現實有很大的差異。作為Thoughtworks，我們認為自己對敏捷的概念非常深入，但我們去了一家公司，他們說，“是的，我們在做敏捷，沒問題”，但我們發現與我們預期的完全不同。

我們目前的挑戰不是讓敏捷成為人們想做的事情，而是應對我所謂的偽敏捷：僅僅是名義上的敏捷，但沒有實踐和價值觀。 Ron Jeffries經常稱之為“Dark Agile”，或者具體地說是“Dark Scrum”。 這甚至比假裝做敏捷更糟糕，它是在積極地將“敏捷”這個名字用來反對我們在90年代末和Snowbird討論這類工作時所嘗試做的基本原則。

這就是我們目前的挑戰。這不是關於使敏捷變得足夠受尊重以至於像這樣的人群會來參加這樣的會議，而是要意識到人們所做的並且稱之為敏捷的許多事情，實際上並不是。我們必須認識到這一點，並與之抗爭，因為有些人曾說過，“哦，我們要進入‘後敏捷’時代，我們必須想出一個新詞”，但這並不能解決根本性問題。重要的是價值觀和原則，我們必須解決這些問題並不斷推進，我們也許最好使用相同的標籤，但我們必須讓人們知道它真正代表的是什麼。[2]

如果這是問題的廣泛層面，我們該如何專注於特定事項呢？我想聚焦於三個我認為最值得關注的主要問題領域。

這其中的第一個就是我將其稱為敏捷產業複雜性。公平地說，我也是其中一員，對吧？我站在這裡的舞台上談論敏捷，實際上我們都在某種程度上參與其中，我們中的許多人都是某種敏捷諮詢公司的一部分，可能在名稱中帶有敏捷。但是，很多被推動的事情都以一種，正如我所說，與我們的許多原則完全相反的方式被推動。

特別是，令我印象深刻的是早期敏捷倡導者之一的一個真正核心的事情，那就是他們意識到，人們在最佳狀態時是在自己選擇的方式下進行工作。

當我們談論敏捷宣言，並列出四個價值聲明時，對於其中大多數價值聲明，我們並不太在意它們的排列順序。但我們對第一個價值聲明有自己的看法：“個人和互動優於流程和工具”。對我來說，這概括了敏捷思維的一個非常重要的部分。如果你想在軟件開發方面取得成功，你需要找到優秀的人才。你需要找到在人際層面上能夠有效協作的優秀人才。他們使用什麼工具或遵循什麼流程的選擇是次要的。我認為，這是一個非常重要的聲明，來自於基本上是一群流程狂的聚會。我的意思是，我們在某種程度上都是流程人員，然而我們承認我們所談論的實際上是次要的。重要的是團隊選擇自己的路徑。

對於團隊來說，這不僅僅是選擇他們所遵循的過程，而且應該積極鼓勵他們繼續演進並在過程中進行變更。任何一種敏捷過程或敏捷方法的特點是它本質上是非常靈活的。它每週都在變化，每月都在變化。我曾經向人們炫耀的其中一句話是，“如果你正在以一年前的方式進行極限編程，那麼你已經不再在做極限編程了”。因為如果你不主動承擔責任，不根據情況進行調整，那麼你就錯過了其中的關鍵部分。我們可以設置各種各樣的儀式和事物來使這個工作，而回顧顯然是許多人認為非常核心的一個技術。事實上，我認為Ron Jeffries開玩笑說Allistair Cockburn對敏捷的方法是“和平共處，每週交付軟件，每次進行回顧以找出如何改進”。回顧實際上是實踐的一個非常核心的部分。

現在，實際上是否有正式的回顧並不重要。你是否在你的回顧看板上有四五個標籤，或者你如何進行回顧也不重要。重要的是思考我們正在做的事情以及我們如何做得更好的概念，而這正是正在從事工作的團隊所做的，這是最重要的事情。

這是對整個Frederick Taylor，對分開工序的人的一種反應。這裡有多少人知道Frederick Taylor及其方法的故事？[有些人舉手]有多少人聽過Frederick Taylor這個名字，甚至聽說過？更多人舉手了。更多的你們應該舉手。他可能是20世紀歷史上最重要的人物之一，因為他實際上如何影響了人們的日常生活。他來自19世紀末的美國，他非常有興趣試圖使正在發展的工業工作場所中的人們更有效率。他對普通工人的看法是，他們懶惰、貪婪和愚蠢。因此，你不希望他們決定如何製造特定的機械，而是其他人，一個更聰明和受過教育的人，他們應該找出最好的方法來做到這一點。甚至還要到底應該這樣做還是那樣做，或者應該那樣做然後這樣做。這是一種非常劇本化的運動和動作感。整個時間和動作行業就是由此而來。在這個概念的核心是做工作的人不應該決定如何做。應該是一個獨立的規劃組來做這個，而這強烈影響了20世紀初期的製造業和工廠工作。

它也影響了軟件行業-人們說，“我們需要軟件流程專家來找出如何做事情，然後程序員只需適應槽位”。但有趣的是，正當軟件人士在談論著如何跟隨這種非常泰勒主義的概念作為軟件開發的未來時（我在80年代和90年代聽到人們這樣說），製造業正在遠離它。在許多製造場所所發生的事情的整個概念是，做工作的人需要更多地參與其中，因為他們實際上看到了正在發生的事情。

敏捷運動是嘗試推動這一點的一部分，嘗試說：“參與工作的團隊應該決定如何完成它”，因為讓我們面對現實，我們在這裡談論的是軟件開發人員。人們得到了良好的薪水，良好的教育，希望如此，良好的動機，所以他們應該找出在他們特定情況下是必要的。

“特定情況”變得很重要，因為不同類型的軟件是不同的。我生活的大部分時間都是在企業應用程序中度過的：數據庫支持的GUI / Web前端世界。這是我認識的大多數人所做的，但這與設計電話交換機或設計嵌入式軟件是非常不同的。即使在我相對熟悉的世界中，不同的團隊也有不同的情況，我們有不同的遺留環境需要協調，我們有不同的團隊成員之間的動態。由於存在如此多的差異，我們怎麼能說有一種方法適合每個人？我們不能。但是我聽到的那麼多是敏捷工業複合體把方法強加給人們，對我來說這是絕對的悲劇。

我原本想說“悲劇”，但我認為“悲劇”是更好的詞，因為最終在軟體開發中並不存在一刀切的解決方案。即使是敏捷方法的擁護者也不會說，敏捷一定是在所有情況下都最好的方法。重點是，進行工作的團隊決定如何進行。這是一個基本的敏捷原則。這甚至意味著如果團隊不想以敏捷方式工作，那麼在那種情況下，敏捷可能不適用，而“[不使用敏捷]”可能是在某種奇怪扭曲的邏輯世界中他們能做事的最敏捷的方式。

所以這是第一個問題：敏捷工業複合體以及強加的做事的唯一最佳方式。這是我們必須反對的。

第二個問題是沒有認識到技術卓越對我們所做的事情的重要性。我參加的許多敏捷會議很少談論實際的軟體編寫技術。這裡有多少人是軟體開發人員呢？ [有幾個人舉手] 少數，但非常少數。同樣的問題在敏捷聯盟的主要會議上一直存在一段時間，但他們意識到他們得到了許多參與項目管理和其他相關領域的人，但實際上很少有真正做實際工作的技術人員。這實際上是相當悲劇的。它導致了更加悲劇性的事情，一些軟體開發人員說：“哦，我們需要為自己創建一個全新的世界。軟體工匠運動，我們可以遠離所有這些商業專家、專案經理和業務分析師，僅僅討論我們的技術問題。”但這是一件可怕的事情，因為敏捷的整個目的是跨越這些不同的領域。最低級的、最初級的JavaScript程序員應該與思考他們所工作的團體的業務問題和業務策略的人有聯繫。

關於這點，我會稍微多談一下我的第三點，但這意味著我們必須注意這些技術技能，並且我們必須考慮如何培養它們，如何促使它們成長，如何使它們變得重要？過去幾年，我一直將主要的寫作練習用於撰寫關於重構的新版本書籍。這裡有多少人聽過重構？[很多人舉手] 很好。有多少人能夠準確地向別人描述它？[舉手的人少一些] 相對較少。這是整個敏捷思維的核心技術，因為它符合我們可以輕鬆更改軟件的方式。當我向人們總結敏捷時，我通常會說它有兩個主要組成部分。一個是我已經談到的，團隊的首要性，以及團隊如何做事情的選擇，但另一個是我們能夠迅速變化的能力，能夠輕鬆應對變化。

我一直很喜歡瑪麗·波本迪克（Mary Poppendieck）的一句話：“對需求的晚期更改是競爭優勢。” 但要做到這一點，您需要設計出能夠對這種變化做出反應的軟件。重構對此至關重要，因為重構是一種紀律性的變更方式。現在，當有人在推特上發表類似以下的言論時，這是一件可怕的事情：“我現在正在重構我們的軟件，所以在接下來的兩個星期裡它將無法正常工作。” 噓 - 那不是重構。重構是小的變更，每個變更都使一切正常運作。它不會改變軟件的可觀察行為，這就是它的定義。我應該知道，因為我是那個得以定義它的人。

重構是許多小的變更，其中沒有一個會改變軟件的可觀察部分，但所有這些變更都會改變其內部結構。通常（重構）是因為您想要添加一些新功能，而當前的內部結構對於該新功能不太適合。因此，您更改結構以使新功能易於適應，同時不斷重構並不會破壞任何東西，然後您可以將其放入。肯特·貝克（Kent Beck）總結道。“當您想要進行更改時，首先使更改變得容易。 （警告，這可能很難。）然後進行簡單的更改”。這是使用重構的一種非常關鍵的方式，但它不僅如此，因為重構是一個持續的過程。您正在查看某些代碼，並試圖說：“這段代碼是做什麼的？我真的不明白這段代碼是做什麼的。讓我考慮一下。讓我們深入研究一下。啊，現在我明白這段代碼是做什麼的了。” 然後，在繼續之前，在 Ward Cunningham 的話中：“您將理解從您的頭腦中移出並將其放入代碼中。”：通過重組它，通過重新命名它。命名是所有這些的一個非常重要的部分。因此，下次您或其他人通過相同的代碼塊時，您就不必進行那個解謎的練習了。

對於每個所需的更改，使更改變得容易（警告：這可能很難），然後進行簡單的更改

-- Kent Beck

這為何重要？因為如果你想要做改變，你想要快速添加事物，你必須迅速了解程式的哪些部分是重要的，它們做什麼，以及我應該如何工作，以便我可以快速進行更改。這也與模組化有關。如果我有一個良好模組化的軟體片段，我不需要了解整個軟體，我只需要了解其中的一部分。技術上的卓越性在於能夠建立這種適應性軟體。

然後一個自我強化的原則出現了。一旦你意識到我可以快速改變軟體以添加新事物，我就不會嘗試在一開始就讓軟體做我想要的一切。因為我不需要。因為我以後可以改變事物。這就是Yagni原則 - "你不會需要它"。在你需要它們之前不要將功能添加到軟體中，因為如果這樣做，它會使軟體膨脹並使其更難理解。但是這種策略如果沒有良好的重構技術就完全是徒勞的。然後重構依賴於測試，而且重構也依賴於持續整合，以及持續整合，您將擁有持續交付的實踐，以及我們將能夠非常頻繁地發布軟體的概念。在某些組織中，我們實際上確實非常頻繁地發布軟體。

現在，有一個觀念認為，軟體的快速發布只有在你準備好忍受大量的錯誤時才能實現。如果你希望軟體可靠，你就要以更加緩慢、謹慎的方式進行。這是錯誤的。我們看到越來越多的證據積累，顯示這是非常錯誤的。我目前最喜歡的書籍是 "加速"，作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。這本書通過對組織的許多調查，展示了不同實踐如何影響事情。其中一個他們展示的事情是，每天發布多次和低缺陷率是相輔相成的。因為你無法每天發布多次，除非你找出如何降低缺陷率。這需要我們談論的那些實踐：自動化測試、重構、yagni - 所有這些都是相輔相成的。極限編程最重要的是，極限編程的各個實踐彼此加強。

我想要強調的第三件事是，要擺脫軟體項目的概念。相反，我們想要切換到一個產品導向的世界觀，而不是啟動一個項目、運行一段時間然後停止；你反而應該說， "讓我們專注於更加持久的事物，並組織一個產品團隊圍繞著它。" 另一種思考方式是：你的組織有哪些業務能力，然後組織團隊圍繞這些能力。這些業務能力將是長期存在的，必然意味著將技術人員和業務人員結合到同一個團隊中。

目前流行的觀念是亞馬遜的 "兩披薩團隊" - 人們經常談論這一點："將自己組織成兩披薩團隊。" 也許還帶有一點美國披薩真的非常大的笑話，所以他們可以是比你想像中更大的團隊。但當他們描述時，他們經常忽略了一點，這一點在我聽到亞馬遜的人談論時是清楚的；那就是每個團隊都需要與客戶保持聯繫 - 直接到底。每個團隊都專注於客戶體驗的某些方面，某些方面是 Kathy Sierra 所謂的 "讓客戶做得更好"。這改變了我們對這個小團隊的概念，因為如果這個小團隊專注於某個客戶體驗的部分，某種方式使客戶做得更好，那麼這告訴了我們該如何劃分我們的小團隊之間的界限。現在，這並不總是容易做到，但我認為這應該是主導的概念。

但我們常常看到這種情況被違反。我曾經去過一個據說是敏捷的組織。我當時正在和一個開發團隊聊天。那裡大概有半打程序員。他們正在開發的軟件只有四個用戶，他們是零售規劃的高級計劃者。六名開發人員，四名用戶。他們從來沒有互相交談過。他們不允許這樣做。相反，有一個 Scrum 產品負責人在他們之間進行對話。事實上，在一年的時間裡曾經有四個產品負責人。我是說，這是一個多麼可怕的敏捷世界，他們竟然敢使用“敏捷”這個詞來形容它呢？在[Snowbird]時，我們討論敏捷軟件開發的名稱時，Kent Beck 提出了“對話”這個詞，因為軟件開發人員、業務人員和任何參與改善客戶體驗的人之間應該有一個持續的對話。

如果我是開發團隊的一員，我希望能夠與所有用戶以名字相稱。我希望能夠交談。我希望能夠觀察他們的行為，我想要了解他們如何思考讓他們的客戶更加快樂的方式，並看到整個過程。所以我們需要思考這個問題。這是我的第三個挑戰。

所以我的三個挑戰是

• 擺脫敏捷工業複合體和對團隊強加事物的想法。讓團隊自行找出他們應該工作的方式。
• 提高技術卓越的重要性，永遠不要忘記，在編寫軟件時，技術方面非常重要，以及
• 圍繞產品進行組織.

所以這聽起來有點負面，因為我談到了當前敏捷狀態的問題。我還有兩分四十五秒的時間來解釋為什麼我對這種情況不太沮喪。這可能是我對整個敏捷宣言最喜歡的事情。這不是在 Snowbird 時寫的，而是大約六個月後在佛羅里達州坦帕市的OOPSLA上，大部分寫敏捷宣言的人與其他感興趣的人聚在一起。此時，敏捷宣言已經以我們無法想像的方式蓬勃發展起來。突然之間，清楚地看到有這個巨大的機會來做有趣的事情，許多人說，“我們需要建立一個真正的組織。”

其中一個問題是：“寫宣言的原始 17 人是否應該在這個持續的努力中擔任特殊角色？”我為之自豪的是，我們 17 位作者做的是，我們說“不”。我們寫了宣言。我們做了一項不錯的工作，我們將成為未來發展的一部分，但我們在未來沒有特殊的角色。那個角色必須向前發展。我們說“新的人會加入並做出偉大的事情”，這確實就是發生的事情。

這是重要的一點，特別是現在戴上 2018 年的眼鏡看待，是關於寫這份宣言的人有一個很大的問題。17 個人：17 位白人、中年的男士。[3] 沒有多樣性的痕跡，但因為我們放手，敏捷的世界可以吸納來自各種背景的許多人參與其中。Mary Poppendieck 是早期敏捷聯盟努力的重要領導者之一。Rebecca Parsons，我在 Thoughtworks 的老闆，長期擔任敏捷聯盟主席。我參加敏捷會議時，看到的女性比其他類型的軟件會議要多得多。這是一件好事。當然，這一切並不是我們一開始就在考慮的工作。但關鍵是：因為我們放手，我們最終得到了一個能夠自己發展事物的社區。能夠應對我們甚至沒有想到的挑戰並解決它們。而正是這種不斷學習、成長和變化作為一個社區，是我們最大的力量。

我不久前與一位後來者交流，他是敏捷世界的新手，他說他發現這個團體具有歡迎和開放的程度，而這在許多其他團體中並不真實。這讓我非常非常開心，因為只要我們能夠如此靈活，只要我們能夠不斷改變，那麼無論面對什麼挑戰，我認為我們都有未來。謝謝。

---