问题标签 [time-estimation]

我需要使用 Python zipfile 模块或 unix 命令行实用程序按需创建 ZIP 存档。

要压缩的资源通常 > 1GB 并且不一定对压缩友好。

我如何有效地估计它的创建时间/大小？

我正在寻找使用线性进度信息计算操作的 ETA（即：文件下载）的最佳方法。

可以说我有以下被调用的方法：

我有几个想法：

• 计算设定时间内的进度（如最后 10 秒）并将该速度用作操作的平均速度
• 保留一组已报告的最后 x 个进度，计算每个增量的速度并使用平均值

我一直在学习 Scrum 并尝试使用一个名为 Acunote 的工具来使用它。我的问题是关于每个任务的两个领域。它们是“估计”和“剩余”。我应该为那些使用什么单位？我使用故事点数吗？剩下的呢？例如，我有一个需要 10 个单位的任务，比如说。我在一天结束时用我相信我需要完成的多少“单元”来填充剩余的部分？

谢谢！

在估算研发任务的时间时应牢记的要点是什么。假设我必须使用“WPF”技术估计“ABC”任务，而我没有这方面的经验，我需要为此进行一些研发。

假设您是项目经理。您可以在几天内为特定开发人员估算特定任务的工作量。执行估计后，您会获得一些最小值和最大值。

在此之后，您将任务委派给开发人员。实际上，您还设置了截止日期。
设置截止日期时使用哪种估计更好：最小值还是最大值？

正如我所见，最小估计可能会给开发人员带来压力，最大估计可能会导致使用分配给开发人员的所有时间，即使任务可以更快地完成（所谓的学生综合症）。两种方法还有哪些优点和缺点？

编辑：

小澄清：我说的是在委派任务时为下属设置截止日期，而不是向我的老板报告。

编辑：

再补充一点：我可以记住我的真实估计，给老板提供稍微大一点的估计，给下属 - 稍微小一点。这个问题涉及到以下问题：提供给开发人员低估以使他更加努力地工作是否是个好主意？

我习惯于以 Joel Spolsky 建议的方式来考虑时间估计——如果一个计划项目需要超过 16 个小时，它应该被划分为更小的任务。现在，我正在我的团队中实施 Scrum 以及基于故事点的估计。在我看来，故事点的一个好的单位将是理想的工时，而不是工时。如果我使用天数，我的大多数问题将估计为 1/2 或 1。

你有什么想法，为什么在 Scrum 文献中最常提到使用理想的工日？

我在寻找真实的数字和经验，请不要太主观：

在寻找其他东西时，我偶然发现了一个有趣的陈述，部分内容如下：

[...]全国平均水平是每人每年 9,000 行代码。[...]

我写了很多代码，但不是全职的。当我回顾过去一年的项目时，我做了一个（非常）粗略的计算（只计算代码行，没有注释或白线），我在一年中达到了大约 19.000 条，这使它成为一个项目。如果我可以自动化其中的一部分，我可以在时间和金钱上扣除利润。

为了估计大型项目的时间节省，我需要平均值。在 C#（或其他选择的语言）中，人类平均一年编写多少行代码？而且，看看你自己的情况，你是否认为你的手写代码可以（部分地）自动化并且有什么好处？

我有一个自由 Web 应用程序项目，客户每两周左右请求新功能。我无法预测即将推出的功能的要求。因此，当客户端请求新功能时，可能会发生以下几种情况之一：

1. 我轻松实现该功能，因为它与现有平台兼容

2. 我很难实现该功能，因为我必须重写平台基础的重要部分

3. 客户撤回请求，因为在现有平台上实施成本太高

在项目开始时，大约六个月，所有功能请求都属于 1) 类，因为系统小而敏捷。但在过去的六个月里，大多数功能实现都属于第 2 类）。系统很成熟，每次我想添加新模块时，我都不得不重构和测试。此外，我发现自己破坏了过去可以工作的东西，并修复它（我没有为此获得报酬）。

客户开始对我实施新功能的时间和成本表示失望。对他们来说，许多功能请求的规模与他们六个月前请求的功能相同。例如，客户会问：“如果去年你花了 1 周时间构建票务系统，为什么今天需要 1 个月来构建活动注册系统？活动注册系统比票务系统简单得多。应该只需要你 1 周的时间！” 由于这种情况，我担心功能请求很快就会进入第 3 类）。事实上，我自己已经承担了很多成本，因为我自愿花费了很多时间来支持这个项目。

当我诚实地告诉客户做某事所需的时间时，客户常常会感到震惊。客户总是将我的估计与项目的前几个月进行比较。我认为他们没有为开发、维护和支持成熟的 Web 应用程序的真正成本做好准备。

在为一家全职公司工作时，经理们更容易接受我的估计，甚至鼓励我填写我的数字，以备不时之需。有没有办法让我的客户以同样的方式思考？

任何人都可以就我如何在不消耗太多成本的情况下继续从事这个网络项目提供建议吗？

附加信息- 我只做了一年的全职自由职业者。我还没有高端客户，但我正在慢慢到达那里。随着时间的推移，我得到了质量更好的客户。

我已经集成了大约六个电子支付网关，从流行的（如贝宝）到不那么流行的。

似乎每次我尝试集成一个非流行的电子支付网关时，我都超过了我最初的时间估计。

我认为我是一个体面的程序员，但我的时间估计可能需要工作。

其他程序员在集成他们从未听说过的电子支付网关时是否会遇到许多“惊喜”？

任何建议都会有所帮助。

谢谢

几个月前，我发现了一个项目管理/时间估算软件，它会要求您根据难度（1、2 或 3）对任务进行分类，然后估算部署所需的时间。

系统会在您工作时自动适应。

我忘记了软件名称。在过去的几天里，我一直在挖掘电子邮件并在 Google 上搜索，但没有任何结果。

任何人都可以通过我的描述固定软件名称吗？

它不是http://www.fogcreek.com（尽管我发现它是一个很棒的软件。

先感谢您。