开发估时

项目完成时间受方方面面的影响，项目的规模，需求的完整度和变更频率，开发人员的能力和士气，交流管理的方式等等。

项目完成时间的难以评估一部分在于开始阶段需求完整度与变更频率是难以确定的，这是由于相关工作人员的个人能力和经验有限，同时也受事物认识规律本身所限制。随着项目开发的深入，需求方才逐步明晰和稳定自己的需求，开发人员才逐渐掌握开发工作的全部细节进而进行合理的评估。

能力和士气更是难以量化的因素，一个有着一二年编成经验的人，或许他原先非常熟悉业务，或许是他天生聪明，干劲十足，或许是以牺牲代码质量为代价，其完成速度可能会超过有着三五经验的人。

项目规模与项目完成时间不是呈线性关系的，项目规模越大，编码调试，开发者自测所需时间就越多，而架构，系统测试，排查错误，交流所需的时间更是呈非线性增长。

作为开发人员，我们难以把控整个项目的时间，但是可以控制部分，那就是开发时间，即自己所负责的功能模块的编码、调试和自测时间，把这部分评估工作做好，对于中小项目而言，项目评估也就完成了一半了。

评估开发时间，一个大前提是开发人员要能够比较完整地理解所在模块的需求及后续可能的变更，不要看到需求只是一个简单的流程图，ui图就贸然下结论，想想google的那个搜索框，够简单吧。你需要用技术语言将他描述出来，如果这个模块是在现有系统上的功能扩展，你还需要考虑它对现有系统的影响和现有系统的维护排错工作，以及现有系统组件的可重用性。

通过ui图和需求文档，可以大致理解需求，即使ui图仅仅只变了一小块，而你对业务又不熟悉，千万不能忽视这个小变动，因为它可能会影响到你整个程序的执行流程设计。对于一般的web应用而言，确定你已经完整理解需求的一个好方法是设计表结构并且理顺各表之间的关联关系。

在理解需求的基础上，定义业务对象，业务对象封装所需的数据项且符合单一职责，然后建立相应的数据表，同时要构思好各表之间的关联关系，有关联时建立关联表的主键。最好能建立各表之间的实体关系图，对照这张图和相关需求文档，把整个流程在脑海中过一遍，同时细分任务，度量工作量：这需要多少增删改查操作，需要多少service接口，后台定时任务有多少，前端和客户端需要哪些处理等等，调试和单元测试大概需要多久（一般需要与编码等长的时间），如果考虑到并发的话，是否需要缓存，架构是否满足当前开发要求等问题也是需要考虑的。

在思考这些问题的过程中，一旦发现需求模糊不明确的地方，一定要跟产品进行再确认，问题在需求层解决成本最低，这也是尽量避免在开发后期改动需求的原因，同时让产品说明下功能后期变动的可能性，将这些因素考虑进去，让自己的设计更具可维护性和可扩展性。

表结构设计参考：

http://blog.csdn.net/c_sharp_Rookie/article/details/3786317

java达人

ID：java_daren