在 PTT Soft_Job 看到這篇討論： 敏捷課程觀察心得

我的看法跟這位差不多，不是反對敏捷，覺得敏捷就是種『軟體開發管理』的『原則』、『方法』、『概念』、『精神』 … 用我個人的詞彙來說，就是『有節奏的軟體開發方法』

音樂沒有節奏，就不是音樂。

導入能否成功，跟團隊、組織、文化很有關係。

敏捷宣言 沒有啥規則，就是概念，換言之『抽象』。抽象的好處是，怎麼解釋都可以，最後太抽象會衍生出各式各樣的分支，或者因為講者個人特色，變得很有特色，有點像是宗教。如果團隊、組織沒意會到是在做 軟體開發 的工作，而是用工廠的思維在管理，那『敏捷』到最後是穿西裝打領帶的宗教儀式。

底下整理一些觀察到的現象與想法。

語意的問題

敏捷原文 agile ，這個詞原意：

1. able to move quickly and easily.
2. able to think quickly and in an intelligent way

中文可以翻譯成 靈活，帶有文學性、浪漫的翻譯： 敏捷

很多人 (通常是管理階層) 聽到這個方法論、管理方法、開發方法之後，很容易以為：

以後很快就可以交付產出了

所以壓時程更加的果斷了，資源給的更加節省了。

實際上，我覺得這個方法的前提是：

• 要改變的是 主詞：『主詞』要變的 靈活，有 靈活 才能 快，然後才談得上 敏捷
  • 主詞請帶入：主管、團隊、管理階層 …
  • 過程：要變得靈活 -> 快 -> 才有敏捷，這過程缺一不可。
  • 不靈活的 主詞，是無法快的，就是不敏捷
  • 靈活要建立在 mindset 與技能強健的團隊 -> 團隊的素質
• 『主詞』不『敏捷』，導入啥都是垃圾，都是很絢麗的煙火

重點在於主詞 - 『你』、『 團隊』、『組織』，然後這些人的心態、mindset、素質

你會發現，我也開始在用垃圾字了 XDDD

當這樣解釋 敏捷 的時候，這個詞很容易變成 buzzword

換個也許聽得懂的說法：

就像海賊王一樣，大家都在同一條船上，各自有各自的專長，大家的夢想不一樣，但是目的是一樣的！所以成員都很靈活、敏捷！

如果『敏捷軟體開發』改成『靈活軟體開發』，聽起來就不夠潮、不夠 Buzz。。。用行銷的角度來看 - 不夠潮、不夠吸引人。就跟書名一樣，要取個吸引人的名字，但這牽扯到語言本身特性的問題。

底下是掉書袋。

語言學 - 語言影響思維

最近看一部電影 異星入境 (Arrival)，故事講的是外星人來到地球，人類嘗試跟外星人接觸，人類的語言學家研究外星人語言的特性，在這過程中發生的事件。

故事中 七足外星人 (Heptapod) 的語言特性：

• 每個圓圈代表一句話，不是用單字做單位，而是每次都想整句話
• 一次噴 (講) 出一句話，代表他們思考的方式與人類的差異，他們的思考是非線性的
• 人類的語言，大多是線性思考，也就是邊想邊說，邊說邊想

下圖是電影中七足外星人的文字：

一個圈圈，代表一句話，換言之，他們的思考是一次想完整的句子。他們一次可以同時噴出多個圈圈，表示可以同時說完一本書的故事。

這部電影深度的分析參考：【问舰】破解脑洞大开的外星人语言！深度解析《降临》 - 有很精彩的分析

這其中帶出 語言學 的一個學說： 沙皮爾-沃爾夫假說，這項學說認為：

人類的思考模式受到其使用語言的影響，因而對同一事物時可能會有不同的看法。

簡單說：語言影響思維。人類的思維，和語言之間有著緊密的關係。思維是在內心說的話，我們在內心用什麼語言說話，就會以這種語言來思考。

我在 思考本質、實踐、想像力、教育 一文最後，提到的也是語言本質性問題。

錯意

Agile 翻譯成 敏捷，因為『語意』理解的問題，很容易讓人誤解。管理者、或團隊容易把『敏捷』當成 銀彈，以為可以讓軟體開發更快交付 (Delivery) …. 實際上軟體開發特性已經有諸多理論、論述證明，像是：

• 人月神話
• Peopleware
• 沒有銀彈

所以當引入這個方法論的時候，用 敏捷 一詞，就會讓大家內心以為 讓產能變快 ，實際他是能 快速面對改變，兩者意義天差地遠。

『中文』語言句型的特性就是：本身沒啥邏輯性，經常是主、動、賓模糊不清，或者省略，直接影響聽者的思維，帶入他既定的想法，最後衝突會更加的多。。。

底下是我對敏捷的看法：

敏捷的核心目的：要改變團隊與組織在溝通與協作的 靈活性 ，目的是為提升 軟體開發程序 的品質，開發過程有品質，隨之而來的就是高度的生產力。

有品質的軟體開發，隨之而來的是:

1. 員工生活有品質: 員工生活沒品質，再大的產能都是失敗的企業，所以擺第一位。
2. 面對市場改面的靈活度
3. 團隊的高生產力

