談談敏捷開發的看法


在 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) …. 實際上軟體開發特性已經有諸多理論、論述證明,像是:

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

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

底下是我對敏捷的看法:

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

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

  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),還是讀書、參加社群讀書會、演講,身體力行與實踐,直接影響團隊。

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

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

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


結論

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

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

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

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

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

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

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

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

04/11 補充

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

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

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

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

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

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


延伸閱讀

喝咖啡 聊音樂

參考資料


Comments