軟體專案實務：從PMP到敏捷的深入解析與實踐

「軟體專案實務」適合職場小白、轉職者及PMI持證者，課程涵蓋從PMP到敏捷的完整架構，並深入探討理想與實務敏捷的差異。課程還分析專案中角色盲點，幫助您全面理解軟體專案運作及各角色的挑戰，提升專案管理技能。

從PMP到敏捷

PMP金三角的核心概念

PMP金三角是傳統專案管理的核心框架，由範疇（Scope）、時間（Time） 和 成本（Cost） 三大要素構成，三者互相影響，形成穩定的平衡關係，同時影響到品質（Quality），因品質是這三個要素平衡的結果。

1. 範疇（Scope）
   定義專案的工作內容和交付成果，通常包含詳細的需求規範與範疇說明。

2. 時間（Time）
   包括專案的計劃排程、里程碑和關鍵路徑。透過時間管理確保專案能按時完成。

3. 成本（Cost）
   涵蓋專案的資金預算與資源配置，目標是在可控範圍內實現最優結果。

4. 品質（Quality）
   表示交付成果是否滿足需求與期望，會受到範疇、時間和成本的限制。例如，若為了縮短工期或降低預算而擴大範疇，可能會導致品質的妥協。

金三角的核心在於，當一個要素改變（如範疇擴大），其他要素（如時間或成本）必然受到影響，甚至影響品質。例如，一位油漆工刷一間房子需三天，若要在1.5天內完成，需增加人力至兩人，這是典型的時間與成本轉換：縮短工期增加了成本。反之，若減少人力以節省成本，卻要求快速完成，可能導致塗層不均等品質問題。因此，專案經理需在時間、成本與品質間權衡，達成目標並維持合理品質。

軟體與房子的差異

蓋房子使用PMP框架能很好地實現利益最大化，因為建築專案具有實體性和可複製性。一座房子一旦完成，其結構與功能是穩定的，第二間「長得一模一樣」的房子對其他買家仍然有相同的吸引力，因為它滿足了同樣的需求。因此，PMP的範疇、時間和成本控制在房子建設中顯得非常高效。然而，軟體的本質與此完全不同。

獨特性與不可複製性

軟體專案具有高度的創新性與獨特性。一旦一個軟體解決了某個問題（例如Facebook解決了社交網絡的需求），相同功能的軟體對用戶來說幾乎沒有吸引力。成功的軟體專案經驗很難被直接複製，市場需要的是新的賣點和創新功能，而這些「市場從未見過的功能」恰恰增加了專案的不確定性與管理難度。例如，開發全新的人工智慧聊天系統或區塊鏈應用程式，市場可能無法準確預測用戶需求的變化，開發過程中需要不斷調整。

資源分配的挑戰

軟體開發的資源分配挑戰也與建築專案截然不同。在房子建設中，一位油漆工刷一間房子需三天，若要在1.5天內完成，可以增加人力至兩人，工作進度基本上能按比例縮短。但在軟體開發中，這種「人力直接轉換時間」的方式往往無效。增加人力可能引入更多的協作成本，例如新增開發人員需要時間熟悉專案，還可能導致溝通成本的倍增。這就像試圖用九個孕婦在一個月內生出一個孩子——不僅無法達成目標，反而可能帶來混亂與延誤。

人月神話

《人月神話》（The Mythical Man-Month）是由 Fred Brooks 撰寫的經典書籍，被譽為軟體工程領域的奠基之作。書中以軟體開發的特性與其他專案進行對比，強調了軟體的複雜性、不確定性，以及管理中的種種挑戰。該書還對範疇變更、模組化設計、團隊協作等關鍵議題提出了深刻的見解，為軟體開發提供了長久不衰的實用指導。

為什麼差這麼多？軟體特性

