投身 IT 行業,什至參與 Programming 和 Project Management 都會了解多種不同的工作階段,例如聽取要求、寫文件、分工、開發、測試。開發軟件、系統、整個方案,以及項目管理的手法作風,都有數種不同方法去達成目標。以前,電腦發展是初步階段,專才對程式開發的管理和編排上尚未成熟,沿用流水式作業(Waterfall Model)

流水式作業,乃劃分整個開發目錄成以下工序,按時完成:聽取要求、分析、設計、寫文件、分工、開發和測試。昔日的項目簡單,要求客觀清晰,固定不變,所以團隊可以共同訂立每一個工序的起始和結束時間,以及嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序,驅使不少IT專才,什至工程行業採用之。借建築地下鐵路而言,就是訂下第一年一月一日去確認建設什麼,採用什麼藍圖,第一年三月一日去演說一個工作進程和時間表,告訴其他團隊用多少資源,多少人力,和建築大計,第一年四月一日就開始分工上馬,訂立第三年一月一日竣工,中間某月一日則報告進度之。

只是,科研進步神速,社會發展蓬勃,人心因此多變。自 80、90年代,開發專員更重視 Design By Module,引進 Object Oriented Design,顧客開始利用互聯網、電視、電台去了解和試用周邊電子產品。團隊沿用流水式作業模式,一聽需求改動就砍掉重練,由頭再做。為求應付多變的市場需求,可重用已開發模組,就衍生了 Prototyping 的概念,叫開發團隊先開發一個初階版本或部份程式讓顧客接受,再改良之。

Prototyping 乃 Agile Development Model 的雛型,以釐清系統需求或確認開發可行性為依歸的開發工序。 Prototyping 著重項目限期前多次示範部份程式藍本,促進用家、設計師、開發專員之間的互信和溝通,提倡不斷修改和改良去實現用户主導的實踐概念。每一個頂目都可以分為三至四個時間點,去完成某個模組,監測功能之。當中完成的程式就是行內人所說的樣板 – Prototypes (雛型)。

當開發團體積累Prototyping 的經驗,時至久之,Agile Development Model 就應運而生。

Agile Development Model 以不斷的 Iteration 或叫工作順序,去完成一個系統或頂目。每一個 Iteration,是包括收集需求、分析、設計、編碼、測試、驗改,而且,以上的次序可以隨意加插或調換,去完成一個最貼近市場需求和未來發展的科研產品。開發團體更可以根據過往經驗,優先研發多種常用模組如轉化 JSON 成 Object Classes、HTTP Get Post 的處理方法、或縮小背景圖片去裝嵌不同尺寸的屏幕‥‥‥等等。

以上協作模式除了可以適應不斷改變的外來環境和需求,更可以透過模組、排序和分工去減省人力資源和開發時間,實現開發自主,提供管理層更大自由度和彈性去監督進度。最近最興的程式如 Java , Swift, Objective-C 等等,已經完全實現 OO Design,用字上更接近人類所用的語言,教新加入的開發者更易上手和新增模組。不過,如果管理層多次誤判,或初次開發時需求收集得不足夠,會教開發團隊不斷衝住開發不完整的新模組,什至按上司要求加多幾頁,沒有足夠時間去分析新加專頁和以往設計間可以重用或模組化的地方,倍增開發團體的壓力,下降程式編寫的專注力和質素。萬一開發系統遇上設計缺憾和資源使用過多(如 Load 圖唔夠 RAM,出 OutofMemoryException),最終走上開發工序的兩難局面:

1. 改良設計

2. 再加新項

由此可見, Waterfall 與 Agile Development 各有千秋,沒有比某一個作業模式更高尚。要視乎項目的本質和需花的人力資源如何去採用哪一種作業模式,什至採取兩者,視乎項目管理和開發團隊之間的要求。我個人傾向使用後者的協作模式。現今社會和人心變遷的速度比以前快,大眾更需要學習如何快速學習新知識,然後用上手。如今大部份的 Programming Language 都可以 OO Design 的 概念去間發,加速減省開發時間,騰出更多時間去檢測和學習新寫法。而且,Agile Development Model 的作業模式更可應用至不同專業範疇,有助更短時間內完成目標,包括社運抗爭。