Do yourself a favor and pick up Steve McConnell's Software Estimation: Demystifying the Black Art. If you have access to past estimates and actuals this can greatly aid in producing a useful estimate. Otherwise I recommend this book and identifying a strategy from it most applicable to your situation.
Only expect to utilize 70% of your developers time. The other 30% will be spent in meetings, answering email, taking the elevator, etc. For example if they work 8hrs a day, they will only be able to code for 5.6 to 6.5 hours a day. Reduce this number if they work in a noisy environment where people are using the telephone.
Add 20% to any estimate a developer gives the project manager.
Lines of code is useless as a metric in estimating a project.
Success or failure depends on concise requirements from the customer. If the requirements aren't complete, count on the customer being not happy with the finished product.
Count on the fact that not all of the requirements will be dictated by the customer. There will be revisions to the requirements throughout the project.
Step 1. Create a schedule that is as granulated as is reasonably possible. Step 2. Ask the people involved how long their features will take. Step 3. Create an Excel spreadsheet which maps predictions to actual times. Step 4. Repeat steps 1-3 for all new projects. Make use of an aggregated mapping from previous instances of step 3 to translate developer estimates to actual estimates.
Note that there are tools which can do this for you.
Number of devs is known and fixed, most devs are above average in terms of know-how, however some learning about domain-specific issues might be required.
This is a good thing. You don't want to flood the number of developers into the project. Though if you go above around 10 people, do count every 2 as only 1, as the rest will go up in overhead. Unless you can split the task into something that can be handled by two totally separate teams. Then you could have a chance of getting some traction.
Known and fixed max. number of app users.
This means that you can with more certainty land your architecture early on, as you can estimate how much effort you must put into scaling your solution. This is a good thing. Make sure that you work within these limits and never ever fool yourself into thinking "it's fast enough". It almost never is if you doubt that it could be too slow...
Technology stack to be used is reasonably diverse (up to 4 different languages and up to 6 various platforms).
This isn't as important as to do your people know this stack/set of languages? If there are any learning involved, raise the estimate x2 or x3 if you don't perform a proof of concept up front to learn the technology. Or even better, take the pain and get some coursing. If the language for implementation or technology to be used is unknown, then it is quite likely that you will misuse the technology and do things that will screw stuff up.
Make sure that the technology is proven or you'll end up getting bitten by it.
Are the source available for the tools/technology?
Do you get support?
Do you understand the product and or used it before?
Have the customer used it before?
If too many of these questions get a no, add some (or a lot of) additional time to the sum.
Interfacing to up to three legacy systems is expected.
This is really a kicker. For legacy integration ask yourself:
Has anyone else integrated with them?
Do you have access to people with knowledge of these systems?
Do they intend to share this knowledge with you?
Do you have to wait for changes being created in these systems?
Are there test systems available for you to use?
Are there development systems available for you to use?
Again, if too many of these questions has a "no" on them, then be afraid. You should also know that actual integration takes about 3-5 times longer than you actually think.
This isn't a project that I would have given a table grabbing estimate for. Do yourself and your customer a favor and do this by the hour. If not, you will as times go by start cutting corners to cover up your lack of progress/underestimation... And both you and your customer will suffer.
There are many cost estimation software tools that can greatly ease the pain of cost estimation, we use ProjectCodeMeter. I know these tools are not perfect, but they do save time getting started by pointing towards the right direction.
发布评论
评论（5）
帮自己一个忙，拿起 Steve McConnell 的软件估算：揭秘黑魔法< /a>。如果您可以访问过去的估计和实际情况，这可以极大地帮助您做出有用的估计。否则，我会推荐这本书，并从中找出最适合您情况的策略。
Do yourself a favor and pick up Steve McConnell's Software Estimation: Demystifying the Black Art. If you have access to past estimates and actuals this can greatly aid in producing a useful estimate. Otherwise I recommend this book and identifying a strategy from it most applicable to your situation.
仅期望利用开发人员 70% 的时间。另外30%将用于开会、回复邮件、乘电梯等。例如，如果他们每天工作8小时，那么他们每天只能编码5.6到6.5小时。如果他们在人们使用电话的嘈杂环境中工作，请减少此数字。
在开发人员向项目经理提供的任何估算的基础上加上 20%。
代码行数作为评估项目的指标是没有用的。
成功或失败取决于客户的简洁要求。如果要求不完整，客户可能会对成品不满意。
请相信，并非所有要求都由客户决定。整个项目的要求将会有所修改。
Only expect to utilize 70% of your developers time. The other 30% will be spent in meetings, answering email, taking the elevator, etc. For example if they work 8hrs a day, they will only be able to code for 5.6 to 6.5 hours a day. Reduce this number if they work in a noisy environment where people are using the telephone.
Add 20% to any estimate a developer gives the project manager.
Lines of code is useless as a metric in estimating a project.
Success or failure depends on concise requirements from the customer. If the requirements aren't complete, count on the customer being not happy with the finished product.
Count on the fact that not all of the requirements will be dictated by the customer. There will be revisions to the requirements throughout the project.
步骤 1. 创建一个尽可能细化的计划。
第 2 步：询问相关人员他们的功能需要多长时间。
步骤 3. 创建一个 Excel 电子表格，将预测映射到实际时间。
步骤 4. 对所有新项目重复步骤 1-3。利用步骤 3 的先前实例的聚合映射将开发人员的估计转换为实际估计。
请注意，有一些工具可以为您执行此操作。
Step 1. Create a schedule that is as granulated as is reasonably possible.
Step 2. Ask the people involved how long their features will take.
Step 3. Create an Excel spreadsheet which maps predictions to actual times.
Step 4. Repeat steps 1-3 for all new projects. Make use of an aggregated mapping from previous instances of step 3 to translate developer estimates to actual estimates.
Note that there are tools which can do this for you.
这个项目不会便宜...
这是一件好事。您不想让大量的开发人员涌入该项目。不过，如果人数超过 10 人左右，请务必将每 2 人算作 1 人，因为其余的人会增加开销。除非你可以将任务分成可以由两个完全独立的团队处理的任务。那么你就有机会获得一些关注。
这意味着您可以更确定地尽早确定您的架构，因为您可以估计必须投入多少精力来扩展您的解决方案。这是一件好事。确保您在这些限制内工作，并且永远不要自欺欺人地认为“它已经足够快了”。如果您怀疑它可能太慢，那几乎永远不会......
这并不重要，重要的是您的员工是否了解这组语言/一组语言？如果涉及任何学习，如果您不预先进行概念验证来学习该技术，则将估计提高 2 倍或 3 倍。或者更好的是，承受痛苦并进行一些训练。如果实现的语言或要使用的技术未知，那么您很可能会滥用该技术并做出一些会搞砸的事情。
确保该技术经过验证，否则您最终会被它咬住。
如果这些问题中有太多答案为“否”，请在总和中添加一些（或大量）额外时间。
这确实是一个踢球者。对于遗留集成，问问自己：
再说一遍，如果太多的问题都是“不”，那就要害怕。您还应该知道，实际的集成时间比您实际想象的时间大约长 3-5 倍。
这不是一个我会给出抢桌估算的项目。为你自己和你的客户一个忙，按小时做这件事。如果没有，随着时间的推移，您将开始偷工减料，以掩盖您缺乏进展/低估的情况……您和您的客户都会遭受损失。
This project is not going to be cheap...
This is a good thing. You don't want to flood the number of developers into the project. Though if you go above around 10 people, do count every 2 as only 1, as the rest will go up in overhead. Unless you can split the task into something that can be handled by two totally separate teams. Then you could have a chance of getting some traction.
This means that you can with more certainty land your architecture early on, as you can estimate how much effort you must put into scaling your solution. This is a good thing. Make sure that you work within these limits and never ever fool yourself into thinking "it's fast enough". It almost never is if you doubt that it could be too slow...
This isn't as important as to do your people know this stack/set of languages? If there are any learning involved, raise the estimate x2 or x3 if you don't perform a proof of concept up front to learn the technology. Or even better, take the pain and get some coursing. If the language for implementation or technology to be used is unknown, then it is quite likely that you will misuse the technology and do things that will screw stuff up.
Make sure that the technology is proven or you'll end up getting bitten by it.
If too many of these questions get a no, add some (or a lot of) additional time to the sum.
This is really a kicker. For legacy integration ask yourself:
Again, if too many of these questions has a "no" on them, then be afraid. You should also know that actual integration takes about 3-5 times longer than you actually think.
This isn't a project that I would have given a table grabbing estimate for. Do yourself and your customer a favor and do this by the hour. If not, you will as times go by start cutting corners to cover up your lack of progress/underestimation... And both you and your customer will suffer.
有很多成本估算软件工具可以大大减轻成本估算的痛苦，我们使用ProjectCodeMeter。我知道这些工具并不完美，但它们确实通过指向正确的方向来节省入门时间。
尝试一下 Wikipedia 上的估算工具列表。
There are many cost estimation software tools that can greatly ease the pain of cost estimation, we use ProjectCodeMeter. I know these tools are not perfect, but they do save time getting started by pointing towards the right direction.
Try this list of estimation tools on Wikipedia.