敏捷的本質

You keep using that word, I do not think it means what you think it means.
— Inigo Montoya, The Princess Bride

核心概念#

Agile 是一個形容詞——它是你做事的方式。你可以是一個敏捷的開發者，你可以在一個採用敏捷實踐的團隊中，一個回應變化和挫折都帶著敏捷性的團隊。敏捷是你的風格，而不是你。

Tip 83 - Agile Is Not a Noun; Agile Is How You Do Things（敏捷不是名詞；敏捷是你做事的方式）

在敏捷宣言誕生近 20 年後，作者們看到許多開發者和團隊成功地應用其價值觀。但也看到了另一面——團隊和公司渴望現成的解決方案：「盒裝敏捷」。更多管理層、更多正式報告、更多專業化的開發者、更多花俏的職位頭銜（其實只是「拿著剪貼板和計時器的人」）。

許多人已經迷失了敏捷的真正含義。讓我們回到基礎。

記住宣言的價值觀：

右邊的項目仍有價值，但我們更重視左邊的項目。任何向你推銷增加右邊重要性、削弱左邊的東西，都不符合宣言作者們的價值觀。

事實上，每當有人說「照做這個，你就會敏捷了」，他們就是錯的。因為敏捷——無論是在物理世界還是軟體開發中——都是關於回應變化。正如奔跑中的瞪羚不會走直線，體操選手每秒做出數百次修正一樣。

團隊和個人開發者也一樣。沒有一個你可以遵循的固定計畫。敏捷宣言的四個價值觀中，有三個告訴你的都是同一件事：蒐集回饋並據此行動。

價值觀不會告訴你該做什麼。它們告訴你，在你自己決定該做什麼時，應該注意什麼。

沒有人能告訴你該做什麼。但作者們認為可以談談做事的精神。一切歸結為如何應對不確定性。宣言建議通過蒐集回饋並據此行動來做到這一點。以下是敏捷工作的配方：

重複這些步驟直到完成。並在你做的每一件事的每一個層次上遞迴地使用它們。

這個回饋循環適用於專案的最高層次。它也適用於最低層次——例如變數命名。從 user 改成 owner，再改成 emailOfAccountOwner——透過在非常低的層次上應用回饋循環，我們實際上改善了整個系統的設計。

在 Topic 8，好設計的本質中，我們主張好設計的衡量標準是設計多容易被改變。而敏捷的討論解釋了為什麼如此。

你做一個改變，發現不喜歡它。我們的清單第 3 步說要能修復弄壞的東西。為了讓回饋循環有效率，這個修復必須盡可能無痛。如果不容易修復，我們就會被誘惑聳聳肩、不去修了。我們在 Topic 3 軟體的熵中討論過這種效應。

要讓整個敏捷的事情運作，我們需要實踐好的設計，因為好的設計讓事情容易改變。如果容易改變，我們就能在每個層次上毫不猶豫地調整。

那就是敏捷。