隨著敏捷得到眾多企業(yè)的關注，負責財務底線的管理者發(fā)現很難用美元估計和衡量敏捷項目的價值。掙值管理(EVM)被廣泛用于衡量公司層面的財務底線結果。但是對掙值管理是否可以應用于敏捷項目管理的爭論在繼續(xù)升溫。

軟件純粹主義者們譴責這一概念，他們聲稱掙值管理所需的前期規(guī)劃對輕量級敏捷方法都“太重了”。另一方面，那些相信或已經實施敏捷掙值管理的人通常對該方法很滿意，因為它提供了必要的衡量和報告要求。

無論你是敏捷開發(fā)純粹主義者或掙值管理的信徒，這里有三個實用技巧可以幫助你消除敏捷指標和你需要報告的的財務底線衡量之間的差距。

1.在高管和“一線員工”之間找到共同語言。

傳統(tǒng)掙值管理和敏捷軟件方法在計劃、預算和項目交付的方法方面有鮮明的對比。掙值管理方法側重于可預測的、預定的計劃，結果在項目完成（計劃的工作與預定的工作）時衡量。這些衡量通過五個基本指標進行跟蹤：

計劃的價值+預定的工作成本：我們計劃花當多少錢？什么時間開始？

掙值+已執(zhí)行工作的預算成本：實際完成工作的美元價值是多少？

實際成本+已執(zhí)行工作的實際成本：我們?yōu)橐淹瓿晒ぷ骰�了多少錢？

完成預算：我們計劃在整個項目周期中花多少錢？

完成估計：基于迄今為止完成的工作，我們估計完成成本是多少？

相比之下，敏捷開發(fā)需要迭代方法。其重點是計劃、預算和價值衡量，但有一個關鍵區(qū)別：對管理軟件交付的范圍變化的適應能力。

使用掙值管理預測和衡量這些變化以提高項目價值是極其困難的，因為敏捷開發(fā)團隊的業(yè)務分析人員通常使用另一種語言。在這種情況下，與財務底線相關的數據被嵌入到復雜的電子表格中，其中常常擠滿了實際上做那些工作的人不會直接使用的財務縮略詞和其它信息。但是在大樓的另一邊，你會發(fā)現敏捷項目團隊使用的是燃盡圖，這是一種項目進度的視覺簡化的表示法。

提高項目價值（和最終財務底線）的第一步是讓在一線和敞亮辦公室中的人使用同樣的語言。這可以通過應用輕量級掙值管理指標使用敏捷掙值管理實現，這些指標可以被項目團隊和管理人員理解，從而能真正衡量項目的價值（進度、成本和性能）而不只是成本。

2.衡量掙值管理的環(huán)境。使用計劃的價值和預定義的“收入規(guī)則”量化計劃工作的成果只留出很小的變化空間。因此，如何用指標來改善范圍定義以及整體項目性能的分析？這個問題的關鍵是衡量掙值管理的環(huán)境。

例如，如果重點放在已完成工作的成本和價值上，那么你必須包括與項目指標最密切相關的敏捷指標。這些可能包括：

報告的工作：為特定任務/項報告的工作數量

每功能成本：特定迭代每個功能的實際成本

每迭代預算：項目每個迭代的計劃預算

每迭代成本：項目每個迭代的實際成本

累計預算：總計劃預算

通過從敏捷掙值管理的角度處理每次迭代，你將準備提供管理所需的財務底線指標。

3．把敏捷指標轉化為常用掙值管理術語。如果你花時間看一下掙值管理和敏捷指標以確定并把指標轉化為常用的術語，財務底線報告將變得更容易。例如，可用在敏捷開發(fā)中的典型指標包括未結估計和結算估計。通過簡單的方式，這些可以分別轉化為掙值管理中的計劃值(PV)和掙值(EV)。但是，PV和EV指標不直接轉化為敏捷指標。因為敏捷中的范圍變化是預期的和頻繁的，在整個項目中沒有一成不變的PV。相反，將根據每個迭代的燃盡圖處理敏捷指標。這顯示了結算估計的想法與實際的安排表，是PV與EV的最佳轉化。

請記住，敏捷方法會約束時間和成本，并且范圍可以變化。因為這個原因，那些考慮財務底線的人將最感興趣未結與已結的項（已計劃什么和已完成什么），以滿足趨勢和更準確地計劃的目的。在一天結束的時候，這一洞察力可以驅動可預測性，是每位經理和所有者的“圣杯”。此外，敏捷掙值管理報告將顯示預算與成本指標來解決傳統(tǒng)掙值管理指標的問題，如每功能成本、每迭代成本和每迭代預算。

敏捷和掙值管理本質上是不同的衡量成功的方法。但是通過在項目層面追蹤相關的指標，當必須滿足其它約束時，敏捷經理可以靈活地衡量敏捷項目的掙值管理項的成功來調整其范圍。

在上面的例子中，成本超過了預算。因為敏捷掙值管理使時間和成本約束保持靜態(tài)，可以很容易地調整范圍以滿足其它約束。例如，如果一個團隊保持在預算之內，他們可以很容易地把功能或范圍添加到項目中，使關心財務底線的股東和高管感到高興。

工作軟件交付

在項目領導人可以從掙值管理報告轉化為敏捷成功之前，他們需要確定衡量什么。掙值管理是關于衡量性能和預測輸出的，但唯一應計算的性能是質量性能。因此，敏捷成功最重要的衡量是質量。

一旦項目啟動，敏捷就開始在軟件開發(fā)的流程中嵌入持續(xù)的質量改進。甚至在團隊開始著手工作之前，就從把測試人員包括為全部團隊成員開始，引入質量實踐。測試人員將幫助定義需求，并開發(fā)指導開發(fā)人員工作的驗收標準。

