使用 PMP 的 EVM 追蹤軟體開發進度

軟體開發在追蹤上的難題

一般在企業內部要開始一個軟體開發的專案有很多時候是老闆忽然靈機一動地問說：「我們來開發一個某某系統，你覺得需要多久？」有經驗的人聽到這個問題時就知道這是考驗專業能力與政治敏感度的時刻，因為這是一個兩難的問題。在好傻好天真的時期會想：「天啊！系統要做到什麼程度、有多少人參與、要給多少資源都還沒確定，就要押完成日？」會有這樣的想法不意外，就像是要蓋一個房子，連要蓋幾層都不確定、設計圖都還沒畫，更別提建材和工人都還沒有著落的情況下就要問何時入住，回答得出來才有鬼！

但在老闆面前為了展現專業與工作經驗、彰顯自己存在的價值，那就只好照之前類似系統開發的經驗抓個時程，再加上安全緩衝的時間做為答案。只是對於這種答案老闆大多第一個反射的回答是：「怎麼會要這麼久？不能在某月某日前上線嗎？」哇！專業的光環當場缺角，於是就要開始搬出一大堆的說詞來證明自己不是漫天要價，同時心裡咒罵著：「是你說要給個時間的，倒底是真心地想要徵詢專業意見？還是要猜你心裡的理想日期？」

打滾了一陣子，不再好傻好天真後被問到同樣的問題，為了政治正確於是開始學會先用感覺抓出時程再打個折當做答案。只不過一旦日期落入老闆的理想日期或更早，老闆則是會見獵心喜地說：「這個日期是你自己說的哦，那就照這樣訂了！」結果就是挖了一個大洞並且自己往下跳！所以吃過虧的人才會知道老闆這簡單的問句是一個深奧又富含職場哲理的問題，而最後還得因五斗米而折腰，為了要討好老闆明知是陷阱也得含淚跳下去。

剛才的情境還只是前菜，等到系統開始建構了，老闆就改成三不五時來問說：「目前進度如何？」又是一個容易動輒得咎的問題，因為老闆其實想要問的是：「何時可以上線？有沒有可能提早？」不要說軟體開發專案是個保證會延期的專案類型了，就連政府的大型工程專案不也是一延再延？但這卻是個眾所皆知而不能說的祕密！「不知道」更是絕對不能被接受的答案，所以要如何「知道」是一個管理上很重要的課題。畢竟就算老闆不問，身為管理者心理也要有個譜，才不會事到臨頭了才驚覺大事不妙。

想要掌握軟體開發專案的進度，有一個前提非常重要，其實不只是軟體開發專案，任何的專案都是。有接觸過 PMP (Project Management Professional) 的人應該都知道，所謂的監控已經是整個專案管理過程中比較後期的工作流程。在進入到監控之前要先進行規劃、安排，最基本的得要先設定好專案的 Scope，不然就像一開始說的連要蓋幾層樓都不清楚，跟瞎子摸象一般，就算知道現在蓋好了多少層也無法確定何時可以入住。

在東、西方文化的差異下，西方比較講求按部就班，東方文化就偏重實事求是，所以像 PMP 這樣的知識體系都是來自於西方，而要將這樣的管理精神套用在我們的工作環境之中也很容易迫於氛圍只剩下半套。所以在軟體開發專案通常就只會有執行及監控這種有產值的流程出現，Scope？是什麼東東？能吃嗎？想當然爾，開發的工作都只能在有個大概輪廓的狀態下進行，細節的部份則是邊做邊確認，想要掌握進度更是如同霧裡看花。

這是最糟的情況嗎？不是！經常變動才是開發工作上的大挑戰，絕大部份的軟體開發專案不太可能會有需求凍結這種事。就像房子蓋好了底下的二、三層，老闆看了覺得似乎加個幾層會更好，金口一開瞬間四層就變八層。但八層的房子要設計的耐重和四層樓明顯地不一樣，在趕工的情況下大多是設計得夠用就好，一旦要加樓層整個結構、甚至地基都要打掉重來。但如果要拿房子的例子和老闆解釋這樣變動帶來的衝擊，老闆才沒空聽你扯什麼房子的問題，又不是要你弄得髒兮兮、揮汗如雨的，不是只要坐在電腦前面打打字、剪剪貼貼就可以收工了，能花多少時間？這種情況之下怎麼可能會有準確的進度資訊？

