敏捷詞彙：工程專業學生必須了解的術語全面概述

即將進入軟體開發產業的工程專業學生面臨一個由快速變遷與迭代交付所定義的環境。支撐大多數現代開發週期的方法論是敏捷。理解與此框架相關的特定術語，不僅僅是學術上的練習；更是專業上的必要條件。本指南全面解析關鍵術語，確保學生與專業人士都能清晰掌握。

無論您參與的是大學畢業專題計畫，還是加入企業工程團隊，敏捷語言都能促進溝通。它建立了對工作流程、品質標準與團隊動態的共識。以下各節將剖析構成敏捷生態系統的核心組成部分、角色與產物。

基礎：敏捷宣言與原則 🏛️

在深入探討特定術語之前，理解其起源至關重要。敏捷宣言於2001年由一群軟體開發人員發布。它強調個人與互動勝過流程與工具。它重視可運作的軟體勝過完整的文件。它強調客戶合作勝過合約談判。它強調回應變更勝過遵循計畫。

這四項價值由十二項原則支持。這些原則在開發過程中引導決策流程。它們主張頻繁交付軟體、歡迎需求變更，並維持可持續的節奏。對工程學生而言，掌握這些價值是走向有效實踐的第一步。

• 個人與互動：溝通比僵化的工具更能推動進展。
• 可運作的軟體：進展的主要衡量標準是可運作的程式碼。
• 客戶合作：利益相關者應全程參與流程。
• 回應變更：必須具備彈性以適應市場需求。

框架中的核心角色 🎭

不同的框架以不同方式組織團隊，但最常見的結構是Scrum。本節將說明該結構中的具體職責。

產品負責人

產品負責人代表客戶與業務的聲音。他們負責最大化開發團隊工作成果所產生的產品價值。此角色包括管理產品待辦事項清單。

• 待辦事項清單管理：排序項目以最大化價值。
• 清晰度：確保團隊理解各項目。
• 決策：接受或拒絕工作增量。

Scrum 主管

Scrum 主管透過確保流程被遵循來服務團隊。他們並非傳統的經理，而是促進者與教練。他們的重點在於消除阻礙團隊進展的障礙。

• 障礙排除：解決延緩工作的阻礙。
• 教練：教導團隊敏捷原則與實務。
• 促進： 主持儀式並確保其富有成效。

開發團隊

這是負責實際交付增量工作的專業人員團隊。他們是跨功能的，意味著擁有創造產品所需的全部技能，且不依賴外部資源。他們是自我組織的，意味著團隊自行決定如何完成工作。

• 自我組織： 團隊決定誰做什麼。
• 跨功能： 技能包括程式設計、測試、設計與分析。
• 共同目標： 團隊承擔對Sprint目標的承諾。

關鍵資產 📄

資產代表工作或價值。它們提供透明度並創造檢視的機會。三個主要資產分別是產品待辦事項清單、Sprint待辦事項清單與增量。

產品待辦事項清單

這是產品中所有已知需求的有序清單。它是需求的唯一來源。它永遠不會完整。隨著產品與環境的演進，細節會不斷變化。它是動態的。

• 排序： 項目根據價值、風險與必要性進行優先排序。
• 調整： 項目會定期審查與更新。
• 細節程度： 排在上方的項目較為詳細；越往下項目則越粗略。

Sprint待辦事項清單

這是為Sprint選定的產品待辦事項清單項目集合。它包含交付產品增量與實現Sprint目標的計畫。由開發團隊擁有。

• 選擇： 在Sprint規劃期間選定。
• 預測： 代表團隊對Sprint目標的最佳預測。
• 更新： 隨著工作進展每日更新。

增量

增量是朝向產品目標的具體踏腳石。每個增量都累加於先前的所有增量之上。無論產品負責人是否決定發佈，它都必須處於可使用狀態。

