[译]软件开发中个人生产力的差异

原文 https://www.construx.com/10x-software-development/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/

一些博客读者要求更多关于 “10x”名称由来的背景信息。这名称的主要是研究人员发现,具有相同经验的程序员或同一行业的不同团队之间,生产力和品质有10倍的差异。

软件开发中个人生产力的差异

Sackman, Erikson, and Grant (1968) 在 19世纪60年代末期的原始研究发现,个人的编程生产力有巨大差异。他们研究了平均有7年经验的程序员,最好与最差的程序员比率在初始编程时间的比例是 20:1;debug 时间的比率超过 25:1 ;程序大小比例是 5:1;程序执行时间是 10:1;他们发现程序员的经验与代码质量与生产力之间没有任何关系。

详细检查 Sackman, Erickson, and Grant 的实验会发现他们方法论的一些缺陷(包括将使用低级语言的程序员和高级语言的程序员的结果混在一起)。然而,即使考虑到这些缺陷,他们的数据仍然显示出最好的程序员与最坏的程序员之间的效率相差 10 倍。 自原始研究以来的这些年,得出普通的结论是“程序员之间存在数量级的差异”,并得到了很多专业的程序员证实。 (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000). 对程序员之间的巨大差异也有很多轶事支持。在20世纪80年代中期我在波音期间,有一个项目有大约80名程序员参与,有可能错过一个不能错过的截止日期。该项目对波音公司至关重要,因此他们将80名员工中的大多数人从该项目中移除,并带来了一个人,他完成所有编码并按时交付软件。我没有参与那个项??目,我不认识那个人,所以我不能100%肯定这个故事是真的。但是我从我信任的人那里听到了这个故事,当时似乎是真的是这样。 这种程序的差异不是软件行业独有。Norm Augustine 在一个研究中发现,在各种职业——写作,橄榄球,发明,警察工作和其他职业中——顶层的20%的人有能够50%的产出,产出可以是达阵,专利,解决的案例或者软件。当你想到这个时,这才有意义。我们都知道那些优秀的学生,杰出的运动员,杰出的艺术家,杰出的父母——这些差异是人类的经历的一部分;为什么我们会期待软件工程师会有所不同?

在坏的方面,个体的极端差异

Augustine 的研究发现,由于有些人没有做出任何实际意义上的贡献(没有达到触地得分的四分卫,没有专利的发明人,没有关闭案件的侦探等等),这些数据可能低估了生产力的实际变化。 但这在软件中似乎是正确的。在一些已发表的关于软件生产力的研究中,实验中大概有10%的受试者无法完成实验任务。在这些研究中,笔者写道:“因此那些实验对象的结果会被排出在我们数据集之外“。但在现实生活,如果某人“没有完成任务”,你就不能只是“将他们的数据排出在数据集之外”。你必须等待他们完成,分配其他人做他们的工作,等等。有趣(并让你恐惧)的是,软件开发那些10%中的人在他们项目实际上贡献是 负数 。 这与现实世界的经验很好地结合在一起。我想我们中的许多人都能想到我们和他工作过的,适合这个描述的特定人物。

软件开发中的团队生产力变化

软件专家长期观察到,团队的成产力和个人生产力的差异一样多——都是一个数量级(Mills 1983.)部分原因是好的程序员倾向于集中在一些组织,糟糕的程序员倾向于另一些组织,这一观察得到来自18个组织的166名程序的一项研究证实。(Demarco and Lister 1999) 在对七个相同项目的一项研究中,花费的努力比例是 3.4 :1 ,程序大小是 3:1 (Boehm, Gray, and Seewaldt 1984)。尽管生产力的范围很广,但在这项研究程序员们不是一个不同的群体。他们都是具有多年经验并且参加计算机科学研究生课程的专业程序员。有理由认为对不太同质的群体的研究会产生更大的差异。 一个对编程团队的早期研究表示,团队完成统一的项目的程序大小比率是 5:1,时间差异是 2.6:1 (Weinberg and Schulman 1974). 用超过20年的数据构建了 Cocomo II 评估模型回看,Barry Boehm 和其他的研究者得出的结论是,用团队中能力排15%的开发人员开发程序(效率)相当于排 90% 的 3.5 倍人月时间。如果一个团队在编程语言或应用领域或两者中都比另一个团队更有经验,那么差异会更大。 用一份特别的数据来指出成产力的不同,那就是 Lotus 123 版本和 Microsoft Excel 3.0。他们都在1989-1990 间完成的电子表格桌面程序。找到两家公司发布类似项目的数据的案例是很少见的,这让面对面比较(head-to-head comparison)特别有趣。在两个项目的结果如下,Excel 用了 50 个工作年的时间写了 649,000 行代码,而 Lotus 123 用了 260 个工作年的时候生产了 400,000 行代码。Excel 的团队每一个工作年产生大概 13,000 行代码,而 Lotus 团队每个工作年产生 1,500 行代码。这两个团队的生产力差异超过 8 倍,这数据支撑了不同个体及不同团队成产力有数量级差异,这一普遍主张。

