我認為
敏捷社區(qū)要改變評測敏捷團隊是否成功的方法。我們收集指標以及從這些指標中獲取信息的方法實際上妨礙了我們做出能用的軟件，而這才是最重要的東西。
強推個體指標有時會導致過于關注其他人，影響團隊的協(xié)作。這會歪曲我們要評測的內容，摧毀我們的真實意圖。
在我看來主要有兩個問題：
觀察者效應： 觀察者效應是指對一個流程進行觀測可能會影響它的輸出。比如告訴一個團隊你會密切關注他們的速度，該團隊可能會為了加快速度而過度估算他們的
工作內容。這在處理 故事點 時尤其危險，因為根本就沒有依據可以判斷估算是否有效。
盡管上面這幅漫畫中的情況很有可能發(fā)生過，但并不是我理想中觀察者效應的例子。我給你們講一個我很久之前認識的技術支持工程師，我們叫他“杰森”好了，因為他的名字就是杰森。杰森是一位優(yōu)秀的技術支持，在別人遇到特別困難的問題時他會施以援手，一般在客戶打來第一個電話時他就能正確地把問題解決掉，而且客戶對他的評價很高。問題是杰森接電話的時間太長，而這一指標對管理層來說非常重要。后來經過幾次會議和一次考核之后，杰森明白他必須把時間縮短，否則就只能另謀高就了。很快幾周就過去了，杰森的呼叫時長在整個支持團隊中排到了前5名。他是怎么做到的呢？如果不是我有一天接他班時提前到了一個小時，他可能永遠都不會跟人講起其中的秘密，那天我發(fā)現(xiàn)他原來是接了電話之后馬上就掛掉了。
這挺有點兒意思，如果杰森的呼叫時長沒有他的真實績效重要，他就不會干那種事。以呼叫時長為指標評測他對產出產生了負面影響。除了這個糟糕的指標之外，即便沒碰到過杰森這么極端的情況，我們也都遇到過只想盡快讓你掛上電話的技術支持。問題是你的團隊為了讓自己的數(shù)值更好看掛了哪些電話？
路燈效應：路燈效應是指我們人類傾向于尋找更容易的答案，而不是真實的信息。比如計算代碼行數(shù)就很簡單，但代碼行數(shù)并不能告訴我們程序的質量如何，也不能表明程序提供的功能性甚至效率怎么樣。
我想起以前曾經工作過的一個團隊，我們做了幾個產品，每個產品的質量標準都不一樣。當時的情形是“產品A”的質量標準要難得多，而產品B、產品C或產品D的質量標準不會是什么太大的問題，除非管理層在下次審查臨近時改變了對這些產品質量的要求。
問題是“質量”這個概念有點模糊，真的不太好評測。而錯誤率就容易測量得多，因此那些做產品A這個質量標準比較高的產品的人，在面對審查時就更加不利。那這份工作最終是由誰來完成的呢？大部分是實習生、臨時工或做外包的那些人，或者其他任何人，總之沒人愿意參與。
事實證明，即便是容易測量的錯誤率，也不能給出什么有價值的信息，因為出現(xiàn)錯誤的次數(shù)更多是由產品而不是員工決定的。我們反而趕走了幾個不錯的新員工，丟掉了客戶，整個團隊的士氣也受挫了，因為他們工作時考慮更多的是在如何避免錯誤，而不是如何構建產品。
因為這兩個都不是
軟件開發(fā)的例子，所以接下來我們把這些概念放到一些常見的、你所熟悉的“敏捷”指標上。容易測量的指標有哪些？
編寫單元測試的數(shù)量： 大多數(shù)敏捷開發(fā)者都會寫很多單元測試；測試驅動的開發(fā)創(chuàng)建的測試更多（兩者都能帶來更好的代碼質量）。所以用一個開發(fā)人員編寫的測試數(shù)量來評測他的生產率肯定是沒錯的！實際上觀察者效應會把這個指標滅掉。告訴開發(fā)人員會用他們編寫的測試數(shù)量來評測他，他們肯定會在不考慮質量的情況下寫很多測試。我們不是為了交付測試代碼；我們的目標是交付可用的軟件。不管在什么時候，我對測試的態(tài)度都是寧缺毋濫。
個人的速度：觀察者效應再一次把這個變成了一個糟糕的指標。如果開發(fā)人員知道他的績效決定了他的個人等級，也知道只能通過他專職的工作得分，那實際上就是在打消他為團隊做貢獻的積極性。他被放在一個非常不敏捷的情境中，他要跟自己的團隊競爭，而不是為團隊做貢獻。
在理想情況下，敏捷團隊是相互協(xié)作的，彼此之間有互動，相互討論和評審他們做的幾乎所有事情。這有助于構建優(yōu)質軟件，快速解決問題，但如果把個人的生產率從團隊里剝離出來，則幾乎不可能形成這種層次的互動，所以不要做這種嘗試，這樣只會傷害團隊做出優(yōu)質軟件的能力。
團隊的速度： 這是Scrum中最容易被誤解的指標之一。一個團隊的速度是獨一無二的。不能拿來跟其他的團隊比較。比如團隊A估計某項工作的工作量為一個50點的sprint，而團隊B估計的sprint相同，不過是150點。如果兩個團隊都成功完成了sprint，那么團隊A的速度是50點，而團隊B的速度是150點。哪個團隊效率更高？都一樣。他們完成的工作是一樣的。因為這個指標鼓勵團隊捏造估值，以影響他們規(guī)劃下次sprint的能力，所以這個指標特別邪惡。如果團隊不能正確規(guī)劃sprint，那整體軟件的發(fā)布就有被延遲的危險。我之前專門寫過一篇博客討論 Scrum 團隊的速度，可供參考。
好吧，大才子，我們應該用什么指標？
問得好，我們用交付的可用軟件評測團隊生產率。我們要評測的是實際產出，而不是貢獻因素。這種方法更敏捷，因為團隊可以自由選擇能夠成功構建軟件的方法，而不是可以得到更高指標得分的方法。這也更合理，因為我們能帶到銀行去的就是能用的軟件（當然是在賣給他們之后）。
那么新指標究竟有哪些？
交付的價值： 這個指標需要產品所有者參與。讓他給出每個故事的價值，能體現(xiàn)這個故事對利益相關者的影響程度。你可以用實際的金額或某種明確的數(shù)字表示這個價值。在每次sprint完成后，你會得到一個數(shù)值，表明從產品所有者的角度來看你交付給客戶的價值是多少。
這個指標不評測績效，而是評測影響。理想情況下，產品所有者會按backlog中的順序從高到低給出每個條目的價值，這樣每次sprint所交付的價值就會盡可能的最大化。對于明確限定了范圍的項目，一開始的sprint會有非常高的交付價值，隨著不斷向backlog中深入，sprint交付的價值會逐級遞減。有時會因為開發(fā)成本的原因消除再運行一次sprint的可能，通常這時開發(fā)團隊就可以開始去做新的產品了。
交付的及時性： 有時我會聽到有人跟我說他們公司推廣敏捷開發(fā)方法的計劃失敗了，因為他們不能明確產品的交付日期。我不會認同這種說法。敏捷團隊應該可以明確確定軟件的具體交付日期。交付時可能會有些故事還沒實現(xiàn)，但那通常是些低價值故事，對客戶的影響不大。也就是說團隊的速度應該是穩(wěn)定的，如果速度加快或變慢，也應該是逐級變化的。如果不同sprint之間出現(xiàn)劇烈的速度波動，則很難做出長期規(guī)劃。
接下來是我們的指標：如果團隊預測接下來的sprint能完成5個故事，那他們完成 5個故事后能掙到2分。如果他們交付了4個故事，或者他們交付提前的時間不到2天（根據你的情況選擇天數(shù)），那他們能掙到1分。如果他們交付提前的時間超過2天，或只交付了5個中的3個，則不得分。在季度末，或一次發(fā)布結束，或年末時，團隊預測sprint的準確程度就是評判他們的標準。
所以我們評測的是交付給客戶的價值以及交付軟件的及時性。只有這兩個跟收錢有關的真實指標。