什麼是敏捷專案管理？

敏捷專案管理是一種迭代式的產品交付方法，從專案開始時就逐步建立，而不是在接近結束時一次性交付整個產品。此方法基於敏捷宣言（2001年）。

敏捷宣言與十二項原則

全部敏捷軟體開發方法（Scrum，看板、XP）都包含敏捷宣言（核心價值）與十二項敏捷原則，這些代表了一套價值觀，指導組織內人員應如何相互對待。這些價值觀與原則對於正確理解敏捷專案管理至關重要。

什麼是敏捷宣言？

宣言的用詞非常慎重，強調以最少必要語言來捕捉敏捷的核心精神：

• 個人與互動勝過流程與工具
• 可運作的軟體勝過完整的文件
• 客戶合作勝過合約談判
• 回應變更勝過遵循計畫

注意：

• 所有這些陳述中的關鍵字是「勝過」。宣言並非建議以左側取代右側，而是強調左側優先於右側。
• 敏捷宣言的創立是作為一種替代方案，以取代那些文件繁重、負擔沉重的軟體開發流程（例如瀑布模型）。

敏捷宣言背後的原則

作為核心敏捷宣言的補充，十二項原則進一步闡明了敏捷的含義。Scrum架構透過各種活動（例如，產品待辦事項清單，每日站會、迭代開發、回顧會議）：

敏捷原則

1. 我們的最高優先事項是透過早期且持續交付高價值的軟體來滿足客戶。
2. 歡迎變更需求，即使在開發後期也是如此。敏捷流程將變更轉化為客戶的競爭優勢。
3. 頻繁交付可運作的軟體，時間範圍從幾週到幾個月，且偏好較短的時程。
4. 業務人員與開發人員必須在整個專案期間每日合作。
5. 以有動機的個人為核心來建構專案。提供他們所需的環境與支援，並信任他們完成工作。
6. 向開發團隊傳遞資訊，以及在團隊內部傳遞資訊的最有效方法是面對面的交流。
7. 可運作的軟體是進展的主要衡量標準。
8. 敏捷流程促進可持續發展。贊助者、開發人員和使用者應能無限期地維持穩定的節奏。
9. 持續關注技術卓越與良好設計，能提升敏捷性。
10. 簡化——最大化未完成工作的藝術——是不可或缺的。
11. 最佳的架構、需求與設計來自於自我組織的團隊。
12. 團隊定期反思如何變得更有效，並根據此調整其行為。

Scrum 是如何運作的？

Scrum 透過特定的概念與實務，與其他敏捷流程有所區別，這些概念與實務可分為三個類別：角色（產品負責人, Scrum 主管、開發團隊及其他利益相關者），事件、實體與規則。

啟動 Scrum 流程時，產品負責人會建立一份優先順序清單，稱為產品待辦事項清單。在Sprint 規劃期間，待辦事項會根據複雜度與商業價值（優先順序）進行評估。產品負責人（客戶）與開發團隊共同決定哪些待辦事項納入本次 Sprint。團隊有固定時間（稱為Sprint，通常為兩至四周）來完成工作，但他們每天會開會以評估進度（每日站會）。在整個過程中，Scrum 主管確保團隊專注於目標。在 Sprint 結束時，團隊會檢視進度，向客戶展示工作成果，並評估哪些做得好，以及哪些需要在下一個 Sprint 中改進。此循環隨後重複。

敏捷方法透過將專案拆解為小型的使用者功能，進行優先排序，並以每2至4週為一個週期持續交付，這些週期稱為迭代或 Sprint。

團隊以短週期運作，目標是持續改進，並僅開發使用者真正需要的功能。工作目標由團隊在每個週期開始時定義。若客戶對某項功能有任何疑問，團隊會直接與客戶溝通。客戶的優先順序由產品負責人分析，並反饋給團隊，以便他們能持續專注於最高優先級的項目。團隊會估計完成一次迭代所需時間及執行方式。

每輪迭代結束時，由客戶衡量績效。每輪迭代中所學到的教訓會在回顧會議中記錄下來，並應用於未來的迭代中。如此一來，產品持續改善，開發流程也持續提升。

注意：
Scrum 是一種透過「檢視與調整」來開發與維護複雜產品的框架。它是一種遵循敏捷宣言與原則的敏捷方法，整合了三種角色、三種實體、五種事件與五種價值——被稱為「3355.”

在此架構中，整個開發過程由幾個短暫的迭代週期組成，稱為Sprints。建議實務包括：

• 每個Sprint持續1至4週。
• 使用產品待辦事項清單來管理產品需求——一個按價值排序的優先清單。
• 在每個迭代中，Scrum團隊會從產品待辦事項清單中選擇最高優先級的項目進行工作。
• 在Sprint規劃會議期間，所選的需求會被討論、分析與估算，以達成對應的迭代目標與交付計畫，稱為Sprint待辦事項清單.
• 每日每日Scrum在整個迭代期間會舉行每日Scrum會議。在每個迭代結束時，Scrum團隊會邀請商業利益相關者及其他相關人士審查可能可交付的產品增量。
• 接著，團隊會檢視並持續改進其工作方式。
• Scrum不僅適用於軟體開發專案，也適用於任何複雜或創新專案、探索活動以及組織變革計畫。

Scrum角色

Scrum架構由三個核心角色定義：開發團隊、Scrum Master與產品負責人。

產品負責人

產品負責人負責最大化產品與開發團隊工作的價值。達成此目標的方式可能因組織、Scrum團隊與個人而異。

產品負責人角色

產品負責人是唯一負責管理產品待辦事項清單。產品待辦事項清單的管理包括：

• 明確表達產品待辦事項；
• 將產品待辦事項清單中的項目排序，以最佳方式達成目標與使命；
• 優化開發團隊所執行工作的價值；
• 確保產品待辦事項清單對所有人可見、透明且清晰，並顯示Scrum團隊接下來將處理的事項；
• 確保開發團隊對產品待辦事項中的項目達到所需的了解程度。

Scrum 主管

Scrum 主管確保Scrum被理解並實際執行。Scrum 主管透過確保Scrum團隊遵守Scrum理論、實務與規則來達成此目標。

Scrum 主管是Scrum團隊的服務型領導者。Scrum 主管協助團隊外部的人了解與Scrum團隊互動中哪些是有幫助的，哪些是沒有幫助的。Scrum 主管協助所有人調整這些互動，以最大化Scrum團隊所創造的價值。

Scrum 主管的角色

Scrum 主管以多種方式支援產品負責人，包括：

• 識別有效的產品待辦事項管理技巧；
• 協助Scrum團隊理解清楚且簡明的產品待辦事項的重要性；
• 理解在經驗環境下的產品規劃；
• 確保產品負責人知道如何優先處理產品待辦事項以最大化價值；
• 理解並實踐敏捷性；
• 促進Scrum 事件必要時。

Scrum 主管對開發團隊的服務
Scrum 主管以多種方式支援開發團隊，包括：

• 引導開發團隊進行自我組織與跨功能合作；
• 協助開發團隊交付高價值的產品；
• 排除阻礙團隊進展的障礙；
• 必要時促進Scrum事件；
• 在尚未完全採用或理解Scrum的組織中，引導開發團隊。

Scrum 主管對組織的服務

• Scrum 主管以多種方式支援組織，包括：
• 領導並引導組織採用Scrum；
• 規劃組織內Scrum的實施；
• 協助員工與利害關係人理解並採用Scrum與經驗式產品開發；
• 推動變革以提升Scrum團隊的生產力；
• 與其他Scrum主管合作，以提升組織內Scrum應用的有效性。

開發團隊

開發團隊由負責在每個迭代結束時交付可發行產品增量的專業人員組成。只有開發團隊的成員才能創建增量。

團隊由組織建立並賦予權力，以自主組織和管理自己的工作。由此產生的協同效應可優化團隊的整體效率和效能。

開發團隊的特徵

開發團隊具有以下特徵：

• 他們是自我組織的。任何人都不會（甚至包括Scrum Master）告訴開發團隊如何將產品待辦事項轉化為可發行的增量；
• 開發團隊是跨功能的，具備創建產品增量所需的所有技能；
• Scrum不承認團隊成員的其他頭銜，除了「開發人員」之外，無論其執行的工作為何。此規則無任何例外；
• Scrum不承認開發團隊內的子團隊，無論具體領域為何，例如測試或業務分析。此規則無任何例外；
• 團隊成員可能具備專業技能和專注領域，但責任屬於整個開發團隊。

Scrum事件

Scrum框架包含五個事件：迭代，迭代規劃, 每日站會, 迭代審查，以及迭代回顧.

• 一個迭代（也稱為迭代）是Scrum中開發的基本單位。迭代是一種時間盒化的努力，也就是說，其持續時間是有限的。每個迭代的持續時間是預先決定的，通常介於一到四周之間，最常見的是兩週。
• 迭代規劃是Scrum框架中的一個事件，團隊在其中決定在迭代期間將處理哪些產品待辦事項，並討論完成這些事項的初步計劃。
• 一個每日站會（也稱為每日Scrum會議）是一場短時間的時間盒化會議，用以確保所有人保持一致。通常持續5至15分鐘，有時也稱為站會、晨會或每日集結。
• 迭代審查發生在迭代結束時。在此次審查中，產品負責人說明在迭代期間哪些計劃中的工作已完成或未完成。隨後團隊展示已完成的工作，並討論哪些方面做得好以及問題是如何解決的。
• Sprint 回顧 在每次 Sprint 回顧後進行。它讓團隊有機會檢視自身，並制定一份改進計劃，以便在下一個 Sprint 中實施。

Scrum 藝術品

藝術品是提供專案細節的實體記錄。Scrum 藝術品包括產品待辦事項清單，Sprint 待辦事項清單，以及產品增量。

• 這個產品待辦事項清單 是一個優先排序的特色、缺陷或技術任務清單，目前尚未進行中。從產品負責人的觀點來看，它應包含所有被認為具有價值的工作。
• 隨著產品需求的改變與演進，產品負責人 以及團隊其他成員會根據需要審查並調整產品待辦事項清單。
• 這個Sprint 待辦事項清單 是團隊承諾在 Sprint 期間要處理的產品待辦事項清單中所有項目之清單。此清單是透過從產品待辦事項清單中優先排序項目，直到團隊認為已達到其 Sprint 容量為止。團隊成員遵循自我組織的 Scrum 框架，根據技能與優先順序在 Sprint 待辦事項清單中登記任務。
• 這個產品增量 是在一個 Sprint 中完成的所有工作，加上之前所有 Sprint 中完成的工作總和。Sprint 的目標是產生一個可發行的產品增量。Scrum 團隊需就增量的「完成」定義達成共識，且所有成員都必須同意並理解此定義。

為什麼要使用敏捷原則與敏捷專案管理？

你的組織是否正朝向敏捷專案管理發展？你是否希望擴展技能，包含敏捷方法？許多組織正在採用敏捷方法，以提升團隊表現、增加客戶滿意度，並增強專案彈性。使用敏捷方法的組織能夠回應動態的市場變化，並成功完成更多專案。敏捷培訓是將組織與專案團隊層級與敏捷及其相關實踐方法對齊的理想方式。敏捷培訓可以澄清許多關於敏捷運作的誤解，並幫助揭示底層的敏捷概念，同時釐清不同實踐方法之間的差異。

通常，當組織使用「敏捷」一詞描述挑戰時，指的是執行敏捷方法的困難。讓所有專案團隊成員（技術與業務）參加相同的培訓，最好在同一班級，有助於解決其中一些問題。整個團隊應聽到相同資訊、概念與實踐策略，形成共通語言與觀點。這種共同理解大幅提升了團隊使用共通語言、共同檢視與調整的能力，減少未來的衝突。

無論你是尋求敏捷認證以擴展個人的敏捷知識，還是希望為組織內多個層級提供敏捷方法的培訓，我們都能透過敏捷培訓幫助你快速啟動。我們可以教你所有敏捷原則與實務，包括 Scrum、XP 和 Lean。

實施敏捷方法的好處

鼓勵終端使用者在專案期間參與，提供可見性與透明度。整個過程中持續的規劃與反饋，從一開始就創造商業價值。

採用早期交付商業價值理念的組織，更容易降低開發相關風險。敏捷專案管理的一些關鍵好處包括：

高品質產品

• 定期測試以確認產品在開發期間運作正常
• 及時定義與詳細規格化需求
• 將持續整合和每日測試融入開發流程
• Sprint 回顧，以實現流程與工作持續改進
• 軟體以逐步且快速的週期進行開發。

更高的客戶滿意度

• 向客戶展示可運作的功能
• 更快且更頻繁地將產品推向市場
• 維持客戶的參與與投入

增強專案控制力

• 每日 Sprint 會議
• 透過資訊顯示器實現透明度

降低風險

• 開發在 Sprint 內進行，確保功能交付之間的時間短
• 敏捷方法在實施最新變更時提供彈性
• 在整個開發過程中適應客戶需求與偏好

更快的投資回報率（ROI）

• 著重於商業價值，讓客戶能優先安排功能
• 經過數次迭代後，即可推出可運作的產品上市
• 敏捷方法支援快速產品發佈，並能衡量客戶回應