如果是这样的话？多少？
我倾向于夸大我的一点因为我可能过于乐观.
Hofstadter定律:任何计算项目都需要两倍的时间 - 即使考虑到Hofstadter定律.
如果你根据过去的经验夸大你的估计来试图弥补你固有的乐观情绪,那么你就不会膨胀.您正在尝试提供准确的估算.但是,如果你膨胀使你总是有绒毛时间,那就不那么好了.
哦,是的,我已经学会了将我的初始估计值乘以2.这就是为什么FogBUGZ的循证调度工具非常有用.
任何要求其程序员估计粗粒度特征时间的组织都从根本上被打破.
破裂的步骤:
聘请技术项目经理.如果需要,开发人员可以像这些人一样加倍.
当任何功能请求,更改请求或错误进入时立即将其放入数据库中.(我的组织使用Trac,它并不完全糟糕.)
让您的PM将这些请求分解为每个需要一周或更短时间的步骤.
在每周一次的会议上,您的PM决定他们希望在那一周完成哪些门票(可能需要营销方面的投入等).他们将这些门票分配给开发者.
开发人员尽可能多地完成分配的票证.和/或,他们与PM讨论他们认为持续时间超过一周的任务.根据需要调整,拆分,重新分配门票等.
代码每周都会被编写和检查.QA总是有事可做.优先级最高的更改首先完成.市场营销人员确切知道管道即将发生什么,以及何时.最终:
您的公司属于软件项目成功率20%的右侧.
这不是火箭科学.关键是第3步.如果市场营销需要看起来很复杂的东西,那么你的PM(有开发者输入)就会知道第一步是不到一周.如果PM不是技术人员,则全部丢失.
这种方法的缺点:
当营销问道,"获得[X]需要多长时间？"时,他们没有得到估计.但我们都知道,他们之前得到的估计也是纯粹的虚构.至少现在他们每周都可以看到[X]正在进行的证据.
作为开发人员,我们每周工作的选项较少.这无疑是真的.但有两点:首先,优秀团队让开发人员参与决定将分配门票的决定.第二,IMO,这实际上让我的生活更美好.
没有什么比在1个月的时间里意识到的那样令人沮丧的是,我给出的2个月的估计是无可救药的,但是无法改变,因为它已经在官方营销文献中了.我要么通过改变我的估计来惹恼上级,冒着糟糕的评论和/或错过我的奖金,要么我做了很多无偿的加班.我已经意识到,很多加班不是一个糟糕的开发者的标志,或者是一个"热情的"标志 - 它是有毒文化的产物.
是的,很多这些东西都包含在(各种)XP,"敏捷","SCRUM"等中,但它并不是那么复杂.您不需要书籍或顾问来完成它.你只需要企业意愿.
Scotty规则:
做出最好的猜测
四舍五入到最接近的整数
两倍(感谢亚当!)
增加到下一个更高的计量单位
例:
你认为这需要3.5个小时
那圈到4个小时
四倍到16小时
将它改为16天
TA-DAA!当你在不到8天的时间内完成它时,你就是一个奇迹工作者.
我能在3-6周内回答这个问题.
通常是的,但我有两个策略:
始终将估计值作为范围(即1d-2d)而不是单个数字提供.数字之间的差异告诉项目经理一些关于你的信心,并允许他们更好地计划.
使用FogBugz的"基于证据的计划 "或个人电子表格来比较您的历史估计值和实际拍摄时间.这会给你一个更好的想法,而不是总是加倍.尤其是因为加倍可能还不够!
它不被称为"膨胀" - 它被称为"使它们远程逼真".
采取您认为合适的估计值.然后翻倍.
不要忘记你(工程师)实际估计的理想时间(scrum术语).
管理工作在实时工作.
不同之处在于理想时间是没有中断的时间(每次中断后30分钟预热).理想的时间不包括会议时间,午餐时间或正常聊天等.
考虑所有这些因素,理想的工作时间将趋于实时.
示例:预计时间40小时(理想)管理将假设为1周实时.
如果您将40小时转换为实时:
假设每天一次会议(持续时间1小时)
每天午休一次(1小时)
加上20%的开销用于聊天浴室休息,以获得coffie等.
现在8小时工作时间是5小时(8 - 会议 - 午餐 - 热身).
时间80%效率=每天理想时间4小时.
您的40小时理想将需要80小时实时完成.
柯克:斯科特先生,你的维修估计数总是增加四倍吗？
斯科蒂:当然,先生.我还能如何保持自己作为奇迹工作者的声誉？
一个好的经验法则是估计需要多长时间,并再次增加1/2以解决以下问题:
要求会改变
您将被拉到另一个项目以进行快速修复
下一桌的新人需要帮助
重构项目部分所需的时间,因为您找到了更好的方法
不是夸大项目的估算,而是单独夸大每项任务.你的上司很难以这种方式挑战你的估计,因为谁会在几分钟内与你争论.
但严重的是,通过使用EBS,我发现人们通常比估算小型任务要好得多.如果你估计你的项目在4个月,它可能在完成之前7个月; 或者它可能不会.另一方面,如果你对任务的估计是35分钟,那通常是正确的.
FogBugz的EBS系统向您显示您的估计历史图表,根据我的经验(同时查看其他人的图表),人们在估算短期任务方面确实要好得多.所以我的建议是从你的项目的伏都教乘法转换为总数,并开始将它们预先分解为许多非常小的任务,你可以更好地估算.
然后将整个事物乘以3.14.
很大程度上取决于您希望获得的详细程度 - 但额外的"缓冲"时间应基于风险评估 - 在任务级别,您可以在其中放置以下各种缓冲时间:高风险:50%至100%中等风险: 25%至50%低风险:10%至25%(均取决于之前的项目经验).
风险领域包括:
需求覆盖范围(#1风险区域缺少设计和要求水平的组件)
所使用的技术知识
知识/对您资源的信心
外部因素,如影响您的其他项目,资源变化等.
因此,对于涵盖组件A的给定任务(或任务组),初始est为5天,并且根据需求覆盖率被认为是高风险 - 您可以添加50%到100%
六个星期.
行业标准:每个请求需要六周时间.有些会更长,有些会更短,最后一切都是平均的.
此外,如果你等待足够长的时间,它就不再成为一个问题.我不能告诉你我多少次经历过那次火爆只是为了让项目/功能减少.
京公网安备 11010802040832号 | 京ICP备19059560号-6 