软件团队中的心理安全

2021-06-07 01:24:18

在安全的环境中的感觉是一个快乐和富有成效的团队的先决条件。我会提到一个软件团队作为一个例子,但它可以应用于任何团队。

Maslow的需要层次结构是一种人类需求的结构化金字塔。

请注意,私人安全在于安全需求,正是在生理需求之上。如果我们不满足那些较低级别的需求,我们如何释放上述那些,在创造力,创新和生产力可能发生的地方?研究表明,心理安全允许适度的风险,谈论你的思想,创造力,并伸出你的脖子,而不必担心它被切断。

根据维基百科的说法,“心理安全能够展示和雇用一个人的自我,而不担心自我形象,地位或职业的负面后果。如果你担心恐惧,是否因为你害怕打破一个系统或被判断而来,你将不挑战现状甚至参与。您甚至可能会找到隐藏这些恐惧的方法。

如果你不明白的东西,但你没有说出恐惧,那是多么不生产?理想情况下,您想在一个展示您的弱点的地方工作。说“我不知道”应该是一个正常的事情。

恐惧和焦虑总是适得其反。承担风险是要求在方式发展和发出错误是自然的。如果错误是生命和工作的一部分,我们最好学会拥抱它们。

团队应该成熟,可以看到犯错是作为学习过程的一部分。无论你的资历水平如何,你都应该感到安全地犯错误(没有内疚感)。接受错误主要是关于文化。它归结为弥补公司和团队的人。在那里,有自主权在团队工作和使用技术的方式以战略方式(例如自动化)来实施一些实践。让我们进一步探索这些主题。

在这里,我们包括文化,做法和方法主题。有太多的主题来覆盖,所以我只给出一些相关的例子:

适当的欢迎:当一个新的团队成员加入时,您不需要举办派对,但确保您准备一些船上会话。对编程可以是一个强大的欢迎工具,提供安全感和归属感。

重点:如果您不断交换上下文,生产率会提高风险降低。理想情况下,您应该在一段时间的时间上运行单个项目/产品。高中切换的压力和误差增加。

没有手指指向和守门社:团队应该是一个凝聚力的人,互相帮助实现共同目标。竞争与此相反。无论他们的经历如何,不要让某人感到难过。使用配对编程作为促进学习和减少知识差距的工具。

不要成为孤独的狼。借助代码审查和对编程等实践,以提高质量并了解您的同事。这些实践减少了对未知的恐惧,因为我们获得了对我们和我们的工作的反馈。

反馈文化:考虑定期回顾,回火速度,团队健康检查以及ad-hoc 1-on-1反馈会议,使团队可以增加相互信任并不断改进。

实验:降低变化抵抗的一种方法是使由科学方法启发的小实验:基于假设,提出实验,分析结果,并对此作用。这适用于任何东西 - 从调整技术来调整方法。这减少了对承诺的恐惧,因为我们以前可以尝试。它也是一种通过始终在过程中调整的小步骤进行大变化的方法。

相互了解:在我的经验中,信任是一个功能团队的第一因素。一个捷径,用于做一些聚集的活动。

精益倾向:做一些有用的最低要求;获得早期和频繁的用户的反馈。

渐进方法:通过提供小型用户驱动的故事来降低风险;不要造成大变化的长期分支;频繁(和绿色)提交。

连续交付:考虑从释放交换到持续价值流的连续交付,并降低大爆炸(即瀑布)释放所固有的风险。

自从我们谈论软件开发以来,技术肯定是恐惧和风险管理的基础。 Jakob Nielsen提出了1994年用户界面设计的10个可用性启发式 - 它们是可用性的标志标志。他们中的一些人在软件团队中适用于使用技术时,它是良好的助记符。

这些设计应始终通过合理的时间内通过适当的反馈,让用户了解正在发生的事情。

了解当前的系统状态对于处理焦虑至关重要。如果您不知道其状态,您如何管理系统?

CI / CD仪表板可以很容易地总结当前构建状态。有些团队总是在团队空间的电视机上展示。

每当生产中发生问题时,您也想知道正在发生的事情。为此,有可观察性的概念,这意味着可以从其输出确定整个系统的行为。

可观察性是监测的超集。它不仅提供了系统健康的高级概述,还提供了对系统隐式故障模式的高粒度洞察力。此外,可观察系统提供了有关内部工作的充分语境,解锁揭示更深系统的问题的能力。分布式系统可观察性

良好的错误消息很重要,但最好的设计仔细防止在第一位置发生问题。消除错误易于的条件,或检查它们并在提交操作之前使用确认选项呈现用户。

如果我们将这一规则应用于软件开发,我们正在谈论建设安全网,以防止第一次出现问题。我们应该接受我们作为人类,可以犯错误。自动化重复和容易出错的任务是必不可少的,因为我们将机器放在做他们擅长的东西。让我们经历最常见的例子:

为您的需求定义足够的测试策略。从单元测试到端到端测试,所有这些都在创建安全网方面 - 自动化测试的目标之一。

您应该经常在本地运行测试套件;至少在将代码推到源控制之前。本地测试环境应该是最接近的现实(Docker可以帮助很多)。

高反馈循环和自动构建系统:配置CI / CD管道的小心。它应该为每次推动触发构建,首先运行测试;如果单个测试失败,系统不会部署到生产中;如果所有测试通过,则您有绿色构建,系统部署。这完全是什么或没有。

停止搞乱生产数据库。相反,为支持团队和开发人员创建命令行和/或图形工具。除了如此安全,这些保证在更新实时数据时始终运行域逻辑。

为频繁开发人员任务(例如ship.sh,test.sh)创建自动脚本。这减少了忘记某些商定的步骤的可能性。考虑一些git钩子。

从理论上讲,您应该考虑对重复或容易出错的任务的自动化。尽管如此,请注意您创建的开发工具的成本/好处 - 实现和维护成本与它在长期创建的好处。

错误消息应以简单的语言(无错误代码)表示,精确指出问题,并建设性地建议解决方案。

如果您无法妨碍错误的位置,则应容易地从中恢复。这里的明显例子是它应该很容易恢复生成问题的变化:如果出现问题,则回来应该像恢复提交,推动它,等待另一个自动构建一样简单(希望快速)。

与预防错误一样,开发人员还应构建工具,以帮助他们在这些情况下,即CLIS和GU​​I进一步检查问题。

如果发生了一些严重的问题,公开谈论它并应用后验尸实践。 此外,请记住,如果发生这种情况,它会' s是因为没有机制来防止它或从中恢复; 不要责怪人或让他们对此感到难过。 从错误中学习并采取行动。 然而,小心不要对症状的行为,而是找出根本原因并对它进行工作。