對一個項目的評估，往往被要求在項目需求還不明確的時候開始。不知道你是否有這樣的體會，客戶給你簡單介紹了一點需求，或者發(fā)給你一份寫的很粗略的文檔，就要求你給個價格看這東西大概是要花多少錢多少時間才能建成。以前我做網(wǎng)站的時候，遇到過好多好多的這類問題。
    在軟件開發(fā)過程中，總要面臨一個"估算(Estimation)"的問題。這個項目需要多長時間？這個模塊你大概多久完成？一共要花多少錢才能搞出來？軟件開發(fā)的成本主常常用人月來計算，當然，也有人/小時，人/天。從數(shù)學上說，計算一個時間的先決條件，是必須要知道速率和距離。那軟件開發(fā)度速率是多少？開發(fā)要走完的距離又怎么估計？
    假定"人天"可以作為我們需要找到的速率(Velocity)的單位，就是某個人每天8小時能干的活的工作量，或說他的開發(fā)能力。對于一大堆待要開發(fā)的需求，它的總工作量和整個團隊的單位開發(fā)能力的計算需要考慮更多的因素。
    先來考慮需求的總量。我們來看這一個例子，列舉你認識的滿足下面條件的人：人，男人，20歲的男人，20歲的 頭發(fā)有些染黃的男人，20歲的頭發(fā)有些染黃抽煙的男人。從這一組詞中，我們可以看到，從左到右描述的越來越具體，你能列舉出的也越來越少。而反過來順序，詞的外延更大，你的能想到的卻越來越多的。
    同樣的，對于需求的描述，如果描述的越細致，你就越能夠準確的估算它的工作量。 登錄系統(tǒng)，這樣的需求很難說要多久。而一個使用用戶名密碼登錄，支持找回密碼功能的登錄系統(tǒng)就稍微好一些。如果能夠畫出界面原型圖那就更加清晰了。對于這樣的需求，我們可以用"理想的人天"來評估。我們說某一個需求的成本，是2 Ideal Days。 就是一個人在理想的2天內(nèi)能夠完成這個工作。
    說到開發(fā)人員的"理想的人天"，就不能離開團隊孤立的看。一個團隊包括項目經(jīng)理和需求分析師、測試員等角色。他們的工作不直接反應到代碼量的多少。如果只考慮一個項目開發(fā)人員的代碼開發(fā)量成本，毫無疑問要虧損的。另外，團隊成員水準參差不齊，不同的任務不同程序員來完成所花費的時間也不同。因此，單獨相加每個成員的"人天"毫無意義。必須要整體考慮一個團隊的總"人天"。
    那么如何衡量一個團隊的總"人天"？如果一個團隊已經(jīng)經(jīng)過長期的磨合，那么可以從以往的數(shù)據(jù)來獲得他們的開發(fā)量。 如果是新建立的團隊，沒有經(jīng)過磨合，那就需要開始實際進行一段時間的開發(fā)，在開發(fā)后3-4個星期再回頭來計算這幾個星期的團隊速率。一般的，一個團隊經(jīng)過一段時間的磨合，在開發(fā)速率上會有緩慢的提升。例如一個需求的估算是5理想人天，而團隊實際開發(fā)了10天。那么團隊的速率就是5理想人天，團隊的負載系數(shù)，即正常被其他事情干擾而降低的比率是2。
    有了這個團隊的速率，項目經(jīng)理就可以放心大膽的說，我們團隊有10人，開發(fā)能力是"n理想人天每周"，負載系數(shù)是2，由于有20n的需求總量，我們大概在40周左右完成。因此，我們的報價是xx,xxx,xxx元。
    如果你有幸長期跟蹤過一個團隊的開發(fā)速率，就會發(fā)現(xiàn)很多有趣的現(xiàn)象。一開始，團隊速率很低，但慢慢的成長。到達一定時期后，就會穩(wěn)定在一個固定值附近。有時候有新的成員加入進團隊，團隊的開發(fā)速率會出人意外的降低一段時間再慢慢回增。
    成本、時間、范圍、質(zhì)量，這是項目管理常見的四要素，四者很難同時滿足。如果關心時間，又不想出錢，還要完成那么多功能，那犧牲的就真正是質(zhì)量了。常說的一分錢一份貨，在軟件開發(fā)中反映的淋漓盡致。所以，為了能夠保證按時按質(zhì)完成任務，一個合理的開發(fā)價格是合格的項目經(jīng)理必須能夠估算出來的。而這需要長期經(jīng)驗和實踐的積累，急不來的。
    但有些時候，也有些不好處理的問題。有人問：我是老板，如果我的開發(fā)團隊合起伙來編造一個估算，把我的需求估算的很多，而把他們的速率估算的很低，工起來工作量不飽和，老消極怠工怎么辦？呃。。我只能說，這只好借助于開發(fā)方法以外的事情了，例如獎金激勵、績效考核、引入外部咨詢團隊(例如ThoughtWorks)等等，人的問題不是能夠簡單靠過程就解決了的，如果道歉有用的話，要警察干嘛？