Site icon Soul & Shell Blog

承認吧!其實你的敏捷開發不太敏捷!

1973-Philippe Petit
1973 年鋼索表演家:Philippe Petit

什麼是敏捷開發 (Agile)?

首先,我們先回顧一下古代的軟體工程與開發模式,在沒有敏捷以前,系統的開發週期往往很長,風險超高。怎麼說呢?以最常聽到的瀑布法開發模式 (Waterfall Model) 來看,一個產品的開發週期可以由以下幾個階段組成:

系統分析 (SA) > 設計 (SD) > 開發 (Dev) > 測試 (Test) > 發佈 (Market Release)

為了讓專案可以如期完成,前期需要花上許多時間進行這個假議題的規劃與設計,花這麼多時間是想要把可能犯錯的地方都仔細想過,好降低開發中的風險。那為什麼說是假議題呢?因為產品還沒上線,沒有人可以拍胸脯確保開發完成後,市場與消費者會願意買單付帳。假設這個開發週期需要 18 個月,我們仍舊無法保證一開始的市場需求在 18 個月後是否一樣存在與強烈!我們都知道世界變地很快,這些需求隨著時間變化也隨時都在改變,先撇開莫非定律與專案時程延誤這樣的肥皂劇,說穿了,在這假裝會準時的 18 個月開發週期裡,我們無時無刻都在承受風險!軟體開發掌握了太多我們不確定的因素,就像小丑走鋼索,搖搖欲墜。

適應變化的能力,比專案如期完成更重要

時程、資源、功能、品質

一個好的系統,時程、資源、功能與品質一樣重要,我認為沒有一定的解答,隨著變化及時調整比重是很重要的。RD 最不擅長回答 PM「做這個功能估計要多久?」,除了可愛的 PM,其他都是假的 (誤~)。畢竟我們都在做一件我們未曾做過的事,未曾開發過的新產品,要花多久時間除非做了才知道?所以才叫做估計!既然是「估」,那不準是理所當然的。再想想前面提到的 18 個月開發週期,真的很可笑!以人月神話這本書的專案時程規劃建議來看,一個健康的專案設計、開發、測試的時間分配比例如下:

哇,上圖有 1/3 的時間都在進行規劃與設計,假設 18 個月的開發週期,那可要花上半年進行規劃與設計。幾年前,我在工作上曾經與日本富士通 (Fujitsu 日本最大軟體製造商) 一同開發產品,還就真的花上半年時間進行設計,在沒有寫一行 Code 以前,把整的系統都在紙上先設計好,包含畫面、流程、訊息、測試案例、DB Schema 與 SQL Query 都已經寫下文件並審核完成 (話說不能寫程式真的很痛苦)。近百人經過半年嚴密的設計,那產品最後有沒有如期完成呢?你猜對了,一樣 GG!即使經驗豐富的架構師設想再周到,以使用者為優先的考量前提下,需求變更是必須的,沒有什麼不能改的。只是當時的開發模式不適合快速迭代與修正,日本富士通是非常注重品質,「Peopleware: 腦力密集產業的人才管理之道」這本書提到的開發團隊甚至有權利基於品質,延後產品上市的時間,或拒絕交付未達品質水準的產品到客戶手上。這件事情是真的,當時真的在品質堪慮的情況下 PM 直接打槍 (太有 Guts 了),社長補刀再開槍,品質至上!

經歷如此傳統的瀑布法開發模式,我深深體會到專案風險發生的可怕,其實很多風險在開發過程就已經被「識別」,但傳統的開發觀念跟不上,還是以時程功能目標優先,如此只會讓風險藏得越來越深,直到最後一刻引爆,你懂 der.......

我想,我們需要一種產品開發模式,可以快速迭代,最好可以讓這些準備會發生的風險提早發生,好讓我們改變作戰策略,決定下一步棋的位子。唯有將產品開發風險進行切割,快速反饋市場需求,才能夠在快速變化的世界中生存,物競天擇、適者生存。先別說這個了,你聽過敏捷開發嗎?

起初像個變形蟲,快速改變、快速適應,最後蛻變為高等生物!

敏捷是一種精神、一種態度

今天不談 Scrum, XP (極限編程), Kanban (看板開發) 等等方法論與實踐手段,我們先思考一下敏捷的目的。雖然我們知道的敏捷常用在產品開發上,但是敏捷其實是一種精神,是一種工作態度,一種信念,甚至也可以用在生活當中。比如媽媽到市場買菜煮飯給你吃,可以一開始已經想好要採購的項目,到了市場隨著接觸菜價與質量等等因素,本來想買的青蔥貴改買洋蔥,豬肉賣相不好改買魚,燒的飯一樣好吃。好菜上桌,這時候你怎麼沒大喊「媽!你這是需求變更!」,因為燒的飯好吃,符合市場 (你的胃) 需求,達到目的。

一樣地,對於工程師來說,把心力放在最有價值的開發項目,打造優雅的軟體架構,快速適應功能需求並實現,像是擅長接受「需求變更」的變形蟲,透過 Hack 精神達到目的,這些過程都是敏捷的實踐。對於產品設計師來說,找出最重要與最迫切的功能,獲得市場反饋後,快速修改,產品重新定位,透過反覆迭代達到 PMF (Product-Market Fit)。這些遠比準時花上 18 個月開發產品,最後不符合市場預期來的友善多了。產品定位、功能與需求有沒有變化一點也不重要,重要的是找到對的事,然後把它做好!

敏捷最大的目的是創造成功的產品,而不是實現 Feature!

敏捷的實踐

概念有了,再來是方法。仿間蠻多敏捷開發導入顧問,同樣與往年的 CMMI 要價不斐,我沒有接觸過,也不知道效果好不好。台灣目前比較常聽到開發團隊採用 Scrum 開發模式,如果你不了解敏捷的根本精神,少了信念,導入敏捷走到最終只剩下形式,下場跟幾年前的 CMMI 一樣 (話說 CMMI v1.3 以後也趕流行加入了 Agile 的元素),不知道為何而做?最終淪落到為了敏捷而敏捷,如果你既有的產品開發模式,已經可以快速適應市場變化,那麼你根本不需要導入什麼 Scrum,因為你已經走在正確的路上了,你只需要不斷的檢討與改善,不是嗎?

以敏捷常做的「站立會議」來說,站立會議主要的目的是快速溝通,用最有效率的方式掌握開發節奏,幫助我們隨時檢視有沒有違背敏捷的精神。如果站立會議變成只是交辦事項、殭屍會議、或者一日復一日的口述報告,那其實已經走偏了。好比 Scrum 中的 Sprint Plan,兩週的 Sprint 只是個建議,盲目的追求兩週的 Sprint,而無法在兩週後讓產品交付到客戶手上,那這樣的兩週一個 Sprint 沒有太大的意義,先想辦法先做到持續交付 (Continuous Delivery) 會更重要!沒辦法交付,就沒有市場反饋,你的 Sprint 只是瀑布模式的縮影,還不如叫做小瀑布開發模式會比較適合,一點也不敏捷。

遵循敏捷根本的精神與信念,比盲目追求敏捷的實踐更加重要!

期盼各位在錢燒完以前,可以找到對的事,然後做到最好!掰了.......

Exit mobile version