我想知道，“真正的”工作日（7-8小时）与“工程师时间”一词有什么关系，用于估算完成某项任务所需的时间。我认为EH的估计工作量（如果正确估算）不能简单地转换为工作日，除以8，并且程序员的有效工作日比他工作的建筑物花费的时间短。当估计小块任务时（即SCRUM中一次迭代的范围是什么）以及何时没有最佳/最差情况估计，这可能导致估计中的大误差，但是计划是基于程序员完成的单个任务估计完成的。当程序员需要估计完成某些单独任务所需的时间时，他们通常会估计从开始工作到完成任务的那一刻起的时间。毋庸置疑，期望有人在一天内完成4个任务，每次2小时是很疯狂的。
我想知道成功公司的最佳做法是将有效时间与“在工作中”的时间相关联，是否有一些书籍或研究估算什么是程序员花在工作上的平均时间（专注于手头的任务），而不是做其他未包含在估算中的活动，如读/写邮件（估计中包含的内容，如果是支持任务或类似内容），头脑风暴，会议，喝咖啡，估算任务和更新错误/任务跟踪工具中的状态。
如果没有书籍或研究，社区中受尊敬的成员有关此问题的文章的任何链接也会有帮助，因为我找不到，这些关键词过于通用。
答案 0 :(得分：3)
我们在编程时会做两件事：
当我们重复类似的事情时，估计 - 无论是相对努力/复杂性还是以小时为单位 - 通常都是相当简单的。即使以分数进行估算，一旦团队加速，这些很容易在一两个冲刺后的几个小时内相互关联。
大多数球队面临的问题是他们经常做新事物。这是因为：
因此，我们在软件项目上做的很多事情都是新的。通常相同的同龄人经常最终被提供给初级开发人员，对他们来说是新的。
新事物的问题在于你有no idea how long they're going to take。你以前从来没有做过！
我已经看到了一些处理这个问题的策略，具体取决于某人如何决定（强迫开发者）产生可靠的估计，你对利益相关者有多少信任等等。
Pad the estimates horribly然后使工作适合他们（这是开发人员最终做的事情，如果PM / SM迫使他们产生可靠的估计，无论开发人员是否意识到这一点。）
Kanban's "classes of service"允许您将一些新事物与一些熟悉的东西混合在一起。这将倾向于允许通过开发管道的流量变化较小，因此您可以基于此估算。
先做一切有风险的事情（特别是如果你不知道它有多危险！）。逐渐流动将稳定下来。在一个9个月的项目中，花了3个月才开始产生任何有用的估计，所以要小心这个。好处是你的利益相关者会看到你提前解决让他们在夜间保持清醒的事情，所以信任度很高。在此期间，您的PM / SM将备用。没关系。
Accept that the old metaphor of "time spent = work done"是涉及大量学习和知识工作的项目的神话。在开发人员被视为工厂的过程中，这可能是合适的 - 生成其他人设计的实施 - 但在敏捷和Scrum的世界中，这是完全不合适的。甚至Scrum.org最近也从他们的指南中删除了估算和速度测量的必要性。找到其他方式来建立信任，管理风险，赢得预算并围绕工作进行对话 - 因为这些是您首先需要估算的唯一原因。
答案 1 :(得分：2)
除了the mythical man month，总是值得一读，Agile estimating and planning是我在这个主题上找到的最好的书之一。
有史以来最好的报价：
“当你甚至不知道什么是精确的时候，没有任何意义 你在说什么。“（John von Neumann）
此外，experimental software engineering试图从受控环境中的实验中得出统计相关的结论。非常粗略地说，你可以设计实验应用科学方法，选择输入变量（即程序员的经验，一周的时间，语言/框架等），以及测量输出。
来自维基百科：
科学方法提出了一个观察，法律和方法的循环 促进科学的理论。实验软件工程适用 这种软件方法。
我记得一本关于这个主题的非凡大学课程的好书是“Experimental Software Engineering”。它假设您掌握了统计分布和descriptive statistics，但这是一个非常好的阅读。
答案 2 :(得分：0)
一种简单的方法来获得计划与实际花费的时间（这本身总是流动到一定程度）是使用敏捷管理工具。 Target process可以与重量级运行，但如果使用少于6个许可证，则可以免费获得完整系统。在过去的5年里，我在4个不同的客户中使用过它，每次都取得了巨大的成功。
我没有您想要的确切答案（即小时* 1.75 =工作时间），但TargetProcess对估计值的持续调整与花费的时间相匹配将很快给出适用于您的比率。
PS-我不为他们工作。