為什麼開發者應該摒棄敏捷？

企業的快樂

當然，很多，或者甚至大部分這些產品都不是壞事，至少對於企業是這樣的。嘗試改進的組織通常確實可以得到改善，而且即使“敏捷”思路應用不當，嘗試的過程仍然會為組織帶來一些好處。組織至少可以更好地瞭解正在發生的事情，而這往往會使得即使是最不明智的管理層也能夠做出更好的決策。很好，企業方面表示完全贊成。

開發者的痛苦

對於開發人員來說，這畫面就沒有那麼美了，所有實際參與過構建“敏捷”企業產品的人員皆是心有慼慼然。“敏捷”理念的應用不良，往往會對開發者產生更多的干擾，使得他們用於工作的時間更少，壓力更大，需求“更快”。這對開發人員來說是不利的，回過頭來最終也會對企業造成不利的影響，因為拙劣的“敏捷”會導致更多的缺陷和更慢的進展。通常而言，優秀的開發人員會選擇離開這樣的組織，從而導致企業效率比之前還沒裝備“敏捷”時更低。

safe而非SAFe

這一條源自Kent Beck在十多年前所說的話。我希望這個世界對開發者來說是safe的。儘管歷經多年的管理、諮詢和寫作工作，但我的本質依然是開發人員。今天早些時候我就在寫程式碼，哪怕不是每天，至少每週我都會寫程式碼。因此，在《Agile Manifesto》中看到“這會使得開發者的生活變得更糟而不是更好”的觀點時，著實讓我傷心了一把。雖然企業沒有從中得到什麼也讓我感到難過，但我主要關心的是開發人員。

在過去的幾年中，我聽到許多開發人員在說“敏捷很糟糕”。而我則幫助那些人理解原因在於他們的組織使用的“敏捷方法”是錯誤的：企業沒有做到Manifesto作者推薦的內容、沒有做到Scrum建議的內容、或者沒有做到許多敏捷軟體開發專家推薦的內容。我希望聽到我的解釋之後，這些人可以幫助自己和他們的組織接近Manifesto Agile背後的真實想法，遠離我們周圍所見的各種形式的Faux Agile或Dark Agile。

這並不真正解決問題。雖然諸如“高階”Scrum培訓和認證，以及以領導為中心的努力也挺不錯，並且可能會隨著時間的推移而獲得成果，但進展緩慢，並且可能永遠不會真正過濾掉“堆積如山的程式碼” 。

現在是時候接受新的觀念了，那就是：

開發人員應摒棄“敏捷”

請注意，開發人員將繼續在Scrum條件下或在使用SAFe的組織中工作。有些甚至可能會遇到像“DAD”這樣更為晦澀的“敏捷”方法，或者如果幸運的話，採用的是更為開明的方法，如“Modern Agile”或“Heart of Agile”。有些人甚至可能足夠幸運到發現自己正在進行極限程式設計，也被稱為“The Scrum That Actually Works”。

能抓老鼠的才是好貓

儘管如此，我認為開發人員應該從任何特定的所謂的“敏捷”方法中解放他們的思想。不管它叫“黑貓”還是“白貓”，能抓老鼠的才是好貓。他們應該將他們的注意力和學習方向轉向可以在任何這些“敏捷”方法中工作的軟體開發方法。對我而言，開發方法涉及極限程式設計的使用實踐，但不限於此。更一般地說，開發人員的工作應該堅持支援敏捷軟體開發的基本原則，正如我們在編寫Manifesto時所考慮的那樣。這就是我們這篇文章的中心思想。

無論管理層認為他們正在應用什麼框架或方法，學會以這種方式工作：

• 每兩週生產一次可執行的、經過測試的、可工作的、整合的軟體，然後每週生產一次。學習技能直到你可以每天建立一個全新的完全可操作的版本，然後一天兩次，甚至一天多次。
• 保持軟體的設計簡潔。隨著它的發展，設計將趨於複雜和笨拙。始終要有意識地抵制和扭轉這種趨勢，始終以微小的連續步驟進行重構，以便你的進度可以儘可能的穩定和一致。
• 使用當前的軟體增量作為你與產品領導和管理人員進行對話的基礎。就準備好的事情以及他們希望你下一步做什麼來說明問題。

這是一個理智的開發團隊的最大希望。軟體的整裝待發，可以讓我們在最後期限內實現最佳結果。“今天是最後期限了？我們已經搞定了，隨時可以釋出。“

當我們接近截止日期時，當我們爭執接下來要做什麼時，我們手頭的軟體會讓我們將談話集中在下一個最重要的事情上，而不是天馬行空。將重點從“做所有這些”轉變為“接下來做什麼”並不容易，但這會讓我們的生活變得更容易，而且也使得改變的可能性更大，因為我們是與領導者合作而不僅僅是在他們的指揮下工作。

