Questions tagged «productivity»

生产率是生产过程中每单位输入的产出的度量。

7
给新员工一个与经验丰富的开发人员分开的子项目是否可以帮助新手更快地成长?
我们的团队有7个开发人员,需要在短时间内(大约一个月)将开发速度提高一倍。我知道有一个常识性规则,即“如果雇用更多开发人员,则只会在头几个月损失生产力”。该项目是一个电子商务Web服务,大约有27万行代码。 我现在的想法是将项目分为大约两个独立的子项目,让新团队在两个子项目中的较小者上工作,而当前团队在主项目上工作。即,新团队将致力于结帐功能,最终将成为独立的Web服务,以减少耦合。这样,新团队就可以在只有10万行代码的项目上工作。 我的问题是:这种方法是否可以帮助新手开发人员轻松适应新项目?还有什么其他方法可以快速扩展开发团队,而不必等两个月,直到新手开始生产更多的软件,然后再开发bug。 ======= 更新 这家企业完全失败了,但并不是因为你们提到的原因。首先,我对新团队的规模和能力不了解。我本应该对它们进行评估。其次,在该站点招聘人才是一项艰巨的工作。在总公司所在地,招聘要容易得多,但是在第二团队的城市中,显然缺少具有所需资格的开发商。结果,工作时间从原来的1.5个月延长到了4.5个月左右,并被高层管理人员取消。 我犯的另一个错误(Alex D曾警告过)是我试图将重构出售给高层管理人员。您从不出售重构,而仅出售功能。 事实证明该启动是成功的。从未发生过的重构变成了技术债务:系统变得更加单一且难以维护,开发人员的生产力逐渐下降。我现在不在团队中,但是我希望他们能在不久的将来完成它。否则,我不会为该项目的成败做出任何贡献。


11
开发人员应该接受Excel宏完成的工作量估算吗?
在一个新项目中,一个朋友必须编写测试,编写测试所需的时间是由他的非开发人员经理编写的Excel宏计算出来的。 在这种情况下,开发人员是否应承担在计算的时间内编写和运行测试的责任?这些测试的结果值得信赖吗? 为了提供信息,我的朋友拒绝对他未做的估算负责,要求成功完成另一个项目,并由经验不足的校外“老兄”代替。

8
哪个工作间隔生产率更高:短期还是长期?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 哪段工作对编程更有效率:短(<= 30分钟),中长或长(> = 2小时)?在什么情况下?(考虑对新功能进行编码,做一些小的修改,调整UI,重构,调试,学习API,尝试理解他人的代码)。 您可以从自己的经历中看出什么?来自研究和最佳实践的信息也非常受欢迎。虽然很高兴看到链接或引用。 可靠信息胜于完整答案。 有价值的外卖: 集中思考是这里的最终目标 一般情况下,不间断的工作(> 2-3小时)会失去焦点和模糊的想法 当您流中时,最好让自己工作1-2个小时 值得尝试Pomodoro技术,以帮助克服思维的惯性和拖延,以获得更好的时间感。特别是可以帮助您开始做您不喜欢做的事情 当使用“休息管理”软件时,您可以让自己更加灵活,例如跳过1个休息,但不能更多。这使您能够适应以下情况:在流程中,有流程时,在不流程时保持可管理 休息期间的新鲜空气,放松和锻炼可以帮助使右半球参与进来,从而获得新的想法和解决方案 尝试用于“中断管理”的软件工具: Pomodairo-它另外跟踪任务列表并具有pice UI WorkRave-提供更大的配置灵活性。没有扬声器也可以使用

10
为什么有时不考虑错误会帮助您解决它?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 5年前关闭。 昨天我花了很大一部分时间来修复一个我认为微不足道的错误。我绕圈转,不知道哪里出了问题。重写大部分代码。正在检查SO。仍然没有喜悦。 于是我回家,walk狗,看电视,在我睡觉之前,宾果游戏我意识到我犯的一个明显错误。今天早上,修复大约花了10分钟。 当我在家时,我并没有积极考虑这个问题。然而,摆脱困境使我得以解决。 这不是第一次发生,我知道这是解决编程问题的相当普遍的方法。我什至听说有人梦想着答案。 为什么这样做? 也许更重要的是,对于何时应该解决问题,应该休息多长时间以及问题离开多长时间后才有效,是否有很好的指南? 我想我正在尝试找出如何优化这种潜意识处理(或正在发生的一切)

