嗨~ 歡迎閱讀 ExplainThis 全端開發雙週報,在這期的雙週報開始前,想與讀者們分享,ExplainThis 籌劃的 E+,在八月底將會舉行《軟體工程師:海外求職與英文面試實戰》的主題直播。
如果你已經是 E+ 的訂閱讀者,別忘了在報名截止日前報名。如果對這主題感興趣,但還沒訂閱 E+ 的讀者,可以透過這個連結來了解 E+ 的詳細介紹~
接著,讓我們一起進到這期的主題內容吧!
[軟體工程] 淺談敏捷開發的精髓
最近看到社群有一波對敏捷開發的討論,自從敏捷宣言以來,敏捷開發模式一直都是個擁戴與反對聲浪都不小的開發模式。幾乎每隔一段時間,社群就會出現年經式的討論,不外乎是有人出來抱怨敏捷,然後接著有人會出來回文說「你講的根本不是敏捷」。接著在一連串的討論後,下了一個「問題不在敏捷,在操作的人亂用」的結論。
雖然說我們不是敏捷專家,但因為待過的團隊不算少,有號稱用敏捷但非常瀑布流的團隊,也有沒特別提敏捷但運作非常敏捷的團隊,因此從這些經驗中,也有一些對於敏捷的心得。
談到敏捷開發,就不能不提 2001 年被提出的敏捷宣言 (Agile Manifesto)。這個宣言是當初多位資深軟體工程師 (例如 Robert C. Martin) 共同提出的,該宣言的內容如下:
藉著親自並協助他人進行軟體開發,我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力,我們已建立以下價值觀:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
也就是說,雖然右側項目有其價值,但我們更重視左側項目。
從該宣言又延伸出了 12 項「敏捷宣言背後的原則」(連結),以及後續業界出現了各種實務方法 (例如 Scrum) 來實踐敏捷的開發精神。不過不幸的是,許多團隊在套用這些方法時,不知不覺就走偏了。
舉例來說,很多使用各類敏捷方法的團隊,經常有很多大大小小的會議。然而,敏捷背後的原則是要「經常交付可用的軟體」,如果長時間花在開會上,壓縮了能經常交付可用軟體的時間,就可能變得與敏捷背後的原則牴觸。
又或者許多公司在導入流程與工具時,會很死硬地要求團隊必須要照著做,即使某些流程在落地後幾乎變得沒有意義,但仍是為了做而做。但敏捷宣言提到「個人與互動 重於 流程與工具 」。
如果真的要做到敏捷,針對每個會議、流程與工具,應該要回到第一性原理思考,檢視其是否真的有意義,而不是死硬著要開某個浪費時間的會議,或者死硬著要求照做某個冗餘的流程 (備註:如果不熟第一性原理思考,可以參考這篇介紹)。
敏捷不該是由上而下的隕石
在許多會抱怨敏捷的文章中,經常會看到抱怨老闆由上而下的隕石。然而這種隕石或流星雨式的徵兆,似乎與「以積極的個人來建構專案,給予他們所需的環境與支援,並信任他們可以完成工作」這個原則相抵處。
理論上,一個敏捷的團隊,要可以自己決定怎麼樣的方式運作 (ownership)。當發現問題,也應該自行間起責任來解決。舉例來說,假如團隊因為沒有寫測試,導致某個功能出問題上線後才發現。
比起是由上而下要求加上流程 (例如把寫測試這件事塞入流程中),把如何解決交還給團隊決定,由團隊負責,會是更符合敏捷的做法。否則,當越來越多問題發生,就會越加越多東西,導致最後流程變得超級冗長,進而變得毫不敏捷。
談到敏捷就不能不談瀑布
談到敏捷,就不能不談在敏捷之前業界主流的瀑布式開發 (waterfall)。所謂的瀑布式開發,是從需求,到設計,到實作,到測試,最後到部署與為運,一個階段往下一個階段,就像瀑布一樣開發。
過往業界對瀑布式開發有許多批評,包含瀑布式開發這種分階段的方式,極度缺乏彈性。又或者瀑布式開發到測試階段已經很後面,所以當測到問題後前面整段重來的成本很高。
然而,眾多批評當中,最嚴重的問題會是瀑布式開發到上線後已經很晚,要實際收到使用者回饋也會很晚。這將導致一個嚴重的問題,那就是經歷各個階段後、花很多時間後,才發現做出對使用者沒價值的成果,導致前面的大量投入全部白費。
但敏捷的核心是追求「滿足客戶需求」,是追求更頻繁的回饋迴圈 (feedback loop),這能避免做出對使用無價值的成果。
使用者很多時候,其實沒辦法說清楚自己真正想要什麼。所以單純的前期使用者訪談,雖然能做為方向的指引,但很多時候不會是馬上就能精準抓對方向。因此更有效的方法,是根據需求做出原型,接著給使用者用用看,同時蒐集回饋來迭代。
很常見的狀況,是使用者訪談後,根據最開始蒐集到的需求後做出的原型,拿回去給使用者測試後,使用者說這不是自己要的。雖然覺得很無言,但在敏捷的做法下,驗證到真正的需求成本會遠小於瀑布的做法。
然而,如果沒有不斷驗證、不斷迭代、不斷精練對使用者需求的理解,就代表跟敏捷的精髓有所偏離。
從本質出發自然就敏捷
最後,如開頭提到的,過去我們曾經待過,在開發模式上完全沒提敏捷,但是實際運作起來高度敏捷的團隊。之所以能做到這樣,是因為在團隊運作的本質上,與敏捷的原則不謀而合。
因此,推薦比起導入各種方法或流程,不如回到原則面來看敏捷的本質。拋開那些方法與工具,直指核心地問自己所在的團隊
是否做到「及早並持續地交付有價值的軟體」
是否做到「滿足客戶需求」
是否做到「招募積極的成員到團隊,並給予所需的環境與支援」
是否做到「用高效的方式溝通」
是否做到「持續追求優越的技術與優良的設計」
是否做到「給予團隊自主」
是否做到「定期自省如何更有效率, 並據之適當地調整與修正自己的行為」
當團隊對於上面這些問題的回答都是肯定的,那即使不導入 Scrum 或 Kanban 等方法,也能夠跑得很敏捷。
最後,在我們過去的經驗中,能良好體現敏捷本質的團隊成員,多半對組織脈絡有一定的掌握,知道組織的架構、知道不同產品之間的定義與上下游關係,並能透過系統性的思考,把這些資訊整合起來。當能夠做到這樣,將能夠更容易地實踐敏捷。
[本期推薦]
先前看到前 Amazon 的首席工程師 Steve Huynh 曾說,整理自己的 brag document,是職涯中投資報酬率最高的事情之一。然而,什麼是 brag document? 推薦可以一讀這篇了解 (連結)
談到軟體的監控與事故處理,很多人可能直觀會覺得這是維運 (ops) 的範疇。在過去確實是這樣子,但近幾年趨勢的改變下,多數公司也都抱持著開發者要第一線處理事故的做法。先前 Increment 有做一份調查,結果發現包含 Amazon、Dropbox、Meta、Google 還有 Netflix 等公司,現在基本上都是開發者負責監控與輪班處理事故。然而,軟體工程師該如何做好監控 (monitoring)?詳見此篇 (連結)
最近看到 《Exploring JavaScript》出了 2024 年版本,加上了 ES2024 的最新內容,才想到該作者 Axel Rauschmayer 過去寫了好幾本進階的 JavaScript 書籍,且每一本的電子書都是免費的。有興趣一讀的人,我們將這本的連結收錄在 PinThis 資源站了 (連結)
自從 View Transitions API 問世後,有些前端轉換畫面的功能,可以不再需用 JavaScript 也能實作。Astro 團隊寫的這篇《Zero-JavaScript View Transitions》很推薦一讀 (連結)
近年來前端界最熱門的 CSS 工具莫過於 Tailwind CSS,這篇《Tailwind CSS under the hood》解析了 Tailwind CSS 背後的原理 (連結)
如果要讓前後端能互相傳資料,在目前的業界有幾種常見的作法,然而哪種適用於哪些不同場景呢? 《WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport》有很完整的分析 (連結)
Edge 是近年來很熱門的議題,在《How to make edge rendering fast》一文中談了如何在邊緣時渲染得更快 (連結)