软件开发前估算开发时间靠谱吗?
粗略的估计也是估计，问题在于你不能死抱着你的初始估计不放，而是要在信息增加的时候调整你的估计，随着项目的进行，会越来越精确。
至于具体的估算方法，强烈推荐《敏捷估计与规划》http://book.douban.com/subject/2188111/ 需求/设计/计划 都是渐进明细的；
“开发人员稳定”这些因素不是不进行估算的理由，这个属于风险管理。这个应该跟历史经验和团队经验等很有关系吧。全新的团队做全新的项目当然估算的偏差大。经验团队加熟悉的项目还是应该很有把握的。脱离实际讨论这个话题就没意思了你估不出来也会有老板来拍个时间给你的，放心。我曾经录制了一段6分钟的视频，探讨了一下怎样在项目中估算时间。
简单说明：估算准确的前提条件有：
- 任务明确
- 任务所需要的资源明确
- 资源的日历清楚
视频地址：http://static.video.qq.com/TPout.swf?vid=y0134eq0sfs&auto=0不靠谱，就像一般的代码感觉自己写得出来，但是一出现BUG那就会花掉大量时间，除非是大神级别那种，否则不要轻易承诺多久可以完成。好比如平时坐车也要，堵路也是难免的有时。
项目完成时间受方方面面的影响，项目的规模，需求的完整度和变更频率，开发人员的能力和士气，交流管理的方式等等。
项目完成时间的难以评估一部分在于开始阶段需求完整度与变更频率是难以确定的，这是由于相关工作人员的个人能力和经验有限，同时也受事物认识规律本身所限制。随着项目开发的深入，需求方才逐步明晰和稳定自己的需求，开发人员才逐渐掌握开发工作的全部细节进而进行合理的评估。
能力和士气更是难以量化的因素，一个有着一二年编成经验的人，或许他原先非常熟悉业务，或许是他天生聪明，干劲十足，或许是以牺牲代码质量为代价，其完成速度可能会超过有着三五经验的人。
项目规模与项目完成时间不是呈线性关系的，项目规模越大，编码调试，开发者自测所需时间就越多，而架构，系统测试，排查错误，交流所需的时间更是呈非线性增长。
作为开发人员，我们难以把控整个项目的时间，但是可以控制部分，那就是开发时间，即自己所负责的功能模块的编码、调试和自测时间，把这部分评估工作做好，对于中小项目而言，项目评估也就完成了一半了。
评估开发时间，一个大前提是开发人员要能够比较完整地理解所在模块的需求及后续可能的变更，不要看到需求只是一个简单的流程图，ui图就贸然下结论，想想google的那个搜索框，够简单吧。你需要用技术语言将他描述出来，如果这个模块是在现有系统上的功能扩展，你还需要考虑它对现有系统的影响和现有系统的维护排错工作，以及现有系统组件的可重用性。
通过ui图和需求文档，可以大致理解需求，即使ui图仅仅只变了一小块，而你对业务又不熟悉，千万不能忽视这个小变动，因为它可能会影响到你整个程序的执行流程设计。对于一般的web应用而言，确定你已经完整理解需求的一个好方法是设计表结构并且理顺各表之间的关联关系。
在理解需求的基础上，定义业务对象，业务对象封装所需的数据项且符合单一职责，然后建立相应的数据表，同时要构思好各表之间的关联关系，有关联时建立关联表的主键。最好能建立各表之间的实体关系图，对照这张图和相关需求文档，把整个流程在脑海中过一遍，同时细分任务，度量工作量：这需要多少增删改查操作，需要多少service接口，后台定时任务有多少，前端和客户端需要哪些处理等等，调试和单元测试大概需要多久（一般需要与编码等长的时间），如果考虑到并发的话，是否需要缓存，架构是否满足当前开发要求等问题也是需要考虑的。
在思考这些问题的过程中，一旦发现需求模糊不明确的地方，一定要跟产品进行再确认，问题在需求层解决成本最低，这也是尽量避免在开发后期改动需求的原因，同时让产品说明下功能后期变动的可能性，将这些因素考虑进去，让自己的设计更具可维护性和可扩展性。
表结构设计参考：
数据库表结构设计方法及原则 - c_sharp_Rookie的专栏 - 博客频道 - CSDN.NET
欢迎关注微信公众号：java达人
ID：drjava
