20歲的敏捷：失敗的反叛 - simplethread

1. 敏捷，作為一個標籤，贏了；沒有人想被稱為非敏捷。
2. 敏捷在實踐中遠遠低於其創始人的革命性思想。

宣言從何而來
2001 年 2 月，一個由 17 位專家軟體從業者組成的小組在猶他州瓦薩奇山脈雪鳥滑雪勝地的小屋會面。經過幾天的討論和辯論，他們共同撰寫了“敏捷軟體開發宣言”。
我不知道每個簽名者的個人歷史，但在我認識的那些人中，他們要麼仍在積極編寫程式碼，要麼有一段很長的近期程式設計歷史。
首先要強調的是，這些都是從業者。他們不是專案經理、CTO 或 VP Engs。他們是開發人員、程式設計師、科學家和工程師。他們仍在編寫程式碼*並與利益相關者合作解決問題。這個很重要。
另一點是敏捷宣言不是憑空產生的。這些人中的許多人已經有了他們創造和/或正在傳教的方法。我的時間可能有點偏離，但我認為所有這些方法論都預先存在“資本敏捷”：極限程式設計、Scrum、DSDM、自適應軟體開發、Crystal、功能驅動開發、實用程式設計。我知道 Schwaber 和 Sutherland 在 1995 年公開談論過 Scrum，而貝克和傑弗里斯在 1996 年開始談論極限程式設計 (XP)。
這個小組中的每個人都有豐富的軟體編寫經驗，他們都在尋找替代文件驅動的、重量級軟體開發流程的方法。宣言的核心是四項價值陳述：

• 個人和互動 勝過流程和工具
• 工作軟體 勝過綜合文件
• 客戶協作 勝過合同談判
• 響應變化 勝過遵循計劃

新希望
從我們 2021 年的角度來看，很容易將如此多的現代軟體開發實踐視為理所當然，但在 2001 年，這些想法非常激進：在收集所有需求並估算每項功能之前，您打算開始構建軟體是什麼意思？這太瘋狂了！
被遺忘的重要部分是，敏捷一開始就公開、激進地反對管理。例如，肯·施瓦伯 (Ken Schwaber) 直言不諱地表達了他要解僱所有專案經理的目標——不僅僅是讓人們離開他的專案，還要從我們的行業中根除這個職業。
我們發現專案經理的角色在複雜的創造性工作中會適得其反。以專案計劃為代表的專案經理的思維將專案中其他人的創造力和智慧限制在計劃中，而不是調動每個人的智慧來最好地解決問題。
Scrum Masters 幾乎沒有權威，沒有投票權。他們是僕人式領導者，幫助保護和疏通團隊，但不管理團隊。XP 是類似的。如果我沒記錯的話，XP 最初有跟蹤器和教練，它們具有類似的促進、支援氛圍。
Alistair Cockburn 是水晶方法論和六邊形架構 宣言簽署人和創造者， 最近對此提出了一個奇妙的、有見地的想法：
Scrum 在其反對的敵對領域反而達成了一筆不菲的交易：

• 在每次衝刺之後，管理層每年有 12 次以他們想要的任何方式改變方向。
• 團隊獲得了整整一個月的安靜時間，沒有中斷或方向的變化來進行繁重的思考和工作。
• 團隊必須宣佈他們在本月可以做什麼和不能做什麼，而管理層不會干預他們的競標。

敏捷成功的原因
在某些方面，敏捷是一場草根勞工運動。它當然從實地的從業者開始，然後被推到管理層。這是如何成功的？
部分原因是開發人員的數量和業務價值不斷增長，影響力越來越大。但在我看來，最大的因素是傳統的瀑布方法根本行不通。隨著軟體變得越來越複雜，業務步伐加快，使用者的複雜程度不斷提高，試圖預先計劃一切變得不可能。擁抱迭代開發是合乎邏輯的，如果對於習慣於計劃一切的經理來說有點可怕。
 

存在問題
不幸的是，像許多革命一樣，敏捷的歷史並沒有像創始人所設想的那樣展開。

• 事實證明，優先考慮個人和互動是一個很難推銷的概念。反而有助於某些公司更方便推銷流程和工具。
• 事實證明，與不切實際的計劃和大量文件相比，可執行的軟體更難生產。
• 事實證明，與客戶合作需要信任和脆弱性，在商業環境中並不總是存在。
• 事實證明，高管們想要掌控一切，但仍然需要為他們的業務制定長期計劃，這往往比對變化做出反應更重要。

開發人員應該放棄敏捷
當“敏捷”理念應用不當時，往往會導致對開發人員的更多干擾、更少的工作時間、更高的壓力以及“更快”的要求。這對開發人員不利，最終對企業也不利，因為“敏捷”做得不好，往往會導致更多的缺陷和更慢的進展。通常，優秀的開發人員會離開這樣的組織，導致企業效率低於安裝“敏捷”之前。
  

敏捷已死（敏捷萬歲）
“敏捷”這個詞已經被顛覆到了實際上毫無意義的地步，敏捷社群所傳遞的似乎主要是顧問和供應商兜售服務和產品的舞臺……一旦宣言流行起來，敏捷這個詞就成了吸引任何有支付鈔票的磁鐵。它變成了一個營銷術語。
所以我認為是時候讓“敏捷”這個詞退休了。
 
現在談論敏捷並不時髦或酷。敏捷是無聊的。每個人都做敏捷，對吧？ 現在是反思過去 20 年並問自己幾個問題的最佳時機：

• 什麼做對了？
• 什麼地方出了錯？
• 下次我們想做什麼不同的事情？