• 可用性： 必須具備可交付的潛力。
• 完成的定義： 必須符合既定的品質標準。
• 完整性： 不可以是部分程式碼；必須是可運作的。

必要儀式與活動 🗓️

活動創造節奏，並提供檢視與調整的機會。它們具有時間限制，表示有最大時長。

Sprint

Sprint 是敏捷的脈動。它是一個固定長度的事件，長度為一個月或更短，在此期間會產生一個「已完成」、可用且可能發佈的產品增量。Sprint 包含並由 Sprint 規劃、每日站會、Sprint 回顧與 Sprint 回顧會議組成。

• 固定長度： 一致性有助於更好的規劃。
• 時間限制： 不可延長。
• 目標： 每個 Sprint 都有明確的目標。

Sprint 規劃

此活動啟動 Sprint。整個 Scrum 團隊共同協作規劃。產品負責人討論目標與產品待辦事項的現狀。開發團隊預測即將進行的 Sprint 中將包含的功能。

• 什麼： 增量中可以交付什麼？
• 如何完成所選的工作？ 所選的工作將如何完成？
• 時間長度： 一個月的 Sprint 最多 8 小時。

每日站會

也稱為每日站會，是開發團隊的 15 分鐘活動。它不是用來向管理層報告進度，而是讓團隊同步活動並制定接下來 24 小時的計畫。

• 頻率： 每天同一時間。
• 重點： 對 Sprint 目標的進展。
• 格式： 常見回答：我做了什麼？接下來要做什麼？有什麼障礙？

Sprint 回顧

此活動於 Sprint 結束時舉行，用以檢視增量成果，並在需要時調整產品待辦事項。Scrum 團隊與利益相關者共同審視已完成的工作。

• 協作： 接下來該做什麼的討論。
• 回饋： 利益相關者對產品提供意見。
• 調整： 待辦事項可能根據回饋進行調整。

Sprint 回顧

Scrum 團隊檢視上一個 Sprint 在個人、互動、流程、工具以及其「完成定義」方面的表現。目標是找出改進方式，並在下一個 Sprint 中執行。

• 持續改進： 關注流程，而非個人。
• 安全環境： 對挑戰進行開放討論。
• 可執行項目： 計畫針對下一個週期的具體改進措施。

常見工程術語 🛠️

除了核心 Scrum 框架之外，工程團隊還會遇到與工作本身相關的特定術語。

使用者故事

使用者故事是從終端使用者角度出發，對軟體功能所做的非正式、一般性說明。它遵循特定格式以確保清晰度。

• 格式：作為[角色]，我希望[功能]，以便[利益]。
• 接受標準：故事完成必須滿足的條件。
• 對話：它代表的是一場對話，而不僅僅是一份文件。

技術負債

比喻而言，技術負債代表因選擇現在較簡單（有限）的解決方案，而非花更長時間採用更佳方法，所導致的額外重做成本。若未及時償還，它會累積利息。

• 捷徑： 經常為了趕上期限而採取。
• 重構： 清理程式碼以減少技術負債的過程。
• 管理： 團隊必須分配時間來償還此負債。

速度

速度是衡量團隊在單一 Sprint 中能夠處理的工作量的指標，也是 Scrum 中的關鍵指標。它透過計算已完成使用者故事的點數總和來得出。

• 歷史： 用於預測未來的承載能力。
• 穩定性： 應在時間上保持相對穩定。
• 比較： 不應比較不同團隊之間的速度。

完成定義（DoD）

完成定義是一份正式描述，說明當增量達到產品所需的品質標準時的狀態。一旦增量符合完成定義，即可釋出。

• 品質門檻： 確保團隊內部的一致性。
• 透明度： 每個人都知道「完成」是什麼樣子。
• 協議： 由開發團隊定義。

前置時間與週期時間

這些指標經常用於看板與一般工程流程中。

