软件团队中的心理安全
在安全的环境中的感觉是一个快乐和富有成效的团队的先决条件。我会提到一个软件团队作为一个例子，但它可以应用于任何团队。
Maslow的需要层次结构是一种人类需求的结构化金字塔。
请注意，私人安全在于安全需求，正是在生理需求之上。如果我们不满足那些较低级别的需求，我们如何释放上述那些，在创造力，创新和生产力可能发生的地方？研究表明，心理安全允许适度的风险，谈论你的思想，创造力，并伸出你的脖子，而不必担心它被切断。
根据维基百科的说法，“心理安全能够展示和雇用一个人的自我，而不担心自我形象，地位或职业的负面后果。如果你担心恐惧，是否因为你害怕打破一个系统或被判断而来，你将不挑战现状甚至参与。您甚至可能会找到隐藏这些恐惧的方法。
如果你不明白的东西，但你没有说出恐惧，那是多么不生产？理想情况下，您想在一个展示您的弱点的地方工作。说“我不知道”应该是一个正常的事情。
恐惧和焦虑总是适得其反。承担风险是要求在方式发展和发出错误是自然的。如果错误是生命和工作的一部分，我们最好学会拥抱它们。
团队应该成熟，可以看到犯错是作为学习过程的一部分。无论你的资历水平如何，你都应该感到安全地犯错误（没有内疚感）。接受错误主要是关于文化。它归结为弥补公司和团队的人。在那里，有自主权在团队工作和使用技术的方式以战略方式（例如自动化）来实施一些实践。让我们进一步探索这些主题。
在这里，我们包括文化，做法和方法主题。有太多的主题来覆盖，所以我只给出一些相关的例子：
适当的欢迎：当一个新的团队成员加入时，您不需要举办派对，但确保您准备一些船上会话。对编程可以是一个强大的欢迎工具，提供安全感和归属感。
重点：如果您不断交换上下文，生产率会提高风险降低。理想情况下，您应该在一段时间的时间上运行单个项目/产品。高中切换的压力和误差增加。
没有手指指向和守门社：团队应该是一个凝聚力的人，互相帮助实现共同目标。竞争与此相反。无论他们的经历如何，不要让某人感到难过。使用配对编程作为促进学习和减少知识差距的工具。
不要成为孤独的狼。借助代码审查和对编程等实践，以提高质量并了解您的同事。这些实践减少了对未知的恐惧，因为我们获得了对我们和我们的工作的反馈。
反馈文化：考虑定期回顾，回火速度，团队健康检查以及ad-hoc 1-on-1反馈会议，使团队可以增加相互信任并不断改进。
实验：降低变化抵抗的一种方法是使由科学方法启发的小实验：基于假设，提出实验，分析结果，并对此作用。这适用于任何东西 - 从调整技术来调整方法。这减少了对承诺的恐惧，因为我们以前可以尝试。它也是一种通过始终在过程中调整的小步骤进行大变化的方法。
相互了解：在我的经验中，信任是一个功能团队的第一因素。一个捷径，用于做一些聚集的活动。
精益倾向：做一些有用的最低要求;获得早期和频繁的用户的反馈。
渐进方法：通过提供小型用户驱动的故事来降低风险;不要造成大变化的长期分支;频繁（和绿色）提交。
连续交付：考虑从释放交换到持续价值流的连续交付，并降低大爆炸（即瀑布）释放所固有的风险。
自从我们谈论软件开发以来，技术肯定是恐惧和风险管理的基础。 Jakob Nielsen提出了1994年用户界面设计的10个可用性启发式 - 它们是可用性的标志标志。他们中的一些人在软件团队中适用于使用技术时，它是良好的助记符。
这些设计应始终通过合理的时间内通过适当的反馈，让用户了解正在发生的事情。
了解当前的系统状态对于处理焦虑至关重要。如果您不知道其状态，您如何管理系统？
CI / CD仪表板可以很容易地总结当前构建状态。有些团队总是在团队空间的电视机上展示。
每当生产中发生问题时，您也想知道正在发生的事情。为此，有可观察性的概念，这意味着可以从其输出确定整个系统的行为。
可观察性是监测的超集。它不仅提供了系统健康的高级概述，还提供了对系统隐式故障模式的高粒度洞察力。此外，可观察系统提供了有关内部工作的充分语境，解锁揭示更深系统的问题的能力。分布式系统可观察性
良好的错误消息很重要，但最好的设计仔细防止在第一位置发生问题。消除错误易于的条件，或检查它们并在提交操作之前使用确认选项呈现用户。
如果我们将这一规则应用于软件开发，我们正在谈论建设安全网，以防止第一次出现问题。我们应该接受我们作为人类，可以犯错误。自动化重复和容易出错的任务是必不可少的，因为我们将机器放在做他们擅长的东西。让我们经历最常见的例子：
为您的需求定义足够的测试策略。从单元测试到端到端测试，所有这些都在创建安全网方面 - 自动化测试的目标之一。
您应该经常在本地运行测试套件;至少在将代码推到源控制之前。本地测试环境应该是最接近的现实（Docker可以帮助很多）。
高反馈循环和自动构建系统：配置CI / CD管道的小心。它应该为每次推动触发构建，首先运行测试;如果单个测试失败，系统不会部署到生产中;如果所有测试通过，则您有绿色构建，系统部署。这完全是什么或没有。
停止搞乱生产数据库。相反，为支持团队和开发人员创建命令行和/或图形工具。除了如此安全，这些保证在更新实时数据时始终运行域逻辑。
为频繁开发人员任务（例如ship.sh，test.sh）创建自动脚本。这减少了忘记某些商定的步骤的可能性。考虑一些git钩子。
从理论上讲，您应该考虑对重复或容易出错的任务的自动化。尽管如此，请注意您创建的开发工具的成本/好处 - 实现和维护成本与它在长期创建的好处。
错误消息应以简单的语言（无错误代码）表示，精确指出问题，并建设性地建议解决方案。
如果您无法妨碍错误的位置，则应容易地从中恢复。这里的明显例子是它应该很容易恢复生成问题的变化：如果出现问题，则回来应该像恢复提交，推动它，等待另一个自动构建一样简单（希望快速）。
与预防错误一样，开发人员还应构建工具，以帮助他们在这些情况下，即CLIS和GUI进一步检查问题。
如果发生了一些严重的问题，公开谈论它并应用后验尸实践。 此外，请记住，如果发生这种情况，它会＆＃39; s是因为没有机制来防止它或从中恢复; 不要责怪人或让他们对此感到难过。 从错误中学习并采取行动。 然而，小心不要对症状的行为，而是找出根本原因并对它进行工作。
