Blog3- Page

溝通是產品開發的核心。無論您是在定義範圍、協調利益相關者，還是引導工程團隊，清晰明確都至關重要。視覺模型作為一種通用語言，彌合了技術限制與商業目標之間的差距。在這些工具中，用例圖因其能從用戶角度映射系統功能而脫穎而出，成為基礎性工具。對產品經理而言，理解這些圖表不僅僅是技術素養的體現，更是精確掌握需求與範圍管理的關鍵。 本指南專為產品管理情境而設計，深入解析用例圖的符號、關係及其含義。我們將探討這些視覺元素如何轉化為可執行的需求，確保每一項功能定義都清晰、可測試且符合用戶需求。讓我們來檢視推動有效系統建模的核心組件。 理解用例建模的基礎 🧱 用例圖可視化使用者（或系統）與正在開發的軟體之間的互動。它捕捉什麼系統所做的內容，而非如何系統是如何執行的。這種區別對產品經理至關重要。它讓您能專注於價值交付與用戶目標，而不必陷入實現細節的泥潭。 這些圖表有助於： 範圍定義：明確劃分系統內部與外部的內容。 需求收集：識別滿足用戶目標所需的所有必要互動。 溝通：為可能不閱讀技術規格的利益相關者提供視覺參考。 測試：作為定義測試案例與接受標準的基準。 核心符號：構建模塊 🛠️ 每個圖表都是由一組特定符號構成的。每個符號都具有關於系統邊界與參與者角色的獨特含義。以下是您將會遇到的主要元素的詳細說明。 1. 參與者 👤 參與者代表與系統互動的外部實體所扮演的角色。通常以人形圖示表示。在產品管理中，正確定義參與者是界定範圍的第一步。 人類參與者：這些是真實的人，例如客戶、管理員或訪客。 系統參與者：這些可以是與您的產品互動的其他軟體系統或硬體裝置。 時機：參與者啟動互動或接收輸出。他們是「用例」的來源。 產品經理洞察：避免使用可能變動的具體職稱來標示參與者。應使用功能性角色（例如「註冊使用者」而非「市場部的約翰」）。這樣可確保即使團隊結構變動，圖表仍保持有效。 2. 使用案例 🔄 使用案例是一種橢圓形，代表系統執行的特定功能或目標。從使用者的角度來看，它是一個完整的功能單元。 命名規範： 使用動詞-名詞結構（例如：「處理付款」、「產生報表」）。 細粒度： 保持使用案例的原子性。如果一個功能可以進一步拆分，請考慮它是否能獨立作為一個明確的目標。 價值：

在軟體開發中，最昂貴的錯誤並非出現在程式碼中，而是出現在需求中。當開發團隊根據模糊的描述建構功能時，結果往往是返工。這種返工會消耗時間、預算和團隊士氣。一個結構良好的需求文件可以成為抵禦這些成本的防護盾。在本案例研究中，我們探討了如何透過一種視覺化建模技術，在撰寫任何程式碼之前，就識別出專案範圍中的關鍵缺陷。 該專案涉及一個物流平台，旨在連結倉儲操作員與送貨司機。最初的請求很明確：建立一個模組來管理包裹交接。團隊假設工作流程是線性的。然而，引入用例圖後，揭示了原始口頭簡報完全忽略的複雜邊界情況。這一簡單的視覺化介入，避免了組織在專案生命週期後期面臨重大架構重構。 🏗️ 專案背景 客戶是一家正在擴展數位基礎設施的中型供應鏈公司。他們正從手動追蹤轉向完全自動化的系統。主要目標是縮短包裹抵達集散中心至分配給司機之間的時間。利益相關者包括營運經理、倉儲主管和資深開發人員。 初期會議專注於「順利路徑」。這是一種一切按計畫進行的理想情境。利益相關者描述了一個司機到達、掃描條碼，系統確認交接的流程。所有人都點頭同意。專案獲得核准。開發團隊開始建立資料庫結構和API端點。 然而，實際運作很少是線性的。現實世界的物流涉及中斷、錯誤和例外情況。在缺乏正式的視覺模型來壓力測試需求的情況下，團隊繼續假設系統僅需處理標準互動。正是這個假設，埋下了風險的種子。 📐 理解用例圖 用例圖是系統的一種行為視圖。它展示了外部參與者與系統本身之間的互動。它不顯示內部邏輯或程式碼結構，而是專注於「誰」和「做什麼」。 主要元件包括： 參與者：與應用程式互動的使用者或外部系統。在此案例中，包括司機、倉儲人員和管理員。 用例：參與者可以執行的特定目標或動作，例如「掃描包裹」或「報告損壞」。 系統邊界： 定義軟體範圍的方框。方框內的所有內容都是系統的一部分；方框外的所有內容都是環境。 關係： 連接參與者與用例的線條。這些定義了互動的流程。 建立此圖表迫使團隊明確闡述系統的邊界。它將隱含的假設顯性化。如果利益相關者提到一個無法納入圖表的流程，這就表示需求存在缺口。 🤔 初始範圍與假設 在繪製圖表之前，範圍由一份列出高階功能的文件定義。團隊認為範圍僅限於「交接」模組內。假設包括： 司機始終擁有可用的網路連接。 條碼始終可被掃描器讀取。 包裹始終位於正確位置。 對於包裹狀態不存在爭議。 這些假設在早期規劃階段很常見。

