敏捷是一種用來描述軟件開發方法的術語,強調增量交付、團隊合作、持續規劃和持續學習,而不是在接近結束時一次性交付所有內容。
敏捷注重保持流程精簡並打造最小可行產品(MVP),在最終成果出現前經過多次迭代。反饋會持續收集並加以實施。簡而言之,這是一個更具動態性的過程,所有人都朝著共同目標努力。

敏捷軟件開發
Scrum 與其他主流敏捷方法
敏捷是一種心態——一組價值觀與原則。它是一種思考與行動的方式。敏捷意味著短週期、迭代與增量交付、快速失敗、獲取反饋、早期交付商業價值,並著重於人、合作與互動。敏捷是一種透明、檢視與適應的心態。然而,敏捷並不含任何角色、活動,或成果物。它是一種心態。例如,Scrum是敏捷旗幟下廣泛使用的框架之一,幫助您變得更具敏捷性。但敏捷運動還包含許多其他框架,例如看板、XP、水晶,以及其他,如下所示:

Scrum 敏捷旗幟
Scrum
Scrum 是一種人們用來解決複雜適應性問題,同時高效且富有創意地交付高價值產品的框架。它被用於管理軟件項目以及產品或應用開發。其重點在於適應性產品開發策略,即跨功能團隊在 2 至 4 週內(Sprint)內共同朝著共同目標努力。它由一系列價值觀、成果物、角色、儀式、規則與最佳實踐組成。
精益
精益起源於豐田生產體系(TPS),該體系在 1950 年代、60 年代及以後徹底改變了實體商品的生產。儘管精益在製造業中保持其地位,但它也已在知識工作中找到了新的應用,幫助各行業的企業**消除浪費、改善流程並促進創新**。軟件開發與精益方法天然契合,因為它與製造業一樣,通常遵循既定流程,具備明確的接受標準,並帶來可見的價值交付。引導所有精益實踐的核心概念稱為精益支柱。它們是:
- 持續改進
- 尊重人員
- 輕量級領導
看板
看板是一種高度可視化的流程管理方法,廣泛應用於精益團隊中。事實上,83% 的精益生產團隊使用看板來可視化並主動管理產品的創建,專注於持續交付,同時避免給開發團隊帶來過重負擔。與 Scrum 一樣,看板是一種旨在幫助團隊更有效合作的流程。
看板基於三大核心原則:
- 將你今天的任務(流程)可視化: 將所有項目以彼此之間的關聯性來觀察,可以提供豐富且具洞察力的資訊。
- 限制進行中工作量(WIP): 這有助於平衡以流程為導向的方法,使團隊不會立即開始並承諾過多的工作。
- 改善流程: 當一項任務完成後,待辦事項清單中優先順序最高的下一個項目將被啟動。
Kanban 透過定義最佳團隊工作流程來促進持續合作,並鼓勵主動且持續的學習與改進。
動態系統開發方法(DSDM)
DSDM 是一個由八項原則組成的框架,包括生命週期與產品、角色與職責,以及多項最佳實務技巧。這些原則支援並促進戰略性重要商業效益的早期交付,從而為組織帶來最佳的投資回報率(ROI)。
DSDM 是一種將規劃與品質優先於功能的開發方法。它從一開始就固定成本、品質與時間,並使用 MoSCoW 优先級技術將專案需求分解為四種類型:
- M必須擁有
- S應該擁有
- C可以擁有
- W不需要擁有
DSDM Atern 的八項支援原則,引導團隊建立必須採納的態度與心態,以持續交付價值。
- 專注於業務需求
- 按時交付
- 合作
- 絕不妥協品質
- 從穩固的基礎逐步建構
- 迭代式開發
- 持續清晰的溝通
- 展現控制力
極限程式設計(XP)
最初由肯特·貝克描述,極限程式設計 (XP) 已成為最流行且最具爭議性的敏捷方法之一。XP 是一種以紀律性方式快速且持續交付高品質軟體的方法。其目標在於提升軟體品質,並提高對客戶需求變化的回應能力。它強調高度的客戶參與、快速的反饋週期、持續測試、持續規劃,以及團隊間緊密的合作,並以極短的頻率交付可運作的軟體(通常每1至3週一次)。
該方法的名稱來自於從傳統軟體工程實踐中汲取有益元素並推向「極端」程度的想法。例如,程式碼審查被視為一種有益的實踐。在極端形式下,透過結對編程的實踐,程式碼會持續受到檢視。
原始的 XP 框架基於四個核心價值——簡潔、溝通、回饋與勇氣。
它還包括十二項支援性實踐:
- 規劃遊戲
- 小型發布
- 客戶接受測試
- 簡單設計
- 結對編程
- 測試驅動開發
- 重構
- 持續整合
- 集體程式碼所有權
- 程式碼標準
- 隱喻
- 永續發展