軟體開發對工程師而言，是一個閱讀遠多於撰寫的過程。根據個人經驗，工程師的工作時間中約有70%用於閱讀現有程式碼，而撰寫新程式碼的時間僅佔30%。程式碼的品質對專案效率的影響至關重要。糟糕的程式碼會導致誤解、重複和不必要的複雜性，而好的程式碼則簡單、清晰、直觀，甚至能讓非程式設計專業的人也看懂其邏輯。

記憶負擔與工作記憶容量

人類的工作記憶容量是有限的。簡單易懂的程式碼能減輕記憶負擔，讓工程師在有限的記憶空間中容納更多上下文資訊。例如，結構明確的程式碼可以幫助工程師快速理解邏輯並迅速修改；而糟糕的程式碼則會佔用大量記憶資源，導致效率下降甚至出現錯誤。同時，這也顯示出高品質程式碼對長期專案維護的深遠影響。

中斷對效率的影響

工程師經常面臨會議、即時訊息或其他干擾，南加大研究顯示，從中斷到重新專注平均需要23分鐘。如果程式碼簡單清晰，工程師能更快回到工作狀態；而糟糕的程式碼則需要更多時間重新解讀，進一步降低效率。程式碼的可讀性在這樣的情境下顯得格外重要，因為它直接影響了工程師在面對日常中斷時的恢復能力。

品質帶來的長期差異

軟體專案如同一場潛水探險。高品質的程式碼就像清澈的海水，開發者能輕鬆看到目標，採集深海中的珍珠（即高價值功能）。而低品質的程式碼則如同渾濁的水域，能見度低，開發者只能摸索著採集沿海的海帶（即低價值功能）。

與房子建設不同，軟體並非一次性完工，而是需要不斷維護、擴展和更新的動態過程。程式碼的品質直接影響後續工作的難度與成本：

• 高品質程式碼：讓當前工作更高效，未來的迭代也更容易，為長期成功奠定基礎。
• 低品質程式碼：增加開發者的理解與修改難度，導致成本上升與效率下降。

這種差異解釋了為何軟體開發需要更高的靈活性與長期視角。高品質程式碼不僅讓專案當前的進度更順暢，還能降低未來的技術負債，使專案具備可持續發展的潛力。

為什麼差這麼多？溝通成本

在軟體開發中，為了實現具有創新性的功能，密切且頻繁的溝通不可避免。然而，隨著團隊規模的擴大，溝通成本會急劇上升，這正是 Brooks's Law（布魯克斯定律）揭示的核心問題：「向落後的軟體專案添加人手只會使專案進度變得更慢。」

新增成員不僅需要時間熟悉專案，還會增加現有成員的溝通負擔。其溝通成本可以用公式計算：

溝通連結數 = n(n-1)/2

其中，n 是團隊成員數量。隨著人數增加，溝通連結數呈非線性增長：

• 3人團隊：溝通連結數為 3(3-1)/2 = 3
• 4人團隊：溝通連結數為 4(4-1)/2 = 6
• 5人團隊：溝通連結數為 5(5-1)/2 = 10

這意味著每新增一名成員，團隊協作需要投入更多時間和精力。

單純增加人手無法解決問題

1. 學習曲線：新成員需要時間熟悉程式碼和專案背景，短期內降低整體效率。
2. 溝通負擔：更多成員意味更多會議、同步和討論，增加了溝通成本。
3. 協作衝突：成員增多可能導致程式碼衝突和需求理解偏差。

假設一個原本由三人負責的專案新增兩人，溝通連結數從 3 增加到 10，溝通成本翻了三倍。這不僅未加速工期，反而使協作變得更為複雜，展現了 Brooks's Law 的實際影響。

Agile敏捷的誕生

在應對未知變化的挑戰中，軟體開發必須兼顧靈活性與程式碼品質。正如前面所述，軟體開發若注重品質，能同時帶來成本與時間的雙重效益。高品質的程式碼不僅降低了返工和修正錯誤的成本，還能減少開發人員在理解、修改和擴展時的時間浪費。尤其在動態變化的需求環境中，程式碼的可讀性與穩定性至關重要，能讓團隊迅速響應市場的變化。

