14

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

所以,假设你有:

  • 基于 .NET 平台(C#、ASP MVC 等)构建的 Web 应用程序
  • 定义数量的用例,混合了简单和复杂的用例(在这个项目中,有 70 个用例;但假设项目的用例数量足够多,可以给出复杂和不复杂的良好钟形曲线)
  • 一个已定义的数据库模式(同样,在这种情况下有 50 个左右的表,但假设一个 Web 应用程序比典型的具有七个表的书本示例做得更多:))
  • 合作伙伴想要一个快速而准确的、当前最佳猜测的估计,并且明白这不是一份合同,在软件开发方面经验丰富,并且软件(以及对软件的理解)会版本和发展
  • 一群扎实、熟练的开发人员

人们是否有任何经验法则可以用来快速估计所涉及的小时数?

更新:我要求基于可衡量但粗略的要求的球场估计规则。“4 到 6 周”的答案很有趣,油嘴滑舌的答案,但我想听听那些实际上已经建立了一些简单的工作晴雨表的人的意见。

4

15 回答 15

8

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

当我说任务列表时,我的意思是这样的:(这是一个示例,尽可能详细,尤其是在站点地图上)

  • 数据库
    • 意见
    • 存储过程
  • 网站地图
    • 主页
    • 关于页面
    • 联系表
  • 从开发迁移到生产
    • 自测
    • 客户测试
    • 错误修复

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

于 2010-01-27T03:31:28.767 回答
5

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

于 2010-01-27T03:21:50.807 回答
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 天的任务,我永远不会真正承诺项目时间表。用于在客户/经理有效地要求我在脑海中进行数学运算并且不愿意以“我不知道”作为答案时回答快速、即兴的问题。

再一次,绝对确定每个人都听到了我的声音: 不要使用这种方法来创建实际的项目估算。 它充其量对于提出最小基线项目“规模”很有用,您可以在董事会会议上说这些话来设定一些类似的期望,而无需在虚线上签字。

于 2010-01-27T05:38:42.300 回答
3

敏捷估计技术建议使用以下技术:

  • 为您确定的每个“特征”分配一个相对大小度量。考虑功能(登录),而不是层/任务(保存凭据的表)。T 恤尺码效果很好 - S、M、L、XL

  • 采用 M 大小的功能,并确定团队已经在所需技术中交付的东西 - 将其用作您预期的校准措施。因此,您的团队的历史表明它可以在 2 周内交付 M 功能。使用 S = 1/2M, L=2M, XL=4M,计算预期项目长度。

  • 如果您的团队还没有做过类似的事情;选择一个特性并一起实现它。

  • 切勿将您的计算引用为时间点 - 始终将其引用为一个范围,较大的范围表示较少的确定性。(注意 MS 如何只预测哪一年会发布一些东西!)

说了这么多,你有没有想过你可能问错了问题?你愿意冒多少风险?

与其试图预测不可预测的事情,不如从尽可能小的团队开始(减少沟通开销),并提供让您进入市场的最小功能集(更早地验证业务/市场需求)。

如果一切顺利,您将获得更多真实信息,以便与更大的团队一起估计未来的功能。

希望有帮助!

于 2010-01-27T04:22:54.833 回答
1

没有我会传递的规则。正如 Sam 所说,根据您要估算的项目的规模和复杂性,这些粗略估算很容易出错。大多数好的估算都来自某种迭代过程,您可以在其中进行估算,查看估算错误的原因,然后在下次估算时进行补偿。

在指定项目和任务时也要尽量详细。如果你有“做某事,30 小时”之类的任务,你应该小心。我通常会尝试拆分大于一个工作日(5-7 小时)的估算。

您还提到您甚至不知道您正在评估的人的专业水平,这并没有让它变得更容易。当然,您可能会非常保守,但您只是冒着过度招聘而不是迟到的风险。所以我认为你应该问问自己;我宁愿遇到哪个问题,迟到或项目中有太多人。作为一家初创公司

于 2010-01-27T03:55:01.473 回答
1

你所追求的听起来有点类似于一种叫做功能点分析的旧估计技术。每个需求都被识别并表征为一种类型(例如输入屏幕)。然后,这些被分配了高、中或低的复杂度等级。为类型和复杂性分配了一个数值,并将整个批次相加,为您提供系统的功能点总数。

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

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

关于您当前的项目,我建议您使用类似的系统,尽管稍微简化了一点。将每个表格评定为简单、中等或复杂,并对每个网页屏幕进行相同的评分。简单得1分,中等得2分,复杂得3分。将总数加起来,这将是您的功能点总数。

然后你需要找到一个修饰符来乘以这个来给你一个估计。最好的方法是对同一团队开发的旧系统进行功能点分析。将实际工作时间除以该项目的功能点总数,就可以得到你的修饰符。

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