極限程式設計
特性驅動開發(FDD)
特性驅動開發(FDD)由傑夫·德盧卡於1997年在新加坡一家大型銀行的軟體開發專案中提出。它是一種迭代且增量的軟體開發流程,也是建立軟體的敏捷方法。FDD將許多廣受認可的產業最佳實踐整合成一個協調整體。這些實踐從客戶價值觀點出發——即特性。其主要目標是持續且準時地交付具體且可運作的軟體。使用FDD的一個關鍵優勢是,由於「足夠設計」(JEDI)的概念,它能擴展至大型團隊。由於其以特性為中心的流程,FDD是維持對敏捷、增量且本質上複雜專案控制的優良解決方案。它包含五項核心活動:
- 建立整體模型
- 建立特性清單
- 依特性規劃
- 依特性設計
- 依特性建構

特性驅動開發(FDD)
每個專案都有其獨特的模型,用以產生特性清單。最後三個活動是短週期迭代,每週期不超過兩週。若某項任務超過兩週,則會被拆解為更小的特性。
水晶
水晶方法由艾利斯泰爾·柯本於1990年代中期開發,作為一系列方法(水晶家族)。這些方法源自柯本多年的研究與團隊訪談。柯本的研究顯示,他訪談的團隊並未遵循正式的流程,卻仍成功交付專案。水晶家族是柯本用以記錄這些成功團隊做法的方式。水晶方法主要著重於:
- 人員
- 互動
- 社群
- 技能
- 天賦
- 溝通
敏捷宣言
「敏捷」這個詞是在2001年的敏捷宣言中首次提出的。宣言的目標是建立指導更優良軟體開發實務的原則。敏捷宣言包含四項核心價值。閱讀敏捷宣言並不代表右側的項目毫無價值——相反地,敏捷更重視左側的項目。

敏捷宣言
現在讓我們來檢視敏捷宣言的第一行。這一行指出,我們更重視人、他們的互動、溝通與合作,而非各種廣泛的流程與工具。當然,流程與工具具有價值,但當它們真正支援人們共同合作以交付高品質產品時,其價值會更加顯著。我們在許多組織中常見的情況是,流程與工具本身成為目標。從敏捷的觀點來看,我們的看法不同。流程與工具應支援人們共同合作,為客戶創造價值。
敏捷原則
作為敏捷宣言的補充,敏捷聯盟也定義了一套十二項原則,提供超越宣言本身的指導與更詳細的說明:

敏捷宣言原則
- 我們的最高優先事項是透過早期且持續交付高價值的軟體來滿足客戶。
- 歡迎變更需求,即使是在開發的後期。敏捷流程將變更轉化為客戶的競爭優勢。
- 頻繁地交付可運作的軟體,時間範圍從幾週到幾個月不等,且偏好較短的時程。
- 業務人員與開發人員必須在整個專案期間每日合作。
- 以有動機的個人為核心來建構專案。提供他們所需的環境與支援,並信任他們完成工作。
- 向開發團隊傳達資訊,以及在團隊內部傳達資訊的最有效方法是面對面的對話。
- 可運作的軟體是衡量進展的主要指標。
- 敏捷流程促進可持續發展。發起人、開發人員與使用者應能無限期地維持穩定的節奏。
- 持續關注技術卓越與良好設計,能提升敏捷性。
- 簡化——最大化未完成工作的藝術——是不可或缺的。
- 最佳的架構、需求與設計來自自組織團隊。團隊定期反思如何變得更有效,並相應調整其行為。
總結
敏捷開發是軟體開發產業中一個流行的術語——一種管理軟體開發專案的替代方式。它並非特定的軟體開發方法論,而是一系列基於敏捷宣言中所表達價值與原則的方法與實務。解決方案透過自組織、跨功能團隊之間的合作不斷演進,並運用適合其情境的實務。