Uncle Bob給新世代的敏捷價值和原則

本書並不是一本研究著作，我並沒有嚴謹地審閱所有的文獻。你即將要看到的，是我個人的「回憶」、「觀察」，以及我這二十年來使用敏捷的「看法」——僅此而已，除此之外沒別的。

我的寫作風格是「談話式」和「口語化」，所以有時候我的用字遣詞會有點粗俗。雖然我不是那種喜歡講粗話的人，但有一個（稍微修飾過的）不雅字眼還是出現在書中，因為我想不到有任何更好的方式，可以用來傳達我想表達的意思。

對了，這本書可不是完全在自吹自擂。一旦覺得有必要，我會引用一些參考資料供你去參照。我還會盡量和敏捷社群裡的人核對一些事實。我甚至要求其中幾個人，在他們所屬章節中分別提供補充資訊和反對意見。不過，你還是不應該把這本書看作是一本學術著作。把它當成回憶錄可能會更好一些——一個脾氣乖戾的老頭，一邊發著牢騷、一邊叫那些標新立異的敏捷小鬼們滾出他的草坪。

本書適合程式設計師，也適合非程式設計師。它不是技術性的，這本書裡面沒有任何程式碼。它的目的，僅是概述「敏捷軟體開發」的初衷，而無需深入了解程式設計、測試或管理等技術細節。

這是一本小書，因為所要論述的主題並不大。敏捷是一個小小的觀念，關於小型程式設計團隊做小事情時會遇到的小問題。敏捷並不是一個關於大型程式設計團隊做大事情會遇到大問題的巨大概念。只不過有些諷刺的是，這個小問題的「小小解決方案」剛好有一個名字。畢竟在1950和1960年代，幾乎與軟體發明的同一時間，這個小問題就解決了。在那段日子裡，小型軟體團隊在做小事情的時候，往往表現得很好。然而到了1970年代，小型軟體團隊在做小事情時，所有人卻都陷入了「意識型態的困境」，只因他們認為自己應該成為一個大團隊來幹大事。

難道我們不應該成為大團隊來幹大事嗎？絕對不行！大團隊無法完成大事，必須由許多小團隊合作完成許多小事，才能夠完成大事。這是1950和1960年代的程式設計師自然而然就知道的事，然而卻在1970年代被遺忘了。

為什麼會被遺忘呢？我懷疑是因為斷層（discontinuity）。1970年代，世界各地的程式設計師數量開始爆增。在這之前，全世界只有幾千名程式設計師。之後，卻有成千上萬個。現在這個數字已接近一億。

那些1950和1960年代的第一批程式設計師並非年輕人。他們在1930、1940和1950年代開始程式設計。到了1970年代，當程式設計師的人口開始激增時，那些老人才正要退休。所以「必要的訓練」從未發生過。一群不可一世的20多歲年輕人正要進入就業市場，同一時間，另一群經驗豐富的人們卻開始離開，而他們的經驗並沒有得到有效的轉移。

有人會說，這個事件在程式設計的歷史上開啟了一段黑暗時代。三十年來，我們一直在努力，企圖想以「大團隊」成就「大事情」，卻從不知道，秘訣其實是與「很多小團隊」做「很多小事情」。

然後到了1990年代中期，我們開始意識到我們失去了什麼。「小團隊」的概念開始萌芽、茁壯。這個想法開始在軟體開發人員的社群裡傳播開來，凝聚成一股力量。時間來到2000年，我們意識到我們需要對整個行業進行重啟（reboot）。我們需要有人提醒，那些前輩本能就知道的事。我們需要再一次地意識到，「大事情」必須是由「許多個小團隊」共同合作「許多個小事情」，才得以完成。

為了協助推廣這個想法，我們替它取了一個名字。我們稱之為「敏捷」（Agile）。

我在2019年的第一天寫了這篇序言。自2000年的重啟以來，已過了近二十年，在我看來，是時候再來一次重啟了。為什麼呢？因為敏捷「簡單而微小的觀念」在這幾年間變得非常混亂。它與Lean、Kanban、LeSS、SAFe、Modern、Skilled以及其他許多概念混淆在一起。這些想法並不壞，但它們並非最初的敏捷思想。所以現在是時候了。讓我們喚回前輩在1950和1960年代所知道的「本能」，以及在2000年重新學到的東西。現在，該是還原敏捷真實面貌的時候了。

敏捷的價值觀

Kent Beck很久以前就命名了四個敏捷價值觀，它們是：勇氣（courage）、溝通（communication）、回饋（feedback）和簡單（simplicity）。

勇氣

第一個價值觀是勇氣——或者，換句話說，就是在一個合理的範圍內勇於冒險。

敏捷團隊的成員並不太關注所謂政治意義上的「安全性」，因為這會犧牲品質和機會。他們發現長遠來看，管理軟體專案的最佳方式就是具備一定程度的侵略性。

勇氣和莽撞是有差異的。部署最小功能集（minimum feature set）需要勇氣。維護高品質的程式碼和高品質的紀律需要勇氣。但是，倘若你對程式碼沒有高度信心，或是程式碼的設計不具備可持續性，這就是莽撞了。為了遵循時程表而犧牲品質，這是莽撞的。

相信品質和紀律可以提高速率，這是一種勇敢的信念，它會持續受到強勢卻天真的人們挑戰，因為他們都很著急。

溝通

我們珍視直接、頻繁的跨管道溝通。敏捷團隊成員希望彼此交談。程式設計師、客戶、測試人員和管理人員希望坐在一起、頻繁互動，而不是只有在開會時才有交集。他們重視面對面、非正式的、人與人之間的對話，而不單是透過email、通訊軟體或備忘錄聯繫。

這就是凝聚團隊的做法。在快速、混亂、非正式且瘋狂的頻繁互動中，人們經常靈光乍現、恍然大悟。一個經常坐在一起交流的團隊可以創造奇蹟。

回饋

我們研究的各種敏捷紀律，實際上都是為了向「做出重大決策的人」提供快速回饋。規劃遊戲（Planning Game）、重構（Refactoring）、測試驅動開發（Test Driven Development）、持續整合（Continuous Integration）、小型發布（Small Releases）、集體所有權（Collective Ownership）、完整團隊（Whole Team）等等會最大化回饋的頻率與數量。它們讓我們能夠及早確定事情出錯的時間，以便修正它們。這些實踐讓我們學到關於先前決策的後果，並從中記取經驗和教訓。敏捷團隊因回饋而成長茁壯。回饋是讓團隊有效工作的主因，也推動了專案取得有益的成果。

簡單

敏捷的下一個價值觀是簡單——即「直截了當」。我們經常聽到這樣的說法：軟體中的任何問題，都可以透過增加一個間接層（layer of indirection）來解決。但是，勇氣、溝通及回饋的價值觀確保了「問題的數量」被降至最低。因此，間接層也可以保持在最低限度。解決方案可以很簡單。

這不僅適用於軟體，也適用於團隊。「被動攻擊型」（Passive Aggressive）的行為就是一種不直接的表達。假設你發現了一個問題，但你卻默不作聲地把問題傳給別人，你就採取了不直接的表達。若你明明知道會有嚴重後果，卻還是答應了管理人員或客戶的請求，你亦採取了不直接的行為。

簡單就是直接——程式碼直截了當，溝通和行為也直截了當。在程式碼中，一定數量的間接層是必要的。間接層的機制可以減少彼此依賴所帶來的複雜性。在團隊中，其實不太需要這麼多間接層（亦即不直接）。大多數時候，你會希望盡量表現得直截了當一些。

讓程式碼保持簡單。讓團隊更簡單。（本文摘錄整理自《無瑕的程式碼｜敏捷篇》，博碩文化提供）

圖片來源_博碩文化

 書名  無瑕的程式碼｜敏捷篇：還原敏捷真實的面貌

Robert C. Martin／著；盧國鳳、陳錦輝／譯；魏聲圩／審校

博碩文化出版

定價：560元

圖片來源_Angelacleancoder (CC BY-SA 4.0)

 作者簡介  Robert C. Martin

Robert C. Martin（Uncle Bob）1970 年就開始了他的程式設計師生涯。他是cleancoders.com 的共同創辦人，該網站為軟體開發人員提供線上影片訓練課程。他也是Uncle Bob Consulting LLC 的創辦人，為世界各地的大型企業提供軟體顧問、訓練以及技術開發等服務。他曾是一間芝加哥顧問公司8th Light的軟體工藝大師（Master Craftsman）。