以这篇回文做一点延伸
※ 引述《Feis (坐吃山空)》之铭言：
: 预估工时本身没有错，问题是我们怎么看待预估的结果
: ‘预估工时’本身只是个工具，不是结果
: 如果真的要从虚工的角度来看，坦白说，连讲话都是虚工。
: 开会更是浪费时间的极致
: 程式码不就是一堆字，把字打完就收工，其他都多余的
: 但是软件开发真的是这样吗？
: 从另外一方面来看，真正的虚工经常是管理层对于管理手段和工具的不熟悉所造成的
: 而不是工具本身所造成
: 如果每天只要上班有打卡下班有打卡就有钱拿那我每天上班两分钟就好
: 这世界就不是这么运作的
: 打卡会成为一种管理工具不就是在某些组织文化下的平衡
: 造成一定浪费下但又能达到一定效益的结果
: 预估工时或是工作量 (point) 也就只是一种沟通的手段
: 为了让不同背景不同经验不同能力的人能够有一个比较一般化的方式沟通
: 他是沟通的‘起点’而不是终点
: 我不懂为什么为了要表达其他工具也很重要的论点就要把预估工时当做没有帮助
: 实际上如果连下一秒软件专案能不能‘符合预期’的运作都不能保证
: 其他根本都是多余，你 QA 跟 Review 能做什么事？
: QA 完还是不知道能不能动不是搞笑吗
: 预估工时的目的当然随着专案或组织特性有所不同
: 但是他终究是工具的一种，不要把它当作天条，但把它当一无不值一定是有问题的
（自己学这块是以英文为主，试着翻译一些，可能与坊间有出入）
软件工程的活动（activity）往往有多重目标，
也常常跟其他的活动有相关、相辅相成，以达成特定目标
以预估时间（estimation）来说，
目标通常是包含“在时间预算内完成专案”＋“产生数据以帮助沟通”，
跟客户或使用者讨论清楚完成的定义（definition of done），
通常是与不同相关人士沟通时非常重要的工具
estimation通常与几个活动有直接关连：
1. planning 专案规划：包含时间、品质、产出等面向
2. tracking 专案追踪：包含时间、需求、风险等面向
3. risk management 风险管理：包含时间、品质等面向