Agile is Dead?

更新於 發佈於 閱讀時間約 13 分鐘

前陣子,在 Facebook 上分享了《Agile is Dead》中文翻譯版,分享時人在公車上,不喜歡用手機打字的我,沒有下任何註解就分享出去了,但後續的發酵倒是令我有點意外。我個人沒有推崇任何方法,就如同我討厭有人跟我推銷宗教一樣。只是在進入職場前跟著老師很早就接觸 RUP 和 agile software development,在職場中也待在 scrum 團隊多年,甚至後來也擔任 scrum master,希望給團隊最大的空間能夠自我組織與成長,也以這目標在努力,因此,若真要問我對這篇文章的感想是什麼?

事實上跟文章的內容大致相同,只是標題很聳動,我應該會說 Agile 是個已經被過度炒作的商業名詞,注意,我用大寫開頭,因此常被誤解是銀子彈能解決所有軟體開發中會遇到的問題,但事實上它並不是,要視 context 才能知道哪種方法 (不論是不是 agile 方法) 適合您的團隊。

在沒有內化《Manifesto for Agile Software Development》核心精神前就導入任何方法,就好像練武功只練外功沒練內功會走火入魔一樣,會有很多副作用,因此覺得這方法很 OOXX。至於為什麼導入時總是會先從方法開始而不是先從了解精神開始?我想這跟為什麼練武功都是先從練基本功與招式開始相同,因為要把一個概念內化是很難的,方法是最容易讓人上手可以開始的地方,但練武到後期,若在一個好的師父帶領下,不會讓他的徒弟只練外功不練內功,相同地,如果有好的 agile coach,是會讓團隊慢慢內化宣言背後的精神,只可惜,在商業炒作下,有太多拿著 XXX 證照的講師,說是幫助團隊導入 agile 開發方法,方法教完了就離開,團隊也就照著方法做了,短期可能有些成效,但講師一不在團隊內,團隊無法用內化的思維自己解決問題,也就停滯甚至退步。

若我們用理解 pattern 的方式來理解這些方法,也許應該先從當初這些方法推出時的 context,以及所面對的 forces 有哪些,了解這些方法如何平衡這些 forces,然後才能判斷是否適合用在您的 context 中。不過可惜的是,我沒參與過那場討論出《Manifesto for Agile Software Development》會議,我無法明確知道 context 與 forces,但我在學軟體工程與專案管理時,有個漫畫倒是常常被引用,即便到現在依然是如此:

raw-image

在那個年代…這說法好像我也很老了,需求常常是軟體開發商與客戶之間永遠的痛,軟體開發者覺得客戶不知道自己在說什麼,客戶覺得軟體開發商總是誤解他們的需求,又或者是,軟體開發商受不了客戶對需求一變再變,但客戶覺得不是他們變更需求,而是軟體開發商根本就做錯了。在這樣的 context 下,有一些方法被提出來,想平衡需求無法明確與變動的 forces,像是 Rational Unified Process (RUP) 或是對我來說惡名昭彰的 CMMI,某種程度上,我認為 use cases 搭配 iterative development 的 RUP,確實是比根本不該用來開發軟體的 waterfall process 要好很多。

raw-image

只是,當商業業務本身變動越來越快的情況下,對開發中的軟體需求自然也就跟著變動,若不跟著變動,即使做對了做完了,對客戶來說也沒有用處,因為當初的需求現在已經不是需求了。以下是我的猜測,軟體開發商完成了合約中的項目,卻無法幫助客戶;為了確保做對合約中的項目,即使是用 RUP,也做了大量的big up front design,因此對於變更有一定的排斥;因為 RUP 有一定的規範和文件,讓不少人覺得 RUP 很笨重;因為 RUP 通常伴隨著 UML,變成設計師或分析師與工程師之間,只有 diagram 而沒有溝通。所以在現實中需求是易變動的 context 下,為了平衡上述的 forces,宣言誕生了,以及後來的幾種方法 (就我的印象,有些方法誕生其實比宣言要早)。

《Manifesto for Agile Software Development》就這四條 (還包含一段關於如何解釋 over 的描述),看似簡單,但卻是很難達到的目標:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

即便使用 Scrum 或 Kanban 等方法,都不保證能達到上述的目標。

當軟體開發不再只是工程師的事,需要各種角色 (像是美術與企劃) 的參與,individuals and interactions 就需要考量到不同領域做事方式的不同,取得一個多方都能快樂工作的平衡點,這就很難。