• 前置時間： 從客戶請求到交付的總時間。
• 週期時間： 專注於處理該項目所花費的時間。
• 效率： 時間越短，通常表示流程越順暢。

替代框架與方法 🔄

雖然Scrum很受歡迎，但它並非唯一的途徑。工程專業的學生應了解相關的開發方法。

看板

看板著重於可視化工作、最大化流程效率，並限制進行中的工作數量。它不像Scrum那樣規定特定角色或固定迭代週期。

• 可視化看板： 欄位代表工作流程的階段。
• 進行中工作數量限制： 每個欄位中可包含的項目數量的限制。
• 流程： 強調持續交付，而非批次處理。

極限編程（XP）

XP強調技術卓越與工程實務。它經常與Scrum結合使用。

• 配對編程： 兩位開發人員共用一台工作站工作。
• 測試驅動開發： 在撰寫程式碼之前先撰寫測試。
• 持續整合： 頻繁合併程式碼，以早期發現錯誤。

精益軟體開發

精益將製造業原則應用於軟體開發。它著重於消除浪費，並快速交付價值。

• 消除浪費： 移除任何不增加價值的事物。
• 強化學習： 鼓勵建立反饋迴圈。
• 盡可能延後決策： 在必要之前保持選項開放。

指標與度量 📊

資料驅動改進。工程團隊依賴特定指標來評估系統健康與效能。

燃盡圖

顯示Sprint或專案中剩餘工作量的圖表。它幫助團隊了解是否按計畫完成工作。

• Y軸： 剩餘工作。
• X軸： 時間。
• 趨勢： 應在 Sprint 結束時趨近於零。

燃起圖

類似於燃減圖，但顯示的是隨時間完成的工作量，以及總範圍。

• 範圍可見性： 顯示範圍是否在增加。
• 進度： 將已完成的工作與總工作量進行視覺化對比。

吞吐量

在特定期間內完成的工作單元數量。對於衡量團隊隨時間的承載能力很有幫助。

• 速率： 每日、每週或每 Sprint 的項目數。
• 預測： 有助於預估未來的交付日期。

關鍵術語摘要表 📋

術語	定義	分類
Sprint	工作完成的時間盒期間	事件
產品待辦事項	所有已知需求的有序清單	產物
使用者故事	從使用者角度對功能的簡短描述	產物
速度	每個迭代完成工作的衡量指標	指標
完成的定義	工作完成必須滿足的標準	標準
技術負債	因取巧而導致返工的代價	概念
Scrum 主管	團隊的促進者與教練	角色
產品負責人	代表客戶並管理待辦事項清單	角色
增量	可用的產品新增功能	產物
看板	專注於流程與在製品數量限制的方法	框架

將此知識應用於你的職業生涯 💼

工程專業的學生經常從學術專案轉向職業環境，卻對這些術語缺乏明確理解。這種差距可能導致與利害關係人之間的摩擦，或團隊內部的誤解。熟悉這份術語表可以彌補這段落差。

當你遇到不理解的術語時，請主動請教以釐清。切勿自行猜測意義。業界重視精確性。使用正確的術語能展現專業能力，並體現對流程的尊重。

此外，理解這些概念能讓你為更好的實務倡議。若你發現團隊正在累積技術負債，可運用此框架建議安排重構時間。若流程不清晰，可引用「完成的定義」來建立明確性。

持續學習是工程思維的一部分。敏捷宣言鼓勵反思如何更有效地完成工作。本指南為此反思提供起點。隨著你進步，將會遇到新的術語與細微差異。保持個人術語表，並在學習過程中不斷補充。

軟體環境不斷變動，框架持續演進。然而，合作、迭代交付與品質等核心原則始終不變。掌握這些術語能確保你在任何工程環境中都具備適應力與效率。

請記住，工具會改變，但原則永存。無論你在新創公司或大型企業工作，清晰溝通與結構化交付的需求始終存在。將此術語表作為你職業發展旅程的參考依據。