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

时间:2010-01-27 03:18:15

标签: c# estimation

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

所以,假设你有:

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

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

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

15 个答案:

答案 0 :(得分:8)

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

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

  • 数据库
    • 浏览
    • 存储过程
  • 网站地图
    • 主页
    • 关于页面
    • 联络表格
  • 从开发到生产的迁移
    • 自测试
    • 客户 - 测试
    • 错误定影

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

答案 1 :(得分:5)

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

答案 2 :(得分:5)

基于粗略要求,实际上没有可靠的估计。事实上,根据我的经验,估计超过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天。当客户/经理有效地要求我在脑子里做数学并且不愿意接受“我”时,回答快速,袖手旁观的问题不知道“的答案。

再一次,只是为了绝对确定每个人都听到了我的意见:不要使用这种方法来创建实际的项目估算。最好提供最小值基线项目“规模”,您可以在董事会会议上说出一些内容,以便在没有在虚线上签名的情况下设定一些期望。

答案 3 :(得分:3)

敏捷估算技术提出了以下技术:

  • 为每个已识别的“要素”指定相对大小度量。思考功能(登录),层/任务(保存凭据的表)。 T恤尺码效果很好 - S,M,L,XL

  • 采用M尺寸的功能,并确定团队已经按照所需技术交付的内容 - 将其用作预期的校准措施。因此,您的团队的历史记录显示它可以在2周内提供M功能。使用S = 1 / 2M,L = 2M,XL = 4M,计算预期项目长度。

  • 如果您的团队尚未做过类似的事情;选择一个功能并一起实现。

  • 永远不要将您的计算作为时间点引用 - 始终将其作为范围引用,范围越大表示确定性越低。 (注意MS如何只预测哪一年会被释放!)

所有这一切,你认为你可能会问错误的问题吗?你愿意承担多少风险?

不是试图预测不可预测的,为什么不从尽可能小的团队开始(减少通信开销),并提供最小的功能集,让您进入市场(早期验证业务/市场需求)。

如果情况良好,您将获得更多真实的信息,以便与更大的团队一起估算未来的功能。

希望有所帮助!

答案 4 :(得分:1)

我没有传递任何规则。正如Sam所说,根据你想要估计的项目的规模和复杂程度,很容易得到这些大概的错误。大多数好的估计都来自某种迭代过程,在这种过程中你做出估计,看看估算错误的原因,然后在下次估算时进行补偿。

在指定项目和任务时,还要尝试详细说明。如果您有“做某事,30小时”等任务,您应该谨慎。我通常会尝试将大于一个工作日(5-7小时)的估算值分开。

你还提到你甚至不知道你估计的人的专业水平,这并没有使它变得更容易。当然,你可能会非常保守但是你只是冒险过度雇佣而不是迟到。所以我觉得你应该问问自己;我宁愿拥有哪个问题,迟到或者项目中有太多人。作为创业公司

答案 5 :(得分:1)

你所听到的声音有点类似于一种名为Function Point Analysis的旧估算技术。确定每个需求并将其表征为类型(例如,输入屏幕)。然后将这些分配给高,中或低的复杂性等级。为类型和复杂性分配了一个数值,并添加了整个批次以为您提供系统的功能点总数。

然后,您将修改器应用于功能点总计,以将其转换为小时数。修饰符将考虑所使用的工具以及(可能)开发人员的技能。

该系统理论上很棒。诀窍是提出正确的修饰符。在实践中,在完成3个或4个项目之后,您只能获得相当好的估计,然后可以根据过去的经验计算修改器。

关于您当前的项目,我建议使用类似的系统,尽管有点简化。将每个表评定为简单,中等或复杂,并对每个Web屏幕执行相同操作。为简单分配1分,为中分配2分,为复杂分配3分。加总数,这将是你的功能点总数。

然后,您需要找到一个修饰符来将其相乘以给出估算值。提出这个问题的最佳方法是对同一团队开发的旧系统进行功能点分析。将实际工作小时数除以该项目的功能点总数,并且有修改器。

这只会给出一个非常粗略的估计,但它可能是你得到的最好的。有了这样的方法,您就可以向客户展示您的估算方法,至少。

答案 6 :(得分:1)

