Un analista aziendale dovrebbe scrivere storie utente dell'API?

IMHO il punto chiave, che è già stato menzionato nei commenti, è se l'API è un requisito esterno (perché il tuo sistema offre a terze parti la possibilità di accedervi a livello di programmazione), o se è un dettaglio di implementazione interno.

Per la situazione precedente, può essere ragionevole vedere l'API come parte dei requisiti aziendali, quindi qualcosa di cui un BA sarebbe responsabile. Per quest'ultimo, ha spesso più senso lasciare che l'API sia sotto la responsabilità degli sviluppatori del team.

Si noti che questo è solo un "modello del libro": se si desidera che la separazione tra il "tipico ruolo dev" e il "tipico ruolo BA" nella propria organizzazione sia rigorosa, dipende da voi e dalla vostra squadra. Un team davvero agile dovrebbe distribuire le responsabilità nel modo in cui funziona meglio tra loro, non nel modo in cui un modello teorico le definisce.

tl; dr; Non dovresti scrivere le user story dell'API (nel tuo contesto), ma non tutti gli elementi del backlog sono user story.

Nei commenti, dici che l'API fa parte della tua architettura. Non è, di per sé, un prodotto che l'utente consuma (al contrario di prodotti come AWS che hanno un'API che gli utenti utilizzano per gestire i loro servizi). Pertanto, è impossibile scrivere una User story (dal punto di vista dell'utente) per l'API. Tieni presente che in origine le storie degli utenti erano state scritte dagli utenti.

Inoltre, l'API in questo caso è il modo in cui io, in qualità di sviluppatore, fornirei su un'altra storia di un utente, non su ciò che viene consegnato. Per utilizzare il tuo esempio, l'e-mail di conferma e effettuare una chiamata all'API è il modo in cui il team implementa tale funzionalità, in modo che rientri nella categoria di attività.

Naturalmente, le User story non sono richieste per Scrum. "Aggiungi la chiamata e-mail di conferma all'API REST" può essere un elemento di backlog - semplicemente non è una User story. Ci sono molti motivi per cui consiglierei di utilizzare user story invece di elementi backlog come questo, ma se ti trovi in una situazione in cui ne hai bisogno, non è intrinsecamente anti-scrum averne uno (potresti essere in violazione del team di sviluppo autonomia attorno all'implementazione, ma questo è un altro argomento).

Infine, chiunque può scrivere articoli nel backlog. Scrum dice solo che il proprietario del prodotto è responsabile della prioritizzazione e della salute del backlog. Se il team vede la necessità di un'altra storia utente o di un altro tipo di elemento del backlog, gli è consentito di scriverlo.

Credo che chiunque possa scrivere i requisiti dell'API a patto che abbiano familiarità con il dominio, le API, i test dell'API e abbiano un po 'di buon senso. Ma, ho visto alcuni Analisti di Business e amp; Product Manager che scrivono storie di API senza base & dettagli essenziali, rendendo così le storie inutili per sviluppatori e tester. Quindi, sviluppatori e tester devono capire da soli i requisiti.

Ad esempio, ho visto storie di API che non menzionano intestazioni, parametri di query, risposte di esempio, ecc. Alcune API hanno campi come data, percentuale ecc., ma mancano i formati previsti per questi campi. ( formato data USA o UK?, percentuale con 1 o 2 cifre decimali? Un BA o un PM hanno davvero bisogno di un grado di fantasia per fare domande semplici come queste? ). In tutte le storie, la risposta per diversi percorsi felici o scenari di utilizzo normali non viene mai menzionata.

Come doc brown giustamente menzionato, i requisiti di scrittura possono essere la responsabilità dell'intero team e non solo BA o PM. Ma se il tuo BA o il PM non sono abbastanza abili e abbastanza esperti da farlo, allora gli sviluppatori e il controllo qualità dovrebbero assumersene la responsabilità.

No. Un'API è un'interfaccia tra due (o più) pezzi di software (ad esempio lato client e codice lato server). Pertanto ritengo che sia generalmente preferibile che la natura dell'API sia negoziata tra gli sviluppatori, oi team, responsabili della creazione e della manutenzione di questi due software.