agil freundlich zwei separate Anwendungen / Teams [geschlossen] zu integrieren

Question

Wir haben zwei verschiedene agilen Teams, jedes Arbeits auf separaten, aber miteinander verbundene Anwendungen.
Jedes Team hat bisher schon in einer unabhängigen Art und Weise (distinct Codebasen, Persistenz speichert, Sprint, Backlogs usw.) zur Arbeit der Lage. Vor kurzem entschied das Produktmanagement, dass diese Anwendungen werden besser noch enger integriert. Auf einer Seite zur Kenntnis, die Größe der einzelnen Teams (bestehend aus QAs, Devs, BAs) wird in den nächsten 6 bis 12 Monate zu erhöhen.

Das Management hat beschlossen, den agilen Prozess zu halten, weitgehend intakt, da es gut (zwei Teams unabhängig voneinander so viel wie möglich in Betrieb) gearbeitet hat, hat aber die Idee einer vertragsbasierte Dienstschicht als Mittel zur Integration der Anwendungen schwebt.

In jedem Sprint, jede Geschichte, die Integration mit der anderen Anwendung erfordert wird, identifiziert werden. An diesem Punkt wird eine zusätzliche „Integration“ Geschichte wird auf den anderen Teams Bestand hinzugefügt werden. Das Team wird dann mit der Erfüllung des Vertrages beauftragt werden. In der Zwischenzeit kann das andere Team ihre ursprüngliche Geschichte Arbeit fortsetzen, einen Mock / gefälschten Service ersetzt, bis das andere Team einen Arbeitsdienst produziert.

Da Agile eine KISS philosphy predigt, haben einige Leute auf die Teams genommen Problem mit der „Komplexität“ dieses Ansatzes. Sie befürworten als eine schlankere / einfachere Integration Methodik der Stored Procedure-Sharing fortgesetzt verwendet, dass „in der Vergangenheit gut gearbeitet hat“.

Ich ziehe Vertrag basierte Programmierung für alle Arten von Gründen, aber der Hauptgrund ist es die Fähigkeit der Kompilierung Einblick in das Verhalten, um Ihre Anwendung erwartet wird, zur Verfügung zu stellen. Sie erhalten auch klare Grenzen um, wer was Code besitzt, und dessen Code, den Sie wahrscheinlich zu brechen, wenn Sie Ihren Vertrag brechen. Stored Procedures tut nichts dergleichen.

Da haben wir bereits viele Vorteile aus agilem ernten, ich würde gerne glauben, dass es bereits eine „agile freundliche“ Art und Weise mit dieser Art von App-Integration / Synchronisation zu beschäftigen. Gibt es einen Vertrag basierte SOA Schicht trifft den agile Geruchstest zu schaffen? Gibt es eine dritte Möglichkeit habe ich nicht in Betracht gezogen?

Answer 1

Gute Frage. das Design Gratwanderung ist immer eine schwierige Sache. Ich denke, die Anwendungen zu halten so locker wie möglich gekoppelt ist definitiv der Weg zu gehen.

Die einfachste Sache, die könnte möglich Arbeit ein großer Ansatz ist, aber im Anschluss an diesen zu einem dogmatischen Ende ohne Rücksicht auf die SOLID Prinzipien und allgemeines gutes Design wird Ihnen zwei Anwendungen geben, die eng miteinander gekoppelt sind und wahrscheinlich voll von technischen Schulden, dass bringen wird in Zukunft das Team irgendwann zum Stillstand.

Die Entkoppelung und das Hinzufügen der Abstraktion in scheint jetzt wie das Vernünftigste, so lange zu tun, wie Sie nicht viele zusätzliche „Rahmen“ und fügte hinzu, die noch nicht benötigt wird. Der Trick besteht darin, sicherzustellen, dass Sie gut genug Design, das der Rahmen bei Bedarf ermöglichen würde, wachsen, ohne an dieser Stelle vieler unnötigen Sachen Aufbau aus -. Sie müssen nur genug tun, um die Anwendungen zu entkoppeln

Answer 2

Ich glaube nicht, dass die aktuellen Prozess intakt zu halten, ist eine gute Idee. Zusammenarbeit und Kommunikation zwischen den Teams haben sonst zu erhöhen, wird auf beiden Mannschaften negative Auswirkungen haben. Sie sollten in der Scrum Scrum ähnliche Praxis folgen.

Bearbeiten Scrum von Scrum. Ich habe keine Erfahrung mit Projekt von mehr als einem Scrum-Team behandelt, aber wegen der sehr guten Erfahrungen mit Daily Scrum ein glauben, dass Scurm von Scrum funktioniert und Steigerung der Produktivität in allen Teams