我認為敏捷社群要改變評測敏捷團隊是否成功的方法。我們收集指標以及從這些指標中獲取資訊的方法實際上妨礙了我們做出能用的軟體，而這才是最重要的東西。
強推個體指標有時會導致過於關注其他人，影響團隊的協作。這會歪曲我們要評測的內容，摧毀我們的真實意圖。
在我看來主要有兩個問題：
觀察者效應： 觀察者效應是指對乙個流程進行觀測可能會影響它的輸出。比如告訴乙個團隊你會密切關注他們的速度，該團隊可能會為了加快速度而過度估算他們的工作內容。這在處理 故事點 時尤其危險，因為根本就沒有依據可以判斷估算是否有效。
儘管上面這幅漫畫中的情況很有可能發生過，但並不是我理想中觀察者效應的例子。我給你們講乙個我很久之前認識的技術支援工程師，我們叫他「傑森」好了，因為他的名字就是傑森。傑森是一位優秀的技術支援，在別人遇到特別困難的問題時他會施以援手，一般在客戶打來第乙個**時他就能正確地把問題解決掉，而且客戶對他的評價很高。問題是傑森接**的時間太長，而這一指針對管理層來說非常重要。後來經過幾次會議和一次考核之後，傑森明白他必須把時間縮短，否則就只能另謀高就了。很快幾周就過去了，傑森的呼叫時長在整個支援團隊中排到了前5名。他是怎麼做到的呢？如果不是我有一天接他班時提前到了乙個小時，他可能永遠都不會跟人講起其中的秘密，那天我發現他原來是接了**之後馬上就掛掉了。
這挺有點兒意思，如果傑森的呼叫時長沒有他的真實績效重要，他就不會幹那種事。以呼叫時長為指標評測他對產出產生了負面影響。除了這個糟糕的指標之外，即便沒碰到過傑森這麼極端的情況，我們也都遇到過只想盡快讓你掛上**的技術支援。問題是你的團隊為了讓自己的數值更好看掛了哪些**？
路燈效應：路燈效應是指我們人類傾向於尋找更容易的答案，而不是真實的資訊。比如計算**行數就很簡單，但**行數並不能告訴我們程式的質量如何，也不能表明程式提供的功能性甚至效率怎麼樣。
我想起以前曾經工作過的乙個團隊，我們做了幾個產品，每個產品的質量標準都不一樣。當時的情形是「產品a」的質量標準要難得多，而產品b、產品c或產品d的質量標準不會是什麼太大的問題，除非管理層在下次審查臨近時改變了對這些產品質量的要求。
問題是「質量」這個概念有點模糊，真的不太好評測。而錯誤率就容易測量得多，因此那些做產品a這個質量標準比較高的產品的人，在面對審查時就更加不利。那這份工作最終是由誰來完成的呢？大部分是實習生、臨時工或做外包的那些人，或者其他任何人，總之沒人願意參與。
事實證明，即便是容易測量的錯誤率，也不能給出什麼有價值的資訊，因為出現錯誤的次數更多是由產品而不是員工決定的。我們反而趕走了幾個不錯的新員工，丟掉了客戶，整個團隊的士氣也受挫了，因為他們工作時考慮更多的是在如何避免錯誤，而不是如何構建產品。
因為這兩個都不是軟體開發的例子，所以接下來我們把這些概念放到一些常見的、你所熟悉的「敏捷」指標上。容易測量的指標有哪些？
編寫單元測試的數量：大多數敏捷開發者都會寫很多單元測試；測試驅動的開發建立的測試更多（兩者都能帶來更好的**質量）。所以用乙個開發人員編寫的測試數量來評測他的生產率肯定是沒錯的！實際上觀察者效應會把這個指標滅掉。告訴開發人員會用他們編寫的測試數量來評測他，他們肯定會在不考慮質量的情況下寫很多測試。我們不是為了交付測試**；我們的目標是交付可用的軟體。不管在什麼時候，我對測試的態度都是寧缺毋濫。
個人的速度：觀察者效應再一次把這個變成了乙個糟糕的指標。如果開發人員知道他的績效決定了他的個人等級，也知道只能通過他專職的工作得分，那實際上就是在打消他為團隊做貢獻的積極性。他被放在乙個非常不敏捷的情境中，他要跟自己的團隊競爭，而不是為團隊做貢獻。
在理想情況下，敏捷團隊是相互協作的，彼此之間有互動，相互討論和評審他們做的幾乎所有事情。這有助於構建優質軟體，快速解決問題，但如果把個人的生產率從團隊裡剝離出來，則幾乎不可能形成這種層次的互動，所以不要做這種嘗試，這樣只會傷害團隊做出優質軟體的能力。
團隊的速度： 這是scrum中最容易被誤解的指標之一。乙個團隊的速度是獨一無二的。不能拿來跟其他的團隊比較。比如團隊a估計某項工作的工作量為乙個50點的sprint，而團隊b估計的sprint相同，不過是150點。如果兩個團隊都成功完成了sprint，那麼團隊a的速度是50點，而團隊b的速度是150點。哪個團隊效率更高？都一樣。他們完成的工作是一樣的。因為這個指標鼓勵團隊捏造估值，以影響他們規劃下次sprint的能力，所以這個指標特別**。如果團隊不能正確規劃sprint，那整體軟體的發布就有被延遲的危險。我之前專門寫過一篇部落格討論 scrum 團隊的速度，可供參考。
好吧，大才子，我們應該用什麼指標？
問得好，我們用交付的可用軟體評測團隊生產率。我們要評測的是實際產出，而不是貢獻因素。這種方法更敏捷，因為團隊可以自由選擇能夠成功構建軟體的方法，而不是可以得到更高指標得分的方法。這也更合理，因為我們能帶到銀行去的就是能用的軟體（當然是在賣給他們之後）。
那麼新指標究竟有哪些？
交付的價值： 這個指標需要產品所有者參與。讓他給出每個故事的價值，能體現這個故事對利益相關者的影響程度。你可以用實際的金額或某種明確的數字表示這個價值。在每次sprint完成後，你會得到乙個數值，表明從產品所有者的角度來看你交付給客戶的價值是多少。
這個指標不評測績效，而是評測影響。理想情況下，產品所有者會按backlog中的順序從高到低給出每個條目的價值，這樣每次sprint所交付的價值就會盡可能的最大化。對於明確限定了範圍的專案，一開始的sprint會有非常高的交付價值，隨著不斷向backlog中深入，sprint交付的價值會逐級遞減。有時會因為開發成本的原因消除再執行一次sprint的可能，通常這時開發團隊就可以開始去做新的產品了。
交付的及時性： 有時我會聽到有人跟我說他們公司推廣敏捷開發方法的計畫失敗了，因為他們不能明確產品的交付日期。我不會認同這種說法。敏捷團隊應該可以明確確定軟體的具體交付日期。交付時可能會有些故事還沒實現，但那通常是些低價值故事，對客戶的影響不大。也就是說團隊的速度應該是穩定的，如果速度加快或變慢，也應該是逐級變化的。如果不同sprint之間出現劇烈的速度波動，則很難做出長期規劃。
接下來是我們的指標：如果團隊**接下來的sprint能完成5個故事，那他們完成 5個故事後能掙到2分。如果他們交付了4個故事，或者他們交付提前的時間不到2天（根據你的情況選擇天數），那他們能掙到1分。如果他們交付提前的時間超過2天，或只交付了5個中的3個，則不得分。在季度末，或一次發布結束，或年末時，團隊**sprint的準確程度就是評判他們的標準。
所以我們評測的是交付給客戶的價值以及交付軟體的及時性。只有這兩個跟收錢有關的真實指標。
怎麼才能保證你的敏捷團隊不會被指標毀掉
我認為敏捷社群要改變評測敏捷團隊是否成功的方法。我們收集指標以及從這些指標中獲取資訊的方法實際上妨礙了我們做出能用的軟體，而這才是最重要的東西。強推個體指標有時會導致過於關注其他人，影響團隊的協作。這會歪曲我們要評測的內容，摧毀我們的真實意圖。在我看來主要有兩個問題 觀察者效應 觀察者效應是指對乙個...
怎麼處理才可以讓程式的訊息不會被HOOK
遮蔽鉤子的方法之一是檢查訊息的 內部增加乙個校驗機制，如果訊息來自本應用程式，則予以響應，否則丟棄。1 從cedit繼承乙個子類cpasswordedit，宣告全域性變數g bauthoridentity表明訊息傳送者的身份。bool g bauthoridentity 然後相應cpassworde...
如何確定敏捷是否適合你的團隊？
對從事專案管理的人員來說，敏捷已經成為一場席捲全國的風潮。但敏捷並不是什麼新事物，它已經有20多年的歷史。正如社交 圈子所說的那樣，敏捷的聲勢與流行程度正在逐年見長。但敏捷是不是真的如坊間傳聞的那樣，是乙個可以解決所有專案困境的萬能藥？當然不是！但敏捷的確是一種比較好的專案管理方法。敏捷為專案負責人...