敏捷是落後保守的 — Dorian Taylor

本文《Agile as Trauma》指出敏捷的本質是反動的（reactionary：保守、落後、反動）。敏捷就像任何概念一樣，必須適應和學習，將產品管理和領域驅動設計的方法與敏捷相結合是我們今天所處的位置，但這種組合還沒有被命名。

原文點選標題：

敏捷宣言是程式設計師對不良管理的免疫反應。宣言檔案是受傷後的痛苦的表情，以及它的知識分子後代繼續揹負著這個包袱。雖然敏捷時代帶來了專案管理技術和開發工具的顯著進步，但它仍然是一個戰術性的、技術性的、最終是反動的運動。

敏捷誕生的上下文

為了開始癒合，把敏捷放在更廣闊的上下文環境中是很重要的。許多與敏捷相關的實質性思想早於它大約20到30年。這不是指控它剽竊，相反，這是一個斷言軟體開發有其特殊性，即使在技術和技術進步的情況下，這些模式也是不變的，因此您最終一定會重述這些模式。模式包括但不一定限於：

• 增量開發：軟體是在模組中建立的：就像書是由章節組成的，而章節是由部分，段落和句子，它們本身在程式碼中就像在文字中一樣逐字排列。基本結構不能組合成更大的結構，除非它們本身在內部是一致的，因此軟體的建立，就像任何語言製品一樣，是自然遞增的。
• 迭代開發：不要被混淆增量發展。軟體非常冗長，非常精確咒語資訊系統應該如何表現. 整個過程簡化為獲取資訊關於資訊系統並將其凝聚成正式語言—如果您繼續為其提供資源，這個過程永遠不會自然終止：您可以總是回去把你寫的東西和一些隨著時間的推移，重訪是規則。
• 跨職能團隊：由於軟體開發簡化為收集和集中資訊，很明顯，這些資訊將來自不同的來源，負責收集和集中資訊的人員將具有不同的專業知識。而且，程式設計本身就是一種準唯我論的活動。程式設計師要求,嚴格說來，不比小說家或畫家合作。因為軟體開發是自然遞增的，人們可以並行地在系統的不同部分上工作。這自然而然地讓程式設計師自己擁有各種各樣的專業知識。
• 固定時間，可變範圍：就像任何其他媒介中的內容開發一樣，軟體開發減少到消除熵。不像然而，其他媒體幾乎沒有其他的計數. 問題是你和/或你的團隊每單位時間只消除固定數量的熵，一開始你不知道問題中有多少位需要消除。你這麼說我們要工作了這很多，而這個過程的另一端產生的結果就是你得到的。在目前的理論中，有時在實踐中，這就是衝刺它們應該起作用，而不適合的物質會積累到一些積壓或者其他。
• 使用者參與：既然軟體的目的是為使用者服務，那麼使用者構成了一個重要的資訊源，包括他們與原型的互動，以及作為被稱為最小可行產品.

敏捷錯在哪裡

20年來，敏捷為我們提供了站立會議、sprint、結對程式設計、使用者故事、DevOps和持續整合。這都是戰術上的東西。

70年代敏捷討論中最明顯缺失的一個觀點是概念完整性.

如果沒有概念上的完整性，團隊中有多少人就有多少個心智模型。這種狀況就要求“某人說了算”的戰略決策，

任何敏捷的擁護者都可以告訴你瀑布是壞的，如果你不是在做敏捷，你一定是在做瀑布。

還有一種觀點認為：產品必須儘快進入市場，以獲得先行者的優勢，或者也許以更溫和的形式，必須立即在市場上進行測試，以確保它是人們想要的東西。這些說法都不假，但它們也不是全部的真相。

尤其是，並非所有的軟體都是Web應用程式。事實上，相當一部分軟體不是消費品，甚至不是完全的消費品產品。

古特哈特定律的詛咒

古特哈特定律是一個簡單的心理模型：當一個度量成為目標時，它就不再是一個好目標。當開發了“多少功能”稱為程式設計師的考核目標時，它就不是一個好的目標了。

“功能”是程式設計師輸出的一個單位，大致相當於一個子程式。“功能”可以作為一種管理控制，因為它們體現在最終產品中，而且它們與程式設計師時間的關係是最接近線性的。

“功能”也適用於市場營銷，由於沒有人可以否認一個功能的存在，一個方便的策略就是計算它們。在我們最新的版本中，有超過100個新功能！"。同樣地，任何時候，資訊傳遞都是這樣的：我們的產品讓你......，他們在談論功能。的確，如果沒有可敬的功能作為依託，各地的營銷部門都會漂泊不定。

但是，“功能”這個衡量目標並沒有用，因為它們很容易被操縱。

一個脆弱的、敷衍了事的、快速完成的功能實現會比一個強大的、完整的功能實現獲得更多的內部誇獎。如果提出的問題是：產品A有X功能嗎？ 那麼答案是肯定的。這也使得功能成為競爭產品的一個虛假的比較基礎，為什麼說虛假？因為你需要認真地檢查它們，以確定它們好到何種程度上。

 "功能工廠 "作為一個貶義詞來指代那些沉迷於增加功能的公司，同時積累了不可估量的所謂技術債務。

這種情況是由管理層為了營銷的方便而推動的，我對更忠實于敏捷原則的應用能否糾正這種情況持懷疑態度。事實上，我懷疑敏捷過程在本質上很容易受到這種妥協的影響。

還有一個與軟體開發相關的客觀可計算的現象，那就是行為。產品是否在Y條件下做了X，也是一個經驗問題，其答案是 "是 "或 "否"。程式設計師應該熟悉這種模式；這正是測試套件的編寫方式。

行為比功能更有優勢，因為你可以用行為來描述任何功能，但你不能用功能來描述行為。這是因為功能在軟體靜止時是可見的，而行為只有在軟體執行時才是可見的。此外，功能的存在只能向使用者表明一個目標是否可能實現，行為將決定實現該目標的痛苦程度。

我在這裡要討論的行為的最後一個優點是，它模糊了修復錯誤和建立功能之間的界限，並將這兩者凝聚成一個雕塑行為的統一過程。功能的數量可能不會很快增加，但產品的行為將在微妙和適合方面穩步增長。我還打賭，行為不容易被操縱，因為任何嘗試都會顯得非常明顯和愚蠢。市場部可以自己挖掘語料庫中的可識別功能；反正他們已經做得差不多了。

什麼時候衝刺才是真正的馬拉松？

像其他創造性的工作一樣，軟體開發的速度不會因為我們可以消除那些使它變慢的現象而加快。

程式設計工具的進步確實可以消除一些變慢的現象，開發人員可以把更多的時間花在應用邏輯上。理想情況下，你可以直接告訴計算機你想要什麼，它就會製造出來，但如果你能做到這一點，那麼就不需要程式設計師了。

即使在一個沒有程式設計師的世界裡，仍然需要弄清楚，你想告訴計算機為你做什麼：你希望它的行為是什麼。

除了你用什麼框架編寫它，或者你是否使用NoSQL，或者你如何佈置原始碼樹之外，仍然有很多決定要做。

如果你排除了那些涉及到讓工件工作的決定，剩下的決定將涉及到它是否比其他方式更好地工作。這些決定中的大部分都是試驗和錯誤的結果，而其中相當大的一部分都涉及到使用者的反饋。

。。。