專案金三角與敏捷合理性

傳統的專案金三角包含範疇（Scope）、時間（Time） 和 成本（Cost） 三個角，三者彼此影響。然而，在軟體開發中，時間與成本往往與 品質（Quality） 緊密掛鉤。當品質得以保障，開發時間可以縮短，成本也更易控制。

如果我們將專案金三角中的時間與成本去掉，核心就剩下範疇與品質。這種簡化直接指向了敏捷開發的核心邏輯：範疇不再僵化，而是通過迭代和增量交付逐步擴展；品質則成為不可妥協的基石，確保每一次迭代都能穩定支持後續開發。

從範疇與品質到敏捷開發

敏捷開發方法以價值驅動為核心，專注於靈活調整範疇，並在高品質的基礎上快速交付成果。這種方式避免了傳統開發中因範疇過於固定導致的延誤和返工問題，也體現了軟體開發與敏捷方法之間的高度契合性：在動態需求的環境下，範疇與品質的平衡決定了專案的成功，而敏捷的迭代方式正是解決這一平衡的最佳實踐。

理想敏捷悖論

精實創業與 MVP

MVP（Minimum Viable Product，最小可行產品） 是敏捷開發與精實創業的核心概念，透過最少資源驗證市場需求，快速針對用戶痛點提供解決方案。

以製作腳踏車到汽車為例

假設一家新創公司希望進軍交通工具市場，他們的目標是最終推出一款全自動駕駛的汽車。但在產品開發初期，直接推出這樣的高複雜度產品不僅成本高昂，也難以確定市場是否接受。因此，他們選擇以下路徑：

1. 腳踏車：第一版產品是簡單的腳踏車，專注於解決短距離交通需求，並測試用戶對品牌的接受度。
2. 電動腳踏車：根據市場反饋添加動力系統，驗證用戶對電動助力的興趣。
3. 摩托車：進一步增加速度與續航能力，逐步進入中距離交通市場。
4. 汽車：最終基於前期積累的用戶需求與技術實驗，推出智能駕駛汽車，滿足更廣泛的交通需求。

MVP 的價值

這種從簡單到複雜、逐步迭代的方式，既能降低開發成本與風險，又能通過用戶反饋逐步完善產品功能，最終推出更貼合市場需求的完整產品。同樣的理念應用於軟體開發，可以讓每次功能推出都為用戶創造價值並積累市場信任。

精實創業的迷思

對於精實創業的批評之一是，市場可能不知道自己真正需要什麼。市場需求往往是對現有解決方案的改進，而非對全新創新的具體要求。這意味著，用戶的反饋可能會局限於他們已知的範疇，缺乏對突破性創新的想像力。例如，他們可能會提出「更快」、「更便宜」、「更方便」的解決方案，但很少會想到徹底改變遊戲規則的新產品。

市場需求的局限性

精實創業的理念依賴用戶反饋來指導產品開發，但這種反饋的價值取決於用戶對問題本身的認知深度。例如：

• 電動車的出現：在電動車誕生之前，市場的聲音可能僅聚焦於如何降低汽油車的價格或提高燃油效率，而非思考如何用另一種能源完全替代汽油。
• 汽車的誕生：在馬車時代，市場關注的可能是更快或更耐用的馬匹，而不是一輛完全脫離動物驅動的新型交通工具。

這些例子表明，用戶往往無法構想「未知」的解決方案，而只是強調現有框架下的優化。

軟體專案對「賣點的腦洞」的依賴

這種可以稱之為賣點的腦洞的創新思維，恰恰是軟體專案成功的關鍵。在軟體開發中，單純依賴用戶反饋，可能導致開發團隊過度關注小幅改進而忽略真正的突破。例如：