沒有品質，隨之而來的，會是無止盡的 溝通成本。包含導入敏捷開發這件事情，就是一個巨大的 溝通成本。

相關詞語：蝴蝶效應、三體問題、混沌工程

穀倉

穀倉效應 這本書提到文化的特性，影響了人類的思維。在穀倉裡的人，經常會有這樣的思維：

人們往往認為自己的作法「很自然」、「很正常」、「合情合理」，至於別人則不然。

這段描述，跟我曾解釋「音階本質」的想法雷同，我這樣說明音階：

在學習音階的過程中，我心裡一直有個疑惑，為什麼要叫做自然大調音階？自然小調音階？為啥是自然的？不是人工的？為啥又會有調式這種東西存在？按照一般教學書的介紹，其實調式是古代種族的民俗音階，對我們現在人來講是一種『民俗』，對該種族來講，不就是所謂的『自然音階』嗎？我們只是用自己的眼光來看待這些文物，然後覺得我們所學的就比較『自然』、或者是『理所當然』。

重點在於：為什麼是 理所當然？什麼是 理所當然？

大調音階 理所當然的就是自然音階嗎？那不過是你我成長環境裡的 Default 值而已，別人的環境不見得是如此。

敏捷 理所當然的就是要 快！為什麼？對嗎？

我覺得敏捷的理所當然在於 靈活，靈活 要打破各個層級腦袋的思維。如果大家都用自己的眼光看待整個產品開發，那麼，穀倉效應是必然的。

本質

敏捷的 本質 問題，前面提了很多次了，我覺得就是 靈活。靈活指的是產品開發、或者軟體開發過程中，組織、團隊的溝通與目標要能夠面對靈活的市場改變。

但是改變必須要有些原則，就是要 控速 - 控制速度，用音樂來說：

節拍 不能一直變！才能持續交付有價值的音符！

一首歌的速度 t=60，代表每分鐘有 60 個拍子。如果一首演奏過程，速度一直變，一下 60 一下 180，一下 50，沒有個音樂家能夠在這種速度演奏的！

產品開發，要面對市場的改變，但要基於一定的節奏感。所以 Scrum 的方法就是兩週一個 Sprint 是比較適當的時間，為什麼是兩週？

因為要讓大家有時間專心做事！！！沒辦法 專心做事，導入什麼方法都是沒意義的！

靈活的開發流程，要建立在 品質 之上，品質建立在 基本功，在 演講：Ops as Code using Serverless 的問答中，提到軟體開發者的基本功。

那些成功的企業，他們能夠靈活地面對市場改變，基本功、品質都是他們很重視的項目。

改變

從小就常聽到這句幹話：這個世界唯一的不變就是變

市場會一直改變、客戶會一直變、老闆會一直變、技術一直變、團隊成員一直變。不管是外在與內在的改變，都會面臨這樣的問題：

是 心隨境轉？，還是 境隨心轉？

真的需要變？還是自己腳步慌了？

組織、團隊都要思考這問題，如 為將之道 一樣：

夫為將者，能去能就，能柔能剛；能進能退，能弱能強。
不動如山岳，難測如陰陽；無窮如天地，充實如太倉；浩渺如四海，眩曜如三光。
欲知天文之旱澇，先識地理之平康；察陣勢之期會，揣敵人之短長。

出處：三國演義 第一○○回：漢兵劫寨破曹真，武侯鬥陣辱仲達

市場變化很快，也可能只是像蛋塔、髒髒包一樣，曇花一現。怎麼站穩腳步，怎樣讓自己或團隊進入 Inner Peace，然後看清什麼是 需求，怎麼 有效組織、管理這些需求，是團隊、組織要有的智慧與判斷。

曇花一現：蛋塔、雷神巧克力、厚奶茶、夾娃娃機、髒髒包

面對改變，可以先蹲下，再挑高，微軟是這方面的高手。也可當領航者，領導大家往前衝，Google、Amazon、Apple 是這方面的代表。

現象

以前在帶 SQA Team 的時候，我通常會請新進同仁在 onboard 後一個月內給予建議、feedback，看到怪怪的、不對的都可以講。因為他還沒融入環境中，旁觀者清，最能直接感受出組織、流程、或者產品的問題，甚至是團隊的問題。

到現在，我常常會用旁觀者的 視野，加入時間軸的角度，來看待一切。底下是我用旁觀者的角度觀察的現象，不見得是對或錯，因為我也可能在穀倉裡：

• 沒有人在乎新技術的研究：分散式系統架構、Cloud Natvie、Containzie
• 技術債永遠在那裡
• 效能: DB、系統架構、開發流程、網路架構
• CI/CD 怎麼設計、怎樣的 CI/CD 才夠 Quality?
• 環境怎麼建置
• 效能怎麼測試

沒人在乎忽的軟體工程，能動就好。

當這些都被視而不見的，最後敏捷只會變成宗教、seafood …. 因為導入之後，問題還是在那裡，沒有任何改變。

實踐

