我经常费力解释成为高效软件团队的一员意味着什么。当然，那里有很多东西，比如LinkedIn有一整套思想领导力，列出了各种指导方针和启发式方法，可以帮助团队有效运作，但根据我的经验，如果你永远不知道什么更好，它可以很难将这些想法内化并遵循别人的模式。到目前为止，我很幸运能够直接与数十名（如果不是数百名）开发人员一起工作。我曾在不健康的团队工作过，在这些团队中，人们会感到恐惧，并且出于对职位的恐惧，把手放在自己的卡片上，对他人隐瞒自己的计划或意图；我还曾在功能失调的团队中工作，在这些团队中，由于优先级不明确或协调成本太高，任何人都无法工作，团队摇摇欲坠，许多天甚至几周的开发时间都被浪费了，团队变成了一个单一的实体集合，而不是工作单位。但幸运的是，我也曾在一些非常优秀的团队工作过。当我在这些伟大的团队中时，我每天都很兴奋去上班，而且我不害怕与比我年长的人公开发言，因为我认为我的声音和我的工作是有影响力的。在本文中，我将尝试记录与我共事过的表现最好的团队的特征和习惯。1.高度的心理安全感心理安全感的概念由来已久，所以我不打算花太多时间解释它。如果您以前没有见过这个概念，请先阅读这篇文章。https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/软件团队由真实的人组成，他们从一出生就在无形的社会和政治结构中生活和工作从一开始就社会化变得更自信、更谦逊、更直率、更有礼貌、更善于争论、更和解等等。显然，这些都是陈词滥调，我说这些是为了证明心理安全不仅仅是聘请几个顾问来培训员工并告诉人们这个概念意味着什么：建立真正的心理安全需要领导者和管理者评估所有无形的社会规则人们如何相互交流，并了解这些规则如何影响一个人参与小组讨论和促进小组活力的能力。简而言之：社会特权很重要。否则，当一些小事开始削弱团队凝聚力时，请不要感到惊讶：咄咄逼人的言词或小动作、刻板印象威胁、将幸存者偏见转变为高效团队成员的信条。据我观察，具有高心理安全水平的软件团队表现出以下一些行为：定期回顾，在“什么不顺利？”中有适当数量的项目柱子。外面不应该总是阳光和彩虹。这会让我想知道是否有任何难题没有在回顾中提出和讨论。健康的团队应该能够公开反思和批评自己，因为每个人都明白建设性的反馈是为了持续改进。个人不会在一个问题上花费很多时间。他们将有一个明确或隐含的“斗争时间窗口”，之后他们会向同龄人寻求帮助，知道他们不会因此而受到负面评价。个人将他们对团队的价值与可见输出分开。我见过人们对他们的代码后来被删除或重构感到沮丧的案例。但在一个健康的团队中，每个人都接受改进是渐进的和渐进的，并且贡献是对团队的整体结果而不是特定的输出（例如代码行数），它表现为“这个我们交付”，而不是“我递送”。此外，具有高心理安全水平的团队可以讨论价值的含义以及为什么它不仅仅是几行代码。有趣的是，带薪休假时间和病假时间往往更长。我认为这反映了他们相信团队的其他成员可以在他们缺席的情况下继续做出正确的决定，因为他们之间进行了足够多的对话，整个团队都觉得他们在产品和技术决策上非常一致。但我不太确定因果关系。因为如果他们发高烧，人们也会申请更多的带薪休假。当一个团队的心理安全感很高时，你可以尝试一些很酷的实验。我相信这些实验创造了一个自我强化的正反馈循环，创造了更高水平的信任和安全。在我的第一个高绩效团队中，在回顾期间，每个人都觉得半年一次的绩效评估周期不够频繁或不够详细，无法促进职业发展，尤其是当我们团队的优先事项发展得如此之快时。所以，我提出了一个实验：反馈周。2.反馈周这是一个为期一周的过程，每个人（包括团队负责人和项目经理）都被随机分配去收集对另一个人的反馈。这个过程非常顺利，以至于当我的队友加入新团队时，他们也带来了试用。最终，办公室里的其他团队开始效仿我们！我在这篇博文中更详细地描述了这个实验。我还在多伦多的DevOpsDays2019上就此发表了演讲。https://deniseyu.io/2018/03/03/better-team-feedback.htmlhttps://www.youtube.com/watch?v=6VARlKoEAPI能开展这样的反馈周，说明你的团队是处于高度的心理安全状态。如果你有幸参与其中，我的建议是：不要原地踏步。这是一个大胆试验您的流程和实践的机会，并尝试像反馈周这样的活动，它可以帮助您挖掘隐藏的积极反馈循环。如果您确实想出了一些很酷的东西，请告诉我！3.良好的开发实践随着系统复杂性的增加，系统中任何个体参与者自己的模型的准确性都会迅速下降。—WoodsTheorem坦白说，我永远不会有一个完整的GitHub心智模型。它太大了，逻辑路径太多了，坦率地说，花太多时间学习代码的所有部分并不能使我的工作变得更好。而且，它明天可能会再次改变。因此，当我必须收集足够的上下文信息来实施下一个功能或错误修复时，我依赖于代码中已经存在的工件的准确性，这些工件是在我之前从事这些工作的人留下的。我花了很多时间仔细研究代码：运行gitblame，查看过去的提交、相关问题，以及任何有助于我理解为什么某行代码是这样写的东西。如果我看到带有“WIP”提交消息的难以理解的更改，它就会成为生产力杀手。良好的软件开发实践意味着花一些额外的时间来记录当前的上下文信息，这些信息可以体现在：描述性提交消息。至少，让每个提交消息都包含一个动词。有些团队走得更远，要求每个提交都可以追溯到一个问题编号。请务必选择适合您团队认知投资水平的方法；遵循传达意图的语言和框架约定、类和方法名称；使用有用的描述信息进行单元测试，使用实际的变量名和数据，而不是“foo”和“bar”之类的变量；在问题跟踪器中来回交流相关功能，而不是在SlackDM和其他地方。今后，加入我们不足6个月的新团队成员将无法访问这些地方。最后，良好的开发实践是关于同理心的。工件越干净，团队成员学习上下文的速度就越快，并且在上下文切换和探测上花费的认知努力就越少。另外，它实际上对你未来的自己有好处。道德哲学的一个分支，将你未来的自我视为具有道德主张的独特实体，我会说：促进这些发展规范将在以后得到回报，特别是如果有人在凌晨3点发短信给你，要你在电话上写的一行代码！4.积极重新分配“经验值”我喜欢角色扮演类游戏，尤其是《火焰徽章》和《口袋妖怪》系列，最近也慢慢爱上了?。我之所以提出这个问题，是因为我认为在《火焰徽章》中建立军队的方式与建立均衡的软件开发团队之间有很多相似之处。在RPG游戏中，我有自己的核心团队，我非常喜欢让所有角色平均升级。如果我得到一个等级较低的新角色，但他有一套可以补充团队的技能或亲和力，我会投资他并提升他一点水平，这样他就可以在地图上移动而不必害怕敌人的攻击.如果我的角色一开始是高等级的，我会避免让他们与较弱的敌人战斗，因为那样只会占用经验值，而这些经验值对我的低等级角色更有好处。我倾向于认为软件团队中存在类似的原则，但不是增加力量、防御、魔法和抵抗力的经验值，每个新工作都是一个“敌人”，一旦交付，就会扩大团队的领域背景和信心。通常，团队中并没有核心“顾问”这样的角色，此时类比开始变得不恰当（主管和项目经理不算，他们通常没有足够的远见或up-to-日期上下文信息，无论如何，把这么复杂和动态变化的东西放在一个人身上是个坏主意）。如果你的团队中已经有很多优秀的骑士和圣骑士-呃，我的意思是高级开发人员-那么作为一个团队，你应该小心不要总是将他们分配给困难的事情。在健康的团队中，上下文重新分配也是他们工作的一部分，这样一个没有经验的战士——我的意思是，一个工程师——也可以获得一些宝贵的经验值。如果每个人至少都觉得自己有能力迎接任何挑战，那么整个团队的生产力和士气就会提高。如果没有，他们知道他们可以增加一名猎鹰骑士作为中尉——换句话说，求助于更有经验的人。5.慷慨地沟通最后一点我想了很多。在对我的想法的所有描述中，我认为最好的是NatFriedman在最近一次全体会议上的演讲。他是这样说的：“我们彼此之间的交流应该遵循稳健性原则：发送的内容保守，接收的内容开放。”交流时。但我认为高绩效团队会100%遵循这个原则。我真的很喜欢这个框架，因为它让我想起了多年前我在codebar做志愿者时接受的导师培训。“假设你接触到的每一位学生，知识有限，智慧无限。”这让教师有责任确保他们的解释易于理解——考虑到教师和学生之间固有的权力不平衡，这是传达额外情感劳动的好方法。同事之间的慷慨交流意味着我们假设任何人在任何时候提出问题：做过基础研究，例如用谷歌搜索；因为这个地方很难找到，或者不存在。换句话说：假设你的伴侣是一个能干、聪明、通情达理的人，他们会问问题是因为他们不了解上下文，尽管他们已经设法理解了。当您开始寻求帮助并且您的上下文信息和工作经验不断“汇总”时，我什至不知道如何表达它是多么令人沮丧。是的，这其中有性别因素，但这超出了我们现在讨论的范围。过去，当人们认为你实际上经验和知识要少得多时，我曾多次发推文表达我的沮丧。当然，别人不可能真正知道，无所不知是不可能的！但这里有一个妥协，一个合理的要求：慷慨。像这样不够大方：我：嘿，这里为什么有负载均衡器？X：负载均衡器用于将请求分发到多个服务，因此我们不会遭受DDoS攻击！这里有一些文章涵盖了负载均衡器的基础知识以及为什么我们应该在理论上使用它们！我：好的，但这不是我要问的。我知道什么是负载均衡器。我只是想了解为什么在做出架构决策时将HAproxy放在这个特定服务的前面。X：哦！好吧，你应该问这个！相反，它会很慷慨：我：嘿，为什么这里有负载均衡器？X：我猜你是在问我们为什么选择HAproxy，以及为什么要提供这些服务。如果没有，现在告诉我。我：对，就是这样！感谢您首先确认我的问题。X：不客气。好吧，18个月前，当我们建立这个系统的时候……上面两种交互的主要区别在于，在慷慨的交互中，在给出答案之前，受访者确认他们对问题的假设，然后检查上下文提问者的水平和意图。慷慨地交流产生了非常积极的影响：首先，您是否注意到交流时使用的词汇量有所减少？他们实际上可以更快地得到答案。其次，不会产生不必要的摩擦。两个人联合起来消除不确定性，而不是纠结于每个人知道多少，如果是后者，也许他们终于可以得出答案，但同时也失去了一些信任和好感。