人在江湖

通常情況下，團隊使用的“敏捷”方法往往是強制的。實際上大規模的“敏捷”方法似乎就是建議強制的。這裡包括所謂的“SAFe”方法、Scaled Scrum和LeSS等等。這些方法進入到企業，就像蝴蝶的翅膀，引發了一場龍捲風。

作為開發人員，你可以肯定的是，這樣推出方法是不會順利的，也沒有以一種真正的敏捷方式進行。你不可能接受培訓，得到的教導微乎其微，更不用說提供的真正可用於完成工作的幫助了。可能你的領導已經接受過培訓，甚至用了整整一週時間，以便於他們可以準備好面對組織生產方法和軟體開發中出現的徹底改變。總而言之，道路是崎嶇的。

現實軟體是你唯一的救贖。——Leia

但是，如果你可以可靠地選擇在“Sprint”或“boxcar”的過程中完成工作，或者無論你釋出什麼，列車售票員都開始呼叫時間段並完成該工作，將其打包為可執行，已測試，已整合，即將推出的新系統版本，那麼你將能盡最大努力實現這個目標。

放慢交付速度

如果你不能很好地解決這個問題，那麼我建議你在每個時間段內減少工作量，直到工作批次足夠小到你實際能夠完成。這很難！總是會有人死命地催你“跑快點”。盡你所能吧！在壓力下籤署超出能力範圍的工作量，我的建議是從事一兩項工作，直到完全完成——完全打包、經過測試和可工作——然後再做另一項工作，以便在boxcar的最後你有絕對可以稱之為“完工”的內容。不要採取廣撒網的策略，以免最後反而一事無成，嘗試從現實出發來制定計劃和期望，不要幻想那些雖然是要求的但從來沒有機會做的事情。

這個過程肯定不是完美的，至少一段時間內如此，甚至可能也不會很有趣。然而，這是我知道的在程式碼山中生存下來的最好機會。擁有完成的可執行的產品片段是我知道可能改變程式碼山這種狀況的最佳方式。在糟糕的情況下，我們所能做的就是盡我們所能，努力讓事情往好的方面發展。

顯然，在一個更開明的組織中，或在一個保持學習的組織中，事物才會越來越接納真正的Manifesto敏捷思想。我們的編碼生活將得以改善，這正是我的期盼。

我一直處於這樣的處境中，除了離開之外，我所知道的最好的就是做好工作，讓軟體保持可見，可執行，經受得住測試和整合，並幫助人們實現現實事務。

選擇一種方法

Manifesto呼籲“自組織的”團隊，最好的情況就是，團隊選擇適合自己的流程。如果我創辦一家公司，那就讓團隊自己選擇他們想要的流程。

要求結果，而不是特定的過程

然而，這是有限制條件的，限制不在於他們如何選擇工作，而在於我需要看到結果。我會清楚地說明，至多每兩週，我會回顧他們正在執行的測試產品的片段。他們會展示給我看他們計劃構建什麼，以及他們已經構建好了什麼。這樣的要求使得他們不得不實實在在地致力於工作，幷包含我可以理解的可見功能。我們會談論他們在下一個時間段應該做什麼。我會清楚地說明一週回顧一次優於兩週回顧一次，一天回顧一次優於一週回顧一次。

提供幫助

我會為他們提供幫助。我會提供一個與業務需求緊密聯絡的人，他將幫助他們決定下一步要做哪些工作。我會提供培訓和支援，以幫助他們需要完成的工作。我會確保他們有能力做我要求他們做的事情。

當然，我會這樣做是因為我知道怎麼做。如果你夠幸運的話，可能正處於與此類似的情況中——至少可以選擇自己的流程。

看我極限程式設計！

如果你有機會選擇，我建議你從極限程式設計開始。它包含所有你需要的規劃和反饋迴圈，包含完成我們在此討論的那些基本技術實踐，幫助完成我所要求的工作。

建議隨時保持警惕，注意你所需的其他東西。 “ATDD，TDD和重構”就是我認為需要注意的東西，當然可能你知道更好的。但是，你還需要許許多多其他的東西。保持警惕，以便於可以隨時識別並獲取。

製作出卓越的軟體是一項終身的活動。即使是極限程式設計——我所知道的最好的官方命名的方法——我也只是略懂皮毛而已。走向卓越取決於你的團隊及其成員。

總結

我真的認為軟體開發人員不應該遵守任何型別的“敏捷”方法。因為這些方法體現在實際中時通常是軟體開發的敵人，而不是朋友。

然而，敏捷軟體開發宣言的價值和原則仍然提供了我所知道的構建軟體的最佳方式，並且根據我資深又豐富多彩的經驗，無論大型組織使用何種方法，我都會遵循這些價值觀和原則。