每位產品經理和利益相關者都曾有過這種感受。專案起初有明確的願景、明確的功能清單和現實的時間表。數月後，路線圖上堆滿了新的需求，截止日期一再延後，團隊也精疲力盡。這種現象被稱為範圍蔓延。它是軟體專案的隱性殺手，無形中侵蝕預算並延遲交付，卻未帶來相應的價值提升。 防止這種偏移不僅僅是說『不』這麼簡單。它需要一種結構化的方法來定義系統實際上要做什麼，更重要的是，定義系統不做什麼。這正是用例圖成為產品經理不可或缺工具的原因。它作為開發團隊與業務之間的視覺化合約，為正在構建的系統設立明確的界限。 本指南探討如何運用用例圖來掌控專案範圍、統一利益相關者的期望，並持續交付價值。 理解產品開發中的範圍蔓延 📉 範圍蔓延不僅僅是增加功能而已。它指的是在未調整時間、成本或資源的情況下，專案目標的不受控擴張。它常以微妙的方式表現：一個『快速修復』最終變成了永久功能，利益相關者的要求繞過標準審查流程，或是對『需求完成』的定義產生誤解。 當範圍不受控制地擴張時，會出現多種負面後果： 資源耗損：開發人員將時間花在未預期的工作上，導致核心功能的開發能力下降。 品質下降：為了應對新功能而匆忙實現，往往導致技術債累積。 團隊倦怠：目標不斷變動，使工程團隊陷入不確定感與疲勞之中。 錯過截止日期：隨著『完成』的定義不斷改變，原本的發佈日期變得毫無意義。 產品經理扮演價值守門人的角色。要有效履行此職責，他們需要一種機制來視覺化系統的界限。用例圖正是透過呈現使用者與系統之間的互動，提供了這種機制。 產品經理在界定界限中的角色 🧱 產品經理有責任最大化開發團隊工作所產生的產品價值。然而，如果工作界限模糊不清，價值便無法最大化。定義明確的界限包含兩項截然不同的活動：表達與保護。 表達意指清楚傳達系統將達成的目標。這正是用例圖發揮作用之處。它能將抽象的業務目標轉化為具體的系統互動。例如，不再僅說『系統需要處理使用者資料』，而是明確指出『使用者登入』、『使用者更新個人資料』與『系統驗證憑證』等動作。 保護意指抵抗將超出既定模型的功能加入的誘惑。當有新需求提出時，產品經理可參考圖表。若該需求不符合現有的參與者或用例，則會被標記為需審查項目，不會自動納入當前迭代。 用例圖的結構 📐 要有效運用圖表，必須理解其組成部分。用例圖是系統功能需求的視覺化呈現。它關注的是『誰』和『做什麼』，而非『如何做』。這種抽象化是防止範圍

