當我們談論軟體開發，許多人腦海中第一個浮現的詞就是「敏捷（Agile）」或者 Scrum。然而，敏捷開發並不是軟體生命週期的全部，它只是其中一種方法。

我們需要理解軟體生命週期（SDLC）的全貌，了解軟體開發不是只有敏捷，敏捷開發也不是只有 Scrum 模型，還有其他各式樣的方法。

傳統模型：僵化的流程

瀑布模型的起源，可追溯到 1970 年 Winston Royce 所發表的一篇論文。他最初提出的是一個具有反覆循環的流程，但卻用一張簡單的線性圖來作為開場，沒想到後來業界卻只採用了這張圖，並將其僵化為一種嚴格的開發模式。

後來瀑布模型與軍事專案有著深厚的淵源，這份模型最早被應用於軍方的大型硬體和軟體專案，這些專案的共同特徵是：

• 高風險
• 高成本
• 需要嚴格的控制與文件紀錄

瀑布模型的核心思想是：將開發過程拆解成一連串線性、按部就班的階段。這種模式強調在開發前進行詳細的需求分析，並認為完整的文件對於大型專案至關重要。

然而，軟體的「需求」總是隨著市場與用戶而持續演進，瀑布模型的致命弱點，就在於其僵化性：無法應對變動，導致用戶反饋太晚。

演進模型：早期對彈性與速度的嘗試

面對瀑布模型的困境，工程師們開始尋找更靈活的替代方案。

• 螺旋式模型（Spiral Model）：這是 1988 年由 Barry Boehm 發表的模型，的這是一個早期的混合模型，它將瀑布的線性階段與反覆的「螺旋」週期結合，並在每個週期中加入風險分析的環節。這使得專案能夠分階段開發、持續驗證，有效降低了專案失敗的風險。

• 快速應用程式開發（RAD）：這個模型由 James Martin 在 1991 年系統性地提出，專注於快速交付。它減少了前期的計畫與文件，並透過快速原型開發和不斷迭代，來獲取用戶反饋。這也代表開發會大量使用自動化工具，並鼓勵與用戶的緊密協作，以應對不斷變化的需求。

常見迷思：認為只有 waterfall 或 Agile 方法

從 1970 年瀑布式開發方法發表至今，半個世紀以來，軟體開發的方法論從未停止演進。除了 Spiral Model、RAD 和 Agile 之外，實際上還有許多各式各樣的迭代模型與方法持續被提出並實踐。

我們需要知道的是，方法論不是靜態的。它是一直在演進的，目的就是為了因應不斷變化的時代和需求。理解這份演進的本質，能幫助我們跳脫框架，不再只認為軟體開發只有少數幾種模型，而是能夠從中選擇最適合當前專案的解決方案。

敏捷宣言（Agile Manifesto）

在 2001 年催生了敏捷宣言（Agile Manifesto），它倡導四個核心價值觀：

1. 個體與互動重於流程與工具
2. 可用的軟體重於詳盡的文件
3. 客戶協作重於合約協商
4. 回應變化重於遵循計畫

這個敏捷宣言至今仍然影響著各種方法，是各種敏捷框架的核心本質。敏捷的本質，並非追求「快」，而是強調對變動的即時反應與彈性。它不是一套單一的流程，而是一套指導原則，涵蓋了多種開發模式

• Scrum：這是最廣為人知的敏捷框架，起源於 1990 年代。它將開發過程拆分為固定時間的短週期（sprint），並通過 standup meeting、sprint planning、 Sprint Retrospective 等事件來確保團隊的協作與透明度。
• 看板（Kanban）：看板是一種專注於工作流程可視化的方法，由 David J. Anderson 在 2000 年代中期應用於軟體開發。它不使用固定的時間週期，而是透過限制進行中的工作（WIP），來優化工作流程的效率，實現持續交付。
• 極限編程（Extreme Programming, XP）：XP 是一套專注於工程實踐的敏捷方法，在 1990 年代末期由 Kent Beck 等人提出。它提倡結對編程（Pair Programming）、測試驅動開發（TDD）、持續整合等嚴格的工程實踐，旨在提升程式碼品質與團隊效率。

Scrum 的成功：恰到好處的平衡

Scrum 的成功，在於它在「簡單」與「完整」之間取得了絕佳的平衡。它提供了一個清晰、易懂的框架，讓任何背景的團隊都能快速上手。

Scrum 的規則和角色非常簡單：

• 三個角色（Product Owner, Scrum Master, Team）
• 五個事件（Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprint）

這份極簡的設計，讓團隊無需花費數月時間來學習複雜的理論，就能立刻開始實踐。它就像一個「敏捷入門工具包」，為那些想要從傳統模式轉向敏捷的團隊，提供了一個低門檻、高效率的起點。

敏捷方法的混合變體

Scrum 並不是唯一方法，也不是唯一標準，許多組織為了因應需求或是組織結構而調整 Scrum 方法，例如：Scrumban、Scaled Agile Framework - SAFe、water-scrum-fall。

最常見的變體是局部導入 Scrum，例如只採用 standup meeting 和 sprint retrospective，並將其與公司現有流程結合。

另一種常見的混合模式是 water-scrum-fall。此流程先透過瀑布模型進行完整的需求規劃，接著以 Scrum 進行開發，最後再回到 waterfall 的驗收與發佈階段。這種做法平衡了事前規劃與敏捷開發，同時滿足特定組織的需求。

總結與常見迷思

瀑布或 Scrum 都只是軟體開發方法中的其中一種，隨著組織的擴張與變化，都會發展出最適合自己的獨特方法。

文章也希望破除以下兩個常見的迷思：

1. 採用敏捷開發不一定要使用 Scrum。
2. 軟體開發方法不只有 waterfall 或 Scrum 這兩種選擇。

選擇軟體開發方法就跟技術選型一樣，必須綜合評估團隊、業務等等方面，這些方法的終極目標都是希望達成公司的目標。如果下次遇到團隊想要改變方法時可以思考以下幾個問題：

• Scrum 適合我們嗎？
• 團隊成員有辦法滿足 Scrum 框架的基本配置嗎？
• 是否要採用 Scrum 的變體，或是其他敏捷方法？