您如何维护开发团队之间的技术合同？

Question

例如，团队A和团队B正在处理需要实现类似功能的不同应用程序。所讨论的特征依赖于数据库，并且数据库处于团队B的控制之下。尽管两个应用程序的用户界面基于不同的技术，但功能应该大致相同。两个团队都有自己的要求和设计文件。可以根据任一团队的反馈更改功能，但两个团队都必须更新其需求和设计文档。

团队在地理上分布，每个团队的成员本身也在地理上分布。两个团队都使用相同的客户实体，但不同的人。每个团队都有自己的业务分析师（需求专家）。 我试图让团队之间的技术交流比电子邮件更正式，这样我们就可以避免误解。

如果团队B更改数据库和/或功能部件，您如何确保其他团队得到适当的通知？您是否使用一些正式的基于文本的文档，如界面合同？你能分享那些模板吗？或者您使用其他机制？

Answer 1

如果有团队网站（作为一个团队）或Wiki，以便两个团队都知道这一变化。

Answer 2

根据我自己的经验（听起来与你的非常相似）的一些事情

你应该尝试为解决方案的数据库部分设计一个单独的设计文档，因为djna建议应该在wiki或类似的地方发布，并与定义的公共合同进行数据交互。这是朝着正确方向迈出的一大步，因为它将为每个人提供一种“共同愿景”，帮助人们融合做正确的事情。合同应该努力确保数据访问以标准化方式完成。

但是，根据经验，代码并不总是完全遵循规范，因此我还要从其中一个团队中分配一个所有者，其职责是将两个系统集成到数据库中。

然后，我将使用测试实现连续的每晚构建过程，并且此构建应包括数据库。这有望在此过程的早期标记任何问题。

从我参与的项目中，您可能偶尔会出现分歧和分解，最终我们合并了两个团队。这对我们来说是最好的解决方案!!

希望这有点帮助

Answer 3

定期举行会议。通过电话会议。站立==简短，高度集中，信息为中心。将讨论委托给会议外的个人讨论，并在下一次报告。

但是，确实需要有一个整体权威，以调解无法达成协议的地方，并确保整体解决方案的完整性。

我同意Wiki或其他协作网站发布当前的现实。