如何建立一个每个人都能茁壮成长的软件工程文化

原文链接：How to Build a Software Engineering Culture Where Everyone Can Thrive

媒体喜欢在技术世界中讲述有关性别歧视，种族主义和其他形式偏见的战争故事。虽然对系统性问题有所了解，但对于那些对科技事业感兴趣的人来说，阅读有关科技文化问题的故事，最好像熟悉的刻板印象威胁一样，最糟糕的是像一个威胁性的职业责任。但好消息是，科技行业文化本质上并不是坏事 - 其中一些是伟大的，创造一个人人都可以茁壮成长的软件工程文化既可行又直接。

糟糕的软件工程文化效率低下 - 除了推出 75％ 无法适应技术创新的人类，从而使人工行业竞争力下降 - 恶劣的软件工程文化，也常常是一种只有少数主导工程师的文化实际上是著有成效的，而其他人感到困惑或最小化，以及大型团队可能花费数年和数百万美元，意外地解决错误问题或构建错误产品的文化。敌对工作场所更明显的问题，很容易衡量不良组织文化和组织效率低下的共病问题的证据。

幸运的是，职场文化具有很强的可塑性，您可以通过大大小小的方式对其进行影响。如果您在工作场所找到改善软件工程文化的方法，那么您可能不仅仅是为自己改善环境，而是为每个人改进环境。结果，每个人不仅会更快乐，而且会更富有成效。

MoveOn 的技术按规模组织。我们所做的工作很重要，我们如何开展这项工作同样重要。我的技术团队不仅建立了动员数百万美国人的工具，增强了人们的权力，并使我们的政府负起责任，但我们正在通过公平的招聘流程招聘团队这样做，我们不断审计和改进我们的软件工程实践和流程，以确保团队中的每个人都有发言权，每个人都有成功的基础。这是一项绝对值得的艰苦工作，当我们的团队流程正确时，我们将获得丰厚的回报，因为我们能够在合适的时间高效灵活地构建正确的技术，扩展我们的系统和流程，并与其他该组织作为技术思想伙伴。我们拒绝接受当前的技术刻板印象和文化期望是不可避免的想法，因此我们是一个更好的团队。

那么你如何建立一个良好的软件工程文化呢？

优秀文化的关键成分

公平有效的软件团队文化考虑到团队的组成，操作流程并使规范明确，使所有团队成员都能获得成功，并使团队对其既定目标负责。

以下是实现此目标的五个关键值：

• 承认团队的多样化经验
• 明确说明沟通和协作规范
• 为学习和提问提供安全的空间
• 明确将所有团队成员加入新项目
• 建立问责文化

实现这些价值观的任何流程组合，都可能适用于您的团队，但并非所有策略都适合每个团队，每个项目和每个组织环境，因此，尝试不同的策略并定期与您的团队进行汇报非常重要。什么工作，不工作。让团队成员协商流程变更，并保持灵活性。

接下来我们将分解每个值的真正含义，并且我将分享我用于实现每个值的策略示例。

承认团队的多样化经验

大多数软件工程环境将包括具有不同经验水平的人员，并且经验将在许多方面变化：编码所花费的实际时间，特定语言或框架的多年经验，特定公司规模，类型和行业的经验。每种语言，框架，平台，行业都有一系列期望，关于项目的操作顺序应该是什么，哪些问题应该容易与难，哪些架构模式被认为是标准的，哪些规范存在于文档，调试，和部署。这里的每一个区别都很重要，在设定沟通和协作规范时应予以考虑。解开每个团队成员的经验和假设将使决策更加清晰，并将平滑潜在的误解。

承认团队多样化经验的策略：