首先让我先说一下,无论你做什么,你的估计都是错的。我想你已经知道了,所以考虑到这一点,我会试着详细说明我在估算一个项目时所做的事情:

  1. 将项目分解为功能,每个功能都具体,可衡量,可实现且逼真。
  2. 为每件衣服提供T恤尺码:超小,中,大,xl,xxl。
  3. 此时,如果可以,请与客户协商,将XL功能的数量减少到最低限度。
  4. 创建子任务,将每个功能分解为子任务。
  5. T恤尺码每个子任务。
  6. 这次尝试减少大尺寸功能的数量,重复步骤2-5,直到你拥有版本1所需的最低数量为止。
  7. 浏览每个功能,为每个功能提供时间估算。
  8. 总结您的估算。
  9. 此时你将在工时/天内获得超级不切实际的魔术最佳案例估计。我建议将它乘以至少两个。

    您可以将此数除以您可以使用的可用开发者资源数量,以获得发货天数。

    我强烈建议把这些信息写成(fogbugz)[www.fogbugz.com]。然后,您可以根据预计的时间标记实际时间,以便更好地了解您的发货日期是否真实。

    软件估算只不过是猜测,但通过适当的跟踪,您可以在接近目标时改进猜测。如果你无法衡量它,你就无法管理它。

    祝你好运,希望能按时发货!

答案 7 :(得分:1)

不要永远花在估算上。

  • 尝试将所有内容分成任务,其中最长的不超过一周
  • 没有任何功能需要少于1/2天
  • 为没人想到的事情添加随机数量的未知任务(已知的未知数)
  • 添加所有内容,乘以 3

此外,永远记住神话人月和/或代码完成,项目中的人越多,任何一个人的效率就越低。

更好的是,走敏捷。

答案 8 :(得分:1)

我的经验法则:

  1. 尽可能地分解项目,然后估算每种任务所需的稍微过时的时间,然后将其全部加起来以获得总时间。

  2. 至少将总估计时间乘以2 ,即使是最简单的项目,也可以将3或4乘以更大的项目,或者更复杂,或者我是新到。

  3. 使用带有暂停功能的“Punchclock” - 没有购买,只需要一个小js脚本 - 如果我在3个项目上工作,我有3个打卡时钟,所以我测量花费的时间。它可以让你得到令人惊讶的结果,因为我认为我们大多数人都不知道我们需要多少时间...是的,我们认为我们知道,但尝试测量 - 你可能会发现你比你快认为

  4. 这对我很有用,但我觉得需要一些更多的经验法则。

答案 9 :(得分:0)

雇用一个聪明的人来完成工作,然后过一会儿,问他们在给定的日期需要多少人才能完成。如果你一直不确定是否需要/有多少人雇用,那么他/她就不会这样做。

答案 10 :(得分:0)

恕我直言,编写应用程序需要大约500 +/- 100小时,而编码测试需要另外300个小时,而野外运行测试和应用程序需要500个小时。所以对于3位熟练和有组织的开发人员来说,它应该需要大约3个月:)但它只是估计。

答案 11 :(得分:0)

鉴于你有

  

想要快速肮脏的伙伴,   最佳当前猜测估计,和   明白这不是合同   持有,有经验的软件   开发,那个软件   (并理解其中)将   版本和进化

那么你能以敏捷的方式在较小的项目中打破这个项目吗?预先确定交付时间表(每3周一次?),确定用例的优先顺序,确定第一次交付的时间,以便进行后续迭代,并在每次迭代时重新讨论优先级。很可能,您的客户将继续改变他的想法,因此您不妨在此过程中建立定期的反馈/讨论。在较小的部件上获得正确的时机更容易 如果你不能这样做,那就选择Sam的选择 - 花时间建立好的估计。

答案 12 :(得分:0)

正如其他人已经提到的那样,分解任务项目并估算每项任务。我想补充一点,以确保添加一些额外的常见任务,如:

  1. 部署时间(包括几个;开发,舞台,制作等)
  2. 单元测试
  3. 数据库建模
  4. 解决方案设置
  5. 域模型模式
  6. 我发现在任何大型项目中,这些都是最重要的,因为它们为开发人员提供了有效工作的基础。

    [edit]

    我也发现最好将开发者错开一个新的大项目。从几个开发人员(最好的开发人员)开始,将共同的框架任务提升到其他人可以开始并行处理功能并提高工作效率的程度。我一直在进行一些项目,他们只是立即投入几个开发人员,每个人都做自己的事情,这个项目变成了一个相互冲突的想法。这样做有助于提高质量和一致性。

    如果你已经很好地估计了常见的任务,那么你可以预见到何时错开下一个开发时间。

答案 13 :(得分:0)

为创业公司招聘多少人?

在你有一批(选择你的词汇,用户故事,功能点......)之前,你还没有准备好雇用任何人。

因此,您可能需要首先聘请项目所有者来进行此级别的分析。

然后,雇佣两个人在这个名单上成对工作两个星期,他们将能够告诉你工作清单的“宽度”。雇用一对建筑师与原始项目所有者合作,继续扩大名单。

并且,除非你有直接通向人们的道路,否则不要开始任何这一切,如何准确解释你必须要生产的东西。

答案 14 :(得分:-2)

继续你的直觉,然后再添加3个月