程序员的估算

在项目实施过程中，程序员的估算准确性是合理完成计划的关键一环
然而，在实际实施过程中，往往受到各种因素的影响，导致程序员不能/不愿合理估算实施情况
往往是高手过于乐观，然后发现来不及，然后本着负责任的态度要加班加点
新手根本估算不出，唯上级之命，能做则做，不能做也没有责任意识

以下是可能导致程序员估算不准确的因素
1、对需要估算的任务理解不清
2、采用了新的技术
3、不善于对付技术主管或项目经理的压力
4、不善于估计风险
5、不善于估计和其他人的协同工作
6、不善于应对变化
7、难于控制自己的工作效率
8、微妙的心理因素，不愿意让人看低自己的能力
9、博弈心态，故意高估，准备讨价还价


为了改善程序员的估算准确率，首先是技术主管或项目经理必须要充分认识程序员估算的重要性
1、理解程序员的弱势地位，不能倚势强压，鼓励程序员合理估算并给予充分尊重。
      不能把工作量估算的过程变成一个双方讨价还价的过程
2、工作必须细致，估算结果应该是带有前提的，但是绝大多数程序员在估算的时候会不表述这个隐含前提。
      技术主管A：这个工作你要几天？
      程序员B：大概三天吧
      （可能隐含前提：如果我今天下午把我那台突然病毒发作的机器搞好的话
                                      如果这份需求/设计文档写的足够细致的话
                                      如果老大你愿意及时给予我支援的话
                                      如果不考虑单元测试的时间的话
                                     ……）
     因此技术主管或者项目经理必须鼓励程序员充分考虑各种前提，从而作出比较符合实际的估算
3、加强事后总结，并判断原因，协助程序员改善估算方法。
     

评论

10 楼 抛出异常的爱 2006-11-20  

gigix 写道

估算只估相对大小，不估绝对时间。至于相对点数如何转换成绝对时间，是在项目进行当中根据统计数据来换算的。

相对的一个类有七个方法
大多方法是一个参数
有二个是三个参数
大约需要2小时(经验时长)
给普通程序员一上午时间
(一份工作不被打段的话可用时间为3小时)
如果一上午不能完成
则在下午由其它程序作或再作一次分析...

9 楼 gigix 2006-11-20  

估算只估相对大小，不估绝对时间。至于相对点数如何转换成绝对时间，是在项目进行当中根据统计数据来换算的。

8 楼 抛出异常的爱 2006-11-20  

原子化功能模块
可以提高工作效率
但是...
原子化过程花费时间比
工作时长还要长
对于不了解的成员可以用这种方式发现
每个人的最大工作速度
(当然是在一定范围内)
之后用这个速度开估量每个人的开发进度
可以提高其工作强度
并加大剥削力度

7 楼 lordhong 2006-11-20  

实际估算的至少两倍。客户的需求往往都要改。。。

6 楼 LucasLee 2006-11-17  

估算的不准确不要紧，关键是每次都要有进步。这样可以逐渐逼近。

5 楼 Godlikeme 2006-11-17  

充分了解新工作的内容和要求，细化成小任务，评估其中的难点，区分常量时间工作（重复劳动）和突破性工作（需要研究的），需要考虑自己的研究问题能力。
一般先做一个乐观时间估计，就是假设不遇到较大技术和业务难点。视工作重要程度，越重要的工作估计时间越长（可能遇到问题的可能性越大）。普通工作是乐观时间的两倍，重要工作是乐观时间的3-4倍。
个人感觉还是比较合理的。

4 楼 clamp 2006-11-17  

毫无疑问，正确的估算首先应当来自技术主管和项目经理的认识
然而，如果技术主管和项目经理缺乏这个认识，作为程序员的自我判断是否有其必要呢？

如果希望获得进一步发展的话，我认为估算的能力是必须的。
能够正确估算自己三天内的工作的，是一个好的程序员，
能够正确估算自己一周内的工作的，是一个优秀的程序员，
能够正确估算自己两周内的工作的，那多半不仅仅是程序员:P
能够正确估算别人工作的，是开发管理的必备素质。

因此，有必要在外在环境不具备的情况下，从自身做起，逐步提升自己估算的能力。

做法很简单，自己做一个对照表，列明任务、自我估计工作量、实际工作量、误差、原因等。工作量最好精确到小时。
不断的进行总结和改进，估算的能力必定会有大幅度的提升。

3 楼 tuti 2006-11-17  

PERT法, 改进delphi法.

2 楼 wolfsquare 2006-11-17  

1.把需求明确,全组讨论,产生可随时查看的文档
2.新技术统一一个适应期,在这适应期内加强交流
3.压力只来自自己承诺的期限压力,项目压力是PM承担的
4.程序员不应该承担不属于他那部分的风险,一般来说,到了这一级风险都是可以接受的了
5.有些人善于交流,而有些则相反,这些要靠PM来协调
6.达成变化是需要的共识
7.效率问题有些复杂,需要具体分析
8,9.属于PM沟通和引导的问题

1 楼 yuxie 2006-11-17  

我现在的估算方法是：

工期 = 领导定的工期 * 3