您的工作日花了多少时间用于编码?

时间:2008-08-16 20:30:56

标签: estimation time-management

我最近一直在考虑软件估算,而且我对编码时间有很多疑问。我很想知道至少有几年开发软件经验的人。

当你必须估计你在某件事上花费的时间时,你花了多少时间进行编码?占用其他非编码时间的是什么?

您是否发现您花费的时间比您的队友编码更多或更少?你是否觉得自己的工作比他们更多或更少?

你的工作条件是什么样的?私人办公室,共享办公室,团队室?单独编码还是成对编码?您的工作条件如何改变您每天编码的时间?如果你可以在家工作,这有助于或损害你的工作效率吗?

您使用什么开发方法?瀑布?敏捷?从一种方法改为另一种方法对每天的编码时间有影响吗?

最重要的是:您对自己的工作效率满意吗?如果没有,你会做出什么样的改变会对它产生最大的影响?

9 个答案:

答案 0 :(得分:20)

我是一名企业开发人员,Joel Spolsky在一些StackOverflow播客中称之为“郁闷”。由于我的公司不是软件公司,因此几乎没有商业理由来实施软件专家建议公司参与开发人员生产力的许多措施。

我们没有私人办公室和双30英寸显示器。我们的源代码控制系统是Microsoft Visual Source Safe。说够了。另一方面,我做了很多事情,填补了我的一天,并为我的工作增添了一些变化。我参与了业务分析,项目管理,开发,生产支持,国际实施,培训支持,团队规划和流程改进。

我会说我有85%的时间用于编码,当我可以专注并且我有一个重要的编程任务。但更常见的是,我每天约有50%用于编码。如果生产支持(非编码相关)很重,我可能只有15%的时间来编码。

我所工作过的大多数公司都没有积极参与评估敏捷流程或测试驱动开发,但他们也没有做好瀑布方面的工作。他们的大多数开发人员都喜欢剪贴糊涂的牛仔。

有时候我会在家里和孩子一起工作,这是可怕的。我的工作效率更高。

我的生产力很好,但如果去除心理背景转换的中断因素和成本可能会更好。生产支持和项目管理开销都会产生这些类型的中断。但两者都是工作的必要部分,所以我认为我不能摆脱它们。我想考虑的是对团队进行重组,以便项目上的人可以专注于项目,而其他人可以通过致力于支持来阻止中断。然后在项目结束时进行交换。

不幸的是,没有人想要支持,所以我希望的其他生产力改进措施将是以下之一:

  • 更好的测试工具/方法以加快单元测试
  • 更好的业务分析工具/技能,以提高新开发的质量并限制其对生产支持负载的贡献

答案 1 :(得分:16)

实际上,它平均每天可能达到4或5小时。虽然它的“块状” - 可能有几天可能有8或9个小时。

在我所知道的所有软件开发人员中,编写生产代码(与研究相反)4到5的软件开发人员似乎是实际编码的最大值。还有很多其他的东西在继续。

说实话,有很多拖延。我发现它有点像作家块。有时它很难开始,但是一个很好的2小时会议是很多工作。它只是你必须经历的所有准备工作,以确保你采取正确的方法的实验。无数的盯着窗外看电子邮件等......

答案 2 :(得分:6)

我每周工作37.5小时 其中30个小时(80%)我应该向我们的客户收费 实际上,我发现我在实际的客户端系统上使用了大约60%的编码,20%的人使用新技术和阅读博客,20%的人浪费在办公室政治和“社交”上。

我对此感到高兴吗? 我是否希望我能够每周30小时盯着屏幕编码我的指定作业?

好。由于20%的时间用于改善自己的工艺,在有效编码的60%中,如果不这样做,我可能比90%的时间产生更多。 然后再尝试向上级解释这个事实;)

答案 3 :(得分:6)

  嗯,我通常至少会进来   迟到十五分钟啊,我用了   侧门 - 那种方式Lumbergh不能   看到我,嘿嘿 - 呃,在那之后   我只是想出一个空间   小时。

     

...是的,我只是盯着我的桌子;但   看起来我在工作。我这样做   午饭后大概再过一个小时   太。我会在一个星期内说我   可能只做了大约十五分钟   真实的,实际的,工作的。

对我来说,在项目之间切换是拖延的一个重要原因。当我刚完成一个项目时,我倾向于拖延下一个分配给我的要求。我的想法仍然像编码模式,但我必须首先估计创建规范的费用。因此,我必须从编码切换到呼叫客户等,这让人觉得不舒服。

在生产力方面最能帮助我的是在一天的头几个小时内减少任何分心,并立即开始当天最重要的任务。我需要尽早进入流程。


