2024年工程团队需要注意的20种模式报告

在您的工程团队中需要注意的 20 种模式 一个现场指南 ， 可帮助您识别成就、发现瓶颈并使用数据调试开发过程。 目录 PART 1 域冠军2囤积代码5异常高的流失率8Bullseye 提交11英雄13过度帮助15清洁如你去18在该区域20比特旋转22忙碌的身体24 PART 2 范围蠕变27片状产品所有权29扩展重构31还有一件事33橡胶冲压35知识孤岛37自合并 PR40长期运行的 PR42高总线系数44Sprint 回顾46 Introduction 在 Pluralsight ， 我们相信有效的工程经理也是有效的调试器。 有效的管理者将团队视为复杂的相互依赖系统，涉及输入和输出。当输出不符合预期时，优秀的管理者会带着好奇心解决问题，并坚持不懈地追根溯源。他们观察代码审查，可视化工作模式，发现并清除瓶颈或流程问题，从而整体提升团队的健康状况和能力。 通过探究“为什么”，他们揭示了组织中存在的问题，并了解团队的工作方式以及如何在未来解决这些问题。 20 种模式这是一些我们在与数百个软件团队合作时观察到的工作模式集合。我们希望您能利用这份指南更好地了解团队的工作方式，识别成就，发现瓶颈，并通过数据调试开发流程。 PART 1在个人层面上展示的工作模式 1. 域名冠军 领域冠军是代码库中特定区域的专家。他们几乎了解该领域的一切：每个类、每个方法、每种算法和模式。 事实上 ， 他们可能写了大部分 ， 在某些情况下 ， 多次重写了相同的代码段。 其他人可以在审查过程中提供。因此 ， 域冠军通常会显示低接受度纳入评论的反馈。 该领域冠军不仅仅是“了解信用卡处理的工程师”；它涵盖了他们一生中始终专注的所有内容。这是他们每天的全部工作。 领域冠军很少或几乎不会出现停滞的情况。短期内，这是一种高度生产性的模式。但往往难以持续，并可能导致停滞，而这当然会导致流失。 一定程度上的岗位专业化是必要的，通常也能激发员工的积极性。但在专门化的角色内，也可能会出现“过度专注于某一方面”的情况。管理者必须在允许团队成员独自拥有特定专长与鼓励跨领域经验之间找到平衡。 如何识别它 领域冠军企业总是会在同一代码领域工作。他们还会不断重写代码，这在变更和遗留重构指标中会体现出来，随着他们不断优化代码。 做什么 分配关注代码库其他区域的票证。 领域冠军对某一特定领域有深刻的理解。因此，他们通常会提交小规模、频繁的代码更改，并且会表现出持续的高于平均水平的工作效率。影响. 当然，一些工程师可能会更倾向于留在他们熟悉的位置。擅长完成某项任务会非常令人愉悦，而接手需要运用你较少实践过的知识或技能的工作则可能让人感到不适。然而，高效的管理者会努力挑战他们的团队。 因为没有人比域冠军知道更多 ， 所以通常很少有可操作的反馈 请他们愿意接受一项与其领域以外的小任务，部分目的是帮助分享他们在优化和精炼代码领域开发的最佳实践。 在你的下一个一对一开始新的对话 ： 1. 承认他们的专业知识，并鼓励他们与他人分享这一专长。询问是否有（或应该有）哪些人（或团队），尤其是那些在该领域进行代码审查以学习最佳实践的人，可以从参与中获益。 通过使用小规模、低风险的票据逐步蚕食工程师的领域。适度的多元化可以在减少人员流失风险和最大化最佳实践方面发挥重要作用。 2. 问他们喜欢做什么 - 首先是一般的 ， 然后是具体的。 2. 囤积守则 这一模式指的是在冲刺结束时反复独自工作并将所有进展汇总在一个大合并请求中的工作行为。 程序员们通常会在完成工作后再进行分享，而在创意性和研究密集型领域中，当工作刚刚开始时便避免分享也是一项自然倾向。这种行为背后的原因有很多：担心他人对未完成的作品进行评判、担心他人窃取想法，或是希望整个过程看起来更加轻松自如等。 当遇到大规模且不频繁的提交时，首先考虑该模式的持续时间（我们是否已经观察到这种模式多年，还是它只是最近才变得明显？）这些信息可以帮助确定这是否是工程师首选的工作方式，还是由于某些超出常规开发流程的因素所致。 无论原因是什么，问题的核心在于：个人越是积累自己的工作，就越少与他人合作。独自工作本身比与他人合作承担的风险更大。而软件工程是一种团队运动。 这种倾向于私下工作然后一次性提交的做法不仅限制并放慢了个人的发展——它还对团队的整体进步造成了损害。一次性提交工作意味着在整个过程中都没有合作的机会。更糟糕的是，一旦工作被提交，其他人就无法再对其进行修改或提供反馈。review所有这些努力。因此，这种工作行为也可能导致代码质量降低——从提交者的角度来看（他们没有早点提交工作以获得反馈或注意到潜在的错误），以及从审查者的角度来看（他们可能没有足够的时间或精力充分审查所有这些代码）。 如何识别它 大额且不频繁的提交可能表明工程师是在私下里完成项目后再一次性提交全部工作。 这种模式通常首先在工作日志报告中被观察到，但在团队的审阅流程中也同样可识别。这些PR（Pull Request）较大，且通常在冲刺或项目后期提交。因此，它们可能需要更长的时间进行审查（相对于团队的平均水平），或者得到较低程度的审查（参见审查覆盖率）。 这可能是进行一次即兴且非正式的一对一交流的好时机。例如，散步或共饮咖啡等场合都能让对话保持轻松自然。询问他们最近项目的进展，了解哪些部分做得好、哪些部分不尽如人意，并认可他们的成就。 这些工程师在提交基础知识时表现出的接受性通常低于平均水平。当人们孤立工作，在确定这是“正确的”解决方案后才提交进行审查时，通常会发现很难客观地接受反馈。 在项目过程中，提及团队协作的重要性，并说明将工作推迟到完成后再进行会导致几乎没有机会在整个过程中向他人学习。当团队在整个项目中共同工作时，他们可以从彼此的角度中学习，减少不确定性并加快进度，甚至可以找到更好的解决方案。实践中，这可能表现为工程师在认为工作尚未准备好进行审查之前就提交工作。 做什么 首先，要富有同情心。通常在冲刺结束前后，你会注意到这种模式，这时工程师们很可能已经疲惫、压力大且精疲力尽。确保他们有足够的时间和空间来恢复，以便从交付如此大的成果中恢复过来。 模式 03异常高的流失率 3. 异常高的流失率 churn 是开发过程中的一个自然且健康的部分，并且会因项目而异。然而，异常高的 churn 通常是一个早期指标，表明某个团队或个人可能正在难以应对当前的任务。 在对超过85,000名软件工程师的代码贡献模式进行基准测试时，Pluralsight的数据科学团队发现，代码变更（Code Churn）水平经常处于所有提交代码的13%-30%之间（即70%-87%的效率），而典型团队的代码变更水平通常在25%左右（75%的效率）。 n他们正在努力解决手头的问题。这种情况与《囤积代码》（模式#2）的表现不同，因为在这种情况下，工程师最初认为他们已经正确解决了问题，也许甚至已经将其提交进行审查，但随后发现需要进行全面重写，而不仅仅是做一些修改。 测试、重做和探索各种解决方案是预期的，这些水平会在个人之间、不同类型的项目之间以及软件生命周期的不同阶段有所差异。鉴于这种差异性，了解团队的“正常”水平对于识别异常情况是必要的。 n或者 ， 最常见的是 ，关于外部利益相关者的问题我们看到了这一点 ， 其中有不清楚或模棱两可的规格、迟来的需求或对交付物的中期冲刺更新。 如何识别它 异常高的流失率本身并不是问题。更有可能的是 ， 有外部因素导致了这个问题。 这个模式的特点是在冲刺或项目后端出现较高的人员流动率。注意观察工程师的人员流动率显著高于其历史平均水平（详见）。快照and抽查报告) ， 将该信息与它们在项目 中的位置配对。 异常高的流失率可能表明以下三种行为之一： n完美主义：当工程师对“足够好”的标准与公司的“足够好”标准不一致时。工程师不断回到代码中重写它，因为他们认为可以并且应该做得更好，但这可能不会对代码的实际功能带来太多改进。 做什么 骑兵!如果外部利益相关者是not驾驶异常高的流失 ， 打电话 在许多情况下，流失（churn）都是正常的。重新设计、原型制作和POC（概念验证）等都是你预期需要重写大量代码的例子。因此，当你注意到异常high churn, take into consideration whether this is routine or something 's off. If it' s the latter: 通常最好由工程师或团队领导指导 ， 而不是经理。 1. 要求提交前的代码审查或橡皮鸭。 确定是否外部 2. 要求拆分工作。拆分工作的行为往往揭示了根源问题。 利益相关方正在推动这一情况。如果确实如此（并且工程师已经验证这是导致较高客户流失率的原因），则： 3. 请更高级的工程师评估在上下文中 “足够好 ” 是什么的项目。 1. 显示数据。显示迟来的规格或最后一刻的更改使项目失败。 4. 如果问题很困难 ， 或者如果域不熟悉 ， 引入另一个工程师配对程序。 2. 从 sprint 中提取票证 ， 或者决定 MVP ， 并将添加的部分拆分为细化 sprint。 模式 04Bullseye 提交 4. 靶心提交 这种模式在大多数团队中相对常见，但往往不被认可：工程师理解问题，将项目分解为更小的任务，并提交出几乎无法进一步优化的代码。 大多数情况下，并非项目中的所有提交都会成为 Bullseyes。但那些是 Bullseyes 的提交通常具有较小到适度的影响，并且在首次审查时就被彻底审批通过了。庆祝这些成功的提交吧！ 如何识别它 在实践中，可以通过提交时间、截止日期、影响程度以及审查过程中的处理情况来识别Bullseye Commit。通常，代码在截止日期之前就开始编写并提前完成，且几乎没有修改（churn）。Commit 的影响程度较小到中等，并且经过了详细的审查。它在一审时就被批准（参见审查工作流程）。 做什么 识别站立射击中的清晰靶心，或者只是简单地写下：“我注意到了那一次登记，做得好！”无论是公开还是私下，展示你注意到并关心这一点只会加强这一模式。 如果有一位工程师经常提交 Bullseye Commits，其他人可能会受益于了解他们如何处理项目。可以邀请该工程师进行一次午餐学习活动，或者考虑请他们在审查过程中为另一位工程师的工作提供反馈。 它是在审查过程中表现出的彻底程度使得“ Bullseye Commits”（模式 #15）与“橡皮图章”（Rubber Stamping）区分开来。在“ Bullseye Commits”中，代码审查具有实质性的内容。 模式 05英雄 5. 英雄 在发布前的最后一刻，“ HERO”发现了一些关键缺陷并及时修复，从而挽救了局面。更正式地说，HERO行为是指频繁在最后一刻修正他人工作的倾向。 诚然，一次良好的补救通常比没有补救要好。但频繁的英雄行为会导致团队内部产生不健康的动态，或者鼓励不负责任的编程。一些团队成员甚至学会期望他们在每次发布时都能跳出来介入。 评审过程 (请参阅评审和协作指标) 。 英雄行为可能是糟糕授权或微观管理的征兆。同时，这也反映出多个层面的信任问题。英雄最终会削弱增长，通过绕过反馈循环来实现这一点，长此以往，可能会在原本优秀的工程师中培养出不确定性与自我怀疑。在最坏的情况下，英雄文化会滋生懒惰：每个人都知道英雄会“搞定”所有事情，因此为什么还要费心呢。讽刺的是，这些最后一分钟的修复恰恰是技术债务的根源。 做什么 不是管理 “保存 ” ， 而是管理代码审查过程。 理想情况下，团队成员应进行小而频繁的提交，并为较大的项目请求中间审查。如果这不是实际情况，请先朝着这个目标努力。这将有助于尽早获得英雄的反馈，甚至在代码完成之前。 如何识别它 英雄用户通常在Pluralsight Flow的“帮助他人”指标中占据主导地位，尤其是在后期提交的情况