跟大家分享一下我的理解
也请大神们不吝分享与讨论
我认为工时预估或者所谓的甘特图
其实对于一个软件专案的开发非常重要
理想状况是：
公司要做一个专案
PM召集软件部门的技术主管
一起把一些要实现的功能做大方向的规划
然后主管们根据
自己的经验以及对手下开发者(Developer, Dev)能力的理解
把工时预估出来
PM根据开出来的人力配置做财务规划
有需要的时候跟大老板提出增加人力的需求
然后各部门的主管在根据这个大架构
下去实做
敏捷开发的做法，可能如下：
主管把把大功能切成小功能，以两个星期为一个周期
然后开会分配工作给Dev
跟每个小功能所需要的时间预估
然后每天早上开30分钟的会
把每个组员遇到的问题或瓶颈拿出来讨论，并解决
每两周Release一组版本给测试人员(QA)测试，并且发Bug Report
回馈给Dev，并且把修Bug的时间排进去下一个周期的项目
几个周期稳定了之后再开始部署给客户使用
DevOps的做法很类似
但是对于成员的自动化与团队合作能力相对提高
差别是，在分配工作的时候，
QA跟部署人员(Operation, Ops)也纳进来
Dev在实做的时候，跟QA紧密的讨论
然后每出一个小功能，马上让QA接手，然后Ops接手
并且让流程尽可能的自动化，把重复性的动作都用程式取代
Ops让客户直接开始使用，并即时回馈
然后在下一个周期规划的时候，把修Bug的时间排进去
不管是敏捷还是DevOps每个月或者每季
个部门主管跟PM就会开会修正本来的大架构
做出对未来更精准的预测
实际状况是：
因为公司的口袋不够深？或者包袱太重？或者老板不尊重专业？眼光短浅？
大架构讨论的时候，老板就明说，目前就这些人力，
我要什么时候完成，你们看着办
然后PM完全就被废了武功，变成客户跟技术主管的传声筒
主管们因为人力不足，纷纷跳下去写Code，做测试
主管本来应该是技术力最强，帮助组员解决开发上的难题
并且还要Review组员写的程式码，负责把关有问题有危险的程式码
于是所有的程式码都变成不需要Review了，
有些公司甚至还没有使用版本追踪
因为主管要写Code，所以有些主管也不去预估时间了，
全部交给PM用想象力去压时间
然后PM就变成追踪开发进度的机器人，
开会的时候就准备很漂亮的PTT，跟老板报告进度
老板如果发现进度不如预期，就把工程师叫进来骂一骂
说我以前怎样怎样，然后对于现在要开发的东西
根本风马牛不相及用懒叫比鸡腿
有些老板甚至还会说，这我来开发一定几天就搞定
（这个老板我看104现在还在找资讯部门的主管，一间跟法律有关的公司
如果有人被找去面试，可以站内信）
我甚至还有遇过有些公司根本没有PM
做功能就是客户透过联络人或者业务把需求传进来
然后主管交代事情分工下去做，组员负责把东西干出来
主管自己要做开发，所以组员遇到问题，主管可能也没很多时间帮忙
于是就叫你自己想办法，于是就开始出现可怕的程式码
有些公司号称DevOps
结果只是技术长整天也没在带团队，偶尔会在通讯羣组上
跟大家聊一下天，讨论一下一些新的资讯
每天各个团队的小组长把要做的东西贴在通讯羣组上
但是基本上没人在管羣组里面贴了什么，都是按照自己的意思去开发
然后后QA的人就很惨，PM给出的需求，东漏西漏，整天帮Dev擦屁股
QA没擦干净的，变成Ops的人帮忙擦，结果Ops的变成全公司最赛的工作
有些公司，主管叫组员把自己要开发的项目条列出来，自己预估工时
然后需要叫组员做事的时候，就直接交代下去，也没在管本来开发的进度
最后Review的时候就说，啊你自己估计的工时怎么没办到这样
我所理解的工时预估
其实是要增进团队跟领导人对于预估项目完成准确度的能力
结果因为种种原因，变成
没有用的报表，流于形式浪费时间的开会
或者质疑组员有没有在偷懒的数据
实在无言
※ 引述《yukimatoi (缠)》之铭言：
: 我们公司的流程是
: 评估市场需求→PM提案→设计师开规格→RD实作→QA→发布
: 实际上是什么开发流程我是不知道
: 网络上有看过离职的前辈说这是瀑布式
: 公司这几年又把一些敏捷的思想带进来...
: 说因为没有一个人神到可以设计出最终规格
: 所以产品要不断迭代 RD可以先做出一个成品给设计师看 跟设计师互相讨论
: 但矛盾的是 我们的产品上线时间很早就被敲定
: 所以大部分的专案 下场就是没有得到足够的迭代
: 最后不是砍规格 就是RD跟设计师一起加班赶进度
: 甚至还有上线两个月前规格才完成的状况
: 我也问过主管 这样迭代真的足够吗？ 主管只说：恩，公司要赚钱
: PM最喜欢的就是预估时程 画满甘特图 预期最后有几个功能会完成
: 但最常见的状况就是规格大改(因为我们会迭代)
: 不然就是RD为了进度hard code才勉强满足进度
: 反正有问题就看谁倒楣谁修谁接手
: RD大老虽然说要推行test 但是跟PM根本没有共识 专案进度也没有排入test撰写的闲暇
: 所以RD要不就是自愿加班写test 要不就是干脆不写 或是写一些无关紧要的test
: 我不知道是不是只有我们公司才这样
: 还是这是业界常态只是我太菜了
: 我是真的不太懂预估工时的意义到底在哪
: 工时预估准确 ─┬→ 可喜可贺
: └→ 规格变更 ─→ 完成时间延长(然后叫你再估一次工时)
: 工时预估不准 ─┬→ RD逊砲，请重估
: ├→ RD报喜不报忧 留下技术债
: └→ 规格变更 ─→ 完成时间延长(再估一次)
: 工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
: (实际需要的时间 大概只有神知道)
: 但预估工时反而会给PM“一切都在我的掌握之中 专案都在轨道上”的错觉
: 还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