3
Visual Studio只是一个IDE吗?
对于Windows开发,我的意思是。 查看其他问题,还有VS的替代品,但它们似乎是基于Web的替代品,这很好,或者,如果您愿意,您可以在记事本中编写整个.net网站。 但是,除了Windows开发的IDE之外,还有更多功能吗?IE浏览器是否可以在记事本中创建应用程序,Visual Studio的编译器部分还是单独的部分(可以通过命令行或其他方式调用)? 我不想不使用VS,我对它感到满意,做了我需要做的事等等,只是我好奇的一个方面。

6
Eclipse中Java的顶级开发人员生产力工具/插件是什么?
已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它目前不接受新的答案或互动。 我个人使用Visual Studio 2010中的CodeRush进行重构,使用模板编写代码的速度更快,并且通常浏览我的代码的速度比普通VS快10倍。最近,我一直在开发另一个Android应用程序,并开始思考... Eclipse的顶级生产力插件是什么? 最好是免费的。我正在寻找可以用Java而不是PHP或Rails或Eclipse支持的任何其他语言编写的插件。

8
强制执行的专业发展计划有用吗?
许多公司,尤其是大型公司,都为员工制定了强制性的职业发展计划。员工和经理制定了个性化的专业发展计划,并经常跟踪进度。 作为开发人员,您认为这样的PDP有用吗?您是否遵守承诺? 作为经理,您是否认为这样的PDP为公司带来价值并提高员工的整体素质? 好的开发者似乎将继续自我教育,并努力变得更好,无论公司采取何种程序,而不好的则不会。 拥有PDP是否有好处?或者仅仅是管理人员认为他们需要做的事情?

29
什么会使开发人员放慢速度?[关闭]
按照目前的情况,这个问题并不适合我们的问答形式。我们希望答案得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它目前不接受新的答案或互动。 什么事情会使开发人员放慢脚步? 请尽量避免发布以下答案: 现在速度很慢,但在功能中很有用。(TDD,重构等) 列出干扰。

1
是否有关于注释源代码对软件质量,可维护性和开发人员生产力的影响的经验研究?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 6年前关闭。 我主张对源代码进行评论并记录软件产品。根据我的个人经验和观察,在必须开发软件或维护软件的过程中,对经过严格注释的源代码进行的工作以不同的方式帮助了我。 但是,还有一个阵营说评论最终毫无价值,或者其价值值得怀疑。许多不加评论的编码支持者认为: 如果一段代码写得很好,那是自我解释,因此不需要注释 如果一段代码不是不言自明的,则对其进行重构并使其变得不言自明,以便它不需要任何注释 您的测试套件就是您的实时文档 随着时间的流逝,代码和注释不同步,这成为令人头疼的另一个原因 敏捷表示工作代码比大量文档更重要,因此我们可以放心地忽略编写注释 对我来说,这只是教条。再次,我个人的观察是,由才华横溢,经验丰富的开发人员团队编写的软件最终最终会产生大量不言自明的代码。 同样,Java API,Cocoa API,Android API等表明,如果您要编写和维护高质量的文档,则可以实现。 综上所述,基于个人信念的有关文档优缺点的讨论以及对源代码的评论通常不会以良好的结局而无法得出令人满意的结论。 因此,我正在寻找有关软件文档(尤其是注释源代码)对其质量和可维护性及其对团队生产力的影响的影响的学术论文和实证研究。 您是否偶然发现了此类文章?如果有的话,结果如何?

8
高分辨率笔记本电脑显示器对程序员重要吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 5年前关闭。 已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它目前不接受新的答案或互动。 我要购买一台主要用于编程的新笔记本电脑。华硕Zenbook UX31A和新的Retina Macbook Pro确实让我很感兴趣。显然,这些笔记本电脑上的高分辨率显示器可用于娱乐,照片编辑等。我的问题是:这些显示器对程序员有没有好处?这些显示是否使代码更易于阅读?整整盯着屏幕一整天,它们在眼睛上是否还轻松?

