In answer to your question, development time entries are important. But you can't measure them through a single IDE, nor indeed through any software. The development process is a complex one involving discussions, planning around a whiteboard, diagrams sketched on a piece of paper, research on the Internet, etc etc.
Read Jeff Atwood's excellent post on laziness and the other posts he refers to there. A good, successful developer spends time away from the IDE making sure they don't spend 90% of their working day reinventing the wheel, or 50% of their day heading down the wrong track because they haven't thought the design through.
I find the basic idea interesting, even though automated time tracking has flaws, just as measuring the number and frequency of commits to a project (as done on ohloh.net for example) can be a very misleading indicator about its activity.
However, the reality is that time worked is the basis for billing, and needs to be measured somehow. There are already solutions for this, though.
(there are many more out there but these two I know well).
They work independently from what tool(s)/IDEs I am using, they can detect my absence/presence on the computer and prompt me about how I want to file the time, and they can do all the necessary reporting. It is also easy to add and manage filed entries.
What would your Visual Studio Plugin achieve that these solutions don't offer already?
但作为一名开发人员，我知道我很容易因更重要的案例而分心。我还知道我花了很多时间使用 IDE 以外的工具来处理这些案例 - 例如在 MbUnit 中进行测试、在线查找错误消息解释，或者向那些问我为什么还没有完成工作的人提供状态还有一个错误。我也曾去过一些地方，我通常一天的一半时间（或更多时间）都在开会或在实验室中在其他地方的远程计算机上完成工作。当我坐在办公桌前时，我可以使用计算机来制定我正在做的工作的想法，或者只是使用笔和纸。
因此，当你问“坐在那边的那个人真的在做他的工作吗？”这个问题时，需要考虑很多变量。您确实需要查看更多正在运行的应用程序，而不仅仅是 Visual Studio 2008 (devenv.exe)。您可能需要查看与开发人员的测试框架、文本文档、与其他计算机甚至 Firefox 的远程桌面连接相关的进程活动。 （对于某人是否真正在工作，Firefox 将是一个巨大的判断！）
作为您该项目研究的一部分，我还建议研究您公司行业中使用的一些其他时间收集系统，并比较它们的功能。
Time spent developing in an IDE provides only a (sometimes very) partial metric of how much time a developer works.
I have been using FogBugz version 7 lately at work, and it has a feature that allows developers to estimate how long it will take them to finish a case. The developer can then use the software to say, "I am working on this case". Then the clock will count down until it reaches zero, based on the developer's working schedule (including days off), the hours that they say they are in the office, and the percentage of their time that they estimate they are working on cases.
But as a developer, I know that I can easily get sidetracked by more important cases. I also know that I spend a good deal of time working on the cases using tools other than the IDE - such as testing in MbUnit, looking for error message explanations online, or giving status to people who ask me why I have not finished working on a bug yet. And I've also been in places where I spent half the typical day - or more - in meetings or in a lab doing my work on a remote machine somewhere else. When I'm at my desk, I could be using my computer to map out ideas for the work I'm doing, or just pen and paper.
So there are a lot of variables to consider when you ask the question, "Is the guy who sits over there really doing his work?" You would really need to look at more running applications than just Visual Studio 2008 (devenv.exe). You would probably need to look at activity for processes associated with a developer's test framework, text documents, remote desktop connections to other machines, and even Firefox. (Firefox would be a huge judgment call as to whether somebody is actually working!)
As part of your research for the project, I would also suggest researching some of the other time collection systems that are in use throughout your company's industry and comparing their features.
A bit off track, but you could potentially use this sort of data to illuminate areas of complexity (LOC), areas that are prone to change (frequent updates 'n' days apart), etc. but even this would be skewed by different programmers approaches to development.
We track all our time by project daily. It takes me less than five minutes a day to fill out what I was working on. This is not something that can be automated or even should be automated as it will never be anywhere close to accurate. Files aren't always associated with just one project and it would cost me more time to tell an application which files belong to which project that the five minutes it takes to fill our my timesheet. No one spends the entire day typing - there are meetings and phone calls and thinking (you know where you figure out what you want to type!), none of that will be captured in your automated system. What you are porposing will not be more accurate, it will be less accurate than requiring people fill in time sheets daily.
虽然时间条目很重要，但弄清楚如何组织时间却是麻烦所在。非技术人员对开发的各个阶段的理解程度如何才能理解数据？我同意其他回复，即 IDE 跟踪是一个糟糕的主意，特别是如果正在做的部分工作涉及通过 Web 浏览器更改数据库，这就是我当前的大型 CMS 项目中的内容，我们可能必须更改模板或创建内容来测试功能是否有效。
这也严重忽视了可能发生的游戏系统想法。如果我让 IDE 在调试状态下保持打开状态，因为我想要扫描内存或执行其他操作，需要打开窗口才能实际查看某些内容，但我也可能离开了办公桌，除非您以某种方式跟踪我正在查看的位置和坐着。
While time entries are important, figuring out how to organize it is where trouble comes into the picture. How well would non-technical staff understand the various phases of development in order to understand the data? I'll agree with the other responses that the IDE tracking is a terrible idea, especially if part of what is being done involves changing a database through a web browser which is what I have in my current big CMS project where we may have to change templates or create content to test out if the functionality works.
This also heavily ignores the gaming the system idea that can happen. What if I leave my IDE open in debug because I'm wanting to scan memory or do something else that requires the window be open to actually look at something but I could also have left my desk unless you are somehow tracking where I'm looking and sitting.
发布评论
评论（6）
在回答您的问题时，开发时间条目很重要。但您无法通过单个 IDE 或任何软件来测量它们。开发过程是一个复杂的过程，涉及讨论、围绕白板进行规划、在纸上绘制图表、在互联网上进行研究等等。
请阅读 Jeff Atwood 在 懒惰 以及他在那里提到的其他帖子。优秀、成功的开发人员会花时间远离 IDE，确保他们不会花费 90% 的工作日重新发明轮子，或者不会用 50% 的时间走上错误的道路，因为他们没有仔细考虑设计。
In answer to your question, development time entries are important. But you can't measure them through a single IDE, nor indeed through any software. The development process is a complex one involving discussions, planning around a whiteboard, diagrams sketched on a piece of paper, research on the Internet, etc etc.
Read Jeff Atwood's excellent post on laziness and the other posts he refers to there. A good, successful developer spends time away from the IDE making sure they don't spend 90% of their working day reinventing the wheel, or 50% of their day heading down the wrong track because they haven't thought the design through.
我发现这个基本想法很有趣，尽管自动时间跟踪存在缺陷，就像测量项目提交的数量和频率（例如在 ohloh.net 上所做的那样）可能是关于其活动的非常误导性的指标。
然而，现实情况是工作时间是计费的基础，需要以某种方式进行衡量。不过，已经有解决方案了。
看看
（还有更多，但我很熟悉这两个）。
它们独立于我使用的工具/IDE 工作，它们可以检测我在计算机上的缺席/存在，并提示我如何记录时间，并且它们可以完成所有必要的报告。添加和管理归档条目也很容易。
您的 Visual Studio 插件将实现哪些这些解决方案尚未提供的功能？
I find the basic idea interesting, even though automated time tracking has flaws, just as measuring the number and frequency of commits to a project (as done on ohloh.net for example) can be a very misleading indicator about its activity.
However, the reality is that time worked is the basis for billing, and needs to be measured somehow. There are already solutions for this, though.
Take a look at
(there are many more out there but these two I know well).
They work independently from what tool(s)/IDEs I am using, they can detect my absence/presence on the computer and prompt me about how I want to file the time, and they can do all the necessary reporting. It is also easy to add and manage filed entries.
What would your Visual Studio Plugin achieve that these solutions don't offer already?
在 IDE 中进行开发所花费的时间仅提供了开发人员工作时间的（有时非常）部分指标。
我最近在工作中一直在使用 FogBugz 版本 7，它有一个功能可以让开发人员估计完成一个案例需要多长时间。然后，开发人员可以使用该软件说：“我正在处理这个案例”。然后，时钟将根据开发人员的工作时间表（包括休息日）、他们所说的在办公室的时间以及他们估计处理案例的时间百分比进行倒计时，直到达到零。
但作为一名开发人员，我知道我很容易因更重要的案例而分心。我还知道我花了很多时间使用 IDE 以外的工具来处理这些案例 - 例如在 MbUnit 中进行测试、在线查找错误消息解释，或者向那些问我为什么还没有完成工作的人提供状态还有一个错误。我也曾去过一些地方，我通常一天的一半时间（或更多时间）都在开会或在实验室中在其他地方的远程计算机上完成工作。当我坐在办公桌前时，我可以使用计算机来制定我正在做的工作的想法，或者只是使用笔和纸。
因此，当你问“坐在那边的那个人真的在做他的工作吗？”这个问题时，需要考虑很多变量。您确实需要查看更多正在运行的应用程序，而不仅仅是 Visual Studio 2008 (devenv.exe)。您可能需要查看与开发人员的测试框架、文本文档、与其他计算机甚至 Firefox 的远程桌面连接相关的进程活动。 （对于某人是否真正在工作，Firefox 将是一个巨大的判断！）
作为您该项目研究的一部分，我还建议研究您公司行业中使用的一些其他时间收集系统，并比较它们的功能。
Time spent developing in an IDE provides only a (sometimes very) partial metric of how much time a developer works.
I have been using FogBugz version 7 lately at work, and it has a feature that allows developers to estimate how long it will take them to finish a case. The developer can then use the software to say, "I am working on this case". Then the clock will count down until it reaches zero, based on the developer's working schedule (including days off), the hours that they say they are in the office, and the percentage of their time that they estimate they are working on cases.
But as a developer, I know that I can easily get sidetracked by more important cases. I also know that I spend a good deal of time working on the cases using tools other than the IDE - such as testing in MbUnit, looking for error message explanations online, or giving status to people who ask me why I have not finished working on a bug yet. And I've also been in places where I spent half the typical day - or more - in meetings or in a lab doing my work on a remote machine somewhere else. When I'm at my desk, I could be using my computer to map out ideas for the work I'm doing, or just pen and paper.
So there are a lot of variables to consider when you ask the question, "Is the guy who sits over there really doing his work?" You would really need to look at more running applications than just Visual Studio 2008 (devenv.exe). You would probably need to look at activity for processes associated with a developer's test framework, text documents, remote desktop connections to other machines, and even Firefox. (Firefox would be a huge judgment call as to whether somebody is actually working!)
As part of your research for the project, I would also suggest researching some of the other time collection systems that are in use throughout your company's industry and comparing their features.
有点偏离轨道，但您可能可以使用此类数据来阐明复杂性区域 (LOC)、容易发生变化的区域（相隔“n”天的频繁更新）等。这会因不同的程序员的开发方法而产生偏差。
A bit off track, but you could potentially use this sort of data to illuminate areas of complexity (LOC), areas that are prone to change (frequent updates 'n' days apart), etc. but even this would be skewed by different programmers approaches to development.
我们每天按项目跟踪所有时间。我每天只需要不到五分钟就能完成我正在做的事情。这不是可以自动化的，甚至不应该自动化的，因为它永远不会接近准确。文件并不总是只与一个项目相关联，如果我要花五分钟的时间来告诉应用程序哪些文件属于哪个项目，那么我会花费更多的时间来填写我的时间表。没有人花一整天的时间打字——有会议、电话和思考（你知道你在哪里弄清楚你想输入什么！），这些都不会被你的自动化系统捕获。你所提出的不会更准确，它会比要求人们每天填写时间表更不准确。
We track all our time by project daily. It takes me less than five minutes a day to fill out what I was working on. This is not something that can be automated or even should be automated as it will never be anywhere close to accurate. Files aren't always associated with just one project and it would cost me more time to tell an application which files belong to which project that the five minutes it takes to fill our my timesheet. No one spends the entire day typing - there are meetings and phone calls and thinking (you know where you figure out what you want to type!), none of that will be captured in your automated system. What you are porposing will not be more accurate, it will be less accurate than requiring people fill in time sheets daily.
虽然时间条目很重要，但弄清楚如何组织时间却是麻烦所在。非技术人员对开发的各个阶段的理解程度如何才能理解数据？我同意其他回复，即 IDE 跟踪是一个糟糕的主意，特别是如果正在做的部分工作涉及通过 Web 浏览器更改数据库，这就是我当前的大型 CMS 项目中的内容，我们可能必须更改模板或创建内容来测试功能是否有效。
这也严重忽视了可能发生的游戏系统想法。如果我让 IDE 在调试状态下保持打开状态，因为我想要扫描内存或执行其他操作，需要打开窗口才能实际查看某些内容，但我也可能离开了办公桌，除非您以某种方式跟踪我正在查看的位置和坐着。
While time entries are important, figuring out how to organize it is where trouble comes into the picture. How well would non-technical staff understand the various phases of development in order to understand the data? I'll agree with the other responses that the IDE tracking is a terrible idea, especially if part of what is being done involves changing a database through a web browser which is what I have in my current big CMS project where we may have to change templates or create content to test out if the functionality works.
This also heavily ignores the gaming the system idea that can happen. What if I leave my IDE open in debug because I'm wanting to scan memory or do something else that requires the window be open to actually look at something but I could also have left my desk unless you are somehow tracking where I'm looking and sitting.