你看到了什么?

您是否看到不同个体之间的能力差异为10; 1?不同的团队之间?你工作过的最好的程序员比最差的程序员好多少? 10:1甚至超过了范围吗? 我期待听到你的看法。

相关关联

Augustine, N. R. 1979. “Augustine’s Laws and Major System Development Programs.” Defense Systems Management Review: 50-76.

Boehm, Barry W., and Philip N. Papaccio. 1988. “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.

Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. “Prototyping Versus Specifying: A Multiproject Experiment.” IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.

Card, David N. 1987. “A Software Technology Evaluation Program.” Information and Software Technology 29, no. 6 (July/August): 291-300.

Curtis, Bill. 1981. “Substantiating Programmer Variability.” Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. “Software Psychology: The Need for an Interdisciplinary Program.” Proceedings of the IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, and Timothy Lister. 1985. “Programmer Performance and the Effects of the Workplace.” Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.

Sackman, H., W.J. Erikson, and E. E. Grant. 1968. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.” Communications of the ACM 11, no. 1 (January): 3-11.

Valett, J., and F. E. McGarry. 1989. “A Summary of Software Measurement Experiences in the Software Engineering Laboratory.” Journal of Systems and Software 9, no. 2 (February): 137-48.

原文地址:https://www.cnblogs.com/jojo-feed/p/10163829.html

时间: 2024-10-03 07:10:36

[译]软件开发中个人生产力的差异的相关文章

现代软件开发中现代软件工程的合理运用

进入新时期以来,我国的社会经济水平与科学技术发展水平都上升到了一个新的高度,不论是在社会生产中还是在日常生活中,计算机信息技术都得到了普遍的运用.而计算机信息技术主要是在软件的支持下进行系统运行的现代科学技术,在现代软件开发中,现代软件的整体特点与结构都会对现代软件工程在其中的应用产生重大的影响,因此,必须要采用最合适的软件工程方法,让现代软件工程在现代软件开发中得到更加合理的应用.

[阮一峰]在软件开发中,一旦这些技术被取代,你的知识将变得毫无价值,因为它们大部分都是实施的细节。

原文:http://www.ruanyifeng.com/blog/2018/10/weekly-issue-28.html 在软件开发中,技术变化如此之快,你花费了大量时间学习技术和工具,一旦这些技术被取代,你的知识将变得毫无价值,因为它们大部分都是实施的细节. 我最近总是在想这段话,软件开发算不算是真正的知识? 如果它是一种真正的知识,那么理论上,我们学到的东西大部分应该不会过时,就好像微积分不会过时一样.可是实际上,我们都知道,软件开发技能有时效性,十年前学习的编程知识,十年后几乎肯定不能

09.精益敏捷项目管理——敏捷软件开发中QA角色

00.当从鳄鱼嘴里侥幸逃脱时,你很难机器你的初衷其实只是想排出沼泽中的积水. 01.精益--敏捷软件开发中质量保证(Quality Assurance,QA)的角色展开,涵盖了许多关键问题 *测试人员的作用是防止缺陷,而不是发现缺陷 *开始做开发周期计划时如何发挥验收测试的作用,以做到在最大限度上减少浪费 *在早起不容易去做测试时做些什么 02.质量保证和质量控制 a.质量康芝是确保产品或服务被设计和生产出来,满足或超越客户需求的做法 b.质量保证是指由计划的.系统的生产过程,为产品符合预期目的

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

软件开发中几个基本概念

软件开发中几个基本概念 Peixu.Zhu 自己真的深切理解那些经常挂在嘴边的概念么? 抽象 Abstract 抽象的特点是仅存在于思想和理论之中,而非物理或者具体的存在.(不是指C++中的抽象类) 抽象是永存的,不会随着时空而发生变化. 具体 Concrete 具体的特点是物化的或者是具备物理形态,是真实存在的. 具体不是永存的,是随着时空而发生变化的,仅存于具体的时空之中. 具体和抽象的最大区别是是否随着时空而发生变化,即是否存在于我们的四维空间. 实体 Entity 实体是单独的个体事物(

软件开发中,什么是模块化开发?

软件产品可以被看作是由一系列具有特定功能的组件组成,作为一个完整的系统也可以被分解成一系列功能模块,这些模块之间的相互作用就形成了系统的所有功能. 所谓模块是指可组成系统的.具有某种确定独立功能的半自律性的子系统,可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统.每个模块的研发和改进都独立于其他模块的研发和改进,每个模块所特有的信息处理过程都被包含在模块的内部,如同一个"黑箱",但是有一个或数个通用的标准界面与系统或其他模块相互连接. 在软件的模块化开发

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的