估计Web应用程序小时数的经验法则[关闭]

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

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

• 数据库
  • 桌子
  • 意见
  • 存储过程
• 站点地图
  • 主页
  • 关于Page
  • 接触形式
• 从开发到生产的迁移
  • 自测试
  • 客户测试
  • 错误修复

我总是以小时来估计时间。(不是15-30分钟的街区)

粗暴的客人很容易犯错误。我建议将提议的应用程序分解为尽可能多的细节和任务,并估计单个任务并将其相加。然后为你忘记的所有任务增加一些额外的时间。

实际上,没有一种方法可以根据粗略的需求进行可靠的估计。事实上,根据我的经验,任何一个估计超过1天的任务都是一个强有力的迹象,表明该任务需要进一步细分为子任务。

即使是一周的估计结果也很糟糕。根据我的经验,大多数任务估计为1周,但没有进一步的细节,最终需要2-3周的时间,而且这个问题只会随着更大的项目而变得更糟。

这主要是心理上的。我们知道,作为程序员/设计师/架构师,我们是乐观主义者。当我们给自己一个又长又模糊的目标去击中时,即使我们真的不是,也很容易感觉到我们已经领先了比赛。再多4周?我要做的就是修复上周运行的搜索功能?这很简单!让我们把它放在一边,研究一些有趣的Ajax渐变效果。

说到这里,我经常使用一种特殊的启发式方法来进行信封背面的估计,让我清楚地知道,这些方法是 从未实际承诺或用于项目计划 -它们只是帮助回答客户和经理们经常问的问题的简单方法,“所以,假设我们想这样做 <some_vague_project> ,您认为需要多长时间?”

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

• 预期终身运行一次、临时或永久?
• 项目的独创性——我们以前做过类似的事情吗?
• 所需领域知识水平与已知领域知识水平——规范是否有学习曲线?
• 波动性-范围/所有权有多清楚,变化的可能性有多大?
• 影响-IT是否支持/替换关键业务功能?
• 用户界面复杂性-少于5个屏幕,少于20个或更多?
• 它是面向客户的吗?(如果是这样的话,需要进行无数次修订)
• 它是否需要与任何其他系统进行互操作?

然后我通常会给每一个(注意这是 不是一个“系统” 这一切都发生在我的头脑中,通常需要微调)。为一个大致的项目大小汇总点:

• 无分:1-2天(脚本)
• 1分:1-2周
• 2分:2-4周
• 3分:1-2个月
• 4分:3-6个月
• 5分:6-12个月
• 6分以上:无线索。

注意我在这里所做的-有一个或多或少的指数增长率与复杂性。当你添加了一个新的皱纹,比如应用程序是面向客户的,这不仅增加了项目的额外时间,而且 双打 或 三元组 时间因为现在 一切 如果要替换关键的业务功能,则需要更长的时间来审查语言、法律、外观和感觉等相同的想法;现在,每个组件都需要进行防御性的编写,以计划每种可能的应急情况。

我想重复一下 这在实际的项目计划中没有实际的用途,如果不将整个规范分解为最大1-2天的任务,我就永远不会实际地承诺项目时间表。 这是 只有 为了快速回答问题,当客户/经理有效地要求我在头脑中做数学,并且不愿意接受“我不知道”作为答案时,我会立即回答问题。

再一次,为了确保每个人都听到我说的话: 不要使用此方法创建实际的项目评估。 它对提出一个 最低限度 基线项目“规模”,你可以在董事会会议上说,设置一些期望的外观,而不必在虚线上签字。

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

• 为每个已识别的“功能”分配一个相对大小的度量。思考功能(登录) 不 层/任务(保存凭证的表)。T恤的尺寸很合适-S、M、L、XL

• 取一个M大小的特性,并确定团队已经在所需技术中交付的东西-将其用作预期的校准度量。因此,您团队的历史表明,它可以在2周内交付M功能。使用s=1/2 m,l=2 m,xl=4 m,计算预期项目长度。

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

• 不要将计算作为时间点引用-始终将其作为范围引用,范围越大表示确定性越低。(请注意,微软是如何预测将发布哪一年的产品的!)

尽管如此,你是否认为你可能问错了问题?你愿意冒多少风险?

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

如果顺利的话,你会有更多的 真实的 与更大团队一起评估未来功能的信息。

希望有帮助!

我没有什么规则可以传下去。正如萨姆所说,根据您试图估计的项目的规模和复杂性,很容易得出这些大致正确的估计。大多数好的估计都来自于某种迭代过程,在这个过程中你做出一个估计,看看为什么这个估计是错误的,然后在下一次估计时进行补偿。

在指定项目和任务时,也要尽量详细。如果你有“做点什么,30小时”之类的任务,你应该谨慎。我通常尝试将大于一个工作日(5-7小时)的估计数进行拆分。

你还提到,你甚至不知道你所评估的人的专业水平,这并不能让事情变得更容易。当然,你可能会非常保守,但你只是冒着过度雇佣的风险,而不是迟到。所以我认为你应该问问你自己,我宁愿有什么问题,迟到或者项目中有太多人。作为一个初创企业

