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

Question

例如，团队A和团队B正在开发需要实现类似功能的不同应用程序。所讨论的功能依赖于数据库，并且数据库由team B控制。尽管这两个应用程序的用户界面基于不同的技术，但功能应该大致相同。两个团队都有自己的需求和设计文档。功能可以根据任何一个团队的反馈进行更改，但随后两个团队都必须更新他们的需求和设计文档。

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

您如何确保如果团队B更改了数据库和/或功能，另一个团队将得到适当的通知？您是否使用一些基于正式文本的文档，如接口合同？你能为这些分享任何模板吗？或者你使用其他的机制？

Answer 1

根据我自己的经验(听起来和你的非常相似)

您应该尝试为解决方案的数据库部分提供一个设计文档，如djna所建议的，它应该发布在wiki或类似的网站上，并具有与数据交互的定义的公共合同。这是朝着正确方向迈出的很好的一步，因为它将给每个人一种“共同的愿景”，帮助人们朝着做正确的事情的方向收敛。合同应该努力确保数据访问是以标准化的方式进行的。

然而，根据经验，代码并不总是完全遵循规范，所以我也会从其中一个团队中指派一个所有者，他的职责是将两个系统集成到数据库中。

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

从我工作的项目中，你可能仍然偶尔会有分歧和崩溃，最终我们合并了两个团队。这对我们来说是最好的解决方案！！

希望这能帮上点忙

Answer 2

如果有一个团队站点(两者都作为一个团队)或Wiki，这样两个团队都能意识到变化，那会怎么样呢？

Answer 3

定期召开的会议。通过电话会议。Stand-up == brief，高度聚焦，以信息为中心。将讨论委派给会议外的个人讨论，并在下一次汇报。

但是，确实需要一个全面的权威机构，在无法达成协议的地方进行调解，并确保整体解决方案的完整性。

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