在當今的數位環境中打造成功的產品，不僅僅需要功能清單和截止日期。它需要明確理解用戶如何與系統互動、他們能獲得什麼價值，以及技術限制如何塑造整個開發過程。在這一切對齊的核心，存在一種常被快速節奏環境忽略的視覺化工具：用例圖。儘管敏捷方法強調速度，但跳過用例所提供的結構化分析，可能會導致大量返工、範圍蔓延以及利益相關者期望的錯位。 本指南探討用例圖在塑造現代產品路線圖中的關鍵作用。我們將超越基本定義，深入理解這些圖表如何作為商業目標與技術執行之間的戰略橋樑。到最後，您將明白為何納入這些圖表並非行政負擔，而是確保清晰與精確的根本需求。 🔍 什麼是用例圖？ 用例圖是系統與其外部實體之間互動的視覺化呈現。它從終端用戶的角度著眼於功能需求。與詳細描述流程內部邏輯的流程圖，或展示螢幕視覺佈局的線框圖不同，用例圖回答的問題是：使用者能用這個系統做什麼？ 在產品規劃的脈絡中，這些圖表扮演著高階藍圖的角色。它們定義了系統的邊界，並識別出與系統互動的參與者。這種區分對路線圖規劃至關重要，因為它將內部機制與外部價值交付分離開來。 主要特徵包括： 以參與者為中心： 圖表從人類或系統參與者出發，而非功能本身。 以目標為導向： 每個用例代表參與者希望達成的特定目標。 系統邊界： 明確界定軟體內部與外部的範圍。 關係： 展示不同動作之間的關聯（例如：重複動作、可選動作）。 🏗️ 圖表的核心組成部分 為了有效利用這些圖表進行路線圖規劃，必須理解其基本構成。誤解這些元件將導致規劃失誤。以下是構成分析結構的關鍵要素。 1. 參與者 👤 參與者代表與系統互動的角色。參與者並非特定個人，而是根據其與系統的關係所定義的角色。理解參與者有助於根據使用者群組來優先排序路線圖項目。 主要參與者： 那些為達成目標而啟動用例的人（例如：顧客下訂單）。 次要參與者： 主系統所互動的系統或服務（例如：支付網關或庫存資料庫）。 內部與外部： 区分人類使用者與其他軟體系統對於技術範圍界定至關重要。 2. 用例

產品管理涉及將複雜的需求轉化為可執行的技術規範。在縮短業務目標與工程執行之間差距的工具中，使用案例圖是最有效的工具之一。雖然這些圖表常與軟體工程師聯繫在一起，但它們提供了系統互動的高階視圖，這對產品經理至關重要。理解這種視覺語言，讓您能夠驗證範圍、識別缺失的需求，並促進與利害關係人之間更清晰的溝通。 本指南全面拆解標準使用案例圖中的每個符號。我們將探討參與者、動作、邊界與關係。透過本資源，您將能夠解讀這些圖表，並為產品生命週期的設計階段做出有意義的貢獻。 🧩 核心組件 使用案例圖是使用者如何與系統互動的視覺化呈現。它著重於功能而非實作細節。要閱讀或建立使用案例圖，您必須先理解其基本構成要素。這些元素共同作用，以定義軟體的範圍與相關角色。 1. 參與者 👤 參與者代表與系統互動的外部實體。它們不一定是人；也可以是其他系統、硬體裝置，甚至是基於時間的觸發器。在產品管理的脈絡中，您最常遇到的是人類參與者。 主要參與者：這些是啟動特定使用案例以達成目標的使用者。例如，一位客戶啟動購買. 次要參與者：這些是支援主要參與者但不啟動流程的系統或使用者。範例可能包括金流閘道驗證交易。 呈現方式：在圖表中，參與者通常以火柴人表示，並放置在系統邊界之外。 定義參與者時，避免將過多角色賦予單一火柴人。若使用者執行具有不同權限的獨立任務，請考慮建立獨立的參與者（例如，管理員與訪客）以釐清需求中的存取層級。 2. 使用案例 ⚙️ 使用案例代表系統執行的特定目標或功能。它描述了一系列能為參與者產生可觀察價值的動作序列。可將使用案例視為從系統角度出發的「待完成任務」。 呈現方式：使用案例以橢圓形或橢圓形繪製於系統邊界內部。 命名規則：名稱應遵循「動詞 + 名詞」的結構。例如，「更新個人資料」 優於 「個人資料更新畫面」. 範圍：單一使用案例理想上應為原子性。若某功能涉及多個不同目標，則可能需要拆分為獨立圖表或進行邏輯分組。 3. 系統邊界 🚧 系統邊界是一個矩形框，用以定義所建模軟體或系統的範圍。框內所有內容均屬於系統的一部分；框外則為參與者或外部依賴。 目的：它有助於釐清當前版本中哪些內容屬於範圍內、哪些屬於範圍外。 標註：該框通常標註系統或產品的名稱。