你所追求的听起来有点像一种古老的评估技术 Function Point Analysis .每个需求都被识别出来,并被描述为一种类型(如输入屏幕)。然后,这些被指定为高、中或低的复杂性等级。为类型和复杂性分配了一个数值,并将整个批次相加,为系统提供一个功能点总计。

然后,您将一个修饰符应用于函数点合计,以将其转换为工时。修改器将考虑到正在使用的工具,以及(潜在的)开发人员的技能。

这个系统理论上很好。技巧是想出正确的修饰语。在实践中,只有在完成了3或4个项目之后,您才能得到相当好的估计,然后才能根据过去的经验计算修改器。

关于您当前的项目,我建议使用类似的系统,尽管有点简化。对每个表进行简单、中等或复杂的评分,并对每个Web屏幕进行相同的评分。简单得1分,中等得2分,复杂得3分。把总数加起来,这就是你的功能点总数。

然后您需要找到一个修饰符将其与之相乘,以给出一个估计值。最好的方法是对同一个团队开发的旧系统进行功能点分析。将实际工作小时数除以该项目的功能点总数,然后就有了修改器。

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

首先,让我先说,不管你做什么,你的估计都是错误的。我想你已经知道这一点了,所以在考虑到这一点的情况下,我会在评估项目时详细说明我要做什么:

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

此时,您将获得超不切实际的魔法最佳案例估计(以工时/天计)。我建议至少乘以2。

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

我强烈建议您获取这些信息,并将其设置为(fogbugz)[www.fogbugz.com]。然后,您可以将实际时间与估计时间进行比较,以便更好地了解实际的装运日期。

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

祝项目顺利,希望它能按时发货!

不要永远花在估算上。

• 试着把每件事都分解成任务,最长不超过一周。
• 任何功能都不需要少于1/2天的时间
• 为没人想到的事情(已知的未知数)添加随机数量的未知任务
• 添加 一切就绪 乘 结果 三 .

此外,请始终记住神话中的人月和/或完整的代码,项目中的人越多,每个人的效率就越低。

更好的是,要敏捷。

我的经验法则:

1. 尽可能地分解项目,然后估算每种任务所需的时间,再将所有时间相加得到总时间。

2. 总估计时间乘以2 至少,即使是最简单的项目 对于更大的项目,或更复杂的项目,或是我不熟悉的事情,都会增加3到4倍。

3. 使用一个带有暂停功能的“punchclock”——不是购买的,只是一个小的JS脚本——如果我在3个项目上工作,我有3个穿孔时钟,所以我测量花费的时间。它能给你带来令人惊讶的结果,因为我认为我们大多数人都不知道我们需要多少时间来做任何事情……是的,我们认为我们知道,但是试着测量——你也可能发现你比你想象的要快。

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

雇佣一个聪明的人,让他们完成开始的工作,然后在一段时间后,问他们在一个给定的日期之前需要多少人来完成。如果你不确定是否/要雇用多少人,那就不要/一个都不要。

imho对应用程序进行编码大约需要500+/-100个小时,另外300个小时对测试进行编码,另外500个小时在野外运行测试和应用程序。因此,对于3个技术娴熟且有组织的开发人员来说,这需要大约3个月的时间:)但这只是估计。

既然你有

一个想要快速和肮脏的伴侣, 最佳当前猜测估计,以及 明白这不是合同 持有,有软件经验 开发,以及软件 (及其理解)遗嘱 版本和发展

那么,你能以一种敏捷的方式把项目分成更小的项目吗?提前决定交货时间表(每3周一次?),确定用例的优先级,确定第一次交付的时间,以便您能够完成它,并在随后的迭代中有一个松散的估计/计划-并在每次迭代中重新讨论优先级。很可能,你的客户会改变主意,所以你也可以在这个过程中建立定期的反馈/讨论。在较小的部件上获得正确的时间比较容易。
如果你不能做到这一点,那就选择山姆的选择-花时间建立好的估计。

正如其他人已经提到的那样,分解出任务项并对它们进行评估。我会增加一些额外的常见任务,例如:

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

我发现,在任何大型项目中,这些都是最重要的,因为它们为开发者提供了并行工作的基础。

[编辑]

我也发现最好的办法是让开发人员交错进入一个新的大项目。从几个开发人员(您最好的开发人员)开始,以使公共框架任务达到其他人可以开始并行处理特性并提高生产效率的程度。我参与过一些项目,他们一次投入几个开发人员,每个人都做他们自己的事情,项目变成了一堆相互冲突的想法。这样做有助于提高质量和一致性。

如果您正确地估计了常见的任务,那么您可以预见到在什么时候错开下一个开发人员。

一家初创公司要雇用多少人?

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

所以也许你需要从雇佣一个项目负责人开始做这个层次的分析。

然后,雇佣两个人在这个列表上作为一对工作两周,他们将能够告诉你工作列表的宽度。雇佣足够多的团队来填充宽度,雇佣一个架构师与原始项目所有者一起继续扩展列表。

而且,不要这样做,除非你有一个直接的途径给人们,如何能够准确地解释你必须生产什么。

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