在 Tableau，Tableau Mobile团队约有 30 人，分布在 3 个 Scrum 团队中。我们主要在 Tableau Mobile 本身中处理代码，但也有一些人在 Tableau Desktop 和 Tableau Server 的前端和后端中处理代码。
问题
自上而下的沟通运作良好，但我们希望促进更多的工程师与工程师之间的沟通。
我们的粗略目标是：
- 增加团队间的沟通
- 有一个地方可以深入讨论代码和代码审查。有时代码审查会变得模糊，所以我们想要一个像人类一样实时讨论它们的地方
- 通过在编码之前讨论重大更改，首先防止泡沫代码审查
- 提高对影响多个团队的技术变更的认识
- 传播工程最佳实践
这是一个老问题：你如何从一个人的头脑中获取信息并进入其他人的头脑？要求软件工程师提前几周进行一小时的棕色袋子演示？怎么会有人知道哪些信息是有用的？
我们的解决方案
我们解决方案的核心是每周两次的架构会议。如果我们深入研究，“架构”这个词并不是很适合使用，但这个词可以涵盖广泛的用例，所以我们就用它。
随着时间的推移，我们对这种方法进行了迭代；以下是过去几年运作良好的方法：
- 开放主题：任何人都可以提出任何长度的任何与工程相关的主题。
- 向所有人开放：每个移动团队的每个人，无论角色如何，都被邀请参加。实际上，经常有十几个人参加。
- 可变主题长度：主题可以是快速通知，也可以根据需要填满整个小时。
- 可变形式：主题不需要包含官方幻灯片：它们可以是仅供讨论的、共享 IDE 的屏幕、剖析日志文件等。如果演示者认为它们会有所帮助，则幻灯片非常棒。
- 最后一分钟的话题：话题不需要提前声明。随时出现并说“我有一个话题”。
- 计划主题：主题可如果需要的话可以提前宣布：帖子在移动松弛预读与主题和任何通道，你希望人们能够阅读的时间提前。这可能是会议前几小时或几天。实际上，这用于更大的主题并充当非正式预订系统。提前发布主题也会增加会议出席率。
- 空时取消：如果在 5 分钟宽限期后没有人提出任何主题，我们将取消会议。早期的会议很少被取消，因为我们有积压的话题需要解决。这些天，它大约有 40% 的时间被取消。
- 可选出席：如果主题与您无关，可以公开离开会议。
很多话题
因为任何人都可以提出任何主题，所以各种各样的演讲都很棒。这些主题最终涵盖了很多领域——示例包括：
- 这是一个棘手的情况，我想深入了解并让我们做出决定
- 我刚刚结束了深入调查，我想传播此信息
- 我们正在考虑更改其他团队使用的这个库，这是权衡
- 我们正在考虑实现一些新功能，这种方法看起来合理吗
- 我即将进行大型代码审查，我想亲自指导人们完成这些更改
- 我发现了一个有趣的新调试/IDE 工具/功能，这是它的工作原理
- 以下是一些会影响多个团队的新用户体验设计
- 演讲嘉宾将在非移动区域 X 上发言，因为我们将需要与 X 集成。
这就是非正式性有帮助的地方。如果我们需要时间表和正式的演讲，其中一些主题就会丢失。不是每个人都喜欢把幻灯片放在一起，如果没有这个架构会议出口，信息就不会得到传播。“我想带每个人进行一次大型代码审查”感觉就像一个糟糕的棕色袋子会议，但对这些架构会议非常有效。
失败的实验
随着时间的推移，我们对我们的公式进行了多次迭代，其中一些不太成功的实验包括：
- 限制出席人数：邀请每个人只会做出更好的决定和结果。早些时候有人担心，例如，PM 会用诸如“可交付成果”和“愿望”之类的 PM 词来感染技术讨论……但这从未发生过。PM 知道会议可能是一次穿越 IDE 领域和日志剖析的白痴之旅，但他们尊重这一点并坚持下去。或者他们离开会议，这也完全可以。
- 要求声明主题：要求人们提前将主题发布到 Slack/电子邮件大大减少了演示者和主题的数量。
- 减少会议频率：每周两次意味着总有一个架构会议即将到来，您可以在那里展示您的主题。
- 单独的“社区”会议：我们也尝试过这个，有点像棕色袋子的方法，有主题和幻灯片，还有一些官方。参与度下降，并且不清楚“社区”会议除了灵活架构会议提供了什么之外还提供了什么。
好处
这种开放性和时间表灵活性的结合非常有效。在过去的几年里它运行得非常好，我们基本上已经停止了对这个概念的调整。我们已经看到的一些好处：
- 更多设计讨论：来自不同团队的多人讨论了大多数（所有？）甚至中等复杂度的设计
- 更多的变化意识：更多的人意识到即将发生的设计和代码变化
- 信息传播更快：更多人了解以前只有一个人知道的主题和概念
- 共享最佳实践：在整个团队中更广泛、更快速地共享工具和实践
- 更好的代码审查：代码审查的争议更少，意外更少，并且对每个参与的人都更有效率