當使用者對軟體的要求不再只是一個不會出錯的 working software 時,如何在設計的過程中考慮並溝通各式各樣的 non-functional requirements,以及如何在時程與完整性之間取得平衡,這就很難。

當開發的產品,其使用者是一般消費者,但需求的決定權是握在一個不在團隊中且很難約時間與他討論需求的老闆時,customer collaboration 就很難。

在有單元測試、持續整合的協助下,responding to change 對軟體工程師來說,確實比過去要輕鬆不少,但成本依舊是有的,但無法用單元測試和持續整合協助的部分呢?像是體驗、動畫、轉場、UI 風格等非功能性需求的變動,對於軟體工程師或非軟體工程師來說,有時候一個變更對他們來說卻可能是地獄般的加班,或是 product owner 得理解需要好幾個 sprints 來處理變更,此時 scrum master 能笑著臉對他們說:Responding to change over following a plan 嗎?很難。

既然很難,那就是這方法不好啊?何需要用?我一開頭說過,我不是個 agile software development 的推崇者,所以也不會推別人入教,更不會見人就說 XXX 方法好棒棒,用了之後專案絕對不延誤,開發人員一定很開心,準時上下班,因為根本沒這種東西。我也認為要做到上述宣言確實很難,要花費很多的心力,才能將核心的精神內化到團隊中。因為專案的屬性,當初團隊組成時,認為 Scrum 方法能幫助團隊順利開發產品,所以用 Scrum 方法一路走自今日。當初在接觸 Scrum 時看了《Agile Software Development with Scrum》這本書,書中用一張圖介紹 agile 方法適合的專案,我依稀還有點印象 (手上沒這本書,感謝 Teddy 贊助圖片),下面是自己的解讀 (沒書可以抄 XD)

raw-image
  • 若需求不明確且所需技術也不明確,即圖中右上角 chaos 那一塊,不論用什麼方式,風險都很高,只是 agile 方法能更早暴露風險。
  • 若專案需求明確,彼此共識高,所需技術也明確,也就是圖中屬於 simple 的那一塊,用 agile 方法、RUP、CMMI 或 waterfall 都不會差太多,大致都會成功,差在有沒有機制能讓團隊在專案進行中跟著進步。
  • 若專案需求明確,彼此共識高,所需技術不太明確,一般俗稱 R&D,屬於圖中間下方的 complicated 那一塊,waterfall 是不太合適的,因為在做計畫時,很難處理技術上的不明確,較合適的是能容納試誤的方法。
  • 若專案需求沒這麼明確,或是會變動,但所需技術明確,屬於圖中左側中間的 complicated 那一塊,那能盡早讓客戶見到產品,並隨著調整的方法比較合適。
  • 不過實際上的專案,大都會在兩個軸上遊走,也就是灰色的 complex 那一塊,因此能容納試誤與快速應變的方法比較合適。

有人看到這可能就會說:你就是在推銷 agile 方法啊,我可以很肯定說不是,事實上,只要團隊現行的制度能滿足上述的描述,就能在所屬的專案上進行的較順利 (只是比較順利,成不成功還要看很多因素),不用刻意導入什麼特定的 agile 方法,採取 agile 方法可能會對公司現有制度和文化造成衝擊,越是有阻力時硬推行一種方法其實都不太容易成功。重點是能適應所屬的專案生態,讓團隊成員開心積極地去完成專案,並讓客戶滿意,agile 方法只是眾多方法中,不少團隊使用後認為確實幫助他們解決問題的方法。上面那張圖還只是其中一個面向,要不要導入一種方法還要考慮到時程、成本和品質等面向。所以與其說,某方法已死,較合適的說法也許是視情境決定適不適合您的團隊。

2013 年,我在團隊的 release planning 中安排了幾個影片給團隊成員看,第一個是 Spotify Engineering Culture ,我個人很喜歡這分成上下兩集的短片,裡面有許多可以引起思考的東西:

第二個是 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr,因為產品已經進入準營運階段,我希望透過這影片讓團隊思考未來該如何順暢地營運產品。

本來,我還想安排第三部影片,就是 Dave Thomas (若不知道他是誰,你可以在剛剛的 Manifesto for Agile Software Development 網頁上看到他的名字) 的演講,題目就是《Agile is Dead》,但後來我決定不放進去,就自己的觀察,我們是有幾年 scrum 經驗的團隊,但在團隊成員增加與變動下,整體以『守、破、離』三個階段來看,還在等待破繭而出進入破的狀態,擔心這影片讓團隊往不預期的方向走。

