以這篇回文做一點延伸
※ 引述《Feis (坐吃山空)》之銘言：
: 預估工時本身沒有錯，問題是我們怎麼看待預估的結果
: 『預估工時』本身只是個工具，不是結果
: 如果真的要從虛工的角度來看，坦白說，連講話都是虛工。
: 開會更是浪費時間的極致
: 程式碼不就是一堆字，把字打完就收工，其他都多餘的
: 但是軟體開發真的是這樣嗎？
: 從另外一方面來看，真正的虛工經常是管理層對於管理手段和工具的不熟悉所造成的
: 而不是工具本身所造成
: 如果每天只要上班有打卡下班有打卡就有錢拿那我每天上班兩分鐘就好
: 這世界就不是這麼運作的
: 打卡會成為一種管理工具不就是在某些組織文化下的平衡
: 造成一定浪費下但又能達到一定效益的結果
: 預估工時或是工作量 (point) 也就只是一種溝通的手段
: 為了讓不同背景不同經驗不同能力的人能夠有一個比較一般化的方式溝通
: 他是溝通的『起點』而不是終點
: 我不懂為什麼為了要表達其他工具也很重要的論點就要把預估工時當做沒有幫助
: 實際上如果連下一秒軟體專案能不能『符合預期』的運作都不能保證
: 其他根本都是多餘，你 QA 跟 Review 能做什麼事？
: QA 完還是不知道能不能動不是搞笑嗎
: 預估工時的目的當然隨著專案或組織特性有所不同
: 但是他終究是工具的一種，不要把它當作天條，但把它當一無不值一定是有問題的
（自己學這塊是以英文為主，試著翻譯一些，可能與坊間有出入）
軟體工程的活動（activity）往往有多重目標，
也常常跟其他的活動有相關、相輔相成，以達成特定目標
以預估時間（estimation）來說，
目標通常是包含「在時間預算內完成專案」＋「產生數據以幫助溝通」，
跟客戶或使用者討論清楚完成的定義（definition of done），
通常是與不同相關人士溝通時非常重要的工具
estimation通常與幾個活動有直接關連：
1. planning 專案規劃：包含時間、品質、產出等面向
2. tracking 專案追蹤：包含時間、需求、風險等面向
3. risk management 風險管理：包含時間、品質等面向