• 社交媒體的誕生：Facebook 在創立初期，並不是為了滿足「市場需求」而開發，而是通過一個全新的方式，將人與人之間的聯繫數位化。用戶在使用之前並不知道自己需要這樣的工具，但一旦使用後，它改變了人們的社交方式。
• 流媒體平台的成功：在 Netflix 轉型為串流媒體平台之前，用戶的需求僅限於「租錄影帶更便捷」，但串流媒體的概念徹底改變了人們的觀看習慣，這種創新是市場無法預測的。

理想的軟體專案不存在

值得開發的軟體，不存於現行市場

成功的軟體通常來自於對市場未見過需求的全新詮釋。基於軟體的創新特性，能提供不同於市場現有解決方案的功能才具有真正的賣點。例如，社交網絡的早期市場關注即時通訊的改進，但 Facebook 的成功在於創造了一個全新的社交互動模式，突破了即時通訊的框架，提供用戶前所未見的價值。

基於軟體特性，應採用敏捷迭代開發

軟體開發充滿不確定性和創造性，開發初期很難準確預估範疇、時間和成本。敏捷方法針對這些特性，將專案分解為多個小步驟，每次迭代交付可測試的功能，並根據用戶反饋調整方向。這樣的迭代模式能應對需求的動態變化，是軟體開發的自然選擇。

敏捷開發以價值為單位交付

敏捷強調每次交付都要帶來用戶感知到的價值，例如優化流程、解決痛點或提升效率。在開發一款任務管理軟體時，早期版本可能僅聚焦於「新增任務」與「標記完成」功能，透過反饋逐步加入分類、提醒等增值功能，這種增量式交付讓用戶逐步體驗到產品價值的提升。

價值需符合市場需求

敏捷交付的價值必須符合市場當前需求。市場通常偏好對現有產品的改進，如更快速的載入、更友好的介面，而非完全顛覆的功能。開發者若無法在早期版本中滿足這些需求，可能無法吸引足夠的用戶支持。

市場只想強化現行市場已有的方案

市場反饋往往聚焦於更高效、更便宜或更方便的現有方案。例如，在開發搜尋引擎時，市場需求或許集中於改進索引速度或結果準確性，而非重新定義搜尋的形式（如語音搜尋或生成式 AI 搜尋）。突破性的創新往往由開發者基於遠見和創意推動，而非由市場直接引導。

邏輯閉環：理想軟體專案不存在

• 值得開發的軟體，往往不在現行市場需求中表現出來。
• 軟體特性要求敏捷開發應對不確定性。
• 敏捷交付需要基於市場需求。
• 市場需求通常偏向增強現有方案，非顛覆性創新。

因此，真正「理想」的軟體專案並不存在。軟體開發的成功更依賴於在不完美中尋找平衡，例如利用敏捷應對需求變化，結合創新與市場反饋推動產品迭代，而非追求完全契合的理想狀態。

專案中的角色盲點

正因為理想的軟體專案不存在，專案團隊必須更加重視敏捷宣言中的互動、合作與適應變化。然而，各角色在專案中都有可能因視角或專業範疇的限制而產生盲點，這些盲點若未被解決，將嚴重影響專案的推進與成果。

工程師的盲點

BUG 的本質

沒有工程師會故意製造 BUG，因為每一個 BUG 都意味著更多的返工與額外的壓力。工程師希望程式一次性順利運行，並為團隊節省時間。然而，軟體開發的複雜性和不確定性，使得問題的產生難以完全避免。

多數 BUG 的來源來自於工程師的視角侷限或對需求的誤解：

• 缺乏對需求的全局理解：需求文件可能遺漏細節或缺乏清晰定義，導致功能無法滿足實際需求。例如，開發報表匯出功能時，忽略了用戶需要特定檔案格式。
• 假設用戶以預期方式操作：用戶的實際行為常超出設計預期，例如輸入非法數據或同時多用戶操作，導致程式出錯。
• 快速交付的壓力：在敏捷開發中，為了趕上迭代進度，工程師可能忽略極端情境測試，留下潛在的問題。
• 邊界情境不可預測：一些極端情況（如大數據處理或低網速）難以在測試中完全模擬，導致隱藏問題暴露。