看完影片後的問卷,可以發現團隊從影片中吸收了很多東西,也思考了很多東西。最近,接近 release 周期的尾聲,在我的建議下,團隊使用 Spotify 分享的《How we do large scale retrospectives》的方式,針對未來營運需求,討論團隊組成與制度的調整,會議中,我盡可能保持低調並讓參與的成員發言與討論,也很高興看到成員認真地思考問題並提出見解,幾次來回,與各自小組的成員討論 (在上個 release 週期,決定將一整個約 20 人的團隊拆成 2 個 feature team 與 1 個 OP team),並慢慢整理出一個結論,這過程中,一些《Manifesto for Agile Software Development》的核心精神真正內化到他們的心中。

像是會去思考,這樣的調整會不會只是開發 feature 的成員很開心,但營運的成員很痛苦,會不會只有寫程式的成員很開心,美術成員很辛苦?或是固定 iteration 的週期是不是真的適合不同類型成員的工作模式?一個 story 因固定週期與既有人力被切開後,在某些因素下,後續一些雖然不影響功能性卻影響體驗的小 story 在 priority 上被排到很後面或是被忽略 (我建議過 PO 試試 User Story Mapping 進行追蹤),導致產品雖是個 working software 卻不是一個團隊心目中 high quality 的產品。

可惜的是,新的團隊組成與運行機制,我不會參與到,因為一些因素我決定轉換跑道到別的團隊發展,但我覺得現在的團隊已經算是到『破』的狀態,已經是能 inspect 與 adapt (這是我認為很重要的核心精神) 的團隊,尊重彼此、思考與真心地自我檢討,雖然說還有很多地方能改進,我想這團隊在另一位 agile coach 的相互引導下,應該能順利繼續往下走下去。

最後,要給在考慮是否導入 agile 方法的人建議的話,先熟悉自己的 context 與要面對的 forces,思考後再決定是否導入,不需要為了那個名字而導入。如果想導入 agile,建議初期要找到對的 agile coach 或顧問,並在團隊內培養一位 agile coach,這位 agile coach 需要不斷地吸收內化精神並散播給團隊,讓團隊最後能自己解決問題,不然就很容易進入覺得練功無用,抱怨 XXX 已死的狀態。

其實某某方法已死,這種標題很多,像是 Continuous Integration is Dead 或是 Is DevOps Dead? LogicMonitor Suggests So But I’m Not So Sure,在讀這類文章時,我都建議先釐清作者所處的 context 及想平衡的 forces 有哪些?與他們做過哪些努力和遭遇的困難,再來判斷是否可以套用在自己的 context 中。

參考閱讀