3
我可以使用哪些论点将BDD概念“出售”给不愿意采用它的团队?
我有点支持“行为驱动开发”方法论(又名BDD)。我已经使用BDD已有两年了,并且在开发DotNet应用程序时采用StoryQ作为我的首选框架。即使我已经进行了多年的单元测试,并且以前已经转向测试优先的方法,但我发现使用BDD框架会带来更多的价值,因为我的测试抓住了相对而言需求的意图。在我的代码中清除英语,并且因为我的测试可以执行多个断言而无需在测试进行到一半时结束测试-这意味着我可以一目了然地查看哪些特定断言通过/失败,而无需进行调试即可证明。 对于我来说,这确实是冰山一角,因为我还注意到,我能够以更有针对性的方式调试测试和实现代码,从而提高了我的生产力,并且我可以如果由于输出进入构建日志而导致问题一直困扰到集成构建,则可以轻松确定发生故障的位置。此外,StoryQ api具有很好的流利语法,易于学习,并且可以以多种方式应用,不需要外部依赖就可以使用它。 因此,有了所有这些好处,您会认为很容易将概念引入团队其他成员。不幸的是,其他团队成员甚至都不愿看StoryStorQ来对其进行正确评估(更不用说应用BDD的想法了),并说服彼此尝试从我们自己的核心测试框架中删除许多StoryQ元素,甚至尽管他们最初支持使用StoryQ,但是即使他们希望删除的代码也不会影响我们测试系统的任何其他部分。这样做将最终导致整体上显着增加我的工作量,并且确实与实际情况背道而驰,因为我通过实践经验深信,这是在特定的工作环境中以“测试优先”的方式工作的更好方法,只会导致更大的工作量。鉴于以下情况,我们的软件质量得到了改善 我们发现更容易坚持使用BDD进行测试。为了进一步澄清,我们大多数的单元测试往往都很脆弱且难以维护,多年来由于应用程序测试不佳而导致的结果是,由于不愿坚持测试驱动的流程,开发人员退回到了旧习惯,在项目结束时进行所有测试(这些人声称自己是敏捷的!)。 因此,问题实际上归结为以下几点: 我可以使用哪些论点来真正说明这个团队使用StoryQ或至少采用BDD方法会更好? 您能否指出我能用来支持我的论点以采用BDD作为我们的标准选择方法的任何轶事证据? 您能想到什么相反的论点,这可能表明我希望鼓励团队采用BDD的想法可能是错误的?是的,只要论据是合理的,我很高兴被证明是错误的。 注意:我并不是在主张我们全面重写测试,而只是为了以后的所有测试工作而以不同的方式开始工作,最好以与客户互动的方式开始。 对于希望进一步了解BDD的人来说,以下链接可能会有用: http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/简介 对于那些对更多细节感兴趣的人,我们是一个由4人组成的小型团队,致力于大约5个大型项目。BDD的“试验”最初进行了大约2个月,随后又进行了大约4个月。团队接受了我应该继续以这种方式工作并进行自己的尝试。自试验结束以来,我一直从事BDD工作约两年,而其他人则非常擅长回避问题。我不是在问题上施加“对抗”,而是在寻找一种方法来温和地说服团队摆脱集体的落后,并抽出时间来做好自己的工作。

6
什么时候会放弃向后兼容,而支持新的和改进的接口实现?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我在同一家软件公司工作了十多年。结果,我已经使用各种面向对象的编程语言实现了大型代码库。当我刚开始我的职业生涯时,我是一名初学者,对良好的界面和类设计原则了解不多。我想认为我的设计技能已经随着时间的推移而得到了提高,但是由于对后向兼容性的考虑,现在在改进我的早期代码方面面临越来越多的困难。我的代码已被许多客户用作我公司销售产品的一部分。 我的问题是:什么时候应该停止尝试保持旧接口的向后兼容性并硬着头皮去支持实现一种全新的设计? 我认为,保持向后兼容性成为一个沉重的负担,以致无法对接口进行有用的更改。有谁遇到过类似的问题,谁可以提供一些反馈?

2
利用“空闲时间”开发创造力
一些公司惊奇地发现,程序员是非常有创造力的人。例如,我想到的是Google和Atlassian,他们允许定期(我相信每月)的“自由日”,使程序员可以按自己的意愿进行工作(获得批准),而公司则可以从中获得回报。 引用的示例包括新产品,以前没有人希望修复的错误修复,新团队的形成等。另一个结果(也许是最初的目标)是,在业余时间之间的剩余日子里,程序员有更多的动力。 该理论是否还有更多的支持,那就是允许“受控的”创造性输出有益于激励和士气,或者是使用该方法获得成功的更多示例?

13
您是否允许程序员使用Messenger和Facebook等社交网络?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我有很多老板,每个人对于允许或不使用Windows Live Messenger,Facebook和许多其他Internet网站都有不同的方法。 当然,确实需要Internet来研究解决特定任务的最佳方法。有时您可能在网上有一个朋友,还有一个程序员,他对某些事情了解得更多。 对于某些经理来说,互联网访问会减慢项目进度,另一方面,它使人们可以进行交互并找到全新的解决方案。 你会怎么做?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.