以快速迭代再修改為核心的敏捷專案流程，也許會讓人覺得不用花時間寫成本、風險、產品需求等計畫書，邊做邊試就好，但漫無目的嘗試，不也容易一事無成？另一種常見的誤解是，所有需求變更，團隊都要接受，但改到對為止，也一樣拖慢專案進度、拉升專案成本？以下 5 點是採用敏捷式專案管理常見的迷思。

1. 敏捷專案管理不用寫任何文件？

《敏捷宣言》提到「可用的軟體重於詳盡的文件」，敏捷專案管理確實不像傳統專案管理須產出大量的文件，包括：需求變更計畫書、範疇管理計畫書、風險管理計畫書、成本管理計畫書等，而是開發到哪、規畫書寫到哪。

不過，敏捷專案管理還是要視情況寫文件。台灣敏捷協會理事長張昀煒舉例，每日站立會議的會議紀錄就不用寫，因為報告完大家立刻在工作上實施，但如果這個決議的影響會超過 3 天，就要寫紀錄提醒團隊留意。台灣敏捷協會理事林裕丞提醒，無論是跑敏捷或瀑布專案，都不要為了寫文件而寫，假使微小變更也寫幾頁的說明書，就容易引發反彈，如果只是寫「誰要求、達成目的、何時上線」短短幾行字交代清楚來龍去脈，團隊就會接受。

2. 客戶需求不斷變更是敏捷專案管理的常態？

敏捷專案有反覆開發的特性，每次衝刺完畢後，跟客戶確認產品雛型是否符合原先目標，難免遇到客戶不斷調整或新增需求，導致專案時程延長、團隊工作量增加。《敏捷宣言》提到「與客戶合作重於合約協商」，但這並不代表客戶說什麼就要做什麼，而是專案方要告訴客戶，他們的意見能否為產品帶來價值，例如更貼近市場需求、銷售量能夠提升。

林裕丞分享，自己擔任專案經理時會記錄每次開發的效益，比方說客戶要求增加 2 個新功能在系統上，新功能的使用情況為何，如果都沒有人使用，他就會整理結果向客戶和客戶的上司報告，日後對方再要求專案團隊增加某些功能時就會先評估效益，而非無所本的提出需求。

3. 敏捷專案管理不必事前計畫？

敏捷著重「回應變化而不是遵循計畫」，但這不表示敏捷專案不用事前規畫。以 scrum 專案管理流程來說，專案開始前要規畫產品的待辦清單，每個開發區間要規畫該交付的項目、團隊討論完成的日期。每天開站立會議，討論當天能完成的工作事項。瀑布式專案管理，執行前要詳盡規畫所有細節；敏捷專案管理從短期規畫著手，隨著得到愈來愈多資訊，再校正方向。例如：開發出的新飲品不確定上市後銷售情況，先規畫 3 個月的進度：做出試飲品、進行客戶意見調查，確認市場回饋後，再考慮上市或更改配方。

4. 用敏捷就不需要知道傳統的專案管理知識？

敏捷專案管理的流程與精神雖然跟傳統專案不盡相同，不過傳統專案管理強調的 9 大知識管理領域：整合、範疇、時間、成本、品質、人力資源、溝通、風險與採購，依然提供專案規畫者完整的架構，能夠管理百人、千萬規模的大型專案，重點是要挑合適的工具。

比方說，10 萬元內的專案可能不必做詳盡的風險評估，因為失敗對企業影響不大。林裕丞建議，有專案管理經驗者再去上專案管理證照（PMP）

相關課程、考證照會比較有感，知道工具如何使用，不然考了也只是有資格而已，對工作沒有幫助。

5. 敏捷教練能兼任專案或產品負責人嗎？

敏捷專案管理組織中有 3 種角色：產品負責人（product owner）、敏捷教練（scrum master、agile coach）和開發者（developers）。產品負責人跟專案經理、產品經理角色相近，主要是跟客戶溝通、策畫產品願景及發布規畫，但敏捷教練要拋開傳統專案經理的控制和命令式思維，激發團隊自主的工作熱情，為大家解決執行上的困難。

2 個角色著重的面向不一樣，產品負責人管事情，敏捷教練帶人，建議由不同人擔任，職務分工會比較到位。部分組織會邀請外部專家擔任敏捷教練，因為導入敏捷精神不只是調整專案流程，而是組織文化的變革，例如讓工作者從接收主管命令轉為自主安排開發時程，外部人員比較能夠跳脫既有框架給予建議。

資料來源：《敏捷管理生存指南》，翻滾海貍工作室出版；《學會專案管理的12堂課》，博碩出版；《完全圖解計畫力》，台灣角川出版；《Agile成功法則》，碁峰出版；台灣敏捷協會