User Stories für die API-Integration
So schreiben Sie eine bessere User Story für die Integration. Dies ist einer von mehreren kurzen Artikeln zum Schreiben besserer User Stories mit ScopeMaster®.
Heutzutage besteht ein großer Teil der Software darin, verschiedene Komponentenanwendungen zu integrieren, um ein neues System zu erstellen. Folglich beziehen sich die Softwareanforderungen häufig auf die Verknüpfung eines Systems mit einem anderen. Bei dieser Art der Integration geht es in der Regel um den Datenaustausch zwischen den Softwareanwendungen. Manchmal handelt es sich um einen echten wechselseitigen Austausch, aber meistens geht es darum, Daten von einer Anwendung an eine andere zu senden oder Daten von einem externen System abzurufen. Diese Softwareintegration erfolgt typischerweise über APIs, wie z. B. RESTful-APIs, und oft auch über Microservices.
Lassen Sie uns unsere Aufmerksamkeit darauf richten, wie wir eine bessere User Story für diese Art der Integration schreiben können. Dies ist ein Bereich, in dem mir die Beispiele von Mike Cohn sehr gut gefallen. Hier ist ein einfaches Beispiel: Ein Benutzer einer E-Commerce-Anwendung erreicht den Adresseingabebereich. Sie können ihre Postleitzahl eingeben und eine Suche nach einem externen Dienst wird durchgeführt. Wie schreiben wir also am besten eine solche User Story?
Zunächst müssen wir erkennen, dass ein verbundenes System im Allgemeinen ein weiterer funktionaler Benutzer ist. Wir müssen auch unsere Sprache einfach und klar halten. Es gibt Hunderte, wenn nicht Tausende Möglichkeiten, dies zu schreiben. Hier ist nur eine vorgeschlagene Formulierung:
Als ein Käufer ICH wollen Zu hinzufügen Mein Versand Adresse, Verwendung der Posctode_lookup_api zum Abrufen der vollständigen Adresse aus einer Postleitzahl
In diesem Fall haben wir zwei Funktionsschritte in der User Story generiert. Eine zum Erstellen der Adresse und eine andere, die das ausführt extern Nachschlagen. ScopeMaster ist in der Lage, diese beiden Funktionsschritte zu identifizieren, die Funktionsabsicht zu bestimmen und somit eine gute Schätzung der Funktionsgröße zu erstellen.
Der Datenaustausch mit einer RESTful-API folgt normalerweise einem CRUD-Muster (Erstellen, Lesen, Aktualisieren, Löschen) oder (Puten, Abrufen, Posten, Löschen). Bei der Definition und Dimensionierung einer User Story ist es wichtig zu erkennen, dass wir erkannt haben, dass wir Daten versenden und eine Antwort von einem externen „Körper“ zurückerhalten (oder umgekehrt). Der externe „Körper“ kann zwar eine API sein, ist aber tatsächlich ein Benutzertyp oder genauer gesagt ein funktionaler Benutzer.
Erfahren Sie mehr unter wie man hochwertige User Stories schreibt für die Integration
Alternativer Wortlaut
Es gibt viele Möglichkeiten, dieselbe User Story zu schreiben, vielleicht Hunderte. Was wir hier beschreiben, sind also nur Beispiele. Sie können die Geschichte beispielsweise aus der Perspektive des externen Systems (in das wir integrieren) als Benutzer unserer Anwendung schreiben, z
Als Postleitzahlendienst kann ich auf Anfragen reagieren und bei Erhalt einer Postleitzahl Adressdaten versenden.
oder wir können dasselbe aus der Sicht des Benutzers unserer Anwendung schreiben.
Als Käufer kann ich beim Eingeben einer Postleitzahl meine Adresse vom externen Postleitzahlendienst abrufen.
Beides sind gültige Ansätze. Letzteres empfehlen wir aus zwei Gründen:
- Es konzentriert sich auf das Tatsächliche Benutzer Erfahrung.
- Es ist aus der Perspektive unserer Bewerbung geschrieben, nicht der externen Bewerbung.
Denken Sie daran, dass Sie beim Schreiben einer Integration zwischen zwei Anwendungen möglicherweise an beiden Stellen Code entwickeln und ihn unabhängig und als System testen müssen.
Schreiben von User Stories zur Integration