當 QA 指責工程師

QA 的指責通常是出於對產品穩定性和開發者細心程度的高期望，希望減少返工並提高品質。然而，這種指責經常被解讀為對工程師創意發想的挑戰，可能帶來以下影響：

• 開發者感到挫折：認為自己的努力被簡化為「不夠細心」，忽略了開發過程中的複雜性。
• 問題本質被忽略：實際上，BUG 的根源通常在於需求模糊或情境未考慮充分，而非開發者的過失。

工程師的工作伴隨著不確定性與高壓挑戰，需求的模糊性與測試不足讓這些盲點成為開發過程中難以避免的部分。然而，通過主動釐清需求定義與測試覆蓋，這些問題是可以逐步減少的。

PM 的盲點

PM 是專案中的核心協調角色，負責在需求、資源和進度之間找到平衡。然而，需求的緊急變更幾乎是不可避免的，而這些變更往往真的重要，也真的沒想到。儘管如此，這些變更仍然讓 PM 處於尷尬的境地：

• 對客戶：PM 要協助實現變更，往往被認為站在客戶一邊，忽略了開發團隊的壓力。
• 對開發：開發可能覺得 PM 沒有做好規劃，把變更視為「額外負擔」。

緊急變更的本質

需求的緊急變更並非因 PM 規劃不當，而是來自需求本身的不可預測性。例如：

• 市場環境突變，需要立即新增功能來應對競爭。
• 客戶原先未考慮到的使用情境，導致需求改動成為必需。

這些變更並非 PM 的失職，也無法完全避免。

當開發指責 PM「麥擱鈣啊」

開發人員在面對緊急變更時，常以「麥擱鈣啊」（不要再這樣了）表達不滿，實際上是對變更帶來的壓力感到不安。他們的擔憂包括：

• 新需求可能破壞現有程式的穩定性。
• 短期內無法充分測試，導致更多問題。

然而，PM 無法預知所有需求變更，也無法避免外部需求的干擾。因此，這樣的指責實際上是在挑戰 PM 的「通靈能力」。

設計師的盲點

Overdesign 的本質

過度設計（Overdesign） 是設計師在創作過程中，過於追求滿足多樣化場景或小眾需求，導致設計成本大幅提升，卻無法產生對應的價值回報。過度設計的結果通常是高成本的解決方案服務於少數特定用戶，而非大多數目標客群。

設計師可能這樣回應批評：「就真的有人會這樣用啊。」
這種執著往往源於對用戶需求的高度敏感，本意上是為了提供更好的體驗。然而，為了實現所有創意而增加設計的複雜性，卻可能導致以下問題：

• 功能過多，主次不清：多餘的功能讓主流用戶無所適從，核心價值被掩蓋。
• 資源分散，進度延遲：過度追求細節可能消耗過多時間與開發成本。
• 高成本追逐小眾市場：即使設計有效，但效益可能無法覆蓋投入成本。

沒有客訴，因為沒人會用

過度設計的最終結果，可能是設計的場景過於極端，以至於大多數用戶不會嘗試，甚至完全忽略這些設計。這種情況下，設計師雖然實現了創意，但實際上：

• 沒有效率：高成本的投入未能轉化為主流用戶的滿意度或市場回報。
• 沒有客訴並不代表成功：用戶選擇直接放棄使用功能，導致問題隱性化。設計看似完善，但實際被邊緣化。

當設計師執著於實踐所有的創意時，本意是為了用戶著想，卻可能因過度關注少數場景而犧牲了整體效益。設計需要平衡創意與效率，從而更好地服務目標客群。

高階主管的盲點

頻繁開會的本質

高階主管常透過會議統整資訊與推進專案，但頻繁的會議可能適得其反，對效率造成負面影響。事實上，開會不等於推進進度，過多會議可能暴露以下問題：

