用敏捷性對應網路生態的快速變化

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

早期常見的開發模式──瀑布式、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成為連網應用的主流時，這軟體更新的速度更快了，只要完成軟體部署，所有的使用者用到的，都是最新版了！

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

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

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

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

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

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

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

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

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

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

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

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