確認完分工後，來聊聊如何進行專案管理，在這次翻修案中 User Story 或完成特定 Feature 模組數量後，才會考慮部署到正式環境，與一般跑 Scrum 迭代交付有蠻大的不同，採用的是 waterfall + 迭代開發混合模式進行，方式說明如下：

1. 完成單一 User Story 後發佈到測試環境
2. 由 PM 指派需求單位進行驗收
3. 需求單位完成確認後，提出 Task 優化或是 Bug 任務單
4. PM Assign 給開發者，進行調整
5. 持續到所有 User Story 都完成初次驗收，PM 展開功能回歸測試
6. 完成回歸測試
7. 佈署至正式環境
   大致上會不斷循環 1~5 步驟，整個進程如下圖：
   

專案會遲到，但價值從不缺席

如前所述，一個需求往往需要經歷訪談、分析、開發、測試、驗收等流程，過程中常常反覆循環，加上需求數量龐大。去年我們翻修了一套老系統，僅在訪談分析階段就整理出 200 多個 User Story，數量驚人。因此 PM 每天或每週提供一個精準數字往上呈報，其實相當困難。這也是為什麼 Scrum 會透過故事點數搭配燃盡圖，來呈現需求完成度並管控進度。
然而，本案未採用 Scrum 的迭代模式，那麼要如何盡可能呈現專案的實際概況？在 ADO 中開啟 PBI ，每個 User Story 的下方，都會對應到若干任務，這些任務就是需求能夠完成（含驗收）所需的工作項目 (Task)。這些工作項目是 SA 兼 PM 在派發工作時，會同時建立規格與對應任務，最後於 PBI 中加入「Progress Bar」進度條，系統會自動由下而上彙總，呈現 User Story 或更上層 Feature 的總體進度，如下圖所示:

但有了Progress Bar ，仍會有失準，原因是:

• 工作與需求的顆粒度大小有所不同
  有些需求大有小，工作任務有些切割大，有些切小，有些開發者切割開發任務的細緻度不同，所以會影響最終專案進度百分比。

• 實務上，進度是會倒退的
  特別過往我們很習慣使用瀑布式開發模式，很難容忍進度百分比倒退的事實，因為需求會改變並且我們接受可控的改變。

這裡必須替 PM & 團隊夥伴建立信心。考量到故事完整性與價值的提升，我們允許需求在一定範圍內變更。在這種情況下，專案進度必須清楚呈現：

1. 開發團隊已實現的功能或價值。

2. 任何優化或需求變更，都必須透過開立任務單進行派工與紀錄。

3. 若工作量過大，可在工作項中使用 Tag 進行分類。

4. 在階段性任務完成或專案結案時，務必向主管、Owner 與開發團隊報告：我們比原先預期多完成了哪些優化項目。這不僅讓上層了解先前停滯帶來的價值，也能提升開發團隊士氣。

即便專案進度最終延遲，也不代表專案不成功。PM 或 PMO 可引導團隊理解停滯與延遲的原因，並認知延遲是為了帶來更高的價值，只要團隊基於共識持續推進，最終專案帶來的價值大於「準時」，仍然是一個成功的專案。好的專案管理不僅追求時效，更重要的是懂得變化，懂得接受並適應變化，並創造超出原先預期的價值。

舉個自己的經驗，去年手上剛好有套系統導入建置，其實過程中原因預計１年可以完成的專案，在需求訪談與開發過程中，團隊選擇了優化與需求調整，因此犧牲了延後2個月，但是我們比原先多交付了46個優化項目，下圖為任務優化的回顧:

此外插播個小彩蛋，本次翻修案開發團隊準時將所有 User Story 的功能交付，過程包含多個微調與功能強化，在可接受需求變更的條件下仍然能保持開發進度已經難得，可喜可賀啊!!!

Ending Remarks

專案需求從訪談、分析，到開發、測試與驗收，過程常常反覆循環，且需求量龐大，因此難以精確追蹤進度。雖然本案未採用 Scrum，但透過任務切割、進度條等方式，仍能協助 PM 管控進度。由於需求與任務大小不一，進度百分比可能失準，且專案進度有時會因需求優化或變更而倒退。PM 需建立團隊信心，正視進度延遲是為了提升專案價值，並將所有變更任務完整記錄，適時向主管與團隊溝通成果。最終，專案成功不僅在於準時交付，更在於能靈活應對變化，並創造超出預期的價值。