• 分散專注力：頻繁中斷工作參會，降低效率，並增加重新進入狀態的時間成本。
• 流於形式：部分會議僅為報告進度，缺乏實質問題解決，時間成本高卻成效低。
• 決策模糊：討論過多但結論不清，導致後續執行方向不明確。

例如，當專案受阻時，會議可能只是在反覆描述問題，而未帶來具體解決方案。

高階主管的兩難

高階主管需在確保方向正確與維持行動力之間找到平衡：

• 方向正確：會議能協調資訊，統一目標，確保團隊沿著正確軌道前進。
• 行動力：過多會議可能耗費時間，削弱執行效率，甚至引發團隊不滿。

當團隊質疑「為什麼還要開會」時，通常反映以下問題：

• 目標不明：會議缺乏明確方向，參與者難以產生實質貢獻。
• 缺乏行動：結束後沒有具體執行計畫，讓問題懸而未解。
• 內容重複：會議頻繁但重複性高，讓團隊感到時間被浪費。

高階主管應確保會議具備清晰目標與實質行動，避免過度依賴會議，讓其成為真正推進專案的利器。

意識、意願、能力

多數團隊中的問題，其根源往往在於意識層級的盲點，而非意願或能力的不足。無論是工程師、PM、設計師，還是高階主管，角色之間的矛盾常常源於對問題本質的認知差異，而不是誰不努力或不夠專業。

意識層級的問題

• 工程師可能未意識到某些邊界情境會導致 BUG。
• PM可能未意識到需求的不可預測性，過於依賴既有規劃。
• 設計師可能未意識到過度設計的成本效益失衡。
• 高階主管可能未意識到頻繁開會對團隊專注力的負面影響。

這些問題反映的並不是成員不願意配合或缺乏能力，而是他們的視角局限於自身職責，難以全面理解整個專案的需求與挑戰。

為什麼團隊合作與溝通重要

正因為這些意識層級的盲點，團隊中的合作與溝通才顯得尤為重要。透過頻繁的互動與反饋，成員之間可以補足彼此的視角差異，避免將問題簡單地歸咎於「誰不夠努力」或「誰不夠專業」。例如：

• 工程師可以通過與 PM 和設計師的溝通，更清楚理解需求的背景與核心價值。
• PM 可以透過開發與設計的反饋，調整規劃，讓需求更具可行性。
• 高階主管可以通過直接與團隊互動，了解實際執行情況，避免以數字表面化判斷進度。

團隊合作的本質，不是讓所有人變得完美，而是讓彼此的不足不再成為阻礙。 通過合作，團隊能將個體的局限轉化為集體的優勢，最終在不完美的條件下實現專案的最佳效果。

實踐敏捷

理解了團隊合作的重要性後，接下來將聚焦於如何實踐敏捷的團隊合作。敏捷的核心在於透明、溝通和持續改進，而這需要每個角色共同努力，通過清晰的框架和實踐將敏捷精神落地。

人人都會敏捷

精神層面，其實每個人都會敏捷，我們在日常生活中經常運用這種思維來應對變化。以餐廳菜單為例，可以直觀地理解敏捷與 PMP 的核心差異，以及如何適應動態環境的需求：

• PMP 路線：餐廳的精裝印刷菜單設計初期需確定所有內容並經反覆校對，變更成本高昂且需額外時間，類似 PMP 的方式，強調穩定性與長期規劃。
• Agile 路線：黑板菜單靈活性高，可快速調整菜品或應對顧客需求，修改成本低且響應迅速，體現了敏捷的核心特徵。

糕餅店的經營也展現了敏捷與 PMP 的應用差異：

• PMP 路線：糕餅店的經典產品如綠豆椪或鳳梨酥，需求穩定且製作流程成熟，適合長期規劃與標準化生產。
• Agile 路線：糕餅店店門口推出新口味試吃，如抹茶或紫薯口味，快速獲取顧客反饋並調整配方，靈活應對市場需求。

敏捷與 PMP 的互補關係