關于合作的敏捷承諾對開發(fā)質量實踐是很重要的�？缏毮軋F隊提供了多個角度，使團隊可以完全理解項目每個塊的復雜性。這有助于團隊準確地確定整體的每一塊需要多少工作量，以及迭代中哪些部分可以交付。

敏捷把質量改進嵌入流程的另一種方法，是通過持續(xù)集成：它隨著新代碼的編寫不斷測試和集成到系統(tǒng)中。團隊的所有成員都應該參與測試，這是隨著開發(fā)持續(xù)進行的�；貧w測試是每個迭代的關鍵部分，因為每次開發(fā)新功能時，它們必須與之前建立的所有功能無縫地集成。

在測試自動進行時，持續(xù)集成是最成功的。雖然有效的自動化測試可能是昂貴和難以建立的，但是進行硬件和人們需要的前期投資來建立自動化可以得到巨大的收益。這樣可以降低公司的質量保證(QA)費用，同時提高最終產品的整體質量。隨著時間的推移，企業(yè)將只需要更少的專門測試人員，因為迭代中的錯誤可以及早發(fā)現并修復，而不是在項目第11小時再進行處理，因為這時返工滾動到下一個迭代存在巨大的風險。

用戶眼中的質量

不管使用什么指標，所有開發(fā)人員都會對質量軟件的一些基本基準達成一致。例如，質量軟件滿足用戶的需求。敏捷尤其擅長滿足這種質量基準，因為它可以預計和適應產品需求隨時間推移產生的變化。從用戶的角度來看，當需求可以快速適應以滿足他們不斷變化的優(yōu)先事項時，質量就提高了。

質量的另一個基準是產品是否可以交付商業(yè)價值。在瀑布式環(huán)境中，ROI直到項目達到100%完成時才實現。在敏捷環(huán)境中，ROI可以在每次迭代結束（或幾個迭代導致產品發(fā)布）時實現，因為迭代的輸出可以交付給客戶。收益不僅可以在項目的早期實現，而且在項目整個周期中產生的收入的數量也會增加。初期的收入有另一個好處：它允許使用實際的數字而不是預測的數字開發(fā)指標，這樣可以幫助管理者實現他們的可預測性目標。

用戶的質量感知將在每次迭代之后被考慮。產品所有者在回顧中代表客戶的利益，因此客戶的直接反饋也可以得到考慮�；仡櫴且粋�內置的QA功能：團隊會檢查哪些方面工作良好，確定哪些方面需要改進，并分享前進和提高輸出質量的建議。

·完成=高質量

當一個團隊聲明軟件“完成”時，說明軟件已經過測試、可以工作并可以交付給客戶。在“完成”時，團隊和產品所有者知道軟件的每一塊有多好。相比之下，在瀑布式環(huán)境中，測試和集成發(fā)生在過程之后，所以質量直到項目接近完成時才進行評估。

“完成”的概念是質量敏捷方法的核心元素。它需要一個從查看“完成比例”到查看事情是否完成或未完成的掙值管理方法的范式轉變。完成度描述軟件的設計、編碼、測試和集成情況，其質量已經過檢查。但是，完成度比例與質量沒有關系，因為直到測試和集成執(zhí)行之前，質量都是未知的。此外，瀑布式環(huán)境中完成度的比例可能會產生誤導，因為它不占用返工將花費的時間。

·高質量=$$

在流程中嵌入質量可以提高公司的財務底線。其收入預測更一致，因為質量可以在每個迭代中檢查，問題可以在項目接近完成之前發(fā)現。利潤將增加，因為返工形式的浪費減少了。生產更可預測，因為項目中軟件交付的速度是相當一致的。財務風險減輕，因為ROI和進入市場的速度更快。企業(yè)的質量信譽使企業(yè)可以經營得更長久并獲得利潤。

從敏捷的角度來看，良好的性能不能通過工作了多少小時、寫了多少行代碼或者已經花了多少錢來衡量；良好的性能是關于你的產品交付的價值。掙值管理想要衡量質量，但未能達到這一目標，因為掙值管理衡量性能的成本方面，對與生產管線一起發(fā)生的、與預算相關的一切進行評估。具有諷刺意味的是，對成本的關注通常需要以質量為代價。

瀑布式項目經常落后于進度和超出預算，當他們進行項目時，總是通過捷徑使項目回到正軌。因為瀑布式環(huán)境中的測試在發(fā)布之前進行，這通常是被削減的地方，這導致產品在制成成品時只經過不完整的測試。產品可能會按時并在預算內交付，但是如果質量保證不能作為流程的一部分，那么產品仍然是糟糕的。此外，實際成本仍然是未知的，因為發(fā)布后識別的錯誤仍將需要修復。

股東們想知道項目進度、估計的和實際的成本以及產品的質量。一些指標可以幫助管理者在敏捷和瀑布式環(huán)境中完成他們的工作，但這兩種方法的關鍵區(qū)別是用于質量的指標。傳統(tǒng)掙值管理使用成本和其它性能衡量作為衡量質量的代表，而敏捷擁有真正的質量指標：“完成度。”直到輸出已經設計、編碼、測試、集成和可交付后，產品才算“完成”。因此，完成等于高質量。

原文經許可，摘自KatiaSullivan發(fā)表在ProjectsAtWork上的兩篇文章：“敏捷+掙值”（2012年2月1日）和“衡量質量，而不是數量”（2012年3月7日）。ProjectsAtWork于2012年登記版權.。GeoffreyBi譯。

KatiaSullivan是VersionOne的產品與敏捷顧問。她在軟件開發(fā)領域工作了超過12年時間，主要擔任企業(yè)架構、需求管理和項目管理職務。

本中文版由世界經理人（www.ceconline.com）組織翻譯并編輯。