When I worked in a project to switch a medium sized development team to .Net the only way that a full conversion could be estimated was to allow an initial research phase. This allowed some developers to get familiar with the technology and implement, in full, a small part of the functionality. I found it very important that the part of the system that was worked on was completed to a production standard.
Something that was also discussed was hiring a consultant who was familiar with the technology. This was decided against because of cost but I think it would have been enourmously helpful to have someone who had experience of .NET projects to point us in the right direction.
The only other thing to add is that when you work on a project of this nature it is important to also estimate how long it will take to bring other developers up to speed. Obviously this will be less than the time that the research phase took. Though the developers who worked on the prototype should be on hand to help those who are now picking up the new technology.
To sum up:
You need to give yourself time to pick up the new tchnology before you can give real estimates.
You need to baseyour estimates on experience of a full project, to a production standard.
Don't be afraid of hiring a contractor with experience in order to learn best practices quickly.
Dont forget that everyone needs to learn this technology before they are let loose on procduction code.
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;
}
Function Points are an "industry standard" (whatever that means) for estimating how long it takes to do something. For a most part they try to map out what the program does, and THEN you put them into an algorythm like this:
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;
}
The thread I linked to from above talks about Story Board Points, which is an interresting conversation in and among itself. I would look into both of these subjects to find which one works for you.
The nice thing about function points and story board points is that they have a language multiplier. The same way of thinking is used for all languages.
If you are learning a new language, then the complexity would be higher for your specific system.
I usually estimate the time spent learning and the time spent implementing separately. I.e. I estimate the project as if I knew what I was doing based on it's perplexity, but then try to estimate the time it might take me to learn the new technology.
Not too long ago, I had to work on a project in Flex and I had never used Flex (or Flash) before. I was also forced to use a certain 3rd party library of widgets in this Flex application. I estimated how long I thought it would take in a reasonable language like Java, then approximately doubled it to account for learning a new language. The problem was, Flex isn't reasonable, it isn't documented, there a number of bugs in the standard library, and apparently our 3rd-party library took all the design features of the standard library to heart, because it too was very broken. We ended up with a poorly performing product with half the features and over the allotted time. Thankfully, management allowed us to continue working on it for some time (they had been changing requirements, so they owed us that much) and we got it into really good shape. It still doesn't do everything we wanted, but we hacked our way around most of the library bugs, including mitigating the worst of the performance issues (namely, instantiating a UIComponent takes a LONG TIME, so instead of doing them all on startup, we do it as-needed. This is unrelated to our 3rd party lib).
So, in short:
Always estimate lots of spin-up time for learning a new system. Beyond learning the language, you need to learn the idiosyncrasies. This is probably impossible to accurately estimate
Avoid Flex if at all possible. I can't imagine straight Flash is any better, since they share a large part of the library.
My rule of thumb is to double the time you think it will take. I've found that you will always run into some unexpected problems that will take time to resolve.
I guess for projects of a certain size, give yourself some time to make a reasonably simple yet still complete and not trivial prototype of some representative part of your project. Then you will have some time to play with the technology, and also earn valuable insights with regards to the time it takes to create stuff with it.
When I've worked with a new technology in the past (i.e. when the new tech. has been central to the delivery of the project), I've had good results with estimating it as:
New Project Time = Project Time * 1.5
... but it goes without saying, this is a rule of thumb and YMMV.
One thing you can do - besides hiring someone or not estimating - is to estimate the relative complexity of your tasks and then compare the actual implementation time to the complexity level. Over time, the ratio will converge toward a stable value.
Now, I meet a problem like yours. After read these comments here, I think there belong to level which to want to be deep clear about new technology. As first, just research in a short time for new technology as raw( a sketch figure) after that there have a breakdown works already, so now just prioritize and research more deep by order.
发布评论
评论（12）
你不能。
你必须把它当作研究，而研究是无法估计的。
You can't.
You have to consider it as research, and research can't be estimated.
在承诺在特定日期交付任何内容之前，我会给自己一段时间来试验和学习新技术。
在第一阶段之后，做出一些粗略的估计，并确保你的上级知道他们的实际情况有多粗略。
I would give myself a set period of time to experiment with and learn the new technology before promising to deliver anything on a specific date.
After that first period, make some rough estimates, and make sure your superiors know how rough they really are.
使用霍夫施塔特定律：
Use Hofstadter's Law:
当我参与一个将中型开发团队切换到 .Net 的项目时，估计完全转换的唯一方法是允许初始研究阶段。 这使得一些开发人员能够熟悉该技术并完整地实现一小部分功能。 我发现系统中正在开发的部分按照生产标准完成非常重要。
还讨论了聘请一位熟悉该技术的顾问。 由于成本原因，我们决定不这样做，但我认为，如果有具有 .NET 项目经验的人为我们指明正确的方向，将会非常有帮助。
唯一需要补充的是，当您从事这种性质的项目时，估计需要多长时间才能让其他开发人员跟上进度也很重要。 显然，这将少于研究阶段所花费的时间。 不过，参与原型开发的开发人员应该随时为那些正在学习新技术的人提供帮助。
总结一下：
When I worked in a project to switch a medium sized development team to .Net the only way that a full conversion could be estimated was to allow an initial research phase. This allowed some developers to get familiar with the technology and implement, in full, a small part of the functionality. I found it very important that the part of the system that was worked on was completed to a production standard.
Something that was also discussed was hiring a consultant who was familiar with the technology. This was decided against because of cost but I think it would have been enourmously helpful to have someone who had experience of .NET projects to point us in the right direction.
The only other thing to add is that when you work on a project of this nature it is important to also estimate how long it will take to bring other developers up to speed. Obviously this will be less than the time that the research phase took. Though the developers who worked on the prototype should be on hand to help those who are now picking up the new technology.
To sum up:
有人使用功能点吗？
我还建议查看此线程： Does 积分是一个“行业标准”（无论这意味着什么），用于估计完成某件事需要多长时间。 在大多数情况下，他们尝试绘制程序的功能，然后将它们放入这样的算法中：
我从上面链接到的线程讨论了故事板点，这本身就是一个有趣的对话。 我会研究这两门学科，看看哪一门适合你。
功能点和故事板点的好处是它们具有语言倍增器。 所有语言都使用相同的思维方式。
如果您正在学习一门新语言，那么您的特定系统的复杂性会更高。
I also recommend looking at this thread: Does anyone work with Function Points?
Function Points are an "industry standard" (whatever that means) for estimating how long it takes to do something. For a most part they try to map out what the program does, and THEN you put them into an algorythm like this:
The thread I linked to from above talks about Story Board Points, which is an interresting conversation in and among itself. I would look into both of these subjects to find which one works for you.
The nice thing about function points and story board points is that they have a language multiplier. The same way of thinking is used for all languages.
If you are learning a new language, then the complexity would be higher for your specific system.
我通常会分别估算学习时间和实施时间。 也就是说，我估计这个项目就好像我知道自己在做什么，基于它的困惑，但然后尝试估计我学习新技术可能需要的时间。
I usually estimate the time spent learning and the time spent implementing separately. I.e. I estimate the project as if I knew what I was doing based on it's perplexity, but then try to estimate the time it might take me to learn the new technology.
不久前，我必须在 Flex 中处理一个项目，而我之前从未使用过 Flex（或 Flash）。 我还被迫在此 Flex 应用程序中使用某个第三方小部件库。 我估计了我认为使用 Java 这样的合理语言需要多长时间，然后将其大约加倍以考虑学习一门新语言。 问题是，Flex 不合理，没有文档记录，标准库中存在许多错误，显然我们的第 3 方库牢记了标准库的所有设计功能，因为它也非常破碎的。 我们最终得到了一个性能很差的产品，只有一半的功能并且超出了规定的时间。 值得庆幸的是，管理层允许我们继续研究一段时间（他们一直在改变需求，所以他们欠我们很多），我们把它变成了非常好的状态。 它仍然没有完成我们想要的一切，但我们解决了大多数库错误，包括减轻最糟糕的性能问题（即，实例化 UIComponent 需要很长时间，因此不是在启动时全部完成，我们根据需要进行操作。这与我们的第 3 方库无关）。
因此，简而言之：
Not too long ago, I had to work on a project in Flex and I had never used Flex (or Flash) before. I was also forced to use a certain 3rd party library of widgets in this Flex application. I estimated how long I thought it would take in a reasonable language like Java, then approximately doubled it to account for learning a new language. The problem was, Flex isn't reasonable, it isn't documented, there a number of bugs in the standard library, and apparently our 3rd-party library took all the design features of the standard library to heart, because it too was very broken. We ended up with a poorly performing product with half the features and over the allotted time. Thankfully, management allowed us to continue working on it for some time (they had been changing requirements, so they owed us that much) and we got it into really good shape. It still doesn't do everything we wanted, but we hacked our way around most of the library bugs, including mitigating the worst of the performance issues (namely, instantiating a UIComponent takes a LONG TIME, so instead of doing them all on startup, we do it as-needed. This is unrelated to our 3rd party lib).
So, in short:
我的经验法则是，将你认为需要的时间加倍。 我发现你总会遇到一些意想不到的问题，需要时间来解决。
My rule of thumb is to double the time you think it will take. I've found that you will always run into some unexpected problems that will take time to resolve.
我想对于一定规模的项目，给自己一些时间来为项目的某些代表性部分制作一个相当简单但仍然完整且不平凡的原型。 然后，您将有一些时间来使用该技术，并获得有关使用该技术创建内容所需时间的宝贵见解。
I guess for projects of a certain size, give yourself some time to make a reasonably simple yet still complete and not trivial prototype of some representative part of your project. Then you will have some time to play with the technology, and also earn valuable insights with regards to the time it takes to create stuff with it.
当我过去使用新技术时（即当新技术成为项目交付的核心时），我取得了良好的结果，并将其估计为：
......但不言而喻，这是一条经验法则，YMMV。
When I've worked with a new technology in the past (i.e. when the new tech. has been central to the delivery of the project), I've had good results with estimating it as:
... but it goes without saying, this is a rule of thumb and YMMV.
除了雇用某人或不进行估计之外，您可以做的一件事是估计任务的相对复杂性，然后将实际实施时间与复杂性级别进行比较。 随着时间的推移，该比率将趋于稳定值。
One thing you can do - besides hiring someone or not estimating - is to estimate the relative complexity of your tasks and then compare the actual implementation time to the complexity level. Over time, the ratio will converge toward a stable value.
现在，我遇到了像你这样的问题。 读完这里的这些评论后，
我认为对于新技术有一个想要深入了解的层次。
首先，在短时间内对新技术进行原始研究（草图），之后已经有了分解工作，所以现在只需按顺序优先考虑并进行更深入的研究。
我希望这有用。
Now, I meet a problem like yours. After read these comments here,
I think there belong to level which to want to be deep clear about new technology.
As first, just research in a short time for new technology as raw( a sketch figure) after that there have a breakdown works already, so now just prioritize and research more deep by order.
I hope this is useful.