目前大多數企業組織都已採用某種形式的敏捷式開發（agile development），但也並非完全這麼順利。想要了解敏捷式開發為何成功，那麼回顧瀑布式開發的鼎盛時期，與敏捷式開發宣言（Agile Manifesto）的出現，都能有所助益。

文／Isaac Sacolick ‧譯／兩三松

現今每個企業的技術部門，似乎都在實作某種版本的敏捷式開發方法；或者至少團隊相信確實如此。無論是軟體開發新手，或是有十餘年經驗的老手，目前的工作或多或少都有受到敏捷式方法的影響。

【推薦文章 ：11 種立即降低 IT 成本的方法】

但究竟什麼是敏捷式開發？開發人員和企業組織之間應當如何採納敏捷式開發？本文簡單介紹敏捷式開發的歷史，以及它與經典瀑布式開發的不同處。文中將透過實際案例來比較敏捷式與瀑布式開發之間的差異，並解釋為何敏捷式開發在目前的開發環境之中，更適合開發人員與團隊的實際工作模式。

在敏捷式出現之前：了解傳統的瀑布式開發方法

老手們應該還記得瀑布式開發方法論，它曾經成為軟體開發的業界標準。在開始撰寫程式碼之前，只要採用瀑布式，就需要預先準備大量文件。通常該過程從業務分析師撰寫業務需求文件開始，該文件會從應用程式中蒐集業務需要。這些文件落落長又很詳細，包含從整體策略，到全面的功能規格，以及視覺化使用者介面設計等方方面面。

【推薦文章：推進 IT，調配有限人力與 CIO 領導力是關鍵 】

技術人員依照業務需求文件，接著產出技術需求文件。該文件定義出應用程式架構、資料結構、物件導向功能設計、使用者介面與其他非功能性需求等。

待業務與技術需求文件完成後，開發人員將開始撰寫程式碼，接著進行整合工作，最後投入測試。上述這些工作，都必須在應用程式正式上線之前全部完成。整個過程很容易耗上好幾年時間。

瀑布式開發方法論的實際應用狀況

瀑布式開發的相關文件，通常被稱為「規格書」；開發人員應該和文件原作者一樣了解這些文件內容。不然開發人員可能因未能正確實作關鍵細節（像是在 200 頁文件裡的第 77 頁概述），而受到責難。而使用軟體開發工具，也需要經過專業培訓，但其實能選擇的工具並不多。因此開發人員常常被迫自行開發所有底層所需的工具，像是開啟資料庫連結與多執行緒資料處理等。

即使對於基本的應用程式，通常也會因為團隊規模很大，造成能用的溝通工具有限。過程中必須讓所有技術規格書能夠保持一致性，協助所有人能像閱讀聖經一般地遵守這些規範。如果需求發生變化，業務負責人得走上一趟漫長的審查和簽核流程。在整個團隊中，想要溝通變更與修復程式碼，可是一趟昂貴的程序。

[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球CIO同步獲取精華見解 ]

由於軟體是基於技術架構進行開發，因此一開始會開發系統底層的構件（artifact），接著再開發依賴底層構件運作的上一層次構件。由於開發任務是依人員技能進行分配，因此會讓資料庫工程師先建立資料表（table）與其他資料庫構件。然後應用程式開發人員接著撰寫程式功能與業務邏輯程式碼，最後寫出使用者介面。通常需要耗費幾個月時間，才能看到該應用程式能夠執行。但等到那時，相關利害關係人通常已覺得焦躁不安，而且往往看到成品之後，才更清楚他們實際需要的功能是什麼。也因此讓修改程式的成本會非常高昂。

最糟的是到了最後，並不是所有呈現在使用者面前的功能，都能夠依原先規畫順利執行。有時，使用者根本不會使用其中某項功能。其他時候，某項功能獲得了廣泛成功，但需要重新設計，才能支援可擴展性與提升效能。在瀑布式開發的世界裡，只有在軟體部署下去之後才了解實際狀況，中間必須經歷一整個漫長的開發週期。

瀑布式開發的優缺點

瀑布式開發約在 1970 年代發明，當時具有革命性意義，因為它為軟體開發帶來紀律，並確保有明確的規範可供開發人員遵循。瀑布式開發基於源自亨利福特在 1913 年汽車裝配線的創新瀑布式製造方法，該方法為生產過程中的每個步驟提供了確定性。瀑布式開發旨在確保最終產品，能與最初要求的產品功能相符。

當軟體團隊開始採用瀑布式開發時，運算系統與對應的應用程式，通常是複雜且單一的，需要提交有紀律的明確結果。與目前相比，當時需求的變化緩慢，因此可能產生的大規模問題較少。事實上，當時的系統是在假設它們不會被更動，而且永遠要擔任戰艦級繁重任務的情況下所建置的。設定耐用多年的時間框架，不僅在軟體開發中很常見，而且在製造業與其他企業活動中頻繁出現。但隨著網路時代到來，瀑布式開發的僵化性卻成為弱點，顯得速度和調度靈活性變得更加珍貴。