作為產品經理，您處於商業需求與技術執行的交匯點。其中一個持續存在的挑戰，是將複雜的需求轉化為開發人員與利益相關者都能同意的視覺化格式。用例圖長期以來一直是系統分析中的基本工具，但其實際應用經常引發爭議。它們為何必要？何時應當創建？它們如何融入現代開發週期？ 本指南針對產品經理在用例圖方面最常遇到的十五個問題。我們將探討參與者、邊界與關係的運作機制，而不依賴特定工具或炒作。目標是釐清這些圖表作為溝通橋樑的功能，而不僅僅是文件記錄。 1. 用例圖到底是什么？ 🧩 用例圖是一種行為模型，用以說明外部實體與正在設計的系統之間的互動。它著重於系統對使用者而言做什麼系統對使用者而言做什麼，而非系統內部如何執行內部執行的方式。 主要目的： 捕捉功能需求。 關鍵組成部分： 參與者、用例與關係。 範圍： 它定義了系統的邊界。 與詳細說明步驟順序的流程圖不同，用例圖保持高階層次。它提供了一個不同使用者可使用功能的快照。對產品經理而言，此圖表可作為在深入細節規格前討論功能的共通語言。 2. 在此模型中，誰可被視為「參與者」？ 👤 關於誰可被視為參與者，常會產生混淆。參與者代表任何與系統互動的角色，不限於人類。 人類參與者： 註冊使用者 管理員 訪客 支援人員 系統參與者： 外部API 支付網關 舊有資料庫 硬體感測器 正確識別參與者，可確保不會遺漏任何關鍵互動。若第三方服務觸發您產品中的某項動作，該服務即為參與者。早期繪製這些互動，可避免開發過程中的整合缺口。 3. 它與流程圖有何不同？

管理產品需求經常讓人覺得像是在沒有盒上圖案的情況下整理一塊複雜的拼圖。團隊累積了故事、任務與功能，卻缺乏連貫的視覺敘事。這種碎片化導致邏輯上的漏洞、重複的勞動，以及無法真正滿足使用者需求的需求。解決方案不在於增加更多文件，而在於改善需求呈現的結構。使用案例圖提供了一種經過驗證的方法，能夠彌補抽象目標與具體實作步驟之間的差距。 當正確應用時，這些圖表能將混亂的待辦事項清單轉化為系統行為的結構化地圖。它迫使利害關係人明確界定誰與系統互動，以及每次互動中提供了什麼價值。這種清晰度能減少開發過程中的模糊性，並確保待辦事項中的每一項都具有明確的目的。以下，我們將探討有效實施此方法所需的策略。 理解核心概念：視覺化行為 🏗️ 使用案例圖是系統的一種靜態視圖。它並未顯示系統內部如何運作，而是從外部實體的角度呈現系統的功能。在產品管理的脈絡中，這種區別至關重要。待辦事項通常描述的是功能，而使用案例則描述的是目標。 請思考任務清單與意圖模型之間的差異。一個任務可能寫著「建立登入按鈕」，而使用案例則是「驗證使用者」。前者是實作，後者是功能。透過先聚焦於功能，團隊可以在後續選擇最佳的技術方案，同時不偏離使用者的目標。 要將此方法融入您的工作流程，必須理解三個主要元件： 參與者：與解決方案互動的使用者或外部系統。 使用案例：系統為參與者執行的特定目標或動作。 關係：顯示參與者如何觸發使用案例，以及使用案例之間如何互動的連結。 當這些元件被明確定義後，產品待辦事項清單便成為一組已確認的互動，而非隨機的想法堆疊。這種對齊確保開發工作始終朝著創造價值的方向前進。 將參與者對應到現實中的角色 👥 需求模型中最常見的混淆來源是參與者的定義。參與者不一定是個人，而是與系統互動的角色。錯誤識別參與者會導致範圍蔓延或遺漏需求。 在建立您的圖表時，應將參與者分為兩個明確的類別：人類參與者與系統參與者。 人類參與者： 這些代表您組織內部或客戶群中的角色。範例包括「管理員」、「客戶」或「審計員」。避免使用「John Smith」等具體職稱，應專注於功能角色。 系統參與者： 這些是提供資料或接收資料的外部系統。範例包括「支付網關 API」或「舊式資料庫」。這些對於定義待辦事項中的整合點至關重要。 早期明確定義這些角色可防止範圍蔓延。如果來自某位利害關係人的功能需求不符合現有的參與者角色，這表示需要重新審視系統邊