于 2010-01-27T04:13:59.110 回答
1

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

  1. 将项目分解为功能,其中每个功能都是特定的、可衡量的、可实现的和现实的。
  2. 为每个功能指定一个 T 恤尺寸:超小号、小号、中号、大号、xl、xxl。
  3. 此时,如果可以,请与客户协商以将 XL 功能的数量减少到最低限度。
  4. 创建子任务,将每个功能分解为子任务。
  5. 每个子任务的 T 恤尺寸。
  6. 这次重复步骤 2-5,尝试减少大尺寸特征的数量,这样做直到您达到版本 1 所需的最低数量。
  7. 遍历每个特征,给每个特征一个时间估计。
  8. 总结你的估计。

在这一点上,您将获得以工时/天为单位的超级不切实际的魔术最佳案例估计。我建议至少乘以二。

您可以将其除以您拥有的可用开发人员资源的数量,以获得发货天数。

我强烈建议您获取这些信息并将其放在类似 (fogbugz)[www.fogbugz.com] 的内容中。然后,您可以根据您的估计时间标记您的实际时间,以更好地了解您的实际发货日期。

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

祝项目顺利,希望准时发货!

于 2010-01-27T04:27:18.997 回答
1

不要永远花在估算上。

  • 尝试将所有内容分成任务,最长不超过一周
  • 没有一个功能每天花费少于 1/2
  • 为没人想到的事情添加随机数量的未知任务(已知的未知数)
  • 所有内容相加并将结果乘以3

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

更好的是,去敏捷。

于 2010-01-27T04:32:38.040 回答
1

我的经验法则:

  1. 尽可能地分解项目,然后稍微悲观地估计每种任务所需的时间,然后将它们加起来得到总时间。

  2. 至少将估计的总时间乘以 2 ,即使是最简单的项目,也可以乘以 3 或 4,用于更大的项目、更复杂的项目或我不熟悉的项目。

  3. 使用带有暂停功能的“打卡钟”——不是购买的,只是一个小 js 脚本——如果我从事 3 个项目,我有 3 个打卡钟,所以我测量花费的时间。它可以为您带来令人惊讶的结果,因为我认为我们大多数人都不知道我们需要多少时间来做任何事情......是的,我们认为我们知道,但尝试测量 - 你可能会发现你比你快思考

这对我来说效果很好,但我确实觉得需要更多的经验法则。

于 2010-11-30T23:50:01.613 回答
0

雇用一个能完成工作的聪明人开始工作,然后过一段时间,问他们在给定日期之前还需要多少人才能完成。如果您不确定是否/要雇用多少人,那就错在没有人/一个人的一边。

于 2010-01-27T03:23:06.107 回答
0

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

于 2010-01-27T04:00:34.650 回答
0

鉴于你有

合作伙伴想要一个快速而准确的、当前最佳猜测的估计,并且明白这不是一份合同,在软件开发方面经验丰富,并且软件(以及对软件的理解)会版本和发展

那么你能以敏捷的方式将项目分解为更小的项目吗?预先确定交付时间表(每 3 周一次?),确定用例的优先级,确定第一次交付的时间以便您能够完成,并对后续迭代进行松散的估计/计划 - 并在每次迭代时重新讨论优先级。很有可能,您的客户无论如何都会改变主意,因此您不妨在此过程中建立定期的反馈/讨论。在较小的部分上更容易获得正确的时间。
如果你做不到,那么选择 Sam 的选择——花时间建立良好的估计。

于 2010-01-27T04:10:04.060 回答
0

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

  1. 部署时间(包括几个;开发、阶段、生产等)
  2. 单元测试
  3. 数据库建模
  4. 解决方案设置
  5. 领域模型模式

我发现在任何大型项目中,这些都是最重要的,因为它们为让开发人员高效地并行工作奠定了基础。

[编辑]

我还发现最好让开发人员错开一个新的大项目。从几个开发人员(您最好的开发人员)开始,将通用框架任务提升到其他人可以开始并行处理功能并提高工作效率的程度。我曾经参与过一些项目,他们只是一次将几个开发人员投入其中,每个人都做自己的事情,这个项目变成了相互冲突的想法的大杂烩。这样做有助于提高质量和一致性。

如果您对常见任务进行了适当的估计,则可以明智地预测何时错开下一个开发人员。

于 2010-01-27T04:30:27.607 回答
0

创业需要招聘多少人?

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

因此,也许您需要先聘请项目负责人来进行这一级别的分析。

然后,雇用两个在此列表上作为一对工作两周,他们将能够告诉您工作列表的“宽度”。雇用足够的配对来填补宽度,并聘请建筑师与原始项目所有者合作以继续扩大列表。

而且,除非你有直接的途径,否则不要开始任何这些,人们如何才能准确地解释你必须生产什么。

于 2010-01-27T05:32:31.863 回答
-2

跟着你的直觉走,然后再加上 3 个月

于 2010-01-27T03:20:51.053 回答