2006-11-17

程序员的估算

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

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


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

评论
抛出异常的爱 2006-11-20
gigix 写道
估算只估相对大小,不估绝对时间。至于相对点数如何转换成绝对时间,是在项目进行当中根据统计数据来换算的。


相对的一个类有七个方法
大多方法是一个参数
有二个是三个参数
大约需要2小时(经验时长)
给普通程序员一上午时间
(一份工作不被打段的话可用时间为3小时)
如果一上午不能完成
则在下午由其它程序作或再作一次分析...
gigix 2006-11-20
估算只估相对大小,不估绝对时间。至于相对点数如何转换成绝对时间,是在项目进行当中根据统计数据来换算的。
抛出异常的爱 2006-11-20
原子化功能模块
可以提高工作效率
但是...
原子化过程花费时间比
工作时长还要长
对于不了解的成员可以用这种方式发现
每个人的最大工作速度
(当然是在一定范围内)
之后用这个速度开估量每个人的开发进度
可以提高其工作强度
并加大剥削力度
lordhong 2006-11-20
实际估算的至少两倍。客户的需求往往都要改。。。
Lucas Lee 2006-11-17
估算的不准确不要紧,关键是每次都要有进步。这样可以逐渐逼近。
Godlikeme 2006-11-17
充分了解新工作的内容和要求,细化成小任务,评估其中的难点,区分常量时间工作(重复劳动)和突破性工作(需要研究的),需要考虑自己的研究问题能力。
一般先做一个乐观时间估计,就是假设不遇到较大技术和业务难点。视工作重要程度,越重要的工作估计时间越长(可能遇到问题的可能性越大)。普通工作是乐观时间的两倍,重要工作是乐观时间的3-4倍。
个人感觉还是比较合理的。
clamp 2006-11-17
毫无疑问,正确的估算首先应当来自技术主管和项目经理的认识
然而,如果技术主管和项目经理缺乏这个认识,作为程序员的自我判断是否有其必要呢?

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

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

做法很简单,自己做一个对照表,列明任务、自我估计工作量、实际工作量、误差、原因等。工作量最好精确到小时。
不断的进行总结和改进,估算的能力必定会有大幅度的提升。
tuti 2006-11-17
PERT法, 改进delphi法.
wolfsquare 2006-11-17
1.把需求明确,全组讨论,产生可随时查看的文档
2.新技术统一一个适应期,在这适应期内加强交流
3.压力只来自自己承诺的期限压力,项目压力是PM承担的
4.程序员不应该承担不属于他那部分的风险,一般来说,到了这一级风险都是可以接受的了
5.有些人善于交流,而有些则相反,这些要靠PM来协调
6.达成变化是需要的共识
7.效率问题有些复杂,需要具体分析
8,9.属于PM沟通和引导的问题
yuxie 2006-11-17
我现在的估算方法是:

工期 = 领导定的工期 * 3
clamp
搜索本博客
存档
最新评论
  • 数学和软件
    对我们一般程序员来讲,如果将两者结合起来,是有相当难度的。不但要掌大量高等数学知 ...
    -- by blackanger
  • 数学和软件
    我觉得软件开发有个三个主要问题:做什么;怎么做;为什么这么做。数学有助于后两个问 ...
    -- by cookoo
  • 数学和软件
    hurricane1026 写道庄表伟 写道数学<>逻辑学 软件开发,更 ...
    -- by cookoo
  • 数学和软件(3)——从勾股 ...
    不否认软件和数学有一定的关系,但是这样的对应关系是不是有点牵强了。。。 。。。 ...
    -- by blackanger
  • 数学和软件
    我的理解是: 数学好的人,可以把软件用纯数学的语言来描述,这种方式也许只能数学水 ...
    -- by blackanger