代码之家  ›  专栏  ›  技术社区  ›  Firoz

如何估计研究和开发任务的时间线[已关闭]

  •  1
  • Firoz  · 技术社区  · 16 年前

    在估计研究和开发任务的时间时,应注意哪些要点。假设我必须使用“wpf”技术来估计“abc”任务,而且我没有这方面的经验,我需要为它进行一些研发。

    5 回复  |  直到 16 年前
        1
  •  3
  •   Mathias    16 年前

    在你有时间使用这项技术之前,不要给出一个估计。分配一定的时间(2天,1周,无论你能从管理层得到什么)来理解这些概念,并自己编写一些代码,以了解开发过程需要什么以及学习曲线有多陡。然后,估计。

        2
  •  2
  •   CesarGon    16 年前

    理想情况下,没有确凿的证据就不应该给出估计。毕竟,一个估计是一个概率,概率在数学上是重要的数字,而不是从稀薄的空气中获得的直觉。(见 "Software Estimation" by Steve McConnell 了解更多信息。)

    不幸的是,我们经常被要求提供任务的估计值,对于这些任务,我们将涉及到的技术具有很大的不确定性。例如,政府补助和其他非技术方案就是这样。在这些情况下,出于务实的考虑,即使我们不熟悉这些技术,也最好提供一个估计。

    我经常使用的技术包括 uncertainty cones timeboxed development .

    希望这有帮助。

        3
  •  2
  •   Community Mohan Dere    9 年前

    纯研究项目

    除了一些临时里程碑/审查之外,还要设置一个时间或资源上限,以重新评估您是否负担得起继续。理想情况下,在开始研究之前,你会对成功的潜在好处有一个很好的了解。在开始之前,你可能还需要定义不同的成功等级和一个应急计划,以防努力没有实现。

    Spiral model 发展会很方便。

    将现有技术应用于问题

    对于当前的主流技术,如WPF,您可能会试图找出有类似经验的人学习该技术需要多长时间。可以从其他人的经验和可用的培训课程中收集证据。

    对于非当前或利基技术,你最好雇佣顾问或转包工作(记住 the difference between consultant and contractor )

    为项目评分

    保持现状-修复缺陷-增强-新功能-新产品-革命性

    比例。规模上的每个头寸通常意味着风险和努力增加2.5倍。有一个参考点,也就是说,如果在您的组织中,端到端地修复一个bug通常需要2天时间,您可以估计一个增强将需要2到5倍的时间,4到10天之间的任何时间,当然,编码将只是这项工作的一小部分。

        4
  •  1
  •   Dani    16 年前

    最好的方法是咨询已经去过那里的人。 他的经验加上对好的总体看法,他比你的员工应该给你一个公平的评价。

    技术越老,周围的人就越有经验,网上有更多的地方可以找到问题的答案。

    如果你在研究一些全新的东西…数据源应该是有限的,我将接受任何估计,并加倍…

        5
  •  0
  •   digiarnie    16 年前

    你可以猜测你认为研究新技术需要多长时间,然后你需要多长时间来进行开发,并将其乘以2。当然,这是相当蓬松的,但通常任何涉及评估任务的事情都是相当蓬松的(好吧,至少我不喜欢这样)。在评估时涉及到很多因素:它是否处理可能比您想象的要长的新技术,通常它涉及处理由其他人编写的代码,这些代码可能会给一个简单的任务增加一个“x”的复杂性因素。

    通常,在估计时间的时候,最好至少在你坐的地方有一个“尖峰”(无论是单独的,或者更好的是与其他团队成员一起)和一到两个小时(或者你选择的时间长短)的比赛。这至少给了你一点时间,以便更好地了解你正在处理的问题。当你看新技术的时候,也许读一点doco,阅读和玩“入门”指南等。然后当你回到评估表,你会对你正在处理的事情有一个更好的了解。

    推荐文章