評估的詳細程度取決於當時所處的環境和所能採納的程度。對於時間估計，建議採納下面的規格標準：
剩餘的時間
**估算
1~15天
天3~6周
周8~20周
周20+ 周
在給出乙個評估時間之前努力思考
評估專案的完成時間，只**於之前做過相似的專案，或者別人做過的相似專案。其它一切拍腦門的時間評估都是扯淡！
要理解被問的是什麼問題，它的範圍包括哪些，儘管這不言而喻。一旦養成習慣，往往答案就在你所考慮的範圍之內。
首先建立乙個系統的時間評估模型，儘管開始是粗糙的，隨著時間的流逝慢慢的完善它。儘管建立模型會花費一些時間，但功效卻事半功倍。
將模型劃分成很多子模型，然後根據一些數學公式找出它們之間的關聯關係。有時候乙個子模型對結果的影響是加法關係，有的時候乙個子模型對結果的影響是乘法關係，有的時候會更加的複雜！你會發現每個子模型都會有乙個引數作用來影響結果，然後找出這個引數。
一旦你發現了這個引數，那麼就給他乙個值。這裡可能會範一些錯誤，不過沒關係。技巧是找出對結果有巨大影響的那些引數，並把它除錯正確。一般來說，加法關係的引數沒有乘法關係的引數對結果的影響大。
用建立好的模型還有引數來計算答案，通過計算機技術，計算的速度會非常快。一旦你發現計算出來的結果很奇怪，不要失望。這有可能是你對問題的理解或者建立的模型有問題，這是個好兆頭。
要不斷的記錄與跟蹤你的評估，每次評估完時間，並且完成專案後，都要看看開始的評估與結果的差距有多大。然後找出原因，為什麼會有這麼大的差距，下一次改正它。一旦形成習慣，那麼你的時間評估就會越來越好！
人們習慣於將整個專案的計畫任務寫滿整面牆，並且完全相信通過數學公式，他們會有非常精準的時間評估。但結果卻不盡人意，因為他們之前根本沒有做過這個專案。
我們發現決定乙個專案的時間日程的唯一因素就是經驗，只要你做過這個專案或者相似的專案，那麼你估計的時間就比較靠譜。迭代開發也是如此，並且它遵循以下規則：
1、檢查需求
2、分析風險（早期的優先順序最高的風險）
3、設計、實施、整合
4、讓使用者確認
首先，你會有乙個模糊的想法，這個工程要有多少個迭代過程，並且他們會花費多長時間。有一些方法或者有些人會要求你把這個作為乙個初始計畫。然而，對於複雜專案來說，這樣做就是乙個天大的錯誤。除非你做過相似的專案，而且還是那些人，用的還是那些技術。
所以在每個迭代過程中，完成編碼和測試後。根據這個過程的經驗，再去評估下乙個迭代過程的時間，以此類推，隨著迭代的不斷進行下去，你評估的也會越來越準確，自信心也會大大增強。
很多管理人士總想著在專案啟動前有乙個固定的，不會改變的時間進度。你不得不幫助他們理解開發團隊、他們的生產效率、還用環境共同決定了完成時間。通過規範化這些，重新定義每個迭代過程的時間進度，你將給他們最精確的時間進度。
你要說：「稍後回答你」！
當你拖慢回答他的過程，按照上述的方法去做，往往會得到非常好的結果。如果很快的回答這個問題，那就等著倒霉吧！
《程式設計師修煉之道》讀書筆記
第1章 你的知識資產 隨著你的知識的價值降低，對你的公司或客戶來說，你的價值也在降低。管理知識資產與管理金融資產非常相似，管理金融資產基本遵循 1.嚴肅的投資者定期投資 作為習慣 2.多元化是長期成功的關鍵 3.聰明的投資者在保守的投資和高風險 高回報的投資之間平衡他們的資產 4.投資者設法低買高賣...
程式設計師修煉之道 讀書筆記
注重實效的程式設計師的特徵 care about your craft 關心你的技藝 think about your work 思考你的工作 1 注重實效的哲學 我的 被貓吃了。負責 破窗理論。軟體的熵 定期為你的知識資產投資 2 注重實效的途徑 dry don t repeat yourself...
《程式設計師修煉之道》讀書筆記
出了問題後，要提出各種解決方案的選擇，而不是找藉口 不要說事情做不到，要說明接下來做什麼來挽回局面 我們看到過整潔 執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化 不要留著破窗戶不修 發現乙個bug就修復乙個，如果沒有足夠的時間進行恰當的修理，就用木板先訂起來 或許你可以先把 注釋起來，或是顯示...