我常常需求费力地跟人解释，作为高效软件团队的一员究竟意味着什么。当然，关于这一点曾经有少量的材料，比如 LinkedIn 就有整套思想指导力实际引见了各种协助团队有效运作的指点方针和启示性思索，但依据我的阅历，假设你历来都不知道什么样才算好，就很难内化这些想法并遵照别人的形式。
我十分幸运，到目前为止，我在职业生涯中曾经直接与几十个（甚至是几百个）开发人员协作过。我曾在一些不安康的团队任务过：在那些团队里，人们会感到惧怕，出于对职位的担忧，他们会把本人的底牌捂得很紧，不让其别人知道本人的方案或意图；我也在功用失调的团队任务过，那些团队由于任务优先级不明白而摇晃不定，或许协调成本太高而没有人情愿干活，许多天甚至数周的开发时间被糜费掉，团队成了一个集体的集合，而不再是一个任务单元。
但幸运的是，我也曾在一些十分优秀的团队任务过。当我身处这些优秀团队的时分，我每天去下班时都很兴奋，关于那些比我年长的人，我也不怕地下提出支持意见，由于我以为本人的声响和任务很有影响力。
在这篇文章中，我将试着记载下，我所同事过的表现最好的团队所具有的特质和习气。
1. 高度的心思安全感心思安全这个概念被提出来曾经有一段时间了，所以我不计划花太多时间来解释它。假设你以前没有看过这个概念，请先阅读这篇文章。
https://rework.with谷歌.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
软件团队由真实的人组成，他们在有形的社会和政治结构中生活和任务，他们从出生起就被社会化，变得愈加自信，愈加谦恭，愈加直抒己见，愈加礼貌，愈加好争论，更擅长抚慰，等等。显然，这都是陈词滥调了，我说这些是为了证明，心思安全不只指的是招聘一些参谋来展开员工培训、通知大家这个概念意味着什么：树立真正的心思安全感需求指导者和管理者评价人与人之间交往的一切有形的社会规则，并了解这些规则如何影响一团体参与团队讨论、贡献团队动力的才能。简而言之：社交特权很重要。否则，当一些微乎其微的大事情末尾腐蚀团队凝聚力的时分，不要感到诧异：攻击性的言语或小举措、刻板印象要挟、将幸存者偏向变成成就高效团队成员的信条。
依据我的察看，具有高度心思安全感的软件团队会有以下某些行为：
活期回忆，在“什么停顿不顺利？”这一栏里列出适当数量的事项。那里不应该总是阳光和彩虹。那会让我疑心回忆中是不是没有提出并讨论什么难题。安康的团队应该可以地下地反省并自我批判，由于每团体都明白，树立性的反应是为了不断改良。
团体不会在一个成绩上花很多时间。他们会有一个或明或暗的“妥协时间窗”，在这个时间之后，他们会向同伴寻求协助，他们知道，本人不会因此而失掉负面评价。
团体从看得见的输入中别离出他们对团队的价值。我见过这样的状况，人们对本人的代码后来被删除或重构感到懊丧。但在安康的团队中，大家接受这样一个理想：改良是增量的、渐进的，贡献是对团队全体结果的贡献，而不是对特定输入（如代码行数）的贡献，表现出来就是“这是我们交付的”，而不是“这是我交付的”。此外，具有高度心思安全感的团队可以讨论价值的含义，以及价值为什么不只仅是几行代码。
带薪休假时间和病假时间往往会更长，这很幽默。我以为，这是他们的信心的一种表现，即团队的其他成员可以在他们不在的状况下继续做出正确的决策，由于他们之间曾经停止了足够多的对话，这使得整个团队都以为，他们在产品和技术决策上十分分歧。但我不太确定这其中的因果关系。由于人们假设发高烧，也会央求更多的带薪休假。
当一个团队有高度的心思安全感时，你可以尝试一些很酷的实验。我置信，这些实验会产生一种自我强化的积极反应循环，发明出更高层次的信任和安全感。在我的第一个高绩效团队里，在一次回忆中，每团体都觉得一年两次的绩效评价周期不够频繁，也不够细致，无法促进职业开展，尤其是在我们团队的优先事项开展得如此之快的状况下。所以，我提出了一项实验：反应周。
2. 反应周这是一个为期一周的进程，每团体（包括团队担任人和项目经理）都被随机分配去搜集对另一团体的反应。这个进程停止得如此顺利，以致于在我的队友参加新的团队后，也带去了这个实验。最终，办公室里的其他团队末尾模拟我们！我在这篇博文中更详细地引见了这个实验。我还在 2019 年的多伦多 DevOpsDays 大会上就此做了一场演讲。
https://deniseyu.io/2018/03/03/better-team-feedback.html
https://www.youtube.com/watch?v=6VARlKoEAPI
可以展开相似这样的反应周，就阐明你的团队处于高度的心思安全形状。假设你足够幸运参与其中，我的建议是：不要只站着不动。这是一个大胆实验你的进程和实际的时机，尝试像反应周这样的事情，可以协助你开掘隐藏的积极反应循环。假设你确实想出了一些很酷的东西，请通知我！
3. 良好的开发标准随着系统复杂性的添加，系统中任何单个行为主体的自有模型的准确性都会迅速降低。— Woods Theorem
我就直说了吧，我永远不会有一个残缺的 GitHub 心智模型。它太庞大了，有太多的逻辑途径，坦率地说，破费过多的时间学习代码的一切部分，并不能使我的任务做得更好。而且，它能够明天就又变了。
因此，当我必须搜集足够的上下文信息以完成下一个特性或 Bug 修复时，我会依赖于代码中已有构件的准确性，这些构件是在我之前从事这些任务的人留下的。
我花了很多时间来研讨代码：运转 git blame，查看过去的提交、 有关成绩，以及任何有助于我了解为什么某行代码这样写的信息。假设我看到一个难以了解的改动，提交信息是“WIP”，这就会变成效率杀手。
良好的软件开发标准意味着需求额外花一些时间来记载以后的上下文信息，这能够表如今：
描画性的提交信息。至少，做到每个提交信息都包含一个动词。有些团队甚至更进一步，要求每次提交都可以跟踪到成绩编号。务必选择适宜你的团队认知投资水平的办法；
遵照言语和框架商定、可以表明意图的类名和办法名；
单元测试带有有用的描画信息，运用契合实践的变量名和数据，而不是“foo”和“bar”这样的变量；
在成绩跟踪系统中就相关特性重复沟通，而不是在 Slack DM 和其他中央。今后，入职不满 6 个月的团队新成员将无法拜访这些中央。
(责任编辑：admin)