敏捷式專案管理是什麼？3分鐘快速了解【2021最新版】

敏捷式專案管理是什麼？「為什麼每天認真地按照工作計畫，結果卻不如預期？」或許這並非是你管理的方式錯誤，而是你需要換一個管理思維。

在這個變動的年代，按表操課、老闆說了算的工作型態，已經不足以面對險惡多變的商業市場，全球正興起更快、更聚焦、更有彈性的超高效管理術－「敏捷式管理」，一起來了解這個連amazon、Netflix、Spotify等大公司都在用的管理法吧！

本篇文章主要有3個重點：

敏捷式專案管理是什麼？
敏捷次管理法有哪些？
如何推動敏捷式專案管理

敏捷式專案管理是什麼？
敏捷式管理又稱為「Agile」，藉由快速試錯來蒐集第一手情報，反饋後凝聚團隊修正方向，重新開發更貼近客戶需求的商品或行銷策略。

敏捷式專案管理是什麼？

敏捷式管理又稱為「Agile」，源自於軟體開發，其核心理念為「快速試錯、即時回應、顧客導向、排定優先順序分配資源」 。

藉由快速試錯來蒐集第一手情報，反饋後凝聚團隊修正方向，重新開發更貼近客戶需求的商品或行銷策略，敏捷並非只重視專案執行的速度，更要求專案的精準性與即時性，才能因應現今變化快速又詭譎的市場。

敏捷宣言與十二項原則

敏捷宣言於 2001年由17名軟體開發者發布，以最簡潔的文字指導組織裡的人該如何共事。

以敏捷思維（Agile Mindset）延伸出四大價值與十二項原則，我們一個一個來了解。

四大價值分別為：

「個人與互動」重於「流程與工具」
「可用的軟體」重於「詳盡的文件」
「客戶的合作」重於「合約協商」
「回應變化」重於「遵循計畫」

#1.「個人與互動」重於「流程與工具」

團體共事中，人與人之間的溝通比制式的流程和工具更重要，因為專案是透過人來完成，工具只是輔助，專案執行過程遇到的困難也是由人來解決。

流程與工具並非不重要，流程與工具是專案執行中應遵循的邏輯與可使用的資源，只是遵循流程和運用資源最終還是回到人的層面，因此才說個人間的互動是專案成功的關鍵，如果空有流程、工具，卻不重視溝通，專案一樣做不好。

#2.「可用的軟體」重於「詳盡的文件」

以開發軟體來說，如果空有詳盡的文件，卻沒有在過程中持續產出可用的軟體或功能，最後的產品可能就不符合客戶的需求，因此與其重視非常詳盡的文件，不如持續產出可用的功能。

重視文件的細節固然也很重要，但是別忘了，開發軟體的初衷就是完成可以流暢作業的軟體；專案也是如此，如果因為過度關注文件而犧牲了開發出可使用的軟件，那麼文件再好再完整，意義也不大。

#3.「客戶的合作」重於「合約協商」

這個原則的意思是重視持續和客戶合作，而不是拘泥於原本的合約、計畫。在執行專案的過程，最好做到靈活、包容、不死板。

一旦客戶改變想法，建議靈活變通，以完成新目標為主，而不是用最初的規定。不管是專案管理還是開發軟件，這類知識型項目是動態的，外界的需求變化速度快，相應技術的進步也相當迅速。

面對專案執行過程中的變化，或預見即將出現的問題時，需要與客戶重新定義合同，雙方達成一致之，專案才能順利執行下去，做出真正符合客戶的成品。

#4「回應變化」重於「遵循計畫」

俗話說計畫趕不上變化，專案中必定存在不少變因，例如技術、人事等。

如果不懂得變通，執意按照最初的計畫執行，那麼最終還是得花時間、人力去修正必然的改變，非常浪費時間。

而敏捷管理的精神就在於「回應變化」勝過「遵循計劃」，既然變化不可避免，不如就接受並做好計劃，將計畫中的改變視為有助於改進項目、增加價值的機會，而不是導致進度延期、增加成本的絆腳石。

敏捷宣言發布之後，又再細分出十二項敏捷原則，目的是為了幫助和指導團隊有更詳細的原則，好度過轉型過程的陣痛期。

十二項敏捷原則內容如下：

