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 中。

參考閱讀

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
你可能也想看
qPCR試薬市場2022-2028:成長分析(新しいデータインサイト)、主要な開発| Agilent Technolog市場の現状と将来展望に関する包括的な洞察を提供する、自動車照明市場2023年調査報告書がリリースされました。当レポートでは、業界の市場動向、成長促進要因、課題、機会などの詳細な分析に加え、競争環境と市場主要企業の市場シェア分析についても徹底検証しています。https://news8.de/schei
avatar
prasad khandekar
2023-07-21
2023 Agile Kaohsiung 7 月聚會:給學生與職場新鮮人的敏捷概念終於有機會在南台灣推廣敏捷概念,舉辦敏捷實體聚會,主題為 - 給學生與職場新鮮人的敏捷概念,關於什麼是敏捷軟體開發流程,這裡就不多做贅述。 很高興這次請到Hermes南下,共同與我分享有關學生的敏捷主題內容。 在等待陸續進場的觀眾時,Hermes很細心地幫我們引領現場,讓已經到位置上的觀眾,先進行一
Thumbnail
avatar
Ivan Chiou
2023-07-09
avatar
We Are Young Family
2023-05-15
超級競品Aglet乘著這波Move To Earn跑步賺錢熱潮不少仿盤蜂擁而出, APP需要授權查看剪貼簿才能使用複製功能 與其他軟件一樣 安全性個人認為是沒有問題的 由於經濟模型尚未公布,無法確認具體Earn的方式 也注意不要投入過多本金反被Earn
Thumbnail
avatar
Wing Wei
2022-05-14
AgletX新的move to earn項目(第38篇)項目名稱:[ Aglet ] 項目介绍:一款非常新的 move to earn 的 GameFi、SocialFi 這是一個類似stepn的move to earn遊戲 本來好像是天氣類型的APP後來轉型的 直到最近這幾天上架後才開始有聲量 我去深入追查一下項目背景 遊戲玩法很簡單
Thumbnail
avatar
kevin111
2022-05-09
越走越賺Walk to earn 新項目Aglet越走越賺Walk to earn 新項目Aglet 幣圈天天都有新鮮事,今天又發現了一款跟sweatcoin很像的項目叫Aglet, 是一款非常新的 move to earn 的 GameFi、SocialFi,互動功能做的非常好,有加入寶可夢尋寶箱打道館的概念,這部分的激勵機制真的會讓人一直想要走
Thumbnail
avatar
Elena
2022-05-08
<享音樂>如初雪般走向你-Ailee(孤單又燦爛的神-鬼怪)/如雪花飄渺虛無,又短暫的愛。 「 漆黑的永遠、 在哪久遠的等待之中、 你如同陽光般灑了下來 」 曾困在深不見底的黑暗, 是你帶來了希望。
Thumbnail
avatar
嵐茵🌸雜談
2021-10-19
A Great Big World 和 Christina Aguilera 的兩次傾情對-寫於2020/12/14     Hi there,如果是有在關注Christina Aguilera的粉絲一定會知道,他和A Great Big World的兩次合作,都是非常感人動聽的作品,或許後者的名氣比不上傳奇的 Christina,但是在這兩首歌曲的合作上卻真的功不可沒,今天就想來分享
Thumbnail
avatar
睿忒
2021-07-30
用敏捷開發(Agile)看波段投資經歷了無數次的軟體開發與來回,赫然回首才發現,每一次的開發、討論、決策與檢討的過程,其實正恰如我們做的每一分投資決策跟資產分配。或許觀點與決策的內容大不相同,但我們可以運用本質上的邏輯,以軟體開發的思維檢視我們的投資組合以及策略,更可以進而反覆執行,找尋屬於自己的獲利循環。
Thumbnail
avatar
艾斯杰 SJ
2021-07-12
[Meetup 筆記] 反覆試探、修正的工作框架──從Cynefin Framework看Agile推廣Agile(敏捷開發)的時候,無可避免會遇到一條提問:到底Agile 能夠解決甚麼問題?這條提問並不容易回答,而Cynefin Framework 可以幫助我們更清楚地描述Agile 適合解決的問題性質。
Thumbnail
avatar
CY L.
2019-09-14