敏捷並非取代 PMP，而是針對不同需求發揮作用。PMP 提供穩定的基礎，適合長期規劃；Agile 帶來靈活創新能力，快速適應變化。

項目	大量規格校正	每天換新試吃
產品交付（變更）速度	慢：需重新調整規格和流程	快：可以每天進行調整
交付成本	高：變更可能曠日費時，成本較高	低：只需食材與烤箱，成本可控
相對適用方法	PMP	Agile

餐廳與糕餅店的實踐展示了 PMP 與 Agile 的應用價值。兩者的結合能在穩定與創新間找到最佳平衡，滿足市場需求的多樣化挑戰。

Scrum 敏捷的實踐框架

Scrum 是敏捷的一種實踐框架，旨在應對快速變化的需求並提高產品交付效率。透過短周期的迭代（Sprint），Scrum 將大型專案分解為小的可管理單元，強調透明度、檢查與調整，幫助團隊快速適應變化。

Scrum 的角色

Scrum 定義了三個關鍵角色，分工明確且相互配合，確保專案運作順利。

產品負責人（Product Owner）

• 與 Scrum Master 配合，清晰傳達產品方向，協助解答團隊的需求問題。
• 與 Scrum 團隊合作，確保開發團隊理解需求的業務價值，回答技術相關問題，並參與 Sprint 計劃會議和成果展示。

Scrum Master

• 與產品負責人協調待辦清單的優先級變更，確保 Sprint 計劃的穩定性。
• 與 Scrum 團隊協作，移除開發過程中的障礙，主持會議並提供敏捷方法論的指導，幫助團隊專注於目標。

Scrum 團隊（Scrum Team）

• 與產品負責人合作參與需求討論，提供技術可行性建議並澄清需求。
• 與 Scrum Master 配合，反映工作中的障礙和挑戰，提出改進建議以提升效率。

Scrum 的會議

Sprint 計劃會議

• 產品負責人解釋產品待辦清單的優先項目，幫助團隊了解目標。
• Scrum 團隊評估任務難度，分解為具體工作項目，並估算完成所需時間或點數。
• Scrum Master協助團隊討論，幫助達成共識。

每日站會（Daily Stand-up）

• 團隊成員快速回答以下三個問題：
  1. 昨天完成了什麼？
  2. 今天計劃做什麼？
  3. 是否遇到任何阻礙？
• 根據討論調整當日計劃，提出需要幫助的問題。

Sprint 展示會（Sprint Review）

• Scrum 團隊展示完成的工作成果（可運行的產品增量）。
• 產品負責人記錄新的需求與改進建議，更新產品待辦清單。
• 利害關係人提供反饋，評價成果並提出改進意見。

回顧會（Retrospective）

團隊討論三個問題：

1. 本次 Sprint 中有哪些做得好？
2. 哪些地方需要改進？
3. 下一步如何提升？

根據討論制定行動計劃，優化未來工作流程。

會議名稱	會議目的	時長	頻率
Sprint 計劃會議	設定 Sprint 的目標，分解工作項目，並規劃執行計劃	每 Sprint 2 小時	每 Sprint 開始時
每日站會	同步進度，快速識別阻礙並調整計劃	每天 15 分鐘	每工作日
Sprint 展示會	向利害關係人展示迭代成果，收集反饋，確保產品方向符合需求	每 Sprint 1 小時	每 Sprint 結束時
回顧會	檢討 Sprint 表現，總結優點與改進點，提升未來運作	每 Sprint 1 小時	每 Sprint 結束時

Scrum 的工具選擇

Scrum 框架中常用的工具和方法，幫助團隊提升效率並追蹤進度。然而，部分工具的適用性需要根據團隊特性進行評估和調整。

1. 看板（Kanban Board）與產品待辦清單（Product Backlog）

   • 看板將工作分為「待辦」、「進行中」和「完成」等狀態，讓團隊清楚了解任務進展。
   • 產品待辦清單是產品所有需求的有序列表，根據優先級決定下一步工作，確保資源投入在最高價值的任務上。

