集成两个独立应用程序/团队的敏捷友好方式[关闭]

Question

我们有两个不同的敏捷团队，每个团队都致力于独立但相关的应用程序。
到目前为止，每个团队都能够以独立的方式工作（不同的代码库、持久性存储、冲刺、积压等）。最近，产品管理部门决定这些应用程序将更加紧密地集成在一起。另一方面，每个团队（由 QA、Dev、BA 组成）的规模将在未来 6-12 个月内增加。

管理层已决定在很大程度上保持敏捷流程的完整性，因为它运行良好（两个团队尽可能独立工作），但提出了将基于合同的服务层的想法作为集成应用程序的手段。

在每个 sprint 中，将确定需要与其他应用程序集成的任何故事。届时，将在其他团队的待办事项中添加一个额外的“整合”故事。然后，该团队将负责履行合同。与此同时，另一个团队可以继续他们原来的故事工作，替换一个 mock/fake 服务，直到另一个团队产生一个工作服务。

自从敏捷宣扬 KISS 哲学以来，团队中的几个人对这种方法的“复杂性”提出了质疑。他们提倡继续使用存储过程共享作为一种“过去运作良好”的更精简/更简单的集成方法。

出于各种原因，我更喜欢基于契约的编程，但主要原因是它能够提供编译时对您的应用程序预期提供的行为的可见性。您还可以清楚地了解谁拥有什么代码，以及如果您违反合同，您可能会破坏谁的代码。存储过程不做这些。

既然我们已经从敏捷中获得了很多好处，我想已经有一种“敏捷友好”的方式来处理这种应用集成/同步。创建基于契约的 SOA 层是否符合敏捷气味测试？有没有我没有考虑过的第三种选择？

Answer 1

我认为保持当前流程不变是个好主意。团队之间的合作和沟通必须增加，否则将对两个团队产生负面影响。您应该遵循与 Scrum of Scrum 类似的做法。

编辑 Scrum of Scrum：我没有处理由多个 Scrum 团队处理的项目的经验，但由于在 Daily Scrum 方面的经验非常好，我相信 Scrum of Scrum 可以工作并提高所有团队的生产力。

Answer 2

很好的问题。走设计走钢丝总是一件棘手的事情。我认为保持应用程序尽可能松散耦合绝对是要走的路。

可能可行的最简单的事情是一种很好的方法，但是在不考虑 SOLID 原则和一般良好设计的情况下遵循这种教条主义的目的，将会给您提供两个紧密耦合的应用程序，并且可能充满了技术债务将在未来的某个时候使团队停止磨合。

现在解耦和添加抽象似乎是最明智的做法，只要您不添加许多尚不需要的额外“框架”。诀窍是确保您有一个足够好的设计，允许框架在需要时扩展，此时无需构建很多不必要的东西 - 您需要做的只是足以解耦应用程序。