改採敏捷式開發

當開發人員開始開發網際網路相關應用程式時，軟體開發就逐步發生了變化。許多早期工作是由新創公司完成的，這些新創公司的團隊規模較小，蝸居於共享辦公室裡，而且通常創辦人並不具備傳統的電腦科學背景。他們必須將網站、應用程式與新功能更快推向市場，面臨著財務與同業競爭壓力；而開發工具與平臺也因此隨之快速更改。

這導致了許多在新創公司工作的開發人員質疑瀑布式開發，並尋找更有效率的方法。由於要預先完成所有詳細開發文件實在不划算，因此開發人員需要找出一個更能協助版本迭代與共同合作的工作流程。開發人員會爭辯需求更動是否必要，但對於依使用者回饋調整軟體則抱持著更開放的態度。新創公司的組織結構比較扁平，應用程式也不像企業傳統大型主機系統那麼複雜，因此更願意建置而不是購買應用程式。更重要的是，新創公司正在努力發展業務，因此當使用者回應某些功能無法順利執行時，開發人員通常更樂意聽取來自使用者的意見。

【推薦文章 ：生成式 AI 應用在軟體開發領域】

此時企業組織要擁有創新的技能與能力，變得更具備策略上的重要性。新創公司可以募集到想要的所有資金，但卻無法吸引有才華的軟體開發人員，這些開發人員熟悉如何使用變化快速的網路技術，然後被強迫遵循「規格書」。開發人員可不會接受，那些採用從起點到終點緊湊時程表來安排專案時程的專案經理意見；在這類時程表裡詳細描述了應當開發什麼、何時應提交應用程式，有時甚至包含如何撰寫程式碼架構。開發人員其實很難完成這種僅由專案經理起草，並不斷洗牌的一季或半年開發時程表。

其實專案經理可以事前知會開發人員網際網路應用程式需要投入的細節，並按照雙方協調的時程表逐步交付成果。當開發人員每隔一到四周就能完成承諾的工作項目時，就能發現提交程式的進度並沒有想像中那麼糟。

在 2001 年，一群經驗豐富的軟體開發人員意識到，他們正在集體實作與傳統瀑布式開發不同的軟體開發方法。其中並不是所有人都在新創公司。該小組包括技術名人 Kent Beck、Martin Fowler、Ron Jeffries、Ken Schwaber 與 Jeff Sutherland，他們共同提出了《敏捷式開發宣言》，記載他們對現代軟體開發流程應當如何運作的共同理念。強調協同工作比文件規範更重要，讓團隊自發形成管理組織而不採取嚴格階層管理；以及管理需求持續變動的能力，避免被封鎖在過於嚴謹的瀑布式開發流程中。從這些大原則出發，軟體開發界的敏捷式開發方法論誕生了。

為何敏捷式開發能夠提供更好的軟體

當企業採用敏捷式開發原則，透過敏捷式框架實作，利用協同工作工具，並採用敏捷式開發實作時，通常能獲得品質更好、開發速度更快的應用程式。同時還可以獲得更好的技術方法論，也就是心態衛生因子（hygiene）。

主要原因是，敏捷式開發是為了靈活調整與適應能力所設計出來的。開發人員並不需要像瀑布式開發那樣預先定義所有答案。將問題分解為易於理解的部份，然後與使用者一起開發和測試。如果某些事情進展不順利或未達到預期，又如果工作當中發生了之前沒有考慮到的事情，開發人員可以調整工作並快速回到正軌，甚至在需要時改變原先的規畫。敏捷式開發讓每個團隊成員都能為解決方案做出貢獻，並要求每個成員對各自工作承擔責任。

【推薦文章：10 大低程式碼/無程式碼開發安全政策 】

敏捷式開發的原則、框架與實作，都是針對現今企業營運條件而設計的。敏捷式開發通常會優先考慮迭代開發，並利用使用者回饋意見來改進應用程式和開發流程。迭代與回饋，都非常適合目前更聰明、更快速運作的世界。

敏捷式開發也鼓勵開發人員持續改進系統。想像一下，如果微軟在 Windows 3.1 版之後就停止開發 Windows 作業系統；或是 Google 在 2002 年就不再改進搜尋演算法，會是什麼樣子？敏捷式開發為軟體的持續改進，建立起良好的開發心態與流程。

最後，敏捷式開發可以帶來更好的軟體，因為敏捷式開發團隊的人員通常效率更高、更快樂。程式設計師對所承擔的工作量有發言權，並且能夠自豪地展示開發成果。產品所有者喜歡更快地在軟體中看到他們的願景被實現，並能夠根據最新的洞見改變調整的優先順序。而使用者更喜歡獲得能夠完成實際工作需求的軟體。

如今企業需要高水準的軟體應用能力，才能在競爭激烈的市場環境中，為消費者提供卓越的數位體驗。企業需要吸引並留住優秀人才，以建置優質的好軟體。而敏捷式開發正可以協助企業達到以上兩點要求。

(本文授權非營利轉載，請註明出處：CIO Taiwan)

內容來源