开发者蓬勃发展白皮书系列

引言 Pluralsight Flow的开发商成功实验室开始着手研究开发人员及其团队如何保持生产力、深入高效协作，并产生实际影响力。这份白皮书是针对软件开发团队进行的深入研究的三项研究中的第一项，旨在总结现实世界中的开发人员及其团队如何取得成功的经验。 每份这些白皮书都将包含基于我们对健康测量如何使软件团队受益所了解的内容，您可以立即付诸实践的建议。 在研究2中， 我们更深入地探讨如何可见性有助于提升个人和团队成员的参与度、绩效和生产力。我们还探讨了期待和预判认可时刻如何影响开发者的动机、参与度和生产力。 在研究1中， 在本文档中讨论的，我们： Across quantitative data from1,282 开发者和丰富的定性数据15+小时在访谈和小组座谈会上的对话中，我们分享以下发现： 提供关于如何使用此框架以提高生产力和开发者满意度的建议解释其与开发者生产力的关联介绍开发者繁荣框架 在研究3中， 开发者如何体验他们的工作环境 我们分享关于如何正确使用合适的软件指标的建议。我们从我们的发现开始，即尽管87%的开发者相信使用指标来衡量其工作的好处，仅20-30%的开发者报告关于一个团队持续使用团队级软件 学习文化、能动性、动机和归属感对开发者生产力的影响 开发者用于应对这些复杂环境所采用的策略 这种紧张局势让工程领导者面临这样的问题： 指标。从那里我们解释了增加测量导致积极成果，包括： • 如何在不牺牲开发者体验的情况下最大化生产力以满足业务需求？ 更多同理心和自我同情开发者中更强的价值感和掌控感增强的应对能力和压力耐受性 在本论文中，我们主张这两个目标可以通过同一种解决方案来实现：专注于开发者蓬勃发展。 我们的研究发现了： • 强调协作解决问题的团队文化能够带来可持续、高质量的软件工作。 Story 1 开发者繁荣： •.开发者繁荣框架（基于稳健sociocognitive research explained further in表1) is a强预测因素开发者生产力 你需要解锁软件开发团队生产力的唯一框架 •开发者们的繁荣指数得分没有明显差异经年累月的编程经验、工程角色类型及行业indicating thatDeveloper Thriving 中的措施可以应用于各种类型的工程项目和不同组织。 当今的工程领导者面临着一个重大难题。 我们目前在工程测量领域观察到两大主要趋势： 在论文的其余部分，我们深入探讨： • 对团队健康的关注增加和开发者体验,为了招募和留住最优秀的软件工程人才 ••• 这种研究为何是必要的Developer Thriving框架的每个组成部分关于如何利用开发者繁荣的建议一个框架来提升您团队的成功 • 在经济下行背景下，对工程生产力的审视更为严格，且需要以更少的投入获得更多成果。 在编码年限、工程角色类型和行业方面，开发者的蓬勃发展分数没有出现显著差异，这表明开发者蓬勃发展的衡量标准适用于各种类型的工程工作以及不同的组织。 我们今天如何看待开发者体验时，到底出什么问题了？ 满意度和幸福感、绩效以及活动，系统地扩展了“生产力”的定义，以包括工作满意度等维度。 我们相信，当领导者试图提高组织发展生产力时，会面临两种衡量陷阱。 尽管SPACE框架将满意度作为生产力的重要组成部分，但它并未解释真实的开发者满意度究竟来源于何处。 • 专注于生产力的表面定义和衡量和激励错误的事物 这导致了开发者、经理和工程领导者 alike 对如何分解和诊断开发者体验如何与更广泛的团队生产力相联系缺乏理解。 • 被复杂性和环境所瘫痪测量和激励虚无 为了找到摆脱这些测量陷阱的方法，我们可以参考近期一波以以人为本、循证科学为基础的软件开发研究： 这是我们的研究回答的问题。 • 从基础证据中学习，了解在编程和软件工作中真正能改善问题解决能力的因素。 开发者繁荣框架的组成部分是什么？ • 直接基于现代软件开发团队的实践进行调查研究 开发者蓬勃发展建立在开发者满意度和生产力之间已知联系的基础上。但它更进一步。有助于回答究竟是什么驱动了满意度的初始动力。 • 避免在衡量生产力时犯重大误解，例如将开发者生产力仅定义为粗略产出指标（如代码行数），或设定单一目标指标并将其用作评估所有软件工作的阈值，而忽略不同背景和需求。 为构建该框架，我们对人类成就与福祉方面的广泛研究进行了调查。基于我们的研究结果，我们开发了开发者体验的四个关键可衡量要素。每个要素都借鉴了那些已被证明对人类问题解决与成就产生直接影响的理论，并将其应用于软件开发团队（表1). TheSPACE框架或许这是该研究中最广为人知的结果之一。该框架（Forsgren等人，2021年；Storey等人，2021年），该框架根据开发者的生产率特征进行描述。 一个“充满活力的”软件团队拥有他们环境中的每个要素。 • 代理 • 动机与自我效能 •学习文化 • 支持与归属 我们定义了开发者繁荣框架的四个要素，并包括一段引言，说明了我们重点关注小组中的IC（集成电路）和经理是如何描述它们的： 一个开发者是： 1. 工作中编写代码时充满动力2. 大多数时候能够看到切实的进展3. 正在编写他们想要编写的代码4. 相信即使工作意外困难时，也能解决问题 一个开发者： 1. 能够对团队定义的成功表达异议 2.在如何评价他们的贡献方面拥有发言权 1机构 2动机与自我效能 一个你知道（提出意见是）受到鼓励的环境会让你在如果……你认为也许应该探索另一个方向时，想要发表意见。 “[我需要] 认可我是一个优秀的问题解决者。我被赋予需要解决的问题，而不是被提供解决方案并被告知去实施它们。这就是你朝着 [技术领导力] 发展的方向。” - IC参与者，焦点小组 - IC参与者，访谈 1. 学习新技能 2. 能够在工作中学到东西并分享 1. 得益于团队的支持，他们在成长、学习和犯错方面获得了帮助 2. 对他们的团队接纳他们的真实身份充满信心 4支持与归属感 学习文化有足够的时间学习增强了我实际编写代码这项任务的信心，而且我认为这最终使我能够更加成功。 当思想和贡献得到同等重视时，我感觉很安全……无论是建筑师、在公司工作了15年并建立起一切的人，还是刚刚开始实习的实习生。 - IC参与者，访谈 - IC参与者，访谈 We believe the components of the Developer Thriving framework are impactful because they create“良性循环”积极的关于代码工作和问题解决的理念、认知和期望。 这些周期有助于增强开发者的进展感和解决问题的能力，尤其是在他们遇到困难、摩擦和失败时。 此外，通过在团队中促进有效的问题解决，这些良性循环为组织提供了一种可扩展且与上下文无关的提高生产力的方式。 我们的研究表明，这些良性循环在何时产生最大影响时可见性and软件测量已被整合进团队的习惯与仪式（见下图）。我们将在该系列后续白皮书中深入探讨可见性及软件措施的重要性。 由“开发者繁荣”文化所解锁的“良性循环”，为我们先前介绍的两个“开发者生产力”测量陷阱提供了最有效解脱之道： 1. 专注于生产力的表面定义，测量和激励错误的事情 2. 被复杂性和环境所瘫痪，且不进行衡量和激励 学会识别这些周期，为工程领导者及软件开发团队提供了诊断阻碍蓬勃发展的障碍的起点，并使那些保护它的最宝贵实践变得可见。 IC开发者和管理者所描述的工程组织内部的“可见性周期”。 今天你可以做些什么，以在不牺牲开发者体验的前提下最大化生产力。 团队，考虑诸如充足的学习时间、强大的支持文化、提供反馈的机会以及解决复杂问题所获得的认可等因素。 驱动变革和决策的指标，并确保长期影响能够随时间跨项目进行追踪。 组织应当投资于那些明确认可并奖励团队在技术进步方面所取得成果的系统，特别是那些出乎意料地具有挑战性、需要新技能或解决了长期存在问题的相关工作。 Developer Thriving 是生产力的重要预测指标。 采取这些步骤有可能改善开发者的体验和代码速度，并减少解决问题的障碍。 开发者他们应当意识到，在代码评审和团队复盘等关键协作时刻，他们是否在支持队友的学习、归属感以及其他关键因素。 当开发者的工作被队友、经理和组织看到和认可时，他们会受益。 管理者寻求提高生产力的组织应当诊断其团队中开发者成长因素（Developer Thrivingelements）的潜在差距，记录基准，并倡导对开发者成长因素（Developer Thriving factors）的投资。 领导层应诊断其工程组织内部是否存在“可见性差距”，特别关注那些目前尚未获得广泛认可的团队或工程工作类型。 通过遵循上述方法，组织可以迅速提高员工满意度和留存率。 在接下来的页面中，我们包含了更多您可以和您的团队使用/遵循的建议，以改进开发者茁壮成长框架的每个组成部分。 组织应当致力于监控工程部门在内部及跨部门之间如何实现开发者福祉。 领导者和管理者应评估工程工作是否得到评估 提升或降低 开发者繁荣：我们研究的建议 降低代理费用 用于评估所有工程工作的指标仅对部分适用，例如，某些团队未能识别遗留系统的约束。 开发人员工作和流程中突然且不可预测的干扰，例如频繁的计划调整 Lift agency 团队和组织层面对开发者主导的倡议（如代码“清理”）的认可 缺乏面向开发者的文档，以帮助在新代码库和代码库的未知部分进行入职。 团队和管理者定期就目标和成功定义进行沟通，承认软件开发团队旨在实现多个目标。 在不对经验、团队需求和组织摩擦等环境因素进行考虑的情况下，严格界定不同开发人员之间的成功。 将度量衡融入团队现有的软件流程中，并为开发者提供一个平台，用于为指标变化添加上下文。 未能认识到特定问题领域可能存在多种技术方案，并在评估和测试之前就惩罚开发人员不选择“正确”方案的业务决策。 动机和自我效能低下 当团队层面的规划未能适应并奖励解决意外困难代码工作的时刻，例如分类和调试 提升动力与自我效能感 开发者会追踪他们编码过程中的部分环节，并反思他们的工作节奏是否以令人惊讶的方式受阻。 分配巨大、复杂或模糊的任务，而未提供充足的支持、时间或资源 新入职的开发人员在加入新团队和代码库时，会获得频繁且可实现的“胜利”。 持续的范围蔓延，以及在规划时刻与评估时刻评估“良好工作”所使用的指标快速变化。 突破常规或出乎意料的问题解决方式被技术主管及其他有影响力的高级同事所注意到并赞赏。 不频繁的管理人员检查，需要许多“重启”，以及开发人员沟通其进展的低效率 较低的学习文化 提升学习文化 对文件记录及其他长期知识共享形式的抑制 团队鼓励结对编程和集体编程，并就开发人员之间的“支持”工作分享荣誉。 脱离语境强调仅反映数量的生产效率指标，从而抑制对质量或努力的认可 一套可靠的代码审查实践，鼓励资深开发人员与初级开发人员之间进行有意义的反馈。 未能认识到“时间成本”在确定潜在解决方案时，有时在技术工作中是一项必要的贡献。 一位经理或技术负责人给开发人员空间去探索一种新的技术方法，即使它与先前的惯例不符。 高级开发人员/技术负责人不确定他们花在指导上的时间是否被管理者视为“有效”的贡献。 团队回顾会议，用于追踪、验证和分享学习新技能的实例 对已识别问题进行未来改进追踪的死后仪式 降低支持与归属感 提升支持与归属感 秘密“规则”、代码工作方面不明确或不一致的预期和规范，例如不必要的严厉代码审查 团队庆祝开发者意外贡献和新增方法。 开发者感到的促销和认可偏袒于某些类型的工程角色而非其他角色。 开发者有机会一起度过非正式的社交时间。 团队和组织确保在领导机会中，如在高影响力演示中的发言角色等，充分体现背景、职业层级和经验的