從上一個工作離開的初衷，就是期望能夠用實踐影響軟體開發，這幾年一直整理自己想法，不管是學習筆記 (像是：AWS)，還是讀書、參加社群讀書會、演講，身體力行與實踐，直接影響團隊。

底下是我實踐方法的的整理：

• 思考本質、實踐、想像力、教育：探索事物的本質，找到實踐方法。
• AWS Study Roadmap：學習 Cloud Native 的思維，新時代的新方法
• Ops as Code using Serverless: 探索 Ops 的本質問題
• Site Reliability Engineering: class SRE implements DevOps
• 需求管理：品質從需求就開始了，需求沒有管理，沒有對焦，沒有品質可言
• 軟體測試方法：測試的本質、方法，測試團隊就是站在客觀的角度、客戶的思維，避免穀倉
• 協同合作系統建制與導入 - 以 Redmine 為例：軟體開發團隊不會用軟體來提升生產力，是很諷刺的
• 導入 CI/CD 的第一步、怎樣的 CI/CD 才夠 Quality?：好的 CI/CD 帶公司走向全世界，爛的帶公司留台灣。

也許未來我也會去當敏捷教練 (只要出張嘴，不追技術了)，但是希望那時候回來看這些文字的時候，不會變成我不想變成的那個人。

另外，目前我不認同 管理工廠的思維，來帶領 軟體開發團隊，這是兩個不同的目的，工廠很容易把人當作工具來看待，但是軟體工程師不是工具人。很多書都會用類似的講法，有很多大師的背書，我覺得放錯了地方了，有空另外寫專文。

結論

我平常不太會談 敏捷 這件事情，不管於公於私。

• 於公：公司有業界著名的敏捷大師、敏捷教練，他們都是這方面的專業。我相信他們專業與經驗可以帶領公司到另一個境界，只要他們開口，工作上我全力支援。
• 於私：靈活對我來講就是基本的原則，好的軟體應該會越做越靈活。

我一直都當作自己是局外人，有自己的見解與看法，我認同敏捷的精神，這些精神我在前一個工作其實也都在用，只是我從沒套 敏捷開發 這個詞，這個詞中文翻譯本身就具備爭議性，就像我也不太喜歡 DevOps 、 RD 、 監控 、 自動化 這些詞一樣，最後積非成是。

• 協同合作系統建制與導入 - 以 Redmine 為例 描述的，就是讓 軟體開發程序 這件事變得有品質。
• 我常舉例積非成是地例子就是 JSON、YAML 的用法：前者是資料交換語言，用來描述資料結構，是機器給機器看的東西；後者也是資料描述語言，用來描述資料序列，是給人類看的。資料交換不需要可讀性，但卻很常被拿來當配置檔，配置檔是給人讀得，他不能下註解，quot 很煩，甚至拿去當作 DSL 用，有點無奈。。。。
• 雖然我不喜歡那些詞，不代表不認同那些想法，而且平常我還是會用，因為大家都這樣說時，不說反而會怪怪的。

我對軟體開發的態度一直以來都沒改變：

由品質建立數量，由數量產生速度

沒有品質的速度，一點意義都沒有，是浪費生命的。

品質 是什麼：基本功、靈活、清楚、完整 …. 這可以另外再寫一篇 XDD

04/11 補充

這篇我想呈現一個問題：『在組織裡，要謹慎傳遞訊息』

以前老闆跟我說：在組織裡溝通的時候，錯誤的訊息，會像網路謠言一樣，一直發酵、誤傳、誤解、錯意、覆水難收，最後就是，無止盡的溝通成本。

例如同樣講一件事情：『通知』這個詞，背後每個人都有不同的想法、想像、還有畫面。。。『每個人』代表分屬不同組織、角色、背景、經歷，對『通知』一詞會有完全不同的理解。

所以『敏捷開發』是好東西，我覺得要用力推進，但是『敏捷』這個翻譯。。。在組織，不見得是好的翻譯。

後來我想到，AWS 很多產品都用 Elastic (彈性) 當開頭，像是 EC2 - Elastic Compute Cloud)、ELB - Elastic Load Balancing … etc，實際上想表達的或許就是敏捷的意思。這或許也只是我個人一相情願的解讀 XD

Anyway，這篇我自己反覆讀了很多次之後，發現我想表達的重點就是：『要謹慎地傳遞訊息』這件事情，不要讓立意良好的想法、方法，反而變成組織前進的阻礙。。。

延伸閱讀

• 思考本質、實踐、想像力、教育
• 軟體測試
• 溝通 = 成本
• 協同合作系統建制與導入 - 以 Redmine 為例
• 台灣軟體產業的經營
• 學習法則
• 人生的視野
• 演講：Ops as Code using Serverless
• Cost in Context Switch
• 為將之道
• 需求管理
• 經營之道
• AWS Certified Developer 準備心得 #技能、經歷、專業，資深、開發、研究 - 談論 R&D 的差異

喝咖啡 聊音樂

• 音階的本質
• 關於速度
• 吉他的基本功

參考資料

• 敏捷軟體開發宣言 (中文)
• 【问舰】破解脑洞大开的外星人语言！深度解析《降临》 - 很精彩的分析
• 沒有銀彈