经验估计项目持续时间[结束]

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

只希望利用70%的开发时间。另外30%将用于会议、回复电子邮件、乘电梯等。例如,如果他们每天工作8小时,他们每天只能编码5.6到6.5小时。如果他们在嘈杂的环境中工作,而人们正在使用电话,那么就减少这个数字。

给项目经理的任何估价加20%。

代码行在评估项目时作为度量标准是无用的。

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

要相信,并不是所有的需求都是由客户决定的。在整个项目中将对要求进行修订。

第一步。创建一个尽可能粒度合理的计划。
第二步。询问相关人员他们的功能需要多长时间。
第三步。创建一个将预测映射到实际时间的Excel电子表格。
第四步。对所有新项目重复步骤1-3。使用步骤3以前实例中的聚合映射将开发人员估算转换为实际估算。

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

另见 Evidence-based-scheduling .

这个项目不会便宜的。。。

已知和固定的dev数量, 大多数开发人员的表现都高于平均水平 但是有些学问 关于特定于域的问题可能是 必修的。

这是件好事。你不想让大量的开发者涌入这个项目。不过,如果你超过10人,每2人算1人,因为其他人都会在头顶上。除非你能把任务分成两个完全独立的团队来处理。那你就有机会得到一些牵引力。

已知和固定最大应用程序数 用户。

这意味着您可以更确定地在早期构建您的体系结构,因为您可以估计在扩展解决方案时必须投入多少精力。这是件好事。确保你在这些限制范围内工作,永远不要自欺欺人地认为“足够快”。如果你怀疑它可能太慢的话,那几乎永远都不会。。。

要使用的技术堆栈是 相当多样化(多达4种 语言和多达6种 平台)。

这不如让你的员工了解这一堆/一组语言那么重要?如果涉及到任何学习,如果您没有提前执行概念验证来学习技术,请提高估计值x2或x3。或者更好的是,忍受痛苦,去上些课。如果用于实现的语言或要使用的技术是未知的,那么很可能您会误用该技术,并做一些会把事情搞砸的事情。

确保这项技术得到了验证,否则你最终会被它咬到。

• 工具/技术的来源是否可用?
• 你得到支持了吗?
• 你了解这个产品吗?或者以前用过它吗?
• 客户以前用过吗?

如果这些问题中有太多得到了“否”,请在总数中添加一些(或大量)额外的时间。

连接到多达三个遗留系统 系统是预期的。

这真是一个好球。对于遗留集成,请自问:

• 还有其他人和他们结合吗?
• 你能接触到了解这些系统的人吗?
• 他们打算和你分享这些知识吗?
• 是否必须等待在这些系统中创建更改?
• 有测试系统供你使用吗?
• 有可供您使用的开发系统吗?

再说一遍,如果这些问题中有太多是“不”的,那就要害怕。您还应该知道,实际集成所需的时间大约是您实际认为的时间的3-5倍。

这不是一个我会给出一个表格抓取估计的项目。帮你自己和你的顾客一个忙,按小时做。如果没有,你将随着时间的推移开始偷工减料,以掩盖你缺乏进展/低估。。。你和你的顾客都会遭殃。

有许多成本估算软件工具,可以大大减轻成本估算的痛苦,我们使用项目代码表。我知道这些工具并不完美,但它们确实可以通过指向正确的方向来节省开始的时间。

Try this list of estimation tools on Wikipedia .