Sviluppo nativo di app per dispositivi mobili: come strutturare le storie degli utenti?


9

Sto per iniziare un progetto che prevede lo sviluppo di prototipi di app mobili native (inizialmente iOS e Android), nonché di un'interfaccia di amministrazione basata sul Web e un'API con cui queste app possano comunicare. Abbiamo già un elenco di storie già elaborate, tuttavia molte sono nel formato:

As a mobile user I want to be able to view a login screen so that I can sign into the app

Se questo fosse mirato per una singola piattaforma, non vedrei un problema. Tuttavia, poiché stiamo prendendo di mira più piattaforme, non sono sicuro se questi debbano ora essere duplicati, ad esempio "Come utente Android" o simili. Sembra una duplicazione, ma è un lavoro che dovrà essere completato separatamente per ogni piattaforma.

Questo è il primo progetto mobile su cui siamo diventati nativi - in precedenza era Phonegap e abbiamo inserito tutte le storie in "Come utente mobile". Dato che essenzialmente si trattava di un'app basata sul web e avvolta nel codice nativo, ciò non presentava un grosso problema, ma sono consapevole che le app interamente native sono un gioco di ruolo diverso!


Questo non è proprio specifico per i dispositivi mobili: si applica a un progetto che deve essere distribuito su più piattaforme, come un PC e Linux, o varie console di gioco. Il titolo dovrebbe essere cambiato?
Kevin Cline,

Risposte:


3

Non vedo perché non vuoi creare storie utente separate per ogni applicazione mobile. Anche se le storie sembrano simili, hanno enormi differenze sia dal punto di vista degli sviluppatori che da quello degli utenti.

Se stai usando un sistema come Jira, potresti persino creare un progetto separato per ogni applicazione. Questo approccio è migliore soprattutto se tutte le applicazioni sono completamente indipendenti in termini di risorse _ sviluppatori diversi, risorse informatiche diverse, ecc. Sarebbe più facile fare delle stime per ciascuna delle attività.

Se non vuoi ancora creare storie utente separate, puoi creare attività per ogni applicazione nella stessa storia. Questo sarebbe utile se si sviluppano tutte le applicazioni contemporaneamente, in modo che ogni storia venga completata quasi contemporaneamente.


2

(Suppongo che tu usi la mischia). Se il proprietario del prodotto sa in anticipo che darà sempre la priorità alle diverse piattaforme mobili allo stesso modo. (Ad es. Perché è una politica aziendale)

E se le storie degli utenti sono abbastanza piccole, in modo che il tuo team possa fare almeno quattro o cinque di esse in uno sprint.

Solo allora non dovresti dividere le tue storie mobili in una storia per piattaforma. Utilizzare la definizione di done per indicare tutte le piattaforme previste.

In tutti gli altri casi: dividi le storie mobili per piattaforma. Non c'è assolutamente nulla di sbagliato in questo.


Grazie Kris - prendo in considerazione il fatto che sono abbastanza piccoli, è sicuramente qualcosa da tenere a mente quando li
dividi

1

Per chiunque abbia aperto questa pagina, forse questa risposta può aiutare a fornire un'opzione per sviluppare con successo un'app per entrambe le piattaforme iOS / Android.

In qualità di project manager che ha gestito i progetti Agile / Scrum, la spiegazione sopra riportata sullo sviluppo della stessa applicazione per due diversi sistemi operativi indicherebbe due flussi di lavoro separati.

Per fare questo con successo richiederebbe due progetti separati. Ogni sistema operativo avrà i propri requisiti. Mescolando i due sistemi operativi in ​​un unico progetto potresti potenzialmente creare confusione su ciò che deve essere sviluppato in entrambi i sistemi operativi. Pertanto, il tuo team potrebbe perdere tempo prezioso per decifrare il sistema operativo a cui apparteneva il requisito. In sintesi.

Consiglierei di creare due progetti con il proprio set di storie utente specifiche per il sistema operativo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.