在做專案時，會常常要報告進度。經常的，我們會寫出工作報告，專案已經完成了80%了。而第二天，第三天，工作中的工作進度還是那個80%。那個80%的數字是怎麼算出來的？也只是我們主觀上隨意用乙個比率進行度量，而結果卻是沒什麼意義。如果想要度量乙個真實的進度，最好的方法不是去報告完成了多少，而是去報告，還有多少要去完成。
我所在的公司專案開發所使用的是敏捷開發模式，這樣，度量乙個專案的工作進度就成為了乙個很重要的開發因素。不能很好的度量工作的真實進度那將會使開發時間一再的延期。
敏捷開發中，對於任務的分割和估算是需要很強的分析和判斷能力的。這個能力不是一日就能練成，或是別人一說就能運用自如的，這需要長期的經驗積累和誠實的工作記錄分析，如果好面子而隱瞞記錄將對自己的度量能力毫無意義。
乙個簡單的例子。如果乙個功能任務讓你去開發，你自認為在8個小時內就能完成。而過了8小時後，再讓你來估計時，你會根據前面的8小時工作能力認為還需要4個小時的時間，這樣你就得到了乙個很重要的度量結果。在正真完成任務後，把花費的總時間與估算時間進行乙個比例就可以得出乙個係數。這個係數就是你以後對於相似功能的乙個重要的比較引數。如果再有下乙個相似任務，你就可以用你的估算時間再乘上你的度量係數，就能比上一次更精確的進行工作進度估算。
使用這種近似評估的方法，會波動一段時間，有時會多，有時會少，但隨時間的推移，你的評估會與事實越來越接近，對任務所要花費的時間會有更清楚的認識。到後來，你會發現你對自己的能力有了乙個很高的精準的評估和把握，對於任何到手的任務你都會心中有數，會有種一種盡在掌握中的感覺。
不要用不恰當的度量來欺騙自己或是團隊，對於任何要完成的待辦事項都要進行評估。
我個人的感覺，敏捷開發在國內還是乙個新興的開發方法，雖然它已經在到國內來了不少年了。但從我所在的公司中的執行狀況看來他還是乙個有著中國特色的敏捷模式。因為，在國外，能完全發揮敏捷開發模式最大功效的團隊基本上他們的隊員都是有著十幾年豐富開發經驗的技術員，在執行敏捷開發的前提就是，對於隊員來說沒有解決不了的技術難題。而後才是加入客戶的參與進行快速的需求的分析和任務的估算、切割，在開發進行中或許會再加個結對的程式設計，在階段開發完成後，由測試進行驅動，並再進行需求變更分析估算開發等，如經迴圈，在國內很難達到這個水平，更不用去說那個更為快速的極限程式設計了。但是這些開發模式中的精華我們是可以吸取消化吸收和溶合的。
努力的鍛鍊出自己的真實度量能力，將會把自己從無盡的精神勞累工作中打撈起來轉而進入到舒心工作日程。知道了自己的真實能力，就能對自己進行合適的工作時間排程，不同的工作時間排程又會使我們有著不同的生活質量，不過，那將是另乙個話題了，今天就先寫到這。
距離的度量
長度時什麼東西，仔細想起來我也不清楚了。百科說的是 一維空間中點到點的距離。不過距離又是什麼？又得依靠長度來進行表示，然後就是死迴圈了。所以，長度就是描述一維空間中兩個點遠近的量，這樣比較容易理解。正如資訊量一樣，評判資訊含量的問題。長度也只是乙個基本的平台。重要的永遠不是平台，而是運用這個平台能夠...
資訊的度量
比如寫 時搜尋資料，從乙個大方向逐步細化為明確的研究再到具體的原理 數學公式等，這個過程就是不確定性的降低。一開始需要閱覽大量相關 明確後就變成了對某個具體的知識內容的精確搜尋，資訊量也在降低。因此 資訊量就等於不確定性的多少。對已知的的資訊進行排序分組能有效降低不確定性，即資訊量。用h表示資訊熵，...
軟體專案度量中主要的度量指標
軟體度量是軟體過程改進的基礎，如果沒有對目前的狀態作出度量，那麼就談不上作改進，當然如果沒有對改進後的過程作度量比較，也無法知道過程改進的效果。那麼，在軟體專案的度量中應該主要度量哪些指標呢？對於乙個組織，要對組織內的所有專案進行度量，則可以從幾個主要指標入手，如 軟體專案規模 size 工作量 e...