有哪些估计软件开发时间的经验？
注意，经验是来自于你日常开发的数据收集和积累。即使现在的功能点法，也是估算出的规模，要转换为工作量，还是得有个人的生产率数据。那首先可以看一个最简单的功能实现，即只涉及到一个单表的增，删，改，查功能实
有哪些估计软件开发时间的经验？注意，经验是来自于你日常开发的数据收集和积累。即使现在的功能点法，也是估算出的规模，要转换为工作量，还是得有个人的生产率数据。
那首先可以看一个最简单的功能实现，即只涉及到一个单表的增，删，改，查功能实现你需要多长时间，这个经验数据是需要自己积累的。在积累这个数据中还需要考虑两个参数
1. 对于单表的字段数多少，对开发周期的影响是多少？即字段数应该折合的系数如何。显然一个5个字段的单表维护和一个20个字段功能维护花的时间是不同的。
2.查询功能涉及到的查询条件多少，对开发时间影响。
这个估算清楚后，再考虑涉及到主从表单的功能，其增，删，改，查功能的实现究竟需要多次时间，要有一个自己做的基准数据。
1. 在这个估算中可以进一步考虑，这个功能实现涉及到外部关联引用有多少？如某个数据录入来自于关联数据对象的多少。
2. 对于查询涉及到的关联对象的多少对查询实现逻辑的影响。
这些都基本搞清楚后，你就有了一个实现一个基本功能需要花的时间。剩下的内容重点就是将业务规则从基础功能中全部拆分出来。对业务规则的实现一个个进行工作量的估算。
业务规则本身实现的难易程度，复杂性短期是很难真正量化估算的，还是需要根据经验进行估算。考虑分支场景，业务规则实现后基本才能够比较完整的估算一个功能的开发工作量。
另外要注意，对于一个开发人员，原来从来没有做的功能，包括做前技术细节也无法想清楚的，要准确的估算工作量基本是不可能的。开发人员对工作量的准确估算还是在于已经在历史项目中大量重复做类似工作，即有这方面的经验积累。项目估算在项目的不同阶段进行估算的内容、方法、精确度都是不同的。不可一概而论。而且在项目实施过程中也是要不断调整的。说几个大概的思路。
1项目刚立项的时候，对整个项目进行估算，整个时候估算是最粗的，误差是最大的，一般误差在--50到100%已经不错了，如果控制在-30%到50%内可以算是牛人了。
2在项目内容基本确定的情况下，进行精确估算，所一个例子，就是讲所有功能点都写出来的计划进行估算就要准确多了，对每一个具体的活动进行估算，然后将所有时间相加（主要是人月，也就是工作量，而不是月）。之所以准确，自己总结了一下。
A：工作细分了，每一个工作就更具体，对每一个工作估算的精度就比较高了。
B：每一工作估算都会有偏差，可能正偏差，可能负偏差，将这些偏差相加，整体偏差会小很多。
3估算的方法，说几个简单、使用的方法
A：如果你是一个人估算，对每一个工作写三个时间，分别是最短完成时间，最可能完成时间、最差完成时间，然后 ，估算使劲=（最短完成时间+最可能完成时间*4+最差完成时间）/6.
B:多人同时估算，4人以上，采用，分别写时间，汇总后算偏差（公式excel有），超过15%的，让最短时间估算人和最长时间估算人将理解，然后重新进行估算，基本上三次估算就可以统一了。
需要注意的问题：
1项目范围的变化一定引起估算的变化，发生变更后要重新估算。这就是项目管理上说的范围变，全都变（主要是指计划要变化）
2估算不要求100%精确，否则就叫计算了，详细估算在20%都是牛人。
3估算的准确基于行业经验，主要和工作的内容多少，单项工作时间，多项工作之间的制约关系的理解有关系，这也可以解释为什么有一些有经验的人可以拍拍脑袋就说出估算来，
4克服心理问题，怕估算不准，不做项目分解、认为计划赶不上变化，害怕分解后的巨大工作量。这些都影响估算明确下，“估”算，即需要经验主义，无法精准。不管用时间、还是敏捷的Point，都是无限接近“完成时间”
做法与楼上基本一致，只是形式不同，以一只新组建的团队为例：
1、明确需求
2、任务拆解与参照物选定
（1）进行拆解ex：
需求A：实现app登录模块（不含找回密码、联合登录等）
拆解A：数据结构设计、登录app接口开发、app登录功能实现、app登录界面实现
注：这里颗粒度可以再细，这个看团队成员的能力决定
（2）接口实现、界面实现、功能实现 三个工作都可以作为基础参照物
3、拍脑袋
（1）根据个人经验，拍脑袋，对A的各项任务粗略估算。
（2）对B、C、D...等需求进行任务拆解
（3）通过与参照物的对比，进行“倍数估算”
（4）团队估算：相同工种，对同一任务估算，最高和最低的同学说明个子的理由，之后团队投票决定任务的估算时间（或point）
（5）预留少量Buff（Buff的预留方式有多种）
4、数据收集
（1）收集个人数据：个人完成的工作量、时间、工作时间比例（会议、开发时间、技术支持等）
（2）收集团队数据：团队总共完成的工作量、时间、遇到的问题等
5、总结-循环
团队总结问题（需求不确定？变更？拆分不细？难度问题？等等）
总结后调整参照物或参照物对应的工时，在新一轮的评估中避免上一个周期的问题。
几个周期后，团队就会找到估算的感觉和默契。
有事写的急，以后再改进补充时间估算是项目经理“时间管理”模块的重要工作，需要假定你的活动定义、排序、都已经做好了。
一、时间估算目的：只是自己大约心里有个数
需要依据经验判定；或请教相关有经验项目经理；或者用类似项目进行估算。
比如我给出一个范围测试，预估一天半就不会超过这个时间
二、详细项目计划：用于制定项目计划
建议由研发对自身模块进行评估时间，而后汇报时间，pm再将进度与要求时间进行比对。
三方（需求方，这个应该是公司内领导或市场）再讨论定下时间，相当于有了共识。如果能细化WBS，就好做。
如果不能，就靠组织的数据积累和团队的经验了。
那首先可以看一个最简单的功能实现，即只涉及到一个单表的增，删，改，查功能实现你需要多长时间，这个经验数据是需要自己积累的。在积累这个数据中还需要考虑两个参数
1. 对于单表的字段数多少，对开发周期的影响是多少？即字段数应该折合的系数如何。显然一个5个字段的单表维护和一个20个字段功能维护花的时间是不同的。
2.查询功能涉及到的查询条件多少，对开发时间影响。
这个估算清楚后，再考虑涉及到主从表单的功能，其增，删，改，查功能的实现究竟需要多次时间，要有一个自己做的基准数据。
1. 在这个估算中可以进一步考虑，这个功能实现涉及到外部关联引用有多少？如某个数据录入来自于关联数据对象的多少。
2. 对于查询涉及到的关联对象的多少对查询实现逻辑的影响。
这些都基本搞清楚后，你就有了一个实现一个基本功能需要花的时间。剩下的内容重点就是将业务规则从基础功能中全部拆分出来。对业务规则的实现一个个进行工作量的估算。
业务规则本身实现的难易程度，复杂性短期是很难真正量化估算的，还是需要根据经验进行估算。考虑分支场景，业务规则实现后基本才能够比较完整的估算一个功能的开发工作量。
另外要注意，对于一个开发人员，原来从来没有做的功能，包括做前技术细节也无法想清楚的，要准确的估算工作量基本是不可能的。开发人员对工作量的准确估算还是在于已经在历史项目中大量重复做类似工作，即有这方面的经验积累。项目估算在项目的不同阶段进行估算的内容、方法、精确度都是不同的。不可一概而论。而且在项目实施过程中也是要不断调整的。说几个大概的思路。
1项目刚立项的时候，对整个项目进行估算，整个时候估算是最粗的，误差是最大的，一般误差在--50到100%已经不错了，如果控制在-30%到50%内可以算是牛人了。
2在项目内容基本确定的情况下，进行精确估算，所一个例子，就是讲所有功能点都写出来的计划进行估算就要准确多了，对每一个具体的活动进行估算，然后将所有时间相加（主要是人月，也就是工作量，而不是月）。之所以准确，自己总结了一下。
A：工作细分了，每一个工作就更具体，对每一个工作估算的精度就比较高了。
B：每一工作估算都会有偏差，可能正偏差，可能负偏差，将这些偏差相加，整体偏差会小很多。
3估算的方法，说几个简单、使用的方法
A：如果你是一个人估算，对每一个工作写三个时间，分别是最短完成时间，最可能完成时间、最差完成时间，然后 ，估算使劲=（最短完成时间+最可能完成时间*4+最差完成时间）/6.
B:多人同时估算，4人以上，采用，分别写时间，汇总后算偏差（公式excel有），超过15%的，让最短时间估算人和最长时间估算人将理解，然后重新进行估算，基本上三次估算就可以统一了。
需要注意的问题：
1项目范围的变化一定引起估算的变化，发生变更后要重新估算。这就是项目管理上说的范围变，全都变（主要是指计划要变化）
2估算不要求100%精确，否则就叫计算了，详细估算在20%都是牛人。
3估算的准确基于行业经验，主要和工作的内容多少，单项工作时间，多项工作之间的制约关系的理解有关系，这也可以解释为什么有一些有经验的人可以拍拍脑袋就说出估算来，
4克服心理问题，怕估算不准，不做项目分解、认为计划赶不上变化，害怕分解后的巨大工作量。这些都影响估算明确下，“估”算，即需要经验主义，无法精准。不管用时间、还是敏捷的Point，都是无限接近“完成时间”
做法与楼上基本一致，只是形式不同，以一只新组建的团队为例：
1、明确需求
2、任务拆解与参照物选定
（1）进行拆解ex：
需求A：实现app登录模块（不含找回密码、联合登录等）
拆解A：数据结构设计、登录app接口开发、app登录功能实现、app登录界面实现
注：这里颗粒度可以再细，这个看团队成员的能力决定
（2）接口实现、界面实现、功能实现 三个工作都可以作为基础参照物
3、拍脑袋
（1）根据个人经验，拍脑袋，对A的各项任务粗略估算。
（2）对B、C、D...等需求进行任务拆解
（3）通过与参照物的对比，进行“倍数估算”
（4）团队估算：相同工种，对同一任务估算，最高和最低的同学说明个子的理由，之后团队投票决定任务的估算时间（或point）
（5）预留少量Buff（Buff的预留方式有多种）
4、数据收集
（1）收集个人数据：个人完成的工作量、时间、工作时间比例（会议、开发时间、技术支持等）
（2）收集团队数据：团队总共完成的工作量、时间、遇到的问题等
5、总结-循环
团队总结问题（需求不确定？变更？拆分不细？难度问题？等等）
总结后调整参照物或参照物对应的工时，在新一轮的评估中避免上一个周期的问题。
几个周期后，团队就会找到估算的感觉和默契。
有事写的急，以后再改进补充时间估算是项目经理“时间管理”模块的重要工作，需要假定你的活动定义、排序、都已经做好了。
一、时间估算目的：只是自己大约心里有个数
需要依据经验判定；或请教相关有经验项目经理；或者用类似项目进行估算。
比如我给出一个范围测试，预估一天半就不会超过这个时间
二、详细项目计划：用于制定项目计划
建议由研发对自身模块进行评估时间，而后汇报时间，pm再将进度与要求时间进行比对。
三方（需求方，这个应该是公司内领导或市场）再讨论定下时间，相当于有了共识。如果能细化WBS，就好做。
如果不能，就靠组织的数据积累和团队的经验了。
一个工作或者是项目的工作量的评估，会牵涉到的因素确实比较多。根据经验，罗列几种因素，比如使用的方法或者工具、开发者的熟悉程度、以及(部门之间的)利益关系、对项目的理解评估人员的个性。基于各种因素考量最后出现的工作量评估会有比较大的区别。
1.使用的方法或者是工具
对于一个项目，A有些现成的模块，B需要重新开始搭建，A和B对完成时间的评估自然不一样。
或是对于开发一个网站，假设合理的工作量是，做前台展示页面需要1个月，后台管理需要1个月。A会评估为1个月，等前台上线之后，再同步开始做后台管理。B可能会认为需要2个月，B认为前后台都完成，才是工作完成。
2.开发者的熟悉程度
这个容易理解，如果是一般对语言或是技术掌握不熟悉的人，花费的时间和返工的时间、沟通的时间自然就要长一点
责任编辑：
