0

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

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

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

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

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

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

4

2 回答 2

1

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

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

于 2010-08-17T20:00:48.117 回答
0

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

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

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

于 2010-08-17T18:25:35.430 回答