• 团队撤退（Retreats）：当你的团队的构成发生变化时，为每个人开辟一两天，让每个人相互见面，分享经验和重置规范是有帮助的
• 团队宪法（Constitution）：将您批准的一系列价值观和规范制定为团队的章程。保持语言直接，保持清单简短，并专注于价值与特定项目是有帮助的。提示每个团队成员根据他们的经验分享有关每个价值为何重要的故事。
• 促进分享经验的机会：您可以将此作为团队撤退或定期团队建设会议的一部分。提示与促进无关紧要。促进是关键，所以每个人（内向和外向，包括初级和高级工程师）都有机会发言和倾听。一些示例提示我发现它是生成性的：“你曾经参与的最艰难的项目是什么？”“你曾经拥有过的最好和最差的管理经验是什么？”主持人应该呼吁所有人会面并给予他们相同的会议记录数，并回答有关他们经历的问题。
• 解包软件估算推理：您的团队将不约而同地讨论任务需要多长时间，并且有时会不同意。当发生这种情况时，明确解开关于任务或问题的哪些部分被认为是复杂的，为什么以及基于此的过去经验的假设是有帮助的。
• 软件工程学习计划：为希望以支持和结构化的方式扩展其软件工程技能的软件工程师创建学习计划。

明确说明沟通和协作规范

写下并正式同意团队成员如何在项目上合作，如何管理任务，以及如何批准和合并完成的工作。如果您没有明确地声明这些规范，您的团队和项目无论如何都会制定规范，但是这些隐式规范可能对某些工程师而不是其他工程师有效，并且这些规范可能对那些认为您组织的主导文化的人更清晰和易用，而对那些不这样做的人更容易混淆。最好是明确。

制定沟通和协作规范的策略：

• 项目启动会议：团队章程帮助团队决定如何在一般情况下一起工作，但是在团队决定如何在这个特定项目上合作的情况下召开项目启动会议也很有帮助。这应该包括如何管理任务、如何安排任务、谁挑选哪些类型的任务、如何和何时请求帮助、何时一起工作、如何批准变更和完成的工作。
• 每日站会：这是大多数敏捷软件管理策略的基本原则。提示每个团队成员报告他们昨天做了什么，今天要做什么，以及他们是否需要任何帮助。尽量缩短会议时间，如有可能，不超过 15 分钟。当面或在视频会议（与电话）中这样做很重要，这样团队成员就可以了解视觉反馈和相关的社会动态，这些都是团队成员中的一部分，彼此都要对团队目标负责。我发现，每天都有一个站立议程文档是非常宝贵的，在这个文档中，每个人在每天的会议之前都按照相反的时间顺序编写更新，这个文档会随着时间的推移累积所有更新。这有助于内向者在实际会议之前收集他们的想法，并创建一个可扫描的已完成工作的书面记录，在准备逃避或赶上错过会议的团队成员时，这些记录非常有用。
• 定期检查流程的机会：有时工程师会被落在后面，或者对其他工程师、流程或项目的进展感到沮丧。最好直接用包括整个团队在内的清晰沟通来避免这些挫折，并为分享反馈创造低压力的机会。有时，我发现将“过程检查”包括到每个团队成员在每日站立会议上报告的项目列表中是很有帮助的。其他时候，我发现每隔几周在 Sprint 计划会议中执行这个 “过程检查” 步骤很有帮助。每当 “过程检查” 发生时，不仅要谈一下，而且要写下提议的过程更改是很有帮助的，因此如果将来出现混乱，就有一个共享的协议可以参考。
• 适用于15分钟以上会议的 POPs：当团队需要做出重大决策或在混乱的情况下导航时，会议很容易陷入死亡陷阱。避免过度会议的一种方法是允许任何人提议一次团队会议，但要确保会议有一个弹出窗口：目的、结果、进程以及在提议会议前至少一天制定的议程。这有助于保持会议的重点和可操作性，提前共享议程可以让有兴趣参加会议的人，以及不想退出会议的人参加会议。

为学习和提问提供安全的空间。