在系統開發的複雜環境中，很少有挑戰比利益相關者所想像的與工程師所建構的之間的落差更為持久。這種脫節經常導致高昂的返工、延遲的時程以及士氣低落的團隊。彌合這一差距最有效的工具之一就是用例圖。儘管它們經常被視為技術文件中的背景內容，但這種視覺化工具在撰寫任何程式碼之前，具有顯著的潛力來統一各方預期。透過專注於使用者目標與系統互動，團隊可以在早期就達成對範圍與功能的共識。這種方法能減少模糊性，並促進企業所有者、開發人員與測試人員之間的共同理解。 有效的溝通不僅僅是分享資訊，更在於確保理解。技術規格往往內容龐雜且抽象，經常無法引起非技術參與者的共鳴。一張設計良好的圖表能簡化這種複雜性，將功能需求轉化為所有人都能理解的視覺語言。本指南探討如何運用此種符號系統來促進協作、驗證需求，並在不依賴特定工具或供應商的情況下，簡化交付流程。 超越基礎的用例圖理解 🤔 用例圖是系統的一種行為視圖。它捕捉使用者或參與者與系統本身之間的互動。與專注於結構的資料模型，或專注於時序的序列圖不同，用例圖專注於系統從外部實體的角度所執行的系統從外部實體的角度所執行的內容。這種區別對利益相關者的參與至關重要，因為它直接關聯到價值與功能，而非實作細節。 專注於目標：每個用例代表參與者希望達成的特定目標。 外部視角：它將系統呈現為一個黑箱，隱藏內部複雜性。 以互動為中心：它強調不同角色如何與應用程式互動。 當利益相關者看到他們的特定角色被呈現為參與者時，他們會立即意識到自己在生態系統中的位置。這種認知是建立主導權的第一步。他們不再只是技術文件的被動觀察者，而是設計對話中的積極參與者。這種視覺化呈現如同一種合約，明確界定責任與能力的範圍。 利益相關者對齊的挑戰 💸 專案失敗的原因通常不是技術負債，而是需求不清晰。當利益相關者對系統有不同的心智模型時，最終產出的產品很少能讓所有人滿意。這種不一致可能以多種方式表現： 功能蔓延：新需求在流程後期才出現，因為最初並未討論。 範圍混淆：開發人員建構了那些被假設但從未明確同意的功能。 期望落差：最終產品在技術上運作正常，卻未能解決使用者的實際問題。 解決這些問題需要一種早期驗證的機制。文字需求往往容易產生不同解讀。例如「系統應處理訂單」這句話，對業務人員、倉管人員與開發人員可能有不同含義。而圖表則強制要求明確性，必須定義觸發條件、動作與結果。這種清晰度能降低假設風險，

