估算那点事

我觉得估算首先要完成详细设计，这样估出来的时间会相对准确。
项目经理只把需求往程序员那里一扔，再加上概念模型做的很烂，业务分析不到位，神都估不准。
所以建议先给一段时间理解业务，做详细设计，这样的时间应该就比较准了。

哈哈，顶这句。企业应用，电子政务类的项目更是如此。

估算的准确与否，主要看执行情况。

再准有时候也没用，客户压缩，老大压缩，项目经理再压缩。。。

1，基于以往项目得到各复杂度的基准线来评估；有很多公司是有工具的。
2，可以粗粒度基于模块（15～30 Buffer），后续需求明确并分析后，再细化到画面数量，按钮，Form，计算字段，接口，特殊处理等等，重构也最好考虑进去。
3， 基于实际经验来分析准确性，做些许微调；
4， 要按照普通工程师标准来评估。
5， 没有技术背景的Estimation都扯淡。

我也是扯淡，别当真。

小计划精确到小时？ 你真以为程序员是机器啊？

所在公司是给政府机构做项目，从来都是限定时间，然后倒序排计划...
然后就是永无止境的加班。。。

我想起以前看过一个大佬外的twitter，后来摘录下来：
Coders are special. "We are expected to know how to do things we've never done before and estimate how long they will take." 

软件开发外部不确定因素太多了。。讲不好听地震灾害之类的都会影响。。。注定了不可能做到那么精确的计划安排。关键应该是安排好计划出现问题时怎么处理。。。。你是否有应急预案。。。针对不同的情况做出相应的解决办法。。。。谋事在人，成事在天。。。。。

敏捷只是解决问题的一个方法，不是万能的，就看lz后面举得两个例子，比如说性能问题，即使采用迭代，也很难在早期发现。还有就是架构的问题等。所以采用敏捷不能保证项目一定成功，只能保证在一定程度上提高项目的成功率而已。毕竟这个世界上没有常胜将军。

深度同情并理解楼主。
很多事情说着简单，做起来就完全是另外一回事，敏捷概念很好，能实践敏捷确是要有很强的功底，“讲政治”也是程序员不可回避的问题。

估算嘛本来就是在假定一切顺利的情况下估计周期。没有哪个估算是绝对准确的，除非您是先知，估算的目的是为里程碑定个deadline让大家有个总体印象。
我觉得应当先做个项目整体计划把大里程碑时间确定下来，在详细设计完成后再做个编码计划，尽量精确到天，然后预留一定的缓冲时间避免突发情况。