從最早接觸「敏捷開發」的概念,到最近觀察臺灣網路應用的發展方式,可以發現敏捷的觀念及方法,或多或少都影響了許多開發團隊的開發方式。這和二十年前剛入行時,所看到的樣貌,已經有了很大的不同。

早期常見的開發模式──瀑布式、RUP

在二十年前,大家所奉為主流的開發模式,基本上還是依循著「瀑布模型」的想法,也就是從分析、設計、設計程式、測試、到維護,一個階段完成後,到下一個階段去,直至完成。

不過即使如此,若以臺灣來看,這也不意謂著大家都能基於瀑布模型來開發,用土砲方式來開發的小型團隊也不在少數──想做一個軟體,有一個大略的想法,於是就開始動手做了,沒有確切的規格,但也不會因為沒有規格,就不開始做,所有的事情,都是都混在一起來做。

當然,有一陣子方法論的風氣興起,也有不少人直接一步踩進了嚴謹開發方法的領域,光是相關文件的產出,就足以投入極高的人力。但是無論如何,儘管「土砲式」的開發仍然可以看到,但是比例也愈來愈低。而採用瀑布模型的開發團隊,卻是愈來愈少。有一陣子,像 RUP(Rational Unified Process)這樣重量級的迭代型開發方法,大行其道,但是,現在幾乎沒看到有人在用了,尤其是網路應用產業裡。

很多團隊,即使沒有採用真正純粹的敏捷開發方法,但他們的開發方式本身也是朝著敏捷化在進行。敏捷化的開發,之所以愈來愈受歡迎,和網路應用產業的特性,絕對密切相關,尤其現在網路應用,幾乎是我們開發軟體的最大重點了。

Scrum興起,許多團隊紛紛採用敏捷式開發

1995 年,在OOPSLA'95的研討會上,Sutherland和Schwaber共同發表了一篇論文,介紹了Scrum開發方法。而在1996年,Martin Fowler、Kent Beck、Ward Cunmingham三位,開始將 XP 開發方法導入著名的C3專案。這個時間點正好要進入Internet應用開發的起飛期。

到了1999年正式進到.com 泡沬期,不知多少英雄好漢,都投入了Internet應用的領域,推出各種不同的新穎應用,即使.com 泡沬化了,但Internet應用的發展,仍然如火如荼,毫不停歇。時至今日,我們所接觸的軟體應用,有很高的比例,都是基於連網的特性而來的。所有的新創軟體團隊,做的幾乎都是網路應用。

在臺灣,你甚至可以看到不少新創應用的開發團隊,都強調他們使用敏捷的開發方法,我更進一步相信,敏捷開發的興盛,和網路應用領域的生態,是相輔相成的。

怎麼說呢?最重要的影響因素,是因為網路應用的開發步調。

開發與部署網路應用的速度,越來越快,時時必須因應變化

網路應用開發的步調,不同於傳統軟體。在過去,我們開發一個軟體,可能會將開發時間,拉到一年左右的時間規模(或更長,也是常見的)。所以,在決定啟動開發的程序之後,在一年後(順利的話)完成軟體,然後,推到市場上發行、或是交付予客戶。

但是,網路應用軟體的發行週期可不是這樣,透過網路,收集使用者回饋的意見更快,同時這也意謂著接收市場的回饋更快,當多個競爭者同時進來角逐市場時,更逼使各家必須更快速的因應競爭者的活動及產品擬定對策,並且做出調整。

因為連網的關係,網路應用軟體的發行,遠較傳統軟體簡單,它們不需要再用磁片或光碟片遞送至使用者端,只需要透過網路即可隨時更新。

進行軟體更新的成本變得低廉許多,更重要的是速度,從決定發行到使用者完成更新,最快可以在幾秒內完成。

因此,網路為軟體開發帶來的最大衝擊之一,就是速度。當Web成為連網應用的主流時,這軟體更新的速度更快了,只要完成軟體部署,所有的使用者用到的,都是最新版了!

現在的網站,甚至可以同時部署帶有些許不同的兩個版本,藉以測試對照組及控制組兩組使用者的反應,來決定之後功能應該如何演進,這就是網路所帶來的速度。而網路為軟體開發活動帶來的速度,致使開發方式勢必不同於傳統。

在網路的快速度之下,發行週期大幅縮短。一個新的應用,其首次推出的版本不能花太多時間,否則,在水面下划水、有著類似想法的競爭者,也許就在你初次發行之前,就搶先發表,同時也取走了市場的占有率。

而在初次發表之後,改版的週期同樣不能太長,因為市場的變化很快速,競爭者也處心積慮地想要搶佔更多使用者的青睞,因為必須透過快速的改版,來回應使用者的需求,並且在自己所設定的方向上,繼續邁進,同時,去修正、優化已經察覺的缺陷。

對於網路應用軟體,我們很難想像,每次改版的時間要花上半年至一年,但過去,傳統軟體開發的確是如此。也因此,在傳統軟體開發上,在一開始會決定所有完整的範圍,然後,著手分析、設計、撰寫程式、……。而下一次的改版,又是一個不小的範圍。

然而,網路應用軟體的開發,很少人這麼做了,只有初版開發之前,因為全無基礎,所以會擬定一個初步能運作、展現主要概念及功能的範圍,盡可能在愈短的時間內推出第一版,收集市場反應,擬定改版的方向(或是決定放棄)。之後,也會透過非常頻繁的改版,來修正問題、添加新功能,使得所做出來的軟體,更符合使用者的喜愛。因此,光是決定每個版本間需求的範圍,就和傳統的方式大相逕庭。

因為快速的需求變化,所以,即使一開始,或是在過程中,開發團隊會維護一張長長的需求清單,但是,並不代表他們打算、必須把這些需求,一次做完。

因為,發行的時間縮得很短,所以,每次只能從中挑出最重要的需求來執行,等到發行後,收集反應後,再決定是否重新排列這份需求清單,以及是否加入新的重要需求。而且,軟體是活的、像是做不完似的,有些列在清單裡的需求,甚至還沒有被實作,就被決定捨棄了。

因為網路所帶來的速度,導致我們管理發行及需求的方式大大的改變,進而影響軟體的開發方法。所以,你應該知道,敏捷開發的方法,正是瞄準這種需求模型而來的。

在網路應用蓬勃發展的這些年,也正是愈來愈多團隊採用敏捷開發方法的時候,而這二者應該是存在相關性的。

當我們面對網路應用軟體在開發時的需求本質時,顯然傳統那些重量級的開發方法不那麼容易對應。尤其,新創應用的團隊,很多都是很小型的開發團隊,過於重量級的開發方法,更會拖慢開發的步調。

但敏捷開發則不同了,一方面,規模上適合小型團隊﹔二方面,也是針對需求變化迅速的情況而設計的。

由於敏捷開發本質上,和網路應用的快速度變化,十分契合,所以,我們能夠預測:對於網路應用服務或軟體的開發而言,採用敏捷觀念來開發的人,還是會愈來愈多。

作者簡介


Advertisement

更多 iThome相關內容