我們的首要任務是通過早期和持續交付有價值的軟件來滿足客戶。
歡迎不斷變化的要求，甚至是開發後期。敏捷流程利用變化來實現客戶的競爭優+勢。
經常提供工作軟件，從幾周到幾個月，優先考慮更短的時間尺度。
業務人員和開發人員必須在整個項目中每天一起工作。
圍繞有動力的個人建立項目。為他們提供所需的環境和支持，並相信他們能夠完成工作。
向開發團隊內部和內部傳達信息的最有效和最有效的方法是面對面交談。
工作軟件是進步的主要衡量標準。
敏捷過程促進可持續發展。贊助商，開發者和用戶應該能夠無限期地保持穩定的步伐。
持續關注技術卓越和良好的設計可提高靈活性。
簡單性 – 最大化未完成工作量的藝術 – 至關重要。
最好的架構，要求和設計來自自組織團隊。
團隊定期反思如何變得更有效，然後相應地調整和調整其行為。

隨後便延展至企業管理，成為現在常見的「敏捷管理法」，核心為以顧客為導向、高效溝通、自組織及持續學習，使用者擴及教育、設計、服務及政府部門。

了解敏捷的精神之後，接下來就來了解敏捷中最重要的Scrum吧!

Scrum中的3個角色

Scrum 最初是一個被用來管理「生產錯綜複雜產品」的框架，運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效，因此你可以持續改善產品，團隊，還有工作環境。

Scrum 框架中包含了 Scrum Teams 和他們相關的角色，活動，產出物，和規則。每個框架中的組成都有特定的目的，也都是讓 Scrum 成功和運行的必要條件。Scrum 規則把角色，活動和產出物整合在一起，也主宰了各個組成之間的關係和互動。

Scrum的意思是橄欖球中的列陣爭球，特色就是需要搭配大量戰術，且隊員須具備高度默契才能使用。敏捷式管理也一樣，執行Scrum的團隊必須是能獨立完成專案的菁英成員組成。而在這個團隊中，主要有3種角色，分別是：

Development Teamr（簡稱Team）
Product Owner（簡稱PO）
Scrum Master（簡稱SM）

#1.Development Team

顧名思義就是指擁有獨立完成專案能力的團隊，人數5-9人為佳。是決定該如何完成專案的人，具備自我管理和持續改善的能力。每個人都有自己的特長，需要依任務自行安排工作。團隊彼此互相輔助。

#2.Product Owner

PO是決定產品要做成什麼樣子的人，需要決定產品的規劃並為產品的成敗負責，不僅要具備敏銳的市場sense，還要擁有優良的溝通力，好應對利害關係人。

#3.Scrum Master

SM是最資深，最了解敏捷式管理法流程的人，主要的任務就是排除一切是個如同僕人般的領導者，既不具備人事權，也沒有財物權，更不能決定產品走向，並且需要具備異於常人的信心與耐心，輔導團隊了解並推動敏捷管理。

Scrum中的9個活動

Scrum中主要有9個活動類型，主要的目的是創造專案開發的規律性，與避免不必要的會議產生，我們一項一項來看。

#1.Sprint

Sprint是Scrum的核心，可以理解為「衝刺期」，目的是為了在這段時間完成可用或可測試的產品。Sprint的時間長度在整個專案執行的過程中都是固定的（例如一個月），前一個Sprint結束，下一個Sprint就立刻開始。Sprint的時間不宜過長，否則複雜性與風險均可能提高，因此建議將時間設為一個月或更短。

在 Sprint 執行過程中，須遵守以下３點：

不接受危及Sprint目標的改變。
不可降低對於品質的要求。
隨著Sprint的進行，PO需適時和團隊確認需求。

#2.取消 Sprint

PO擁有取消Sprint的權力，可能是因為利害關係人、團隊或SM等，而做的決定。主要會在Sprint的目標因為公司、市場、技術發生改變，導致目標變得不合理時，PO就應該取消Sprint。

Sprint被取消之後，需檢視這段期間已經完成的項目，PO會接受那些屬於潛在可發布類型的項目，並且重新審視未來是否要繼續花時間完成那些項目。

取消Sprint非常消耗資源，因啟動新的 Sprint Planning 要重新集結隊員與分配工作等，這會對 Scrum Team造成重大傷害與消耗，正常情況不應該頻繁發生。

#3.Sprint Planning

