过去几个月我一直在研究 Flex,因为这是我第一次真正做 Flex,我最终低估了导致延迟的项目任务。那么,在研究一项新技术时,如何估计项目时间呢?
12 回答
你不能。
你必须把它当作研究,而研究是无法估计的。
在承诺在特定日期交付任何东西之前,我会给自己一段固定的时间来试验和学习新技术。
在第一个阶段之后,做一些粗略的估计,并确保你的上级知道他们到底有多粗略。
使用霍夫施塔特定律:
即使考虑到霍夫施塔特定律,它也总是比您预期的要长。
当我在一个项目中将一个中型开发团队切换到 .Net 时,可以估计完全转换的唯一方法是允许初始研究阶段。这使一些开发人员能够熟悉该技术并完全实现一小部分功能。我发现按照生产标准完成的系统部分非常重要。
还讨论了聘请熟悉该技术的顾问。出于成本考虑,我们决定不这样做,但我认为让有 .NET 项目经验的人为我们指明正确的方向会非常有帮助。
唯一要补充的一点是,当您从事这种性质的项目时,重要的是还要估计让其他开发人员跟上进度所需的时间。显然,这将少于研究阶段所花费的时间。尽管开发原型的开发人员应该随时准备帮助那些现在正在采用新技术的人。
总结一下:
- 您需要给自己时间来掌握新的技术,然后才能给出真实的估计。
- 您需要根据整个项目的经验,根据生产标准进行估算。
- 不要害怕聘请有经验的承包商,以便快速学习最佳实践。
- 不要忘记,每个人都需要学习这项技术,然后才能了解生产代码。
我还建议查看此线程:有人使用功能点吗?
功能点是一种“行业标准”(无论这意味着什么),用于估计做某事需要多长时间。在大多数情况下,他们试图绘制出程序的功能,然后你将它们放入这样的算法中:
long GetManHoursForProject()
{
long Count_of_Function_Points = GetFunctionPointCountFromAnalyticalPhaseOfSDLC();
double Average_Complexity = 1; // .8 for easy, 1 for normal, 1.2 for hard
long Programming_Language = 130; // for C++ (higher level languages have higher values)
double Man_Months = Count_of_Function_Points * Programming_Language * Average_Complexity;
long Man_Hours = Man_Months * 20 * 8; // 20 days per month, 8 hours per day
return Man_Hours;
}
我从上面链接到的主题讨论了故事板积分,这本身就是一个有趣的对话。我会研究这两个主题,以找到适合您的主题。
功能点和故事板点的好处是它们有一个语言乘数。所有语言都使用相同的思维方式。
如果您正在学习一门新语言,那么您的特定系统的复杂性会更高。
我通常分别估算学习时间和实施时间。即我估计这个项目,就好像我知道我在做什么基于它的困惑,然后试着估计我学习新技术可能需要的时间。
不久前,我不得不在 Flex 中开展一个项目,而我之前从未使用过 Flex(或 Flash)。我还被迫在这个 Flex 应用程序中使用某个第 3 方小部件库。我估计了我认为使用 Java 这样的合理语言需要多长时间,然后大约将其翻倍以考虑学习一门新语言。问题是,Flex 不合理,没有文档记录,标准库中有很多错误,显然我们的 3rd-party 库把标准库的所有设计特性都牢记在心,因为它也非常破碎的。我们最终得到了一个性能很差的产品,只有一半的功能和分配的时间。值得庆幸的是,管理层允许我们继续研究它一段时间(他们一直在改变要求,所以他们欠我们那么多),我们把它变成了非常好的状态。它仍然没有完成我们想要的一切,但是我们解决了大多数库错误,包括缓解最糟糕的性能问题(即,实例化 UIComponent 需要很长时间,所以与其在启动时全部完成,我们按需执行。这与我们的 3rd 方库无关)。
所以,简而言之:
- 总是估计大量的启动时间来学习一个新系统。除了学习语言,你还需要学习特质。这可能无法准确估计
- 尽可能避免使用 Flex。我无法想象直接 Flash 会更好,因为它们共享库的很大一部分。
我的经验法则是将您认为需要的时间加倍。我发现你总是会遇到一些需要时间来解决的意想不到的问题。
我想对于一定规模的项目,给自己一些时间来制作一个相当简单但仍然完整且不平凡的项目的某些代表性部分的原型。然后,您将有一些时间来使用该技术,并获得有关使用它创建东西所需时间的宝贵见解。
当我过去使用一项新技术时(即,当新技术成为项目交付的核心时),我将其估计为:
New Project Time = Project Time * 1.5
...但不用说,这是经验法则和 YMMV。
你可以做的一件事——除了雇佣或不估计——是估计你的任务的相对复杂性,然后将实际实施时间与复杂程度进行比较。随着时间的推移,该比率将趋于稳定值。
现在,我遇到了像你这样的问题。在这里阅读这些评论后,我认为属于要深入了解新技术的级别。首先,只是在短时间内将新技术作为原始(草图)进行研究,之后已经有分解工作,所以现在只需按顺序进行优先级和更深入的研究。
我希望这很有用。