2023年开发者蓬勃发展白皮书

Introduction 每篇白皮书都将包含基于我们关于健康测量如何受益软件团队所学知识的具体建议，您可以立即付诸实践。 开发者成功实验室（Developer Success Lab）在Pluralsight Flow设立的研究旨在探讨开发者及其团队如何保持生产力、进行深入且合作的工作，并产生实际影响。本白皮书总结了对软件团队进行的三次深度研究的第一项成果，展示了现实世界中开发者及其团队如何取得成功。 在研究 2 中 ， 我们更深入地研究如何可见性贡献了个体和团队成员改进的参与度、表现力和生产力。我们还探讨了预期和预见认可时刻如何影响开发人员的动力、参与度和生产力。 在研究 1 中 ， 在本白皮书中讨论 ， 我们 ： 跨定量数据1, 282 名开发人员和丰富的定性数据15 + 小时在访谈和焦点小组的对话中 ， 我们分享以下发现 ： 提供有关如何使用此框架来提高生产力和开发人员满意度的建议解释其与开发人员生产力的联系介绍开发人员繁荣框架 在研究 3 中 ， 开发人员如何体验他们的工作环境 我们分享关于如何以正确的方式使用正确的软件指标的建议。我们从我们的发现开始 ，尽管87% 的开发者相信使用指标来衡量他们的工作的好处 ， 只有20 - 30% 的开发者报告在始终使用团队级软件的团队中 学习文化 ， 机构 ， 动机和归属感的经验如何影响开发人员的生产力 开发人员用来导航这些复杂环境的策略 这种紧张关系给工程领导者留下了一个问题 ： metrics. From there we explain how increased测量带来积极成果 ，包括 ： • 如何在不牺牲开发人员体验的情况下最大限度地提高生产力以满足业务需求 ？ 更多的同情和自我同情在开发人员中具有更大的价值和掌握感提高应对能力和痛苦承受能力 在本文中 ， 我们认为这两个目标可以用相同的解决方案来实现 ：开发人员蓬勃发展。 我们的研究发现 ： • 强调协作解决问题的团队文化可产生可持续的高质量软件工作。 故事 1 开发人员蓬勃发展 ：在软件开发团队中解锁生产力所需的唯一框架 •.开发人员蓬勃发展的框架 (基于健壮的社会认知研究进一步解释表 1) is a强预测因子开发人员生产力 •开发人员的蓬勃发展分数没有很大差异根据多年的编码、工程角色类型和行业 ，表明开发人员繁荣中的措施可以是适用于各种类型的工程工作和不同的组织。 当今的工程领导者面临着一个重大难题 我们今天看到了工程测量领域的两个主要趋势 ： 在论文的其余部分中 ， 我们深入研究 ： • 更加关注团队健康和开发人员经验,为了招募和留住最优秀的软件工程人才 ••• 为什么需要这种研究Developer Thriving 框架的每个组件关于如何利用开发人员繁荣的建议框架来提高你的团队的成功 • 考虑到经济衰退 ， 对工程生产力进行更严格的审查 ， 并需要用更少的资源做更多的事情 开发者 thriving 评分在不同年份的编码经验、工程角色类型以及不同行业中没有显著差异，这表明 Developer Thriving 的衡量指标可以应用于各种类型的工程工作和不同的组织。 满意度和福祉、绩效以及活动系统地扩展了“生产率”的定义，将其涵盖维度扩展至如工作满意度等。 我们今天如何看待开发人员的体验有什么问题 ？ 我们认为领导者在尝试提高组织开发者生产力时会遇到两种测量陷阱： 虽然SPACE框架将满意度视为生产力的关键组成部分，但它并未解释开发者实际满意度的真实来源。 • Fixating on surface definitions of productivity and测量和激励错误的东西 这导致开发者、管理人员和工程领导者对如何分解和诊断开发人员体验与整体团队生产力之间的关联缺乏理解。 • 因复杂性和背景而瘫痪测量和激励什么 为了突破这些测量陷阱，我们可以借鉴近期的一系列软件研究，将开发者生产力置于以人为本、基于实证科学的基础之上。 这是我们研究的答案。 • 从基础证据中学习如何在编码和软件工作中真正提高解决问题的能力 Developer Thriving 框架有哪些组件 ？ • 直接研究现代软件团队的真实体验 开发人员蓬勃发展基于已知的开发者满意度与生产力之间的联系进行构建。但它更进一步，有助于解答最初驱动满意度的因素是什么。 • 避免在衡量生产力时出现重大误解，例如仅将开发人员生产力定义为粗略的产出指标（如代码行数），或者设定单一目标度量标准，并将其作为评估所有软件工作的门槛，而不考虑不同的背景和需求。 为了构建这一框架，我们调研了广泛的人类成就和福祉研究。基于我们的发现，我们开发出了四个关键可衡量的开发者体验要素。每个要素都借鉴了已被证明直接促进人类问题解决和成就的理论，并将其适应于软件团队（）。表 1). TheSPACE 框架可能是此类研究中最著名的成果之一。该框架（Forsgren等，2021；Storey等，2021），从开发者生产力的角度对该问题进行了 characterization。 一个 “蓬勃发展 ” 的软件团队拥有其环境中的每个元素。 我们将在下文定义Developer Thriving框架的四个要素，并包含一个引述，展示我们焦点小组中IC（个体贡献者）和管理人员是如何描述这些要素的： • 支持和归属感 开发者是 ： 1. 在工作中编写代码时受到激励 2. 大部分时间都能看到实际进展 3. 在他们想要工作的代码类型上工作4. 对于即使工作出乎意料地困难，也能解决自己的问题充满信心 开发者 ： 1Agency 1. 能够表达对团队成功定义的异议 2.对如何衡量他们的贡献有发言权 2动机和自我效能感 在一个鼓励发言的环境中，如果你认为可能需要探索另一个方向，你会希望表达自己的意见。 我希望获得认可，认为自己是一名出色的问题解决者。我希望被赋予需要解决的问题，而不是直接给出解决方案并被告知去实施。只有这样才能迈向技术领导力。 - IC 参与者 ， 焦点小组 - IC 参与者 ， 访谈 1. 在团队的成长、学习和犯错过程中得到支持2. 有信心团队接受他们的真实自我 1. 学习新技能 2. 能够分享工作中学到的东西 4支持和归属 学习文化拥有这段学习的时间让我在实际编写代码的任务中更加自信，我认为这最终使我更加成功。 当我感到安全时，是因为我的想法和贡献被同等重视……无论是对于一个建筑师、在公司工作了15年并构建了一切的基础人员，还是一个刚刚加入的实习生。 - IC 参与者 ， 访谈 - IC 参与者 ， 访谈 我们相信开发者繁荣框架的组件是有影响力的 ， 因为它们创造了“良性循环 ”： 关于代码工作和解决问题的积极信念、看法和期望。 这些周期性活动有助于强化开发者对于进步和解决问题的感觉，即使并且尤其是在开发者遇到困难、阻碍以及失败时。 此外，通过在团队中促进良好的问题解决，这些良性循环为组织提供了一种可扩展且适用于不同情境的方式以提高生产效率。 我们的研究发现 ， 这些良性循环在可见性and软件措施被纳入团队的习惯和仪式中（请参见下方图表）。我们将在此系列白皮书的后续部分深入探讨可见性以及软件度量的重要性。 由“开发者繁荣”的文化解锁的“良性循环”提供了摆脱我们之前介绍的“开发者生产力”测量陷阱中最有效的方式： 1. 固定表面定义的生产力和测量和激励错误的东西 2. 变得瘫痪的复杂性和背景和测量和激励什么 学会识别这些周期给了工程领导者和软件团队一个起点，以诊断促进繁荣的障碍，并使保护这些繁荣的价值最高的实践变得可见。 IC 开发人员和经理描述的工程组织内部的 “可见性周期 ” 。 团队建设，考虑充足的學習時間、強有力的支持文化、提供 Feedback 的机会，以及對解決困難問題的认可。 您今天可以做些什么来在不牺牲开发人员体验的情况下最大限度地提高生产力 推动变革和决策的指标 ， 并确保随着时间的推移和跨项目跟踪长期影响。 Organizations应投资于明确认可并奖励团队所取得的技术进步的系统，特别是那些意外具有挑战性、需要新技能或解决了长期问题的工作。 开发人员的繁荣是生产力的有力预测指标。 采取这些步骤有望改善开发人员体验和代码速度，并减少解决问题过程中的障碍。 开发人员应意识到他们在关键的合作时刻，如代码审查和团队回顾会议中，是否在支持队友的学习、归属感以及其它关键因素。 当团队成员、经理和组织看到并认可他们的工作时 ， 开发人员就会受益。 经理旨在提高生产力应当诊断团队中可能存在的开发者繁荣要素缺口，记录基线数据并倡导投资开发者繁荣因素。 领导者应该诊断其工程组织内部是否存在“可见性缺口”，特别注意那些目前尚未获得广泛认可的团队或类型的工程工作。 通过遵循上述内容 ， 组织可以快速走上提高员工满意度和保留率的快车道。 在接下来的页面中，我们包含了更多建议，您和您的团队可以采用这些建议来改进开发者繁荣框架中的每个组成部分。 Organizations应致力于监控工程功能如何实现开发人员之间和之间的繁荣 领导者和管理者应该评估工程努力是否用 提升或降低 开发人员蓬勃发展 ：我们研究的建议 较低的机构 用于评估所有工程工作的一系列指标，但仅适用于部分情况，例如未能认识到某些团队的遗留系统所面临的约束。 对开发人员的工作和流程的突然和不可预测的中断， 例如频繁的主动重定向 电梯机构 团队和组织级对开发人员驱动的计划的认可 ， 例如代码 “清理 ” 缺乏以开发人员为中心的文档来帮助进入新的代码库和代码库的不熟悉部分 团队和管理者定期讨论目标和成功定义，认识到软件团队追求多个目标。 在不考虑经验、团队需求和组织摩擦等环境因素的情况下，严格定义开发者的成功标准。 将测量融入团队现有的软件流程中，并为开发人员提供一个平台，以便他们可以为指标变化添加上下文。 企业在决策过程中未能认识到给定问题空间中可能存在多种技术方法，并在评估和测试之前惩罚开发人员没有选择“正确”的方法。 较低的动机和自我效能感 当团队层面的规划未能适应并奖励解决意外困难代码工作（如问题triaging和调试）的时刻时， 提升动机和自我效能感 开发者会追踪其编码过程的某些部分，并反思工作节奏是否以出人意料的方式受阻。 分配大型、复杂或模糊的任务 ， 而不提供足够的支持、时间或资源 初级开发人员在加入新团队和代码库时经常获得可实现的 “胜利 ” 持续的功能范围蔓延和计划时刻与评估时刻用于评价“优质工作”的指标的快速变化 出乎常规或意想不到的问题解决方法受到技术主管及其他有影响力的资深同事的注意和赞赏。 管理人员检查不频繁，导致需要多次“重启”以及开发人员在沟通进度时存在效率低下问题。 较低的学习文化 提升学习文化 阻碍文档和其他形式的长期知识共享 团队鼓励配对编程和围攻 ， 并在开发人员之间共享“支持 ” 工作的功劳 强调仅反映数量的生产效率指标，忽视了对质量和努力的认可。 稳定的代码审查流程，鼓励资深开发者与初级开发者之间提供有意义的反馈。 未能承认“时间成本”在确定潜在解决方案中的必要贡献是技术工作中有时必不可少的组成部分。 经理或技术负责人给予开发者空间探索新的技术方法，即使这种方法不符合以往的惯例。 高级开发人员 / 技术负责人不确定他们花在指导上的时间对经理来说是否可见 “计数 ” 团队回顾 ， 跟踪 ， 验证和分享学习新技能的例子 验尸仪式 ， 包括跟踪未来的改进 ， 以应对已发现的问题 较低的支持和归属 电梯支架和所属 代码工作中存在模糊或不一致的“规则”、预期和规范，如不必要的惩罚性代码审查。 团队庆祝开发人员的意外贡献和新方法 开发者感受到的推广与认可倾向于奖赏某些类型的工程职位而非其他职位。 开发人员有机会一起度过非正式的社交时间 团队和组织确保在