在做出正确的事情之前，每个人都会犯错误并错误地学习一千次。你可以称之为“修修补补。”编码的美妙之处在于，你可能会出错，然后最终以你能想到的速度，很少或没有实际成本。但是当你探索一个新的问题空间时，不同的人（基于经验和个人偏好）可能会更广泛或更深入地搜索可能解决方案的树，并且可能已经开发了心理模型，使他们拥有比其他特定问题空间。当工程师感到舒适地分享他们的问题解决过程和步骤时，他们开始变得更聪明，更快捷。这自然会让很多人感到愚蠢并且提出“愚蠢的问题”（其中没有一个实际上是愚蠢的），因此能够做到这一点需要大量的信任。在高风险的工作中很难获得信任，因为自负或声誉受到威胁，每个人都试图辜负某种“天才工程师”的原型。管理者应该通过宣称没有愚蠢的问题，来明确地创建安全空间，通过询问“哑”问题来建模，为协作制定结构化空间，并奖励那些主动协作的人。如果你没有明确地这样做，你团队中的一些工程师可能会创建这些安全空间，但并不是每个人都会被自动包含在内。

创造安全空间的策略：

• 常规 1-1 见面：经理应该定期与员工1-1，最好每周半小时。经理应该鼓励员工推动这些会议的议程。维护此会议的共享 1-1 议程文档很有帮助，员工可以在问题出现时提前添加项目。在撰写论文或反思过去的挑战和机遇时，这个议程文件也可以作为一个有用的文章。
• 定期 2x2 反馈：经理和工作人员分别写下并分享工作人员做得好的两件事，工作人员可以做得更好的两件事，经理做得好的两件事，以及两件可能更好的事情。这可以成为员工绩效的有用登记点，也是员工为经理提供反馈的安全空间。无论你作为一名经理多么友好或平易近人，大多数工作人员都会毫不犹豫地给你负面的反馈，除非你邀请他们。
• 打开术语：当工程师抛出一个不为团队其他成员共享的不熟悉的术语或首字母缩略词时，将行话标记的行为规范化，并提示他们解释该术语对整个团队的意义。
• 计划结对编程：结对编程是一个很好的生产力助推器，也是工程师相互学习的好方法。而不是等待结对编程在已经相互熟悉的工程师之间有机地发生，促使团队成员在他们的日历上明确地计划这一点，并确保所有工程师都能够访问他们想要的配对时间。同时促使工程师为他们协商正确的焦点时间单位（有些时间为 60 分钟，其他时间为 90 分钟，其他时间为 120 分钟），以及配对时最有效的时间。
• 明确的辅导机会：让团队中的每位初级工程师都有机会聘请高级工程师，并明确包括有效指导高级工程师的绩效目标。鼓励导师与他们的学员建立每周会议，并为高级盟友提出安全的空间，以便提出“愚蠢”的问题或澄清流程或规范。
• 练习定期回复：当一名工程师教他人一个新的框架，让所有人通过建议的架构，或者让团队成员加入新系统时，有时候听众很容易关闭或分心。为了使讨论保持活跃，在每5分钟的谈话之后，定期提示听众口头重复刚刚解释的内容。口头重复的表演性质迫使听众向自己证明他们理解概念，或者阐明他们需要理解的其他信息。在入职或进行项目启动会议时将其标准化，并随机呼叫人员进行重复回复以让每个人都关注。
• 鼓励和模仿提出“愚蠢”的问题：作为管理者，人们会仔细观察你的行为和语气，并根据这一点模拟他们的行为和社会规范。因此，重要的是要根据您与团队其他成员的互动方式对上述值进行建模，尤其要模拟在您不完全理解某些内容时，提出直接问题的能力。这表明有效解决问题，总是比自我更重要或总是正确的感知。

明确将所有团队成员加入新项目

开始一个新项目时，重要的是不仅要解开将要完成的工作，还要解释为什么这项工作很重要，以及这项工作对谁来说非常重要。确保工程团队了解“为什么”以及“什么”可以在出现意外选择点时指导决策，并最大限度地降低花时间解决错误问题的风险。在开始一个新项目之后，重要的是要确保每个人都拥有他们需要的东西来完成任务并立即提高工作效率。如果您没有明确地这样做，您团队中的一些工程师将会开始运行，而其他工程师则会在设置本地开发环境等自举步骤时遇到困难。将这些步骤作为启动项目的先决条件可确保每个人都能够立即投入使用。

明确入职的策略:

• 开发环境：在调用项目准备启动之前，确保团队中的每个人都有一个功能开发环境。年轻和年老的工程师都不时地努力使本地开发环境正常运行，这成为软件项目时间表中隐藏的成本。当发生这种情况时，工程师会感到尴尬，并且经常避免承认他们需要帮助，通过保持编码外围的角色，或者只与具有工作开发环境的工程师进行结对编程。最好只是消除潜在的挣扎和耻辱，并将其称之为工作，然后通过明确和支持开发环境设置来计划前端加载这项工作 - 每个人都在一起做的事情，没有被标记为“完成“直到项目中的每个人都有一个有效的当地环境。
• 代码库的导览：在启动或重新启动项目时，最了解代码库的工程师应该对代码库进行导览，暂停不熟悉的团队成员定期“重复”，在成员之间轮换以便每个人都在负责学习代码库结构，以便能够解释它。
• 调试器：一旦每个人都有一个开发环境和对系统如何工作的概念性理解，每个人都应该安装一个调试器，并能够通过系统跟踪执行以获取样本请求或输入。能够在本地工作和调试将确保当工程师开始接收任务时，他们至少能够自己开始这些任务。这减少了挫败感，提高了生产力和所有权。

建立问责文化

软件工程管理的关键工作是确保您的团队在正确的时间以正确的顺序完成正确的工作，并且关注正确工作的关键部分是以正确的方式与利益相关者建立联系。软件团队有几个利益相关者：彼此，更大的组织，以及他们正在构建的软件的用户。软件团队管理流程应该与所有这些利益相关者建立责任。

建立问责文化的策略:

• 项目汇报会议：项目完成并启动后，为举行汇报会议留出空间非常重要，并为此提供便利，以便团队中的每个人都有机会分享他们的反馈意见。我使用的一个有用的提示是 “SaMoLo：下次你会做什么/更多更少？”鼓励团队成员分享技术和流程领域的反馈。这可以让团队成员互相追究是否遵循了作为项目启动会议一部分进行协商的流程。
• 软件过程责任：在项目启动会议中确定的代码审查和发布流程，也在团队内部建立问责制，每日立场会议也是如此。
• 定期演示会议：定期演示项目进度，为大型组织创建问责制。我们希望为所有感兴趣的员工提供每周演示的空间。这是团队的动力，因为他们可以展示他们的工作，它创建了一个用于捕获早期利益相关者反馈的论坛，并在可能的情况下将项目工作集中在迭代可演示的可交付成果上。
• 以用户为中心的指标：通过进行用户测试，根据用户参与度定义和跟踪成功指标，为您的软件用户创建问责制。

为什么这很重要

尽管利润丰厚，软件工程界目前效率相当低。90%的软件初创公司都失败了，我认为这在很大程度上是由于可避免的软件项目执行问题。50% 的大公司软件项目未能按时、按预算或完全启动。对于任何曾在大型软件公司工作过的人来说，迟到一年或超出预算一百万美元都不是新闻。软件工程文化通常将管理者标记为开销或低于软件工程师的地位，这会导致软件工程师成为有效的管理者，以避免这种晋升路径，而当前的软件经理难以与自己的团队进行谈判并在其团队中统治。有时，即使是公开关心软件工程过程，在牛仔编码员受人钦佩的环境中，也会受到侮辱。

在一个大型软件项目上工作只看到最后期限被推迟或项目被取消，这让人士气低落。在营利的世界里，这是一种低效的时间和金钱浪费。在非营利的世界里，我认为这是不道德的使用会员捐款。对于软件工程师来说，这是浪费我们宝贵的时间、精力和注意力。

出于智力和经济方面的原因，审计工作环境的文化并寻找优化和改进的方法是很重要的。如果你从使你的工作文化更公平、更负责任、更公平开始，在一个人人都能成功的地方开始，你不仅会使软件工程师更快乐，软件工程更高效，你还会通过降低软件开发成本和消除歧视性障碍，使世界更公平。

建立一个人人都能兴旺发达的软件工程文化并不难，但现在在充满傲慢、贪婪、自我和道德困惑的技术文化中，这是一个激进的想法。我认为有意建立一个有效和支持性的团队文化是一种行动主义。让我们让公平有效的软件团队文化成为规范！