「我們公司做的是接案，跟 Scrum 的迭代精神不符，還適合用 Scrum 開發嗎？」

這個問題的雷點在於接案-交付型團隊，與產品團隊的幾個矛盾處：

1. 交付型專案，通常合約限制的交付項目與時程，而產品團隊有高度自主權。
2. 產品負責人 (Product Owner) 與專案經理 (Project Manager) 的工作內容不盡相同。
3. 交付型專案沒有迭代驗証的概念，只有準時交付。

理論上來看，用 Scrum 架構套在交付型專案開發，的確會有水土不符的問題。但實際用 Scrum 運行交付團隊的經驗告訴我，透過開發系統中 Refinement 與估點的實踐，對準時交付的風險管理，其實有更好的效果。僅管 PO 與 PM 的工作內容大不同，在開發系統中與團隊的互動模式，基本上是一樣的。

專案時程評估

對軟體開發案來說，一般來說，在簽約前，甲乙方會針對開發範圍，驗收條件等進行談判。對於開發時程的畫押，專案經理就需要開發團隊的協助。此時專案經理可以根據初步的開發範圍與設計文件，撰寫成階層化的待辦清單 (Backlog)，如下圖。

通常，在初步的時程評估上，會由每個領域的技術主管進行「粗估」；但我建議在這個階段，就應該讓團隊介入，得到的評估結果，會比技術主管單方面的輸出準確一些。接下來，PM 帶著 Backlog 召開 Refinement 會議，由團隊針對 Story 進行討論，然後「粗」估點，這個階段不要求精準，而是要得到由開發團隊認可的參考值。

如上圖， PM 此時可以得到整個專案的總點數，經過換算，就可以得到開發時間的預估值。(換算方式請見 Day13-重塑 Planning 會議)。

這個方式的好處在於：

1. 團隊在很早期就已經有心理準備
2. 時程與對應的開發範圍是整個團隊的討論結果，可信度較高，減少談生意的人亂畫押帶來的風險

甘特圖

當 PM 沒有開發團隊做後盾時，只能憑職場經驗，腦補開發團隊的開發時間，拉出想像中的甘特圖。但透過 Refinemet 與估點後，甘特圖上的時間可靠度也就提高了。一旦完成簽約後，就可以開始進行細部的 Refinement 與估點。如下圖，從粗估到細估後，路徑圖也會從模糊，變成清晰。

值得一提的是，理想狀況下，細估後的時程應該會縮短；但如果細估後發生點數大幅膨脹的情況，此時專案風險就會升高。也是給 PM 提前準備應對的機會。

燃燼圖

在點數系統的輔助下，團隊每日對任務的完成度，可以透過更新點數得到。透過燃燼圖 (如下圖) 的繪製，PM 可以透過量化的數據觀測團隊開發狀況，將心力專注在溝通協調專案事務。

上圖中，我圈起兩個值得注意的觀察點：

觀察點 1:

在開發過程中，總點數沒有穩定下降，反而上升。表示初始計畫的點數可能被低估，或是客戶臨時新增了需求。透過數據，即可掌握風險。一般而言，膨脹的點數在 40% 之內，透過不得已的加班手段，都還有機會拯救。

觀察點 2:

逼近交期，但離穩定燃點的理想值差距愈來愈大，此時可能必須與團隊協調加班。而 PM 可以估算出加班造成的成本支出。

我帶過的「產品團隊」與「專案團隊」剛好各佔一半，都是用相同的開發系統在處理不同的開發情境。從結果來看，都可以達成交付任務。回到一開始的問題，我認為跑不跑 Scrum 並不是關鍵，而是規畫工作的執行方式，以及如何建立透明化的訊息流，才是重點。