Sprint Planning簡單理解就是制定工作計畫，主要由SM負責舉辦，目的是討論團隊本次Sprint「要發布怎樣的成果」與「如何達成」，Sprint Planning的內容則是由整個敏捷團隊共同制定，以一個為期一個月的Sprint來說，Sprint Planning的時間最多不超過八小時。

#4.討論本次Sprint可以完成什麼

開發團隊預測本次Sprint能完成的進度，而「產品目標」與「達成目標必須完成哪些Product Backlog items」則是由PO決定。

#5.討論如何完成所選的工作

確定好本次Sprint需要完成的Product Backlog items之後，由開發團隊討論如何完成。

在Sprint Planning 期間，開發團隊就應該先預測好本次能完成的進度，如果開發團隊發現任務太多或太少，可和PO重新討論。Sprint Planning結束後，開發團隊應準備好並向SM與PO說明預計怎麼分工來完成任務。

#6.Sprint目標

Sprint目標是開發團隊與PO之間協商的結果，Sprint目標應該具體且可衡量，通常通過一組特定的產品功能項目進行詳細說明，它應該是一個簡短的句子，例如「添加，刪除和更新購物車的數量」、「開發結賬流程：支付訂單，挑選運費，訂購禮品包裝」。

#7.Daily Scrum

Daily Scrum是針對開發團隊的一項活動，會在Sprint開始之後每天招開，時間應控制在15分鐘左右，主要的目標是檢視進度，Daily Scrum討論主題主要有「昨天做了什麼」、「今天打算做甚麼」、「是否遭遇阻礙與困難」這三類。

Daily Scrum結束後，開發團隊應再次討論詳細內容，重新調整開發步調。SM則負責監督，確保開發團隊每天都有做Daily Scrum並且都在時間內完成。

#8.Sprint Review

Sprint Review會在Sprint結束後舉行，由整個敏捷團隊與利害關係人共同檢視本次Sprint所完成的事項，並討論接下來能做完哪些最有價值的事情，這個正式且輕鬆的會議時間應控制於4小時以內，由SM確保會議的舉行，並確保每個人都了解本次會議的目的。

#9.Sprint Retrospective

Sprint Retrospective是給敏捷團隊自省的機會，主要的目的是建立改進計畫，以便在下一個Sprint能夠更順利。Sprint Retrospective主要舉行的時間，是召開Sprint Review之後，與下一個Sprint之前，由SM確保該活動的發生。

Scrum的5個產出

產出代表了工作或價值，可以用來檢視與調整工作模式的機會。 Scrum 所定義的產出物具有透明性，除了資訊流通之外，也能讓每個人對產出物有相同的理解。

#1.Product Backlog

Product Backlog是該產品所有已知需求的排序表，主要由PO負責。Product Backlog會不斷變化，找出什麼對產品是最有競爭力、最有用的。Product Backlog會列出所有特性，功能，需求，改善功能和修補方式，這些會影響未來產品發表的內容。

#2.監測達成目標的進度

PO應於每次的Sprint Reviews裡追蹤剩餘的工作量，並與之前做比較，評估預期的工作進度與是否能如期完成，而這些資料都必須對利害關係人公開。

#3.Sprint Backlog

Sprint Backlog是開發團隊期望在本次Sprint中包含哪些功能，以及提供如何完成此目標的計畫。如果出現了新的工作，開發團隊會將其加入Sprint Backlog，隨著工作的進行，團隊應重新評估剩餘的工作，如果該部分被認定為不需要，這部分就會被移除。

#4.監督 Sprint 的進度

開發團隊可在Daily Scrum中追蹤剩餘工作量，除了可以以預測達成本次Sprint目標的可能性，也可以管理本身的進度。

#5.Increment

Increment是指在Sprint 期間內完成的工作項目。Increment的定義是指這些工作項目中PO與開發團隊一起驗證的部分，簡單的說就是 PO 說要上線就可以馬上上線的東西才算數。

如果想更了解敏捷管理的原則和運用，可以參考下方影片：

搞懂世界頂尖企業都在用的Scrum溝通管理術

敏捷式專案管理與傳統管理的差別

在介紹專案鐵三角的時候我們可以了解，專案是以範圍、成本、時間展開的，而傳統管理（經典管理）的特色是先將範圍確定後，再分配人力與時間，並且在專案執行的過程隨時追蹤與掌控。

