所有伟大的团队都有一些价值观，过程和态度。
丽贝卡·多德（Rebecca Dodd）
1.他们使一切自动化
人脑的工作无可替代，但是通过使开发人员工作中一些更耗时（有时又乏味）的工作自动化，您不仅可以腾出时间用于其他更具创造性的工作，而且您确保您的软件开发过程易于重复，并且在每个发行周期内保持一致。 GitLab平台后端负责人Douwe Maan说：“我们每个月都有大量发布，但是我们有许多补丁发布。 我们的发行工具存储库中有大量脚本可以对其进行自动化，以使我们不会遗漏任何点，从而每次都相同且可重复。”自动化还意味着要做一些事情，例如利用持续集成来运行脚本，因此，您的代码审核将被接管，从而减轻了需要手动完成的工作。
2.他们对文档一丝不苟
Douwe解释说：“流程和指南的文档编制是一种脚本化或使团队行为自动化的方式。” 因为我们是一个分散的团队，所以很重要的一点是，如果经常出现问题，人们可以在某个地方找到他们需要的东西，而不必等待其他时区的团队成员上网并回答问题-这样可以节省时间，仅适用于有问题的人，但适用于那些愿意一遍又一遍地回答相同问题的人。 Douwe说：“如果我们团队中的人有一个特定的问题或一再阻碍他们的事情，这可能意味着我们应该更好地记录下来或发明一个流程。”
“因此，例如，当回归或安全问题发生时，我们就具有将合并请求和合并到补丁程序发行版中的流程。 在某一时刻，我们的人很少，我们只能说：“嘿，这需要进入补丁发行版，”但是随着团队的成长，这当然不再扩大了，因为您会有20个人问一个人。 为了解决这个问题，我们发明了围绕标签的流程，在GitLab中我们非常频繁地使用标签和里程碑来向人们发出信号，说明问题会发生什么。”
在周期的每个阶段都留有意见，问题或建议的空间对于促进协作并确保每个人都可以关注项目的最新进展至关重要。 “对我们而言，真理的唯一来源始终是问题。 标签，里程碑，分配给人们的工具，这些都可以确保合适的人知道何时该轮到他们做某事，并且通过问题评论进行交接。” Douwe解释说。 这是我们在记录问题的最新更新时必须遵守的另一个领域，因为作为分布式团队，我们不能只是走到同事的办公桌旁检查某些内容。 “我们没有问题，两天后人们会觉得，’嗯，我们又做出了什么决定？’”杜威说。 讨论是在我们工作的同一环境中进行的-无论是对问题的评论，合并请求还是对代码本身的内联问题-所有人都可以很容易地看到它的上下文并返回参考。以后再说。
3.他们使用集成平台
将所有软件开发工具都放在一个环境中可以减少上下文切换，API更改时的繁琐维护以及管理复杂性。 这也使开发过程更加顺畅，因为集成工具通常会在UI中提供快捷方式，而如果您使用两种单独的产品，则快捷方式是不存在的。
Douwe解释说：“很长一段时间以来，GitLab CI一直是单独部署的Web应用程序：UI并未以任何方式集成在一起，它们感觉就像是单独的产品，好像它们不是同一家公司生产的。 在某一时刻，我们决定将其集成，实际上，在一两个星期内，我们开始看到将这些应用程序互连的新可能性。 我们会想，“嘿，如果我们在此页面的最新状态添加按钮，会不会很整洁？” 以前这是我们从未想过的事情，因为我们确实将这两种产品视为需要通过既定渠道进行交谈的单独产品，而不是仅将链接放置在任何地方，只要有链接即可访问CI。 因此，使用内置解决方案，您获得的集成不仅紧密，而且以孤立的开发团队无法想到的其他单独产品的方式集成。 我们不仅将其视为问题跟踪器，代码审查工具或CI工具，还将其视为开发环境。”
4.他们控制一切
将版本控制用于源代码已被广泛接受，这是一个好主意，但是它对于许多其他目的也很有用。 以文档为例：如果使用Wiki，则没有合并请求的概念。 Douwe说：“没有立即提出改进的建议，是没有办法的。因此，这意味着在许多使用Wiki的地方，对其进行更改会让人感到恐惧。”这会产生一种建议更新或改进的感觉。改进仅针对高级团队成员，不鼓励参与文档的工作和协作。 “在这里使用源代码控制意味着即使是最初级的人，例如’嗯，我在这里发现了一个错字’，或’嘿，这不是很清楚，让我们这样做’，也不会犹豫。有足够的时间来写一个合并请求，清楚地概述了他们所提议的优点，这使得建议更改变得不那么吓人。 “它确实使文档（类似于源代码）成为每个人都可以贡献的开源和实时文档。”相同的原则适用于CI / CD配置，测试和基础结构代码等内容。
改进的协作和学习机会并不是对源代码以外的内容使用版本控制的唯一好处：在发生问题时回滚并查明引入错误的能力是优点，因为它更容易实现修复问题，而且团队成员也可以自由地进行实验，而不必担心如果事情破裂会造成无法弥补的损害。
5.他们使每个人都容易贡献
通过打开您的开发平台，其他团队成员可以发现其他团队成员的工作，为他们做出贡献并从中学习。 “如果将CI配置隐藏在只能由项目主管访问的区域中，则意味着团队中很少有开发人员，尤其是其他团队中几乎没有开发人员可以看到该配置，” Douwe说。 “您真的不应该将代码视为团队的产物，还应该将其视为公司其他所有人的资源。 如果您问开发人员他们是如何学习编码的，大多数人不会提及大学或他们所读的书，而大多数人会提及“我阅读的代码是由比我更有经验的人编写的”。 因此，通过让他们尽可能多地访问代码，实际上将使他们成为比在筒仓中工作的更好的编码人员。”
如果您问开发人员他们是如何学习编码的，大多数人不会提及大学或他们所读的书，大多数人会提及“我阅读的代码是由比我更有经验的人编写的。”
这不只是经验不足的开发人员向经验丰富的开发人员学习而已。 有时，从与项目不太接近的人那里获得新的观点可能会激发出解决方案，而当您深入了解一周的代码后，这些解决方案就不会显现出来。 “例如，如果有人读了代码，然后问”嘿，这背后的原因是什么？ 我刚刚找到了您的代码，我想知道……’它使对话成为可能。” Douwe解释道。 “这有助于我们避免“这里没有创造综合征”。”另一个团队的某个人可能已经完成了您以前的项目中需要的工作-为什么不在您的团队中使用它？ “通过共同努力，我们的所有代码都得到了改善，因为如果我们使用共享库（即使它只是公司内部的共享库，例如内部采购），那么如果一个人对其进行了改进或修复了错误或增加了该应用程序的功能，那一个人的工作将立即影响所有不同的团队。”
Douwe说：“我们没有20％的明确时间，但是在GitLab上，由于我们正在努力改进用于完成所有工作的同一平台，因此我们的工作就是使我们自己的工作更轻松。 这意味着，即使未计划在此版本中发布某些内容，但如果您认为可以在几个小时内完成，并且将来可以为您节省几个小时以上，那就去做。
有时，不需要花费正式时间来批准开发新功能的时间。 “除非您有紧急的事情要进行，否则它确实有助于要求开发人员对产品负责，并以可以提出新功能的建议来拥有产品，甚至可以带头开发新功能。例如通过产品管理”。
6.他们使代码审查协作
对您的工作进行审查可能会像您个人判断自己是否足够好。 当代码审查是关于“这是错误的，将其更改为”时，这可能确实令人沮丧。 Douwe解释说：“一种更好的方法，即使看起来似乎有明显的错误，也将问：’您对此更改有何看法/您是否考虑过X，Y，Z /我建议将其更改为此，如果您认为这有意义的话。 那里的交流确实有帮助，这也意味着人们不会觉得被别人告知他们的工作是否足够好，如果他们足够好，那真的是在谈论实际代码，实现“这是解决问题的最佳方法。”团队中的每个人都可以自由地查看彼此的代码或要求进行审查，因此，这仅是改进合并请求，而不是就此人的工作做出判断。 “如果审查感觉像是上级人士所做的事情，并且此时您的代码被认为是完美的，那么审查某人的代码可能会感到有些恐惧，尤其是当某人比您更有经验或拥有在该应用程序领域有更多经验。 真正有帮助的协作是让每个人都可以随意质疑彼此的代码或问题，“这是实现此目标的最佳方法吗？” 不用说’这是错误的。’”
7.允许他们发挥创造力
解决问题是开发人员要做的。 因此，如果客户要求他们认为有用的某些功能，那么要求团队解决客户遇到的问题可能会有所帮助，而不是向他们提供可能不是最佳解决方案的规格。 “在很多情况下，开发人员意识到由于内部采购，解决方案要么已经存在于代码库中，要么已经存在于其他人的代码库中，或者他们甚至可能只是阅读了这个炫酷的开源工具，而产品经理可能没有请注意。”道威说。 “因此，允许开发人员对提案真的持批评态度，并让产品经理的规范不至于太僵硬，这也可以为您提供更好的代码，并使开发人员更满意。”这还可以帮助您构建不仅解决特定问题的功能。客户的问题并按照他们希望的方式加以解决，而是研究对每个人都有用的解决方案。
要了解更多有关使开发团队今天成功的要素的信息，请观看我们的网络广播“管理DevOps文化转变”。
