根据经验估算项目持续时间

Question

什么是常见经验公式，可以对瀑布方法的项目持续时间进行粗略估计（可接受高达20％的波动）。如果它有助于缩小答案，你可以假设以下是多了还是少为人知的：

1. 是已知的和固定的开发者的数量，大多数开发者都在知识方面高于平均水平，但一些学习关于特定领域的问题可能是必需的。

2. 已知和固定最大。应用用户数量。

3. 要使用的技术堆栈合理多样（最多4种不同的语言和最多6种不同的平台）。

4. 预计可与最多三个遗留系​​统连接。

请随意提供覆盖范围比上述要宽的范围的估算方法，它们仅供基本指导。

Answer 1

请你帮个忙，拿起史蒂夫·麦康奈尔的Software Estimation: Demystifying the Black Art。如果您有权访问过去的估算值和实际值，这可以大大有助于产生有用的估计值。否则，我推荐这本书，并从中找出最适合您情况的策略。

Answer 2

只希望利用70％的开发者时间。另外30％将用于会议，回复电子邮件，乘坐电梯等。例如，如果他们每天工作8小时，他们将只能够每天编程5.6到6.5小时。如果他们在人们使用电话的嘈杂环境中工作，请减少此数量。

对开发人员给项目经理的任何估算值加20％。

代码行在估算项目时没有用处。

成功或失败取决于客户的简要要求。如果要求不完整，请指望客户对成品不满意。

指望并不是所有的要求都会由客户决定。整个项目的需求将会有所修改。

Answer 3

第1步。创建一个尽可能粒度合理的时间表。
第2步。询问相关人员他们的功能需要多长时间。
第3步。创建一个将预测映射到实际时间的Excel电子表格。
第4步。对所有新项目重复步骤1-3。利用第3步的先前实例的汇总映射将开发者估算转换为实际估算值。

请注意，有些工具可以为您做到这一点。

另请参见 Evidence-based-scheduling。

Answer 4

这个项目不会很便宜...

是已知的和固定的开发者数目， 大多数开发者都在条款诀窍 高于平均水平，但是关于特定领域的问题的一些学习 可能需要 。

这是一件好事。你不想让开发人员涌入项目。虽然如果你高于10人左右，那么每2人只能计为1人，因为其余的人都会在头顶上升。除非你可以将任务分解成两个完全独立的团队可以处理的事情。那么你可能有机会获得一些牵引力。

已知和固定最大。用户数 。

这意味着您可以更确定地在早期着陆您的架构，因为您可以估计您必须付出多大的努力来扩展您的解决方案。这是一件好事。确保你在这些限制范围内工作，永远不要让自己陷入“足够快”的思维。它几乎从未是，如果你怀疑它可能是太慢了......

将使用的技术堆栈 合理多样（最多4种不同的 语言和多达6个不同的 平台）。

这不像你的人知道这个堆栈/语言集合那么重要吗？如果有任何学习涉及，如果您没有事先进行概念验证以了解技术，请提高x2或x3。或者更好的是，承受痛苦并获得一些提示。如果实施或使用的技术的语言是未知的，那么很可能你会滥用这项技术并做一些事情来搞砸。

确保技术已被证实，否则您最终会被它咬住。

• 该工具/技术是否可用来源？
• 你获得支持？
• 您是否理解产品并且或之前使用了它？
• 有客户使用过吗？

如果太多这些问题得到一个否，那么在总和上增加一些（或很多）额外的时间。

预计可连接多达三个传统 系统。

这真是一个踢球者。对于传统整合问问自己：

• 是否有其他人与他们整合？
• 您是否有机会了解这些系统的知识？
• 他们是否打算与您分享这些知识？
• 您是否必须等待这些系统中创建的更改？
• 是否有可供您使用的测试系统？
• 有没有可供您使用的开发系统？

同样，如果这些问题中有太多问题对他们有“否”，那么就要害怕。你也应该知道实际的整合需要比实际想象的长3-5倍。

这不是一个项目，我会给一个表抓取估计。做你自己和你的客户的忙，并按小时做这件事。如果不是这样，那么随着时间的推移，你将开始偷工减料以掩盖你缺乏进展/低估的情况......而且你和你的顾客都会受苦。

Answer 5

有许多成本估算软件工具可以大大缓解成本估算的痛苦，我们使用ProjectCodeMeter。我知道这些工具并不完美，但他们通过指向正确的方向确实节省了时间。

Try this list of estimation tools on Wikipedia。