IT項目管理中的度量

原作者：人月神話  來源于：新浪博客

人月：項目進度計劃老做不準確，每周都要去調計劃，不知道項目計劃做來還有什么意義？
神話：那你分析了進度計劃做不準確的根源了嗎？人月

人月：原因有很多，有突發事件影響，有個人效率的差別，但我覺得主要是我們估算數據不準確，這樣導致我們在排進度計劃的工期和工時出現很大的偏差。
神話：那什么導致估算數據不準確呢？

人月：原來我們項目估算都是專家法，項目有個很有經驗的開發負責人，每次都是他進行估算的，數據是比較準備的。但現在這個人離職了，新的人員有沒有估算經驗，在估算的時候很大細節問題考慮不到，引起我們估算數據偏差很大。
神話：經驗始終停留在個人的頭腦里面，這種經驗無法量化出來為他人采用。人月，你平時沒有收集你做的歷史版本的規模，工作量和生產率這些數據嗎？

人月：收集了，但不知道如何真正去用這些數據��！
神話：讓我們看下下達任務工作量回饋曲線：工作量－》生產率－》軟件規模－》功能點，一個歷史版本做完后工作量和軟件規模如代碼行這些數據都可以收集到，這樣你很容易得出你們項目的一個平均生產率。

人月：但是我很難在開始估算時候估計軟件的代碼行數。
神話：這是歷史數據的積累不夠，當開始估算的時候我們可以采用功能點或軟件需求的用例數來作為估算的具體規模。

人月：還有，項目經常返工，一遇到返工就把我的進度計劃打亂了，而且返工很影響大家的積極性。
神話：你采用什么方法控制了返工了嗎，人月？
人月：有啊，我們通過評審和Review來在項目的早期階段提前發現缺陷，減少需求的泄露率。
神話：那你怎么來確認的評審和Review的工作量的安排的呢？
人月：我憑經驗隨便估計的。

神話：這里其實還是度量的問題，你應該對歷史版本的缺陷泄露率數據進行收集和分析，當你發現需求到設計的缺陷泄露很高的時候，你就應該在需求的評審和Review上多花時間，而這個時間衡定是跟你返工工作量對比的，只要小于返工的工作量，那這些評審，討論和Review的工作量安排就是合理的。

人月：神話，我覺得度量的好處就是幫助我們進行項目中的決策，因為任何一項決策都需要依據，用事實來說話。而我們收集的度量數據正好就是充足有力的證據。
神話：是這樣的，所以度量對一個項目來說很重要的，度量不僅僅是收集數據，更重要的是分析數據。

人月：但是我還是不是很清楚，比如我收集到數據表明我進度延后了，但我還是不知道如何去分析這個數據？
神話：這就是度量體系的問題，我們的度量指標不是孤立的，每個度量指標之間都有影響和聯系。見上面的關聯關系圖。


神話：當你發現進度延后后需要管理分析工作量，生產率，規模，需求穩定性，返工情況，缺陷泄露的情況，評審的質量等多方面的其它度量數據，才能夠真正發現進度延后的根源在哪里。

神話：如進度延后是由于返工工作量增加了，返工工作量增加原因根據缺陷泄露分析發現是需求階段缺陷泄露率高而并非需求變更多引起的。需求泄露率高是評審質量出問題，而評審質量出問題根源可能是當初評審時間沒有留夠。

人月：這里我理解了，其實我們做任何事情都是有目的和目標的，不是規程要求我們這樣做而去做，而是我們項目存在問題，我們需求去度量來幫助我們決策，從而解決項目的問題。
神話：是的，規程或規范是手段而不是目的，這點一定要搞清楚。

人月：還有一個問題就是我經常收集不到項目中的真實數據，或者收集的數據本身就不準確，如一個工作任務的實際工作量數據。
神話：為何不在項目中推行PSP呢？個體軟件過程既可以保證收集到真實可靠的數據，又可以促使每個人能夠有意識的去自我改進。

人月：那CMMI的度量過程究竟應該怎樣去做呢？有沒有具體的流程
神話：源頭在自我需求，所以是首先項目有某種需求－》然后指定度量計劃-》收集數據-》分析和驗證數據-》根據數據進行決策。