avatar-img
53會員
104內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
你可能也想看
Google News 追蹤
Thumbnail
隨著理財資訊的普及,越來越多台灣人不再將資產侷限於台股,而是將視野拓展到國際市場。特別是美國市場,其豐富的理財選擇,讓不少人開始思考將資金配置於海外市場的可能性。 然而,要參與美國市場並不只是盲目跟隨標的這麼簡單,而是需要策略和方式,尤其對新手而言,除了選股以外還會遇到語言、開戶流程、Ap
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
學習生成式AI,不僅僅是掌握幾個工具,而是從全方位了解AI的發展範疇及其潛力。我經常在企業教授AI課程時,會遇到HR詢問:某些工具用不上,可以不教嗎?當然可以,但如果同仁不了解生成式AI在「數位內容」上的廣泛應用,又如何掌握大語言模型的發展邊界?
Thumbnail
敏捷開發的實踐方式有很多,其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》,其中調整的內容我覺得讓這個框架更符合實務上的應用,因此就其內容並結合個人經驗與見解撰寫這篇短文,希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
Thumbnail
在數位時代,Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件,並結合我開發CDP的實際經驗,分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum,優化專案流程。
Thumbnail
本文介紹了在公司專案中採用敏捷(Agile)方法,並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心:透明度、檢視和調整的核心,來推動敏捷工作。
Thumbnail
前年第一次藉公司機會,參加了DevOpsDay的活動。雖然devOps一詞各自表述,大多狀況還是偏向維運會遇到的技術為主,做為平時開發、跟使用者訪談需求的工作內容來說,參加聚會如果沒有一定的知識,對講者所提到的狀況比較難有共鳴...
ERP系統導入,有兩種常見的方式: 1。 專案開發,或者說完全客製,也就是成立專案,招一批人,量身訂做寫出公司使用的ERP系統。 2。 套裝軟體,像SAP、Oracle和Microsoft都提供ERP系統,顧問負責導入與規劃客製功能,因為套裝ERP系統不儘然所有功能都符合企業的需求,所以有些需求
Thumbnail
敏捷測試能有效幫助科技公司應對網路興起、軟體當道和資訊爆炸的挑戰,透過小型、跨功能團隊的協作與快速執行,並以用戶反饋進行快速迭代以測試產品假說。本文談到敏捷開發的迷思、MVP的重要性以及風險的注重,以及精實創業中如何驗證市場假說。同時提出敏捷的問題點,並結合同理心設計以滿足消費者情感上的需求。
Thumbnail
之前已經與大家談過讓我第一次挑戰就成功設計出有趣桌遊教具的「GO START」專案管理心法當中的 G、O、S,現在就來繼續分享 T、A、R、T。請容我再次強調,這是人人都適用的專案管理心法,上下兩篇一起看完後,你就會發現要掌握專案管理的要點沒有想像中那麼困難。
Thumbnail
與大家分享我第一次挑戰就成功設計出有趣桌遊教具的「GO START」專案管理心法。這篇先介紹心法當中的 G、O、S,下一篇會繼續分享 T、A、R、T。這是人人都適用的專案管理心法,上下兩篇一起看完後,你就會發現要掌握專案管理的要點沒有想像中那麼困難。
Thumbnail
隨著理財資訊的普及,越來越多台灣人不再將資產侷限於台股,而是將視野拓展到國際市場。特別是美國市場,其豐富的理財選擇,讓不少人開始思考將資金配置於海外市場的可能性。 然而,要參與美國市場並不只是盲目跟隨標的這麼簡單,而是需要策略和方式,尤其對新手而言,除了選股以外還會遇到語言、開戶流程、Ap
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
學習生成式AI,不僅僅是掌握幾個工具,而是從全方位了解AI的發展範疇及其潛力。我經常在企業教授AI課程時,會遇到HR詢問:某些工具用不上,可以不教嗎?當然可以,但如果同仁不了解生成式AI在「數位內容」上的廣泛應用,又如何掌握大語言模型的發展邊界?
Thumbnail
敏捷開發的實踐方式有很多,其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》,其中調整的內容我覺得讓這個框架更符合實務上的應用,因此就其內容並結合個人經驗與見解撰寫這篇短文,希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
Thumbnail
在數位時代,Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件,並結合我開發CDP的實際經驗,分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum,優化專案流程。
Thumbnail
本文介紹了在公司專案中採用敏捷(Agile)方法,並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心:透明度、檢視和調整的核心,來推動敏捷工作。
Thumbnail
前年第一次藉公司機會,參加了DevOpsDay的活動。雖然devOps一詞各自表述,大多狀況還是偏向維運會遇到的技術為主,做為平時開發、跟使用者訪談需求的工作內容來說,參加聚會如果沒有一定的知識,對講者所提到的狀況比較難有共鳴...
ERP系統導入,有兩種常見的方式: 1。 專案開發,或者說完全客製,也就是成立專案,招一批人,量身訂做寫出公司使用的ERP系統。 2。 套裝軟體,像SAP、Oracle和Microsoft都提供ERP系統,顧問負責導入與規劃客製功能,因為套裝ERP系統不儘然所有功能都符合企業的需求,所以有些需求
Thumbnail
敏捷測試能有效幫助科技公司應對網路興起、軟體當道和資訊爆炸的挑戰,透過小型、跨功能團隊的協作與快速執行,並以用戶反饋進行快速迭代以測試產品假說。本文談到敏捷開發的迷思、MVP的重要性以及風險的注重,以及精實創業中如何驗證市場假說。同時提出敏捷的問題點,並結合同理心設計以滿足消費者情感上的需求。
Thumbnail
之前已經與大家談過讓我第一次挑戰就成功設計出有趣桌遊教具的「GO START」專案管理心法當中的 G、O、S,現在就來繼續分享 T、A、R、T。請容我再次強調,這是人人都適用的專案管理心法,上下兩篇一起看完後,你就會發現要掌握專案管理的要點沒有想像中那麼困難。
Thumbnail
與大家分享我第一次挑戰就成功設計出有趣桌遊教具的「GO START」專案管理心法。這篇先介紹心法當中的 G、O、S,下一篇會繼續分享 T、A、R、T。這是人人都適用的專案管理心法,上下兩篇一起看完後,你就會發現要掌握專案管理的要點沒有想像中那麼困難。