|
|
1
3
在你有时间使用这项技术之前,不要给出一个估计。分配一定的时间(2天,1周,无论你能从管理层得到什么)来理解这些概念,并自己编写一些代码,以了解开发过程需要什么以及学习曲线有多陡。然后,估计。 |
|
|
2
2
理想情况下,没有确凿的证据就不应该给出估计。毕竟,一个估计是一个概率,概率在数学上是重要的数字,而不是从稀薄的空气中获得的直觉。(见 "Software Estimation" by Steve McConnell 了解更多信息。) 不幸的是,我们经常被要求提供任务的估计值,对于这些任务,我们将涉及到的技术具有很大的不确定性。例如,政府补助和其他非技术方案就是这样。在这些情况下,出于务实的考虑,即使我们不熟悉这些技术,也最好提供一个估计。 我经常使用的技术包括 uncertainty cones 和 timeboxed development . 希望这有帮助。 |
|
|
3
2
纯研究项目 除了一些临时里程碑/审查之外,还要设置一个时间或资源上限,以重新评估您是否负担得起继续。理想情况下,在开始研究之前,你会对成功的潜在好处有一个很好的了解。在开始之前,你可能还需要定义不同的成功等级和一个应急计划,以防努力没有实现。 Spiral model 发展会很方便。 将现有技术应用于问题 对于当前的主流技术,如WPF,您可能会试图找出有类似经验的人学习该技术需要多长时间。可以从其他人的经验和可用的培训课程中收集证据。 对于非当前或利基技术,你最好雇佣顾问或转包工作(记住 the difference between consultant and contractor ) 为项目评分 保持现状-修复缺陷-增强-新功能-新产品-革命性 比例。规模上的每个头寸通常意味着风险和努力增加2.5倍。有一个参考点,也就是说,如果在您的组织中,端到端地修复一个bug通常需要2天时间,您可以估计一个增强将需要2到5倍的时间,4到10天之间的任何时间,当然,编码将只是这项工作的一小部分。 |
|
|
4
1
最好的方法是咨询已经去过那里的人。 他的经验加上对好的总体看法,他比你的员工应该给你一个公平的评价。 技术越老,周围的人就越有经验,网上有更多的地方可以找到问题的答案。 如果你在研究一些全新的东西…数据源应该是有限的,我将接受任何估计,并加倍… |
|
|
5
0
你可以猜测你认为研究新技术需要多长时间,然后你需要多长时间来进行开发,并将其乘以2。当然,这是相当蓬松的,但通常任何涉及评估任务的事情都是相当蓬松的(好吧,至少我不喜欢这样)。在评估时涉及到很多因素:它是否处理可能比您想象的要长的新技术,通常它涉及处理由其他人编写的代码,这些代码可能会给一个简单的任务增加一个“x”的复杂性因素。 通常,在估计时间的时候,最好至少在你坐的地方有一个“尖峰”(无论是单独的,或者更好的是与其他团队成员一起)和一到两个小时(或者你选择的时间长短)的比赛。这至少给了你一点时间,以便更好地了解你正在处理的问题。当你看新技术的时候,也许读一点doco,阅读和玩“入门”指南等。然后当你回到评估表,你会对你正在处理的事情有一个更好的了解。 |