進度條

瀑布式還是隕石開發法?那不如試試看迭代開發吧!

天神沒事就落隕石嗎?老闆在上任何技術大神都無能為力,或許迭代開發能幫助你喔

作者: Vincent Ke 更新日期:

這是網路上流傳一副頗具盛名的隕石開發法,大意就是老闆(或是主管)就是天神,而需求就像隕石一樣的往地面上的工程師砸來,而認命的我們似乎只能認份的加班,來實現老闆千奇百怪的需求隕石海,而這樣的開發方式,通常都是大家心中最軟的一塊,因為時間有限,但需求的量總是供不應求,最後面對的,就是加班地獄。

 

 

 

 

 


但或許,我們可以換位思考一下,在過去許多專案中,往往只有在交付驗收的當下,才有辦法讓老闆(或客戶)窺見所有開發功能的全貌,當中若是一部分的UI / UX 設計不得青睞,可能就會面臨到架構重組或是砍掉重練的命運。

 

 

 

 

若是我們可以透過定期交付每個產品功能中的「最小MVP」,並透過階段性驗收的方式,是不是就可以翻轉掉我們無限加班,改之又改的苦情命運呢?!

 

延伸閱讀:想創業又怕血本無歸?不如試試看「精實創業」與MVP「最小可行產品」

 

是的,你沒聽錯,這樣的開發方式,其實就是所謂的「iterative development 迭代開發」。

 

 

在過去傳統的開發方式中,從產品需求的談定→設計,之後到工程師的開發→驗證→QA最後到上線,都會有一個固定不可逆的循環,而這樣的循環目的,也是為了不讓需求的變更,造成整個產品的設計架構與開發需要重新討論,而依循這樣的流程開發,也是所謂的瀑布式開發(Waterfall)。

 

 

 

 

所以每一個環節除了確認之外,更需要透過文件的產出,來讓大家了解每個階段SPEC與需求是什麼,而開發時間就會依據需求或是產品的上線時間來做討論,但倘若文件溝通之中,只有稍有誤差或是理解上的不同,就有可能讓整個產品的科技樹變得歪斜。

 

 

之後就是各位熟悉的,上線在即,但需求卻不是業主或老闆想像中的那樣;更別提中間沒有擴充或新增需求的彈性在。

 

 

 

 

而迭代開發法,其實所追尋的流程也是如同上述:產品需求的談定→設計→開發→驗證→QA→上線,但不同的事情是,把一個巨大的開發週期,都切割的更加細小,每個週期大概可到2~4,並且在開發上秉持的「先求有,再求好」的最小MVP概念。

 

 

儘管知道每一個功能都仍有不足之處,但在每一個開發週期中,最主要的目的卻不是把功能做到最好,而是把功能先產出來提交給業主確認,並在透過訊息的反饋,來讓改善有更明確的方向。而這樣的方式也許前篇文章提到的「最小MVP」概念,更是不謀而合。

 

 

與過去傳統的瀑布式開發比較,也可以確保在某些不明確的需求訊息,或是開發過程中遇到的灰色地帶時,所做的開發決定是否可以和業主的想法有相關呼應,也可以確保不會有房子已經蓋好,卻發現從住家變成旅館這樣的大幅更改。

 

 

 

 

而迭代開發的流程中,除了上線之外,在下一次的開發前,也和Agile(敏捷式開發)一樣,會Daily standing up meeting以及導入retrospect的機制,來讓團隊成員省思這次的開發週期中,是否有什麼樣的問題,造成開發流程的不順,而成員各自也可以透過這樣的機制,來分享本次開發上遇到的難題與心得。

 

 

 

 

所以迭代開發的用意,其實有點像是在傳統的瀑布式開發之中,把一座偌大的瀑布,切割成許多小瀑布,而這些小瀑布之中的開發,並非求的是功能上的完善,而是結合最小MVP的概念,先求有,在確認之後,在透過迭代的方式,把功能做好做滿。

 

 

而當中其實這樣的模式也和敏捷式開發上有些雷同,只是在敏捷上,更著重在團隊成員間的自律與需求的改變上,如果說敏捷重的是心法,那迭代開發重的是框架。但如果其中有些手法上的交替使用,例如透過User Story來做需求上的討論,也未嘗不可喔。
 

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