在管理軟體開發專案上還有另一個棘手的問題，如果真的是照著 PMP 的規範走，這類型的專案要界定所謂的 Scope，大致上就是在進行需求分析的工作，或許還夾雜著一部份的系統分析在其中。就整個軟體開發的流程來看，這部份的工作所佔的比重並不低，甚至有很多規模不大的系統在分析完之後就沒剩多少工作項目，如此說來理論上這部份應該也要被列入追蹤的範圍內。這時就會形成了一個雞生蛋、蛋生雞的矛盾情境：這些工作就是要弄清楚開發的範圍，如果要把這些工作列入管理但範圍還沒有確定，所以得先完成這些工作... 結論就是想要順利完成一個軟體開發專案，就只能盡人事聽天命了！

進度估算的準確度

好吧，關關難過、關關過，排除萬難把工作項目都開出來，甚至搞了一整個 WBS 就一切順利嗎？軟體開發的工作特性與一般的專案最大的不同是不確定性很高，每一個工作項目都像拓荒一樣是一種從無到有新的經驗。因為每次都是要把不同的工作知識轉換成可運作的程式碼，程式要怎麼寫和資料的特性有很大的關連。再以蓋房子做比喻，開發不同的軟體並不像是重複地蓋磚牆的房子般，因為同樣都是砌磚的施工手法，經驗是確定的。比較像是每次蓋房子時使用的是新建材，所以在蓋的同時都要不斷地摸索建材施作的特性，而很容易出現技術上的瓶頸。

每一個開發人員的素質不同，需要摸索的時間就會不一樣，再加上遇到技術瓶頸時解決問題能力的高低，不太可能套用一致性的法則，這也增加時程上的變數、直接牽動著工作進度的快慢。所以要估算軟體開發的工時是一項複雜度、不確定性都很高的工作。軟體工程裡有提到一些艱深難懂的估算公式，但通常需要取得很多的參數，老實說一點都不實用、在實作上也沒有太大的意義，因為算出來也不保證百分之一百精確。

那倒底要怎麼估才好？這個嘛... 站在技術人員的立場真心地覺得不要估最好，估了也只是求心安的，就像生小孩的預產期一樣，程式碼時候到了自然就會生出來，催也沒用，押了日期沒寫完還不是得延，何苦來哉啊！但是這種說法大概也只有寫過程式的苦主才能夠認同，有時候還滿羨慕所謂的藝術家，同樣是不確定性很高的工作，大家都可以認同創作需要時間也不用給時間表，但明明程式的用途是比藝術家的成果還具有實用價值，大家卻選擇盛讚藝術家然後壓搾工程師。

至於怎麼估，基本的原則是：如果想要精確一點，當然工作項目單位愈小愈好。要估算一個函式多久可以完成，一定是比估算一整個系統的時程來得貼近現況，但相對的要花的時間也比較多。同時有能力切到以函式為單位做工作項目，剩下要做的事打概也只有打字，每個工作項目得到的數字也許都是以分鐘為單位。這樣的管理方式真的有意義嗎？老闆會希望等了大半年後才知道接下來的工作只要二週的時間嗎？所以不是說了，不要估最好！

Burndown Chart 在管理上的問題

只不過，怎麼估並不是這篇文章的重點，這篇文章主要是想說明怎麼追蹤。面對這類型的問題，業界還是有發展出一些簡單的方法，有聽過、參與過 Scurm 的人應該會想到 Burndown Chart。這是一個好工具、簡單明瞭，可以很快速地讓所有專案參與的人或是有利益相關的人了解目前專案的狀態，不管懂不懂 Scrum。基本上在製作 Burndown Chart 的時候，不見得要把每一項工作都精算出對應的工時，只要評估好工作項目的規模大小，以 Story Point 的相對數值來表達即可，這會大幅地減少計算工時所需投入的成本。

Burndown Chart 是用還剩下多少工作做為基準，在團隊工作產值沒有大變化的情況下，繪製出一條由 Y 軸某一點出發向下延伸的斜線一直到和 X 軸交會，交會的點即為完工的日期。在現實中當然不可能會有這麼理想的情況，所以實際的曲線應該是呈現鋸齒狀並且和那條理想的斜線交纏著，專案人員藉此來判斷是否能及時在指定的日期前完成工作。

凡事有利就有弊，Burndown Chart 的呈現比較偏向專案或團隊整體的資訊。在遇到進度不如預期的時候，不太容易從 Burndown Chart 中界定問題的責任歸屬。當然會來從事開發工作的人絕大部份都是單純、善良的，在跟團隊成員討論進度時把圖表亮出來，該誰需要改進的都自己心理有數並且能夠負起責任。但總會遇到少數幾個刁鑽又具有心機的人，這時通常會需要有個明確的數據來讓管理上的對應措施有個底。尤其是身為上頭還有高層、被夾在中間的管理者，當情況開始失去掌握時，也可做為向上尋求協助的其中一項依據。否則一旦讓不好的行為在團隊中引起破窗效應、對工作氛圍造成影響，所產生的後果就會變得很難收拾。

