Tableau跨团队架构评审的工程实践

21-07-02 banq

在 Tableau,Tableau Mobile团队约有 30 人,分布在 3 个 Scrum 团队中。我们主要在 Tableau Mobile 本身中处理代码,但也有一些人在 Tableau Desktop 和 Tableau Server 的前端和后端中处理代码。

 

问题

自上而下的沟通运作良好,但我们希望促进更多的工程师与工程师之间的沟通。

我们的粗略目标是:

  • 增加团队间的沟通
  • 有一个地方可以深入讨论代码和代码审查。有时代码审查会变得模糊,所以我们想要一个像人类一样实时讨论它们的地方
  • 通过在编码之前讨论重大更改,首先防止泡沫代码审查
  • 提高对影响多个团队的技术变更的认识
  • 传播工程最佳实践

这是一个老问题:你如何从一个人的头脑中获取信息并进入其他人的头脑?要求软件工程师提前几周进行一小时的棕色袋子演示?怎么会有人知道哪些信息是有用的?

 

我们的解决方案

我们解决方案的核心是每周两次的架构会议。如果我们深入研究,“架构”这个词并不是很适合使用,但这个词可以涵盖广泛的用例,所以我们就用它。

随着时间的推移,我们对这种方法进行了迭代;以下是过去几年运作良好的方法:

  • 开放主题:任何人都可以提出任何长度的任何与工程相关的主题。
  • 向所有人开放:每个移动团队的每个人,无论角色如何,都被邀请参加。实际上,经常有十几个人参加。
  • 可变主题长度:主题可以是快速通知,也可以根据需要填满整个小时。
  • 可变形式:主题不需要包含官方幻灯片:它们可以是仅供讨论的、共享 IDE 的屏幕、剖析日志文件等。如果演示者认为它们会有所帮助,则幻灯片非常棒。
  • 最后一分钟的话题:话题不需要提前声明。随时出现并说“我有一个话题”。
  • 计划主题:主题可如果需要的话可以提前宣布:帖子在移动松弛预读与主题和任何通道,你希望人们能够阅读的时间提前。这可能是会议前几小时或几天。实际上,这用于更大的主题并充当非正式预订系统。提前发布主题也会增加会议出席率。
  • 空时取消:如果在 5 分钟宽限期后没有人提出任何主题,我们将取消会议。早期的会议很少被取消,因为我们有积压的话题需要解决。这些天,它大约有 40% 的时间被取消。
  • 可选出席:如果主题与您无关,可以公开离开会议。

 

很多话题

因为任何人都可以提出任何主题,所以各种各样的演讲都很棒。这些主题最终涵盖了很多领域——示例包括:

  • 这是一个棘手的情况,我想深入了解并让我们做出决定
  • 我刚刚结束了深入调查,我想传播此信息
  • 我们正在考虑更改其他团队使用的这个库,这是权衡
  • 我们正在考虑实现一些新功能,这种方法看起来合理吗
  • 我即将进行大型代码审查,我想亲自指导人们完成这些更改
  • 我发现了一个有趣的新调试/IDE 工具/功能,这是它的工作原理
  • 以下是一些会影响多个团队的新用户体验设计
  • 演讲嘉宾将在非移动区域 X 上发言,因为我们将需要与 X 集成。

这就是非正式性有帮助的地方。如果我们需要时间表和正式的演讲,其中一些主题就会丢失。不是每个人都喜欢把幻灯片放在一起,如果没有这个架构会议出口,信息就不会得到传播。“我想带每个人进行一次大型代码审查”感觉就像一个糟糕的棕色袋子会议,但对这些架构会议非常有效。

 

失败的实验

随着时间的推移,我们对我们的公式进行了多次迭代,其中一些不太成功的实验包括:

  • 限制出席人数:邀请每个人只会做出更好的决定和结果。早些时候有人担心,例如,PM 会用诸如“可交付成果”和“愿望”之类的 PM 词来感染技术讨论……但这从未发生过。PM 知道会议可能是一次穿越 IDE 领域和日志剖析的白痴之旅,但他们尊重这一点并坚持下去。或者他们离开会议,这也完全可以。
  • 要求声明主题:要求人们提前将主题发布到 Slack/电子邮件大大减少了演示者和主题的数量。
  • 减少会议频率:每周两次意味着总有一个架构会议即将到来,您可以在那里展示您的主题。
  • 单独的“社区”会议:我们也尝试过这个,有点像棕色袋子的方法,有主题和幻灯片,还有一些官方。参与度下降,并且不清楚“社区”会议除了灵活架构会议提供了什么之外还提供了什么。

 

好处

这种开放性和时间表灵活性的结合非常有效。在过去的几年里它运行得非常好,我们基本上已经停止了对这个概念的调整。我们已经看到的一些好处:

  • 更多设计讨论:来自不同团队的多人讨论了大多数(所有?)甚至中等复杂度的设计
  • 更多的变化意识:更多的人意识到即将发生的设计和代码变化
  • 信息传播更快:更多人了解以前只有一个人知道的主题和概念
  • 共享最佳实践:在整个团队中更广泛、更快速地共享工具和实践
  • 更好的代码审查:代码审查的争议更少,意外更少,并且对每个参与的人都更有效率

 

1
猜你喜欢