用于估算Web App小时数的经验法则

Question

我们都知道软件估计很难准确,但我并不是在寻找精确的.我希望能够得出项目的大致人工小时数,以了解在初创公司中雇用多少人.

所以,假设你有:

• 基于.NET平台构建的Web应用程序(C#,ASP MVC等...)
• 定义数量的用例,包含简单和复杂的用例(在此项目中,70个用例;但假设一个项目具有足够多的用例,以提供复杂且不复杂的良好钟形曲线)
• 一个已定义的数据库模式(同样,在这种情况下,有50个左右的表,但假设一个Web应用程序比七个表的典型书籍示例更多:))
• 想要快速,肮脏,最佳猜测估计并且理解它不是合同的合作伙伴,对软件开发经验丰富,并且软件(及其理解)将会发布和发展
• 一群坚实,熟练的开发人员

人们是否有任何经验法则来快速猜测所涉及的小时数？

更新:我要求基于可衡量但粗略要求的球场估计规则."4到6周"的答案很有趣,但是我想听听那些已经建立了一些简单的工作指标的人.

Answer 1

我总是写一份我需要完成的详细任务清单.从那里,我可以更好地判断这些单独任务的时间量,然后我添加这些数字.在那之后,我将额外的25-50%用作缓冲剂,以防出现并发症,这似乎总是会出现.

当我说一个任务列表时,我的意思是这样的:(这是一个例子,尽可能冗长,特别是在站点地图上)

• 数据库
  • 表
  • 查看
  • 存储过程
• 网站地图
  • 主页
  • 关于Page
  • 联系表
• 从开发到生产的迁移
  • 自我测试
  • 客户测试
  • bug修复

我总是用小时来估算时间.(不是15-30分钟)

Answer 2

粗略的猜测非常容易出错.我建议将提议的应用程序分解为尽可能多的细节和任务,并估算各个任务并添加它.然后为您忘记的所有任务添加一些额外的时间.

Answer 3

几乎没有基于粗略要求的可靠估计.实际上,根据我的经验,估计超过1天的任何单个任务都强烈表明该任务需要进一步细分为子任务.

即使是一周的估计通常也会很糟糕.根据我的经验,大多数任务估计在1周没有进一步的细节最终需要2-3周,而问题只会随着更大的项目而变得更糟.

这主要是心理上的.我们知道,作为程序员/设计师/架构师,我们是乐观主义者.当我们给自己一个漫长而模糊的目标时,即使我们真的不是这样,也很容易让我们觉得自己领先于比赛.再过4个星期？而我所要做的就是修复上周工作的破碎搜索功能？这很简单!让我们把它放在一边,开发一些有趣的Ajax淡入淡出效果.

话虽如此,我还经常使用一种特殊的启发式算法来进行背面估计,让我清楚地知道这些启发式实际上从未在项目计划中实际使用或使用 - 它们只是帮助回答问题的方法.客户和经理总是问的问题,"所以我们想说,我们想做<some_vague_project>多久,你认为需要多长时间？"

首先,我确定了项目的某些方面,即:

• 预期寿命 - 一次性,临时性或永久性？
• 项目的原创性 - 我们以前做过类似的事吗？
• 需要的领域知识水平与已知 - 规范是否具有学习曲线？
• 波动性 - 范围/所有权的清晰程度,变化的可能性有多大？
• 影响 - 它是否会支持/取代关键业务功能？
• UI复杂度 - 少于5个屏幕,少于20个或更多？
• 它面向客户吗？(如果是这样,它将需要经历多次修改)
• 是否需要与任何其他系统进行互操作？

然后我通常会为每一个分配"点"(请注意,这不是一个"系统",这一切都发生在我脑海中,通常需要微调).为大致的项目规模计算积分:

• 无分:1-2天(脚本)
• 1分:1-2周
• 2分:2-4周
• 3分:1-2个月
• 4分:3-6个月
• 5分:6-12个月
• 6分以上:没有头绪.

请注意我在这里做的事情 - 随着复杂性的增长,或多或少呈指数增长.当你添加一个新的皱纹,例如应用程序面向客户时,这不仅会给项目增加一些额外的时间,它会使时间增加一倍或三倍,因为现在一切都需要更长的时间审查语言,法律,外观和感觉等.如果它取代了关键的业务功能,那就是同样的想法; 现在,每个组件都需要防御性地编写,以便为每一个可能的意外事件做好计划.

我想重复记录,这在实际项目计划中没有实际用处,我实际上从未实际承诺项目时间表,而不会将整个规范分解为最大1-2天的任务.这只是为了回答快速,袖手旁观的问题,当客户/经理有效地要求我在脑海中进行数学计算并且不愿意接受"我不知道"的答案时.

再次,只是为了绝对确定每个人都听到了我: 不要使用这种方法来创建一个实际的项目估计. 对于提出最小基线项目"规模" 来说,最好是有用的,你可以在董事会会议上说出一些东西,但没有在虚线上签名就可以设定一些期望.