例如，团队 A 和团队 B 正在开发需要实现类似功能的不同应用程序。有问题的功能依赖于数据库，并且数据库由 B 团队控制。即使两个应用程序的用户界面基于不同的技术，但功能应该大致相同。两个团队都有自己的需求和设计文件。可以根据任一团队的反馈更改功能，但随后两个团队都必须更新他们的需求和设计文档。
团队在地理上分布，每个团队本身的成员也在地理上分布。两个团队都与相同的客户实体合作，但人员不同。每个团队都有自己的业务分析师（需求专家）。 我试图让团队之间的技术交流比电子邮件更正式，这样我们就可以避免误解。
如果团队 B 更改了数据库和/或特性功能，您如何确保其他团队得到适当的通知？您是否使用一些正式的基于文本的文档，例如接口合同？你可以分享任何模板吗？还是使用其他机制？
【问题讨论】：
我自己的一些经验（听起来和你的很相似）
您应该尝试为解决方案的数据库部分制定一个单一的设计文档，正如 djna 建议的那样，该文档应该发布在 wiki 或类似网站上，并具有与数据交互的已定义公共合同。这是朝着正确方向迈出的良好一步，因为它将给每个人一种“共同愿景”，帮助人们集中精力做正确的事情。合同应尽量确保数据访问以标准化方式完成。
但是，根据经验，代码并不总是完全符合规范，因此我还会从其中一个团队中指定一个所有者，其职责是将两个系统集成到数据库中。
然后，我将通过测试实现一个连续的夜间构建过程，并且这个构建应该包括数据库。这有望在此过程的早期标记任何问题。
在我从事的项目中，您可能仍然偶尔会出现分歧和故障，最终我们合并了两个团队。这对我们来说是最好的解决方案！！
希望对你有帮助
【讨论】：
如果有一个团队网站（作为一个团队）或一个 Wiki，以便两个团队都知道变化。
【讨论】：
定期站立会议。通过电话会议。站立 == 简短、高度集中、以信息为中心。将讨论委派给会议外的个人讨论，然后在下一次报告。
不过，确实需要一个总体权威，在无法达成协议的情况下进行调解，并确保整体解决方案的完整性。
我同意 Wiki 或其他协作网站发布当前现实。
【讨论】：