作為產品經理，您處於商業戰略與技術執行的交匯點。您將願景轉化為可執行的需求，確保團隊高效地創造價值。在您工具箱中，最強大的視覺化系統行為的工具之一便是用例圖。儘管這些圖表常與軟體工程師聯繫在一起，但它們對於明確範圍、識別利益相關者以及防止範圍蔓延至關重要。 許多團隊將這些圖表視為沉重的文檔負擔。這是一種錯誤。若正確運用，用例圖可作為功能性的唯一真實來源。它彌合了抽象的用戶需求與具體的系統動作之間的差距。本指南概述了一種實用且簡化的創建方法，讓您在不陷入理論複雜性的同時，輕鬆完成這些圖表。 🧠 為何此工具對產品經理至關重要 產品經理需應對源源不斷的需求。若缺乏清晰的視覺化呈現，需求容易變得支離破碎。用例圖為系統提供了一個高階概覽。它能在生命周期早期回答關鍵問題： 誰與系統互動的是誰？（參與者） 什麼他們能做什麼？（用例） 哪裡系統的起點與終點在哪裡？（邊界） 透過明確這些邊界，您可防止團隊開發超出預期範圍的功能。它成為業務與開發團隊之間的合約。當功能方面出現爭議時，圖表可提供客觀的參考依據。 此外，這種視覺化有助於利益相關者溝通。高階主管與客戶常難以理解技術術語。圖表能簡化敘述。它展現互動流程，而無需深入掌握代碼架構知識。這種清晰度能加速決策過程，並減少在重複澄清會議上浪費的時間。 🔍 用例圖的結構解析 要建立有效的圖表，您必須理解其基本組成部分。可將這些視為您視覺化需求規格的構建模塊。您將反覆遇到四個主要元素。 1. 參與者 參與者代表使用者或與主系統互動的外部系統所扮演的角色。必須牢記，參與者並非特定個人，而是一種角色。例如，“客戶”是參與者，而非“約翰·史密斯”。 主要參與者： 這些參與者啟動互動以達成特定目標。他們是推動系統的主要使用者。 次要參與者： 這些參與者支援系統或提供資料，但不會啟動主要用例。它們可能是支付網關、電子郵件伺服器或內部資料庫。 2. 用例 用例代表系統為參與者執行的特定功能或目標。它描述的是什麼系統所做的內容，而非如何它如何執行。每個用例都應是獨特且具有價值的功能單元。 命名應簡潔且以動作為導向（例如，“處理付款”而非“付款處理邏輯”）。 確保每個用例都為至少一位參與者創造價值。 若相關動作具有原子性，則應將其歸納於單一用例之下。 3. 系統邊界 系統邊界是一個框，用來定義軟體的範圍。框內的所有內容都是系統的一部分，框外的所有內容都是

在敏捷開發的快速環境中，將高階需求與即時執行目標對齊是一項持續的挑戰。團隊經常陷入缺乏背景或明確優先順序的使用者故事待辦事項中。這正是用例圖的視覺清晰度成為無價資產之處。透過繪製參與者與系統之間的互動，團隊能夠獲得價值交付的結構化視圖。本指南探討如何利用這些圖表，在迭代規劃會議中有效優先處理功能。 許多組織在戰略路線圖與戰術執行之間存在脫節。待辦事項中堆滿數百項內容，可能導致決策疲勞。利益相關者可能要求看似關鍵的功能，卻與核心使用者需求不符。相反地，開發人員可能以「可有可無」為藉口，建立技術債務。用例圖提供了一個中立的基礎。它能視覺化「做什麼」與「由誰執行」，而不會立即陷入「如何執行」的細節。這種分離使產品負責人與團隊能專注於價值與必要性。 當正確整合時，這種建模技術能將抽象的請求轉化為可執行的項目。它迫使團隊討論邊界與責任。它明確指出哪些功能是系統運作所必需的，哪些是增強功能。這種清晰度是有效迭代規劃的基石。透過理解互動生態系統，團隊能邏輯性地安排工作順序。這能減少重複工作，並確保每次迭代都對產品願景有實質貢獻。 理解基礎：用例圖 🧩 在深入優先排序之前，建立對此工具的共識至關重要。用例圖是系統的行為視圖。它將系統功能表示為一組用例。這些用例從外部參與者的角度來識別。參與者代表與系統互動的角色，例如客戶、管理員或第三方服務。 此圖表並非技術藍圖，不會顯示資料庫表格或API端點。相反地，它專注於目標。每個用例代表參與者希望達成的目標。例如，「下訂單」是「客戶」參與者的目標；「管理庫存」是「倉管員」參與者的目標。透過明確定義這些目標，團隊能建立價值地圖。 主要元件包括： 參與者： 使用者或與解決方案互動的外部系統。 用例： 系統提供的特定功能或服務。 系統邊界： 一個方框，用來定義系統內部與外部的範圍。 關係： 連接參與者與用例的線條，表示互動關係。 包含/擴展： 影響複雜度的用例之間的邏輯依賴關係。 在建立這些圖表時，精確性至關重要。模糊的標籤會導致模糊的規劃。不要使用「檢視資料」，而應使用「檢視客戶訂單歷史」。這種明確性有助於後續的估算。同時也有助於識別重疊。如果兩個參與者有相同目標，團隊可整合功能。這能減少重複，並簡化待辦事項。 迭代規劃的挑戰 🚧 迭代規劃是一項時間限制的活動。目標是在下一個迭代中選擇待辦事項的一個子集來完成。時間有限，能力有限，交付壓力高。