我建议你看看The Programmers'Stone:

We know that stress impairs some cognitive functions. The loss of those functions can precisely explain why programming is hard, and show us many other opportunities to improve the ways we organize things. The consequences roll out to touch language, logic and cultural norms. Click here for the Introduction...

答案 4 :(得分:5)

我花了大约40%的时间编码。 40%用于非编码活动(例如与我们粗略的构建服务器进行斗争,或者弄清楚为什么NUnit失败而没有再次出现错误信息,或者试图弄清楚为什么我们的代码已经停止与Oracle服务器联系下来了...像那样的垃圾)。另外20%通常用于拖延或会议。

我对自己的工作效率感到满意吗?绝对不。我每天工作7小时,我花了大约2.5的编码。我宁愿花费5-6个小时进行编码,只需要一个小时专门用于所有其他内容(遗憾的是,有一件事情会发生这种情况 - PM停止每天使用构建脚本 - - 不会发生)。不幸的是,由于我是一名企业开发人员,管理层并没有把时间浪费掉。因为我在这一天的40%中完成了比在建筑物中大多数无人机在一周内完成(包括PM)所做的更多的工作,他们认为我很有成效。

答案 5 :(得分:3)

@Bernard Dy:我的职业生涯大概有30%用于公司环境(目前还没有)。通常是在经历了一些失败(或者没有失败,但失败了)之后开始了想法,或某种倦怠/改变。一点也不错,很高兴见到来自完全不同背景的人(他们会认为律师和精算师可以非常有趣地与他们一起玩),但最后,我发现它太难获得了早上有动力(或假期后恐惧回来) - 可能是因为你定义的原因(只是缺乏关心)。但它至少有良好的经验和思想来源。而且你可以在世界各地遇到聪明的人(不仅仅是聪明的程序员 - 我总是试图找出真正的大脑背后的企业)。

有趣的是,我唯一一次练习严格的敏捷/ XP是在公司环境中 - 在这种情况下,每天大概7个小时是实际的代码(成对) - 经过一天的努力,我从未如此疲惫。不确定这是不是一件好事,也许我只是懒惰。

答案 6 :(得分:2)

回答我自己的一些问题:

我所在的现有团队只进行粗略的任务估算,因此很难跟踪每天的小时数。我想说,在我的职业生涯中,编码所花费的时间一直在25%(主要是管理层)到85%以上(每周4天在家工作,每周一次聚会半天)。但是,如果我不得不猜测,平均值可能在60%左右。

对编码时间的最大影响是会议的存在与否。当我与同一个房间里的每个人一起开展敏捷项目时,会议往往是临时的,而且很短,因此编码的时间非常长。当我在团队房间时,我也觉得我花了更少的时间 - 有时候花很少的时间 - 做非编码的事情,因为当没有人清楚地看到你的显示器时,更容易浪费时间,不小心或其他。 :)

答案 7 :(得分:2)

我做外包,基本上我整天编码,我有两个项目,我没有太多时间做任何其他事情,这意味着我不能做更多的工作,因为我无法完成任何事情,这是一个良好的政策,你应该尽可能采取。

还要记住,你应该有空余时间,非常重要的是要充分休息,因为如果你不这样做,你将不会很有效率。关键在于规划和纪律。

在我的非编码时间,我和我的妻子一起度过,我也喜欢走出城镇,尽量不去思考我的项目,我越是平衡,我就越有效率。

当我没有多少工作时,我喜欢阅读编程博客,我也喜欢学习编程。

最后我想说恕我直言,我们的角色不应该被看作是一部作品,相反你应该把它看成是有趣的事情。

答案 8 :(得分:1)

我是R& D部门的软件开发人员,每周工作40小时。

我花了...我的时间的10%实际编码。 在我的非编码时间里,我主要测试,评估,比较和记录结果。我还花了很多时间为我将编写的代码编写规范并研究我将编写的代码,参与当前项目的头脑风暴会议等。

我可以说,从我的队友(也是软件开发人员)那里,我是目前编码最多的人;但取决于我们每次工作的任务。 我不会将实际编码量化为努力工作。如果有一个良好的规范,适当的研究和对项目的良好理解,编码只是formality并且几乎可以顺利和快速地进行。

在这里,我们有一个分散的办公室,有两个团队。我们大多是单独编码,很少在一对。我的工作改变了我编码的时间;在过去,我花了大部分时间编写代码,但没有很好地理解编码。如果我有一个任务,我会立即开始编码,并在每次我意识到我做错了什么时重新编码等等。它效率很低。

现在,开发方法介于原型和螺旋之间。它明显改变了我编码的小时数。

我对自己的工作效率感到满意,与我的截止日期和目标相关。