除此之外，在一般企業裡大多都是數個開發案同時進行，團隊中可能根本就沒有一個人是專職在自己手上的專案裡，同一個開發人員會需要負責多個系統，有時還要再加上既有的系統維護。在有的系統要開發新的功能、有的系統要進行維護、有的系統要除錯的情況之下，如果只針對單一個開發案來看，同一位工程師的產值可能就會有大有小，不太可能維持一定的量。就算有心想要幫開發人員排除時程上不利的因素、保持產值的穩定，勢必要考量到各系統在上頭的重視程度、使用對象的重要性、時程的緊迫程度，更麻煩的是會牽涉到各系統負責人之間搶人的政治角力，結果不如預期乃是兵家常事。排除不了，進度的延遲就成了開發人員的非戰之罪，管理者就沒有立場去做苛責，畢竟這是管理者的責任。只是如果像之前提到的，成員中出現少數不屬於善良的那一種類型，利用遊走各系統來掩飾進度問題，以 Burndown Chart 所提供的資訊在管理上也是無從判別的。

使用 EVM 追蹤進度

能夠身處在教科書的理想環境與團隊的組合中做管理畢竟是可遇而不可求，面對這種現實的情況還是要有一套有效的管理方式，在 PMP 中有提供一個進度追蹤的方法叫 EVM (Earned Value Management) 可以提供一些輔助。但在這篇文章裡使用的是簡化過的 EVM，主要是取幾個 EVM 中提到的數據來做為管理上的參考。用最白話的方式來說明 EVM 就是用預期要投入多少成本做為基準，比較實際獲得的價值與目前預計進度、累計投入的成本間的差異。其中目前預計進度為 Planed Value 簡稱 PV、目前累計投入的成本為 Actual Cost 簡稱 AC、與實際獲得的價值為 Earned Value 簡稱 EV。

舉個例子來說，假設今天有一個專案要鋪設一條一百公尺的道路，工程預計進行五天，總投入的金額預估是十萬元，相當於這條道路完工之後價值十萬元。平均來看每一天照計畫完成工作應獲得相當於二萬元的價值，或者每完成一公尺就會產生一千元的價值。當工程進行到第三天，如果完成超過六十公尺代表進度超前、反之則為進度落後。這時如果完成六十公尺的道路但投入的金額少於六萬代表績效超前、反之則為績效落後。

套用在軟體開發專案上，由於在軟體開發的案子中很多時候不太容易計算出完成的功能值多少錢、每一行的程式碼代表多少錢，對企業內部的系統來說更是如此。所以在這裡就可以用一小時來代表一塊錢，看幣值是要設定成一台幣、一美元、一歐元還是一個單位的比特幣，總之就是一單位金錢的價值，而先前的計算模式可以改為以時間單位來統計數據。

所以在實作軟體開發專案的 EVM 時，假設一個功能預計投入 40 個小時、在五天之內完成。當開發工作進行到第三天時，如果完成進度大於 60% 則代表進度超前、反之則為進度落後。而當完成的進度是 60% 但投入的時數小於 24 小時代表績效超前，反之則為績效落後。這裡用百分比來做為統計 EV 的模式是在經驗法則上所得出比較直覺、一致、符合人性的做法，回報進度的人不需要了解什麼是 EVM，只要記錄今天花多少時間開發、完成多少百分比。而百分比則可以依照預計要完成多少程式碼、區塊、函式、功能等等的基準來和完成的部份比對以估計進度的百分比，在這樣的評估方法之下成員之間不太容易有很大的差異出現，獲得的進度數據比較平均、比較成員間進度差異時會比較客觀。

在上述的數值中，PV 是累計到目前為止預計投入的時數、AC 則為累計到目前為止已經投入的時數、EV 則是 PV 的總數乘上進度的百分比。為什麼 PV 是用預計投入的時數加總，而不是和 EV 一樣使用百分比是有原因的。之前提到過每一個成員產值在單一的專案中不見得是個定值，礙於現實，在進行時程排定作業時有可能這個成員今天只搶到三小時、明天五小時，所以每天排定的預計投入時數都不一樣，如此使用百分比這種平均法來計算會和實際的情況有落差。

使用 EVM 在管理上的重點

