Storie degli utenti per l'integrazione API
Come scrivere una storia utente migliore per l'integrazione. Questo è uno dei tanti brevi articoli su come scrivere storie utente migliori con ScopeMaster®.
Oggigiorno una grande quantità di software comporta l'integrazione di diversi componenti-applicazioni per creare un nuovo sistema. Di conseguenza i requisiti software si riferiranno spesso al collegamento di un sistema a un altro. Questo tipo di integrazione riguarda solitamente la condivisione dei dati tra le applicazioni software. A volte si tratta di un vero e proprio scambio bidirezionale, ma nella maggior parte dei casi comporta l'invio di dati da un'applicazione all'altra o la ricerca di dati da un sistema esterno. Questa integrazione software avviene in genere tramite API, come le API RESTful e spesso utilizzando microservizi.
Rivolgiamo quindi la nostra attenzione a come scrivere una storia utente migliore per questo tipo di integrazione. Questa è un'area in cui mi piacciono molto gli esempi di Mike Cohn. Ecco un semplice esempio: un utente su un'applicazione di e-commerce raggiunge la sezione di inserimento dell'indirizzo. Possono inserire il codice postale e viene eseguita una ricerca su un servizio esterno. Allora come possiamo scrivere al meglio questo tipo di user story?
Innanzitutto dobbiamo riconoscere che un sistema connesso è generalmente un altro utente funzionale. Dobbiamo anche mantenere un linguaggio semplice e chiaro. Ci sono centinaia se non migliaia di modi in cui questo potrebbe essere scritto. Ecco solo una frase suggerita:
Come un acquirente IO Volere A aggiungere Mio spedizione indirizzo, usando il Posctode_lookup_api per recuperare l'indirizzo completo da un codice postale
In questo caso abbiamo generato due passaggi funzionali nella user story. Uno per creare l'indirizzo e un altro che esegue il file esterno cercare. ScopeMaster è in grado di identificare questi due passaggi funzionali, determinare l'intento funzionale e quindi creare una buona stima della dimensione funzionale.
Lo scambio di dati con un'API RESTful segue in genere un modello CRUD (crea, leggi, aggiorna, elimina) o (metti, ottieni, pubblica, elimina). È importante riconoscere, quando definiamo e dimensioniamo una user story, che abbiamo riconosciuto che stiamo inviando dati e ricevendo una risposta da un "organismo" esterno (o viceversa). Il "corpo" esterno, sebbene possa essere un'API, è in realtà un tipo di utente, o utente funzionale per essere specifici.
Scopri di più su come scrivere storie utente di qualità per l'integrazione
Formulazione alternativa
Esistono molti modi per scrivere la stessa storia utente, forse centinaia di modi. Quindi ciò che descriviamo qui sono solo esempi. Puoi ad esempio scrivere la storia dal punto di vista del sistema esterno (con il quale ci stiamo integrando) come utente della nostra applicazione, ad es.
Come servizio del codice postale posso rispondere alle richieste e inviare i dati dell'indirizzo al ricevimento del codice postale.
oppure possiamo scrivere lo stesso dal punto di vista dell'utente della nostra applicazione.
Come acquirente posso recuperare il mio indirizzo dal servizio di codice postale esterno quando inserisco un codice postale.
Entrambi sono approcci validi. Consigliamo quest’ultimo per due motivi:
- Si concentra sulla realtà dell'utente esperienza.
- È scritto dal punto di vista della nostra applicazione, non dell'applicazione esterna.
Ricorda che quando scrivi un'integrazione tra due applicazioni potresti dover sviluppare codice in entrambe le posizioni e testarlo in modo indipendente e come sistema.
Scrivere storie utente di integrazione