2. 費波那契時間估算原則

   • 團隊使用費波那契數列（1、2、3、5、8……）為任務估算工作量。
   • 這種方式反映了人類在處理大型任務時的估算不確定性，有助於更準確地規劃時間。

3. 燃起圖（Burn Up Chart）

   • 燃起圖追蹤已完成工作量，並顯示需求變更的總量，將變更視為產品進化的一部分，而非干擾。
   • 它能清楚展示已完成的成果與變更需求的整體關係，讓團隊看到自己的進步並增強信心。

為什麼不推薦燃盡圖（Burn Down Chart）

燃盡圖（Burn Down Chart）原本旨在追蹤剩餘工作量與時間的關係，但在需求經常變更的情境中可能會適得其反：

• 忽略變更價值：燃盡圖通常將需求變更視為負擔，可能導致開發團隊對變更產生抵觸情緒。
• 加劇壓力：當燃盡圖顯示剩餘工作量不斷上升時，團隊容易感到壓力，甚至犧牲質量來「趕進度」。
• 過於理想化：它假設需求固定不變，忽略了軟體開發中需求變化的不可避免性。

Scrum 工具的選擇應根據團隊的需求和實際情境靈活調整。像看板、產品待辦清單與燃起圖這類工具，更能體現敏捷思維的價值，幫助團隊有效管理進度，適應變化，並持續交付高品質成果。

總結：敏捷是適應與平衡的藝術

理想的專案不存在，但成功的專案源於在不完美中找到平衡。在專案管理中，無論是 PMP 還是敏捷，真正的重點不在於選擇哪種方法，而是如何根據需求與場景靈活運用它們，並通過團隊合作與持續學習，逐步接近專案的目標。敏捷，作為一種精神，將始終伴隨著團隊的創新與成長。

線上/實體講座

照片

評價

簡報

為節省用戶流量，此簡報或PDF，

採手動載入。

延伸閱讀

人月神話：軟體專案管理之道

有些書，對於讀者和作者就像是年金一樣，可以年年分紅。《人月神話》就是這樣一本書……年輕的軟體工程師、缺錢的研究生、懶惰的程式設計老手，常問我哪一本電腦書最好：「如果我被困在荒島上，只能帶一本電腦書，應該選哪一本？」這問題很荒謬，但他們堅持要答案。假如你真的被放逐到這樣的小島上，應該陪伴你的是《人月神話》。

讀冊生活

精實創業：用小實驗玩出大事業（2017書衣新版）

★「精實創業」的關鍵概念？

最小可行產品（MVP）：產品或服務不要等到「完美」才推出，只要服務堪用就應該讓消費者使用。當初dropbox的第一版產品只不過是一段影片說明，就可以聽到眾多使用者的迴響。當初google只能搜尋專業技術網站，但使用者都已經知道她的優點。

軸轉（Pivot）：快速推出產品、快速更新，可以讓我們真的知道產品是否讓大家滿意，一旦確認做出來的東西不是大家所需要的，就應該立刻修改方向，這就是軸轉。當初flickr是一個線上遊戲網站，經過「軸轉」，將子計畫改成主計畫，就成為全世界最知名的照片分享服務。Twitter原本是線上廣播，也是經過「軸轉」，成為改變世界的新服務。

讀冊生活

外部優質課程

PMI台灣分會

社團法人國際專案管理學會台灣分會(PMI Taipei, Taiwan Chapter, 簡稱簡稱「PMI-台灣分會」，或PMI-TW) 於1999年10月由PMI總會授權在台北成立，亦於2003年9月獲內政部核定為全國性非營利性組織。

前往學習

大人學

「這裡是《大人學》課程報名網站。您可以在這裡參與我們優質的實體與線上課程，註冊學員也能下載豐富的學習資源。讓我們一同往成熟大人之路邁進！」

前往學習