有人可能會想問如果成員浮報進度資訊有辦法即時發覺嗎？的確，也許是文化使然，總是會有一些人喜歡便宜行事。像是會覺得評估進度百分比很麻煩，所以固定在工作一開始就只設定一個固定的進度值，例如：50% 或 30%，等工作完成後再回報為 100%。或者是有好大喜功的心態，所有開始進行的工作都設定為 100%。這時可以由 EV 值的變化中發現，此時一開始 EV 數值會先出現不合理的拉高，但接下來卻一直沒有變化。而另外一種常見的情況是投入時數漏報、浮報，這種情況可以由 AC 與 PV 的差距異常地大來判別。最難察覺的是回報的數據是在配合計算規則下所「設計」出來的，這時數據會呈現夢幻般完美的狀態，稍一不注意則可能要到截止日才發現進度不如預期，不過這時有配合 Code Review 還是可以看出一些端倪。

這套收集數據的模式有一個優點是每一個工作項目可以是獨立的觀察基準，也可以依據情境將不同的工作項目集中觀察。可以是以整個專案為集中的單位、可以是以 Product Backlog 為集中的單位、可以是以 Sprint Backlog 為集中的單位、也可以是以某一個開發人員所負責的工作為集中的單位。尤其是最後一項觀察基準，對於角色是屬於 Functional Manager 的人來說是一個很好用的工具。在以人為單位所產出的 EVM 資訊可以獲得二項重要的情報，一是透過時程安排的情況來了解在多重專案交互之下是否有負荷超載的情況，並且可以精細到每一天。第二項情報是在將清單中所有工作項目數據合併之後，可以得到單一開發人員的綜合進度數據，同時不會因為實際執行工作的順序與 PV 設定不同而有差異。可以有效地降低專案之間的界線，避免因專案間資訊不通透而無法反映個人進度上的問題。

同樣的優點也可以展現在以專案為單位的觀察基準，在進行開發專案時，很多時候是多個工作項目同時開始，而開發人員並不需要受限於原本設定好的工作執行順序，只要依照實際工作的情況回報數據即可。假設原本排定 B 工作要接在 A 工作之後才開始，而今天上工後同時進行 A、B 二項工作一共花了六小時。此時，進度百分比可以明確地分別依工作項目產出的狀態計算出來，不會有什麼問題。而投入的時數則可以視情況，如果有精確到記錄每一項工作投入的時間最好，如果沒有，都合併記錄在特定一項工作項目也行。在這樣的情況下，也許單一的工作項目在數據上會呈現失真的狀態，但拉高層次來看時卻不會有差別，因為數字加總過後會消弭掉工作項目之間的界線。

如果要硬性要求開發人員必須照著設定好的工作執行順序按步就班完成工作，最大的問題是可能會造成開發的工作無法進行，或是要花更多的時間在來回修正工作項目間不同步的程式碼。如此一來，在回報數據上也許不會有項目歸屬的爭議，但卻阻礙了開發工作且失去了管理的意義。所以這個手法在實作時其實沒有必要執著在 PV 的設定結果，這只是一個收集數據的參考基準，重點應放在投入的時數與完成的進度。

這套方法還有另一個彈性是在需求有異動、要調整某一項工作項目的預估投入時數時，也只要在適合的時間點補上差異的時數即可，不用特意重新調整過去 PV 的狀態，也不會影響成員回報的模式，所統計到的數據可以在過去的資訊基礎上持續地演進。這種不受限於成員投入時數或是預計時數變化的管理方式，套一個最近很夯的說詞叫「滾動式」管理。時程會不斷的變化就讓他變化吧，反正重點是要隨時掌握目前的進度情況。

當然，天下沒有白吃的午餐，這套追蹤的方法可以比 Burndown Chart 提供更多的資訊，是因為在輸入資料時要投入更多的功夫。如果想要以天為觀察的單位，在安排時程的時候就必須要為每一天設定好 PV 值，相對地在情況有變動時資料的調整工作也會變得比較繁瑣。用拉大時間間距的方式，改為以週、月為單位雖然可以有效減少資料維護的頻率，同時也會降低數據反映問題的敏感度，這取決於每個團隊的管理需求。

把 EVM 資訊視覺化

只是盯著數字看可能還不夠直觀，依據 EVM 的公式可以得到二項數據 SPI 及 CPI，分別是 EV 與 PV 及 EV 與 AC 的比值，把 SPI 與 CPI 做成圖表就如同以下所示：

圖上所示範的曲線代表不同時間點數據的位置所連接起來的結果，紅色星形為最早的時間點。圖中兩軸交會的點並不是原點，而是座標 (1, 1)，或許可以稱為理想點吧！原點在圖上左下角的位置。這樣繪製的原因是因為 SPI 及 CPI 都是二個數值的相除結果，大於一代表超出預期，小於一代表不如預期。所以當二個數值所形成的座標落在圖上兩軸交會處，代表目前投入的工時與產值是符合原本規劃的時程，也就是說理想化的情況之下所有的點應該都集中在同一點，不過理想歸理想，如果一切都這麼完美就不需要管理人員了。

透過這二個數據呈現的圖形可以直觀地了解目前專案進度的狀態、並隨著時間的演進呈現出進度的趨勢，範例的圖上四個象限都分別用文字標示出所代表的意義。SPI 是用來看已完成的進度有沒有依照計畫進行，如果小於一會落在 Y 軸的左方、大於一則是會出現在 Y 軸的右方。CPI 是用來代表投入的時數是否有獲得對等的價值，如果小於一會落在 X 軸的下方、大於一則是會出現在 X 軸的上方。最接近理想的情況應該是像上圖所示範的，所有的落點都繞著理想點打轉。

所以當點都落在第一象限上就是值得欣慰，而落在第三象限上就是待改進嗎？其實並不儘然，會影響 SPI 與 CPI 的數值不單單只有人的產值，PV 值估算的精確程度、投入工時的方式都有很大的影響。比如說，SPI 大於一有可能是因為 PV 值在估算時過於寬鬆，原本二個小時的工作估到四小時，所以照計畫投入了一小時反而得到了四小時一半也就是二小時的價值。或者也有可能是人員爆肝、加班趕工所換來的假象，而類似的情況也會反映在 CPI 的結果上。

透過這樣一個圖表在管理時要關注的問題，不外是觀察團隊中成員基本的個人工作效率與負載問題、是不是遇到技術瓶頸以致進度遲滯不前、還是因外在或個人的因素導致工作無法順利開展。在使用這個圖表進行管理時，不用太在意點所落下的位置，應該要像 Burndown Chart 的概念一般，只要確認有維持產值的穩定就是一個可以接受的情況。就如同打靶時所形成的彈著點，彈著點的集中度要比有多少顆落在中心區域要來得重要。彈著點集中代表射手是穩定的，很有可能只是槍枝沒有進行歸零，反之則是各種因素都有可能，反而不容易進行調校。同時還要透過每一個點之間的關係來觀察移動的趨勢，如果開始朝著第一象限以外的區域移就應考慮著手找出原因並改善。所以當所有的點都落在第三象限時，不一定是表示目前進度的情況很糟，如果能讓後續落下的點不會一直朝著原點的方向移動，就可以預測得出系統完成的日期，但日期是不是符合老闆的期望就又是另外一件事了。

避免落入管理上的盲點

誠然，判讀圖表的方法很重要，如何判讀圖表卻不是一個絕對值。所謂的管理是要找到一、二個合用的工具，並且在心中設定一把尺為做為使用工具時的衡量準則，這個準則是要依據現況來做調整。因為每一個專案都是獨特的，專案外在的因素、團隊的成員、工作時的氣氛，都不會有一模一樣的情況出現。教科書上的理論永遠不可能完美地實現在工作的場合裡，硬是要把理論套用在管理上有的時候只會適得其反。

像是如果拿著上面 EVM 的圖表當令箭，強制一定要讓回報的數據所形成的點都落在之前說的理想點上，可以想見團隊在工作時的感覺一定是非常的斯巴達，最後搞得成員怨聲載道，而管理的人也會因為緊迫盯人變得工作量大增，結果是讓所有人都工作得不開心。

管理的情況就像獵人漫畫中，小傑在貪婪之島中為了要得到一坪的海岸線與關主磊札用排球對打的時想出來的接球組合：

（圖片來源：獵人 HunterxHunter 動畫）

中間的奇犽是管理階層，夾在老闆 (小傑) 與團隊 (西索) 之間，老闆要負責承接來自外界的壓力並創造機會，團隊則要負責把握住機會。管理者看起來沒做什麼，但其實位在最關鍵的位置，在中間的管理者要如何分配力道、協調二邊，只有站在中間的人才最清楚，也是管理者展現修為的時刻。在面對情況要怎麼因應是管理者必須審慎以對的，一旦稍有差池就有可能像漫畫劇情中所敘，整個團隊會因受到外力衝擊而潰散。

結語

所以，每一個人在面對管理上的情況要如何拿捏，還真得沒有人能夠說得準。因為處理的結果好與壞，在現實中就是結果論，成王敗寇沒什麼好說的。在這篇文章中，只是把個人過去的工作心得整理出來，讓大家做個參考，也許可以對同樣是管理者的人有所啟發，找到適合自己的工具、建立起心中的那把尺。