我们有两个不同的敏捷团队，每个团队都在分开但相关的应用程序上工作 到目前为止，每个团队都能够以独立的方式工作（不同的代码库，持久性存储，冲刺，积压等）。最近，产品管理部门决定将这些应用程序更紧密地集成在一起。另一方面，每个团队（由QAs，Devs，BA组成）的规模将在未来6-12个月内增加。
管理层决定保持敏捷流程基本完好，因为它运作良好（两个团队尽可能独立工作），但已经提出了基于合同的服务层作为集成应用程序的方法。
在每个sprint中，将识别需要与其他应用程序集成的任何故事。此时，其他团队积压将添加一个额外的“整合”故事。然后该团队将负责履行合同。与此同时，另一个团队可以继续他们原创的故事工作，代替模拟/虚假服务，直到另一个团队提供工作服务。
由于敏捷宣传KISS哲学，团队中的几个人已经对这种方法的“复杂性”提出了质疑。他们提倡继续使用存储过程共享作为一种“过去运作良好”的更精简/更简单的集成方法。
出于各种原因，我更喜欢基于合同的编程，但主要原因是它能够为应用程序预期提供的行为提供编译时可见性。您还可以清楚地了解谁拥有什么代码，如果您违反合同，您可能会破坏其代码。存储过程不执行任何操作。
由于我们已经从敏捷中获得了许多好处，我想我们已经有了一种“敏捷友好”的方式来处理这种应用程序集成/同步。创建基于合同的SOA层是否符合敏捷气味测试？我还没考虑过第三种选择吗？
答案 0 :(得分：1)
我不认为保持当前流程完好是个好主意。团队之间的合作和沟通必须增加，否则将对两个团队产生负面影响。你应该遵循Scrum of Scrum的类似做法。
修改 Scrum Scrum：我不具备由多个Scrum团队处理的项目经验，但由于对Daily Scrum的非常好的经验，我相信Scrum的Scurm可以工作并提高所有团队的工作效率。
答案 1 :(得分：0)
好问题。走设计走钢丝总是一个棘手的问题。我认为保持应用程序尽可能松散耦合绝对是可行的方法。
最简单的方法是可行的工作是一种很好的方法，但是在不考虑SOLID原则和一般优秀设计的情况下遵循这一原则会给你两个紧密耦合并且可能充满技术债务的应用程序将在未来的某个时刻让团队停下来。
现在解耦和添加抽象似乎是最明智的事情，只要你不添加许多尚未需要的额外“框架”。诀窍是确保你有足够好的设计，允许框架在需要的时候增长，而不需要在这一点上构建大量不必要的东西 - 你需要做足够的事情来解耦应用程序。