La mappa della storia utente organizza i requisiti per utente, attività, attività e storie utente più dettagliate, che suddividono il livello di attività dell'utente in parti implementabili più piccole. I pezzi sono destinati a servire come input per il backlog.
Nel tuo esempio, per l'acquirente le cose sono chiare: il ruolo determina la piattaforma. Per il venditore è meno ovvio a causa delle due piattaforme. Potrebbero essere previsti diversi approcci:
-
Storia indipendente dalla piattaforma: ciò significa che l'implementazione di ogni brano sarà sempre eseguita in parallelo, all'interno della stessa versione. Funziona meglio se si dispone di sottotitoli ciascuno responsabile della propria piattaforma.
-
Storie dipendenti dalla piattaforma al livello più dettagliato: menziona la piattaforma nella parte what-I-want della storia o come parte del ruolo utente. Personalmente, opterei per il modo meno convenzionale di aggiungere una clausola [on <platform>] per evidenziare che si tratta di una preoccupazione diversa. In ogni caso, queste opzioni sono l'ideale se potrebbe essere necessario avanzare a velocità diverse per ogni ambiente, o se avresti bisogno di avere diverse varianti su ogni piattaforma (ad esempio per sfruttare al meglio le funzionalità native)
-
Storie della piattaforma principale e storie portuali: è un mix degli approcci precedenti. Le storie degli utenti sono dettagliate in modo indipendente dalla piattaforma per una piattaforma di destinazione principale. Le storie di riepilogo selezionano diverse storie da trasferire sulla seconda piattaforma. Questo approccio funziona meglio se l'applicazione è sviluppata con una tecnologia multipiattaforma (ad esempio Xamarin, Qt, ...) su una piattaforma OS, ma con un design che facilita la porta all'altra piattaforma.
Come potete vedere, il fatto che le storie siano il backlog e utilizzate per determinare gli sprint, l'approccio migliore dipenderà in gran parte da come intendete organizzare lo sviluppo multipiattaforma e sulla struttura del vostro team.