軟體界內 Clean- (無瑕的-) 系列書籍一直名聲響亮，這些書籍也確實帶給我不少啟發，都相當推薦給身邊的夥伴們。
因此在 2022/9/30 出版的《Clean Agile》很快引起我的注意，雖然原書 Clean Agile: Back to Basics 已在 2019 出版，今次讀到的繁中版已晚了幾年，但閱讀過程中屢屢共鳴，不少想法與我參加 2021 ITHome 鐵人賽分享的看法近似，如今讀到本書更有一股親切感。
全書閱讀起來詞句順暢，容易吸收，配合作者隨時的「幽默」串場，讀起來並不會有壓力。
如果要直接講結論：團隊成員應直接入手一本來看，好書推薦。 (喂)
好吧，還是從書中幾個比較有印象的主題出發，加上一些個人的心得與大家分享。
敏捷
本書副標「還原敏捷真實的面貌」相當吸引我，在這敏捷滿天飛，多流派各顯神通的背景下，究竟什麼才是真實面貌？作者在書內安插了一些有趣的歷史回顧環節，我們因此可以得知與 Agile 形影不離的 Waterfall 究竟怎麼來的。
我對敏捷的看法是更自然的，甚至之前也撰文提到「敏捷是自然的」，反而疑惑為什麼不這麼做？為什麼到了軟體開發，反而會變成不自然的狀態？也許是成長背景、學習養成，我對 Waterfall 有著天然疑慮，對我而言，它真是一種拿來「對比」的對象。
為什麼需要「敏捷」？作者以軟體的「獨特性」來說明，闡述了敏捷是關於軟體開發的，以及與其他領域的經驗為何不適合直接套用。
我對此也有一些看法，軟體的存在讓人摸不著邊際。如今數位化行之有年的 2022，便利貼、實體看板、紙本書籍都還有它的市場，也被不少人與團隊認為是必要的，要的是一種「看得見」與「摸得著」的存在。回頭看向軟體就不難發現，面對這樣虛幻的存在，我們該如何做對它做出「好的」估計、分析、理解、運用，甚至是開發它，是有相當難度的，我想這也是為什麼大家仍在尋找方法，還需要辨思敏捷究竟是什麼？有何用？有沒有用？的原因之一。
Teddy 在推薦序提到：「敏捷是追求『軟體開發永恆之道』」，這很關鍵，也是很有份量的一句話，回答了正在思考是否導入敏捷方法、或已經導入但仍然有儲多疑問的團隊可能的疑問－－為什麼要變得敏捷會有這麼多事情要做？為什麼我們得這麼做？
大家在工作歷程上，多少看過甚至參與過一些「短期有效」的策略，例如從一開始就指派某個或某群功能給指定人選、實行加班、省略測試、不開審查與回顧會議來節省時間等。已經先看到答案的我們，自然能理解，如此的敏捷既不「敏」也不「捷」，一來是用力方向不一致，二來是真正在製造問題的根本不是敏捷。
那麼敏捷會快嗎？我的觀點是：「會，但那只是順便而以。團隊把事情做好，自然就快了。」
技術
快速前進的唯一方法，就是選擇好的品質
我特別引用這句話，因為它太重要了。敏捷不是求快，這句話也在近年的研討會再三提及。如同前述，我的觀點中，敏捷可能會讓團隊產出更快，但也只是順便，這得益於流程、溝通、價值觀以及「技術」的到位，無論有意還是無意，這都容易在實踐敏捷時被無視，也因此敏捷成為一種魔法，帶給利害關係人虛幻的期待。
該怎麼實踐「敏捷」？本書提供了簡明的指導方針：測試 (Testing)、結對 (Pairing)、重構 (Refactoring) 以及簡潔設計 (Simple Design)。
作者在 TDD 上面多有著墨，嚴厲指出它與重構、簡潔設計、結對程式設的重要性－－「沒有了它們，敏捷只是空有外表，卻無實際的作用」。
我認同這樣的觀點，同時也提一個退萬步的取捨。假若團隊因為各種原因 (你知道的，特別是跟測試有關係的活動，常有許多奇特的障礙)，至少努力的目標是「縮短測試與實作撰寫之間的時間」，讓這個間隔越短越好。
有趣的是，作者以會計的複式簿記來導出 TDD 的概念，對於兩門學科都接觸過我的，特別有感覺。TDD 從開始就為實作鋪墊了「可測試性」，作者也提及可測試性正是「解耦」的同意義詞，這是值得大家認知到的觀念。而再往後延伸，正因為可測試性，團隊能夠透過測試來驗證(保護)實作，進而獲得了日後重構的「勇氣」。
或許這邊可以再做一些關聯，這種先劃定方向，避免實作走歪的方法，與 User Story 配上驗收條件是否有異曲同工之妙？驗收調件框定了方向，好讓實作能在軌道上，同時 Story 簡潔的特性也避免大家過早陷在一大堆細節上，反而失焦。
認知
我常開個玩笑：「現在我們什麼都不知道，除了截止日期」。
可惜這不僅是個笑話，而是實際經驗，也可以從許多社群分享可以看到這樣的常態。
這種截止日期與要做什麼之間的糾葛恐怕沒有停止過，作者花了不小篇幅談論「估算」這一回事，反覆強調了它的「不精準」。我想這正是反應你我都在面對的－－在有限情資下的不確定性。同時，書中也提醒我們，不要對估算的對象(如故事點、測試覆蓋率)施加壓力，以免讓它偏移更大，很是考量人性。
團隊要抱有「回應變化」與「擁抱變化」的基本態度，如果軟體是那麼的不可變，都搞得向硬體一般了。也正因如此，軟體猶如在變化中又有變化，全團隊(含利害關係人)都應該有這般的認知，觀察運作，即時修正。
作者的「迭代不會失敗的想法」我很認同，我甚至認為敏捷也沒有所謂失敗，倒不如說，當你覺得有失敗的跡像時，表示你看到問題點了，接下來就是去解決問題，僅此而以。
後記
本書結尾作者有對於大規模敏捷提出一些反面的想法，不過我尚未有足以談論這議題的經驗，就不在這邊多談，有興趣的讀者可以多留意。
本文並沒有完全摘錄全書提到的各種具體操作方式，但那相當值得一讀，並反思在團隊內是怎麼執行的，推薦大家找段時間，好好一讀。