傳統專案管理法有個別稱叫「瀑布式管理法」，顧名思義，專案執行的流程就如同瀑布般由上而下發展，一開始的需求就非常明確，不過前置作業與規劃很花時間，等規劃都好了才會開始執行，一旦中間發生變化，先前的規畫都得打掉重來。

簡單整理優缺點如下：

傳統優點

易於管理，每個階段都能提交結果與審查。
適用於需求簡單明確的專案類型。
專案過程較容易紀錄與管理。
能輕鬆應對團隊成員變化。
前一個階段完成後，只需關注後續階段。

傳統缺點

不適用於變化頻繁的專案類型。
一旦專案出現變化，就要從頭來過。
前一個階段完成就很難再回頭修改。
每個階段的開始和結束可能花較多時間等待。
客戶只能在最後的階段才能測試，修改成本高。

敏捷式管理法則是先固定成本與時間，在專案執行的過程不斷的深入、細化範圍，以便在有限的時間提交出另顧客、市場滿意的作品。

敏捷管理的這套流程又稱為「scrum」，強調快速產出、取得回饋與修正，可因應市場變化及時修正。改善了傳統管理法要到最後才看到成果的缺點，有多少資源和時間，就做多少東西。

在敏捷管理中，負責人會把專案切成小分，讓團隊可以先專注在最優先的部分，且每個團隊都要成為對結果負責的「自組織」。

簡單整理優缺點如下：

敏捷優點

快速產出並接收回饋，有助於團隊做出改變。
分擔責任可讓團隊用更少的時間完成更多工作。
每人都承擔責任可保持較高的執行力。
專案中的問題可以更快回報並解決。
開發速度快。

敏捷缺點

較不重視必要的設計與文件。
對團隊的默契考驗高。
有人中途離職將嚴重影響專案時程與開發難度。
團隊中需有經驗較強者帶領，否則專案易遭瓶頸。
較不適合小型專案。

如何推動敏捷式管理？

敏捷管理聽起來不錯，但是該怎麼推廣呢？許多公司嘗試推廣敏捷式管理，但往往因為經驗不足鎩羽而歸，接下來會為你整理敏捷式該如何推廣吧！

#1.打造主動積極的團隊
敏捷強調以人為本，如果團隊本身實力非常堅強，而且積極主動，就是好的開始。團隊中的PO、SM這兩個類似於舵手的角色，若也能清楚、明確的指引團隊方向，確保在做正確的事情。同時也需要讓團隊有獨立開發的空間，團隊願意接受敏捷管理的意願也會越高。

#2.企業思維要變
想推動管理，得從主管做起，主管高層首先要接受新的管理方式並調整思維，讓敏捷成為公司的文化並融入其中，改掉權力一把抓的缺點，讓團隊可以自主，如此才能脫胎換骨。

#3.員工要喜歡
要讓員工接受新的管理方式，管理者可藉由薪資、考績等誘因推廣，同時灌輸敏捷管理的觀念，才能在轉型期間避免人才流失。

#4.從小團隊開始
團隊應由小至大：先由小團隊先試水溫，願意學習跟分享，再逐步推廣，同時團隊成員也要沉得住氣，一開始跌跌撞撞沒關係，但至少一次次進步，培養足夠的信任基礎後，團隊才能享有更多自主權。

#5.旁觀者適時回饋
當局者迷，建議由外部單位或顧問觀察整體情況並回饋，找盲點、方向。

#6.建立共同規則
團隊的後勤人員最好先參加業務會議，了解市場需求，才能即時依數據提供情報，共同規則可以幫助雙方排除溝通障礙，使團隊運作更加順暢。

想完整了解Scrum，可以參考下方影片，有很完整的介紹。

「Scrum」10分鐘輕鬆搞懂科技巨頭都在用的工作管理術

如果公司的組織龐大，你想要更進一步了解如何推動敏捷開發，可以參考這篇《組織太龐大，「敏捷開發」跑得起來嗎？資深 PM 傳授超實用的敏捷心法》裡面有非常實用的資訊。

參考資料：

管理者必學：

工程管理大補帖：

如果你喜歡我們的內容，歡迎訂閱拓璞電子報，我們將不定時發送專案管理相關的資訊！

如果您對我們的系統有興趣或需要專業的輔導諮詢，歡迎聯絡我們！