User story per i requisiti funzionali

Question

Poiché siamo una piccola azienda, lavoro sia come project manager che come sviluppatore. Le specifiche che creo per i clienti contengono un numero di elementi usati per descrivere e definire il progetto, comprese le storie degli utenti insieme a qualsiasi altro elemento che ritengo debba essere incluso per definire il progetto (ad esempio wireframe, flussi di utenti, sitemaps ecc.) Al cliente.

Se una specifica funzionale "descrive come un prodotto funzionerà interamente dal punto di vista dell'utente. Non importa come viene implementata la cosa. Parla di funzionalità. ". Quindi qualcuno vede qualche problema con l'utilizzo di User Story per definire una specifica funzionale per un sito web? Qualcuno effettivamente fa le specifiche funzionali in questo modo?

In realtà sto cercando di migliorare un po 'il mio gioco e chiedermi se questo approccio potrebbe funzionare per i clienti più grandi che forse hanno idee più stringenti su cosa una specifica funzionale dovrebbe contenere, per cui potrebbe essere richiesto un approccio formale. Sicuramente al momento i nostri clienti rispondono bene al nostro metodo di produzione della documentazione.

Sono interessato a sentire ciò che le persone che fanno la gestione del progetto in modo professionale a pensare a questo.

Answer 1

Sono in disaccordo con quello che hanno detto un paio di altre persone.

Per prima cosa sono d'accordo - le storie sono un ottimo modo di dichiarare i requisiti funzionali. Per i miei soldi sono uno dei modi migliori per comunicare realmente i requisiti in un modo che gli utenti finali prenderanno davvero in considerazione. Ho visto troppe specifiche che vengono firmate senza essere state mai lette.

L'unica cosa che vorrei aggiungere a questi requisiti è non funzionale: copertura di prestazioni, sicurezza, volumi di dati, controllo, archiviazione e così via. Mentre possono essere coperti in storie, a volte sono meglio coperti in un modo che attraversa tutte le storie.

In termini di idoneità per le grandi aziende, questo è il punto in cui non sono d'accordo. Nella mia esperienza (e ho realizzato progetti per Shell, American Express, un paio di banche multinazionali e altri) spesso non sono più formali delle piccole aziende, quindi andranno bene con le storie. La realtà è che un utente di una grande azienda non è meglio attrezzato (o interessato) a leggere diagrammi di classi e sequenze di quanto non lo siano altrove.

Le dimensioni e la complessità del progetto possono richiedere requisiti più dettagliati ma sono le dimensioni del progetto, non le dimensioni dell'azienda che conta quando si determina come si documentano i requisiti.

Per me la migliore documentazione sui requisiti è una documentazione adatta al pubblico, e per me le storie degli utenti colpiscono il chiodo in testa per la maggior parte del tempo - sono abbastanza brevi e chiari che quando li firmano significano qualcosa perché li hanno letti e capiti (al contrario dell'abbonamento di una specifica di 100 pagine che invariabilmente significa che non l'hanno davvero letto), ma abbastanza buono perché anche gli sviluppatori possano lavorare.

Answer 2

Sì, è possibile utilizzare storie utente per le proprie esigenze funzionali. Lo faccio tutto il tempo, e lo sono da anni. A mio parere, funziona molto bene, e meglio di altri sistemi che ho usato.

Questo approccio potrebbe funzionare per i clienti più grandi? Per fare una generalizzazione grossolana, no. Avranno un sistema che utilizza per definire i requisiti e probabilmente non le sue user story. Se entri in contatto con storie di utenti, ci sarà una disconnessione con le pratiche attuali, che dovrai affrontare.

Ho avuto successo nell'utilizzare storie di utenti con organizzazioni più grandi, ma ci vuole uno sforzo concertato, al quale devono impegnarsi entrambe le parti.

Answer 3

Quello che stai descrivendo sono gli scenari del caso d'uso che definiscono le caratteristiche, questo è ciò che è richiesto dal punto di vista dell'usabilità ed è esattamente ciò che il cliente capirà e accetterà. Mockup di schermate e diagrammi di flusso aiuteranno sicuramente sia il cliente che gli sviluppatori.

Una specifica di implementazione può quindi essere richiesta per istruire gli sviluppatori su ciò che deve essere incluso nella costruzione effettiva, la profondità di questo sarà determinata dalle capacità degli sviluppatori che includono la loro conoscenza dell'architettura/framework e delle metodologie/convenzioni della casa e può includere specifiche su quali conseguenze varie parti dell'applicazione.

Lavoriamo anche in piccoli gruppi (a volte uno o due sviluppatori) e crediamo che quanto sopra è tutto ciò che è richiesto in questa istanza.

Le aziende più grandi con team molto più grandi possono utilizzare il software di modellazione, i diagrammi UML e altre specifiche più dettagliate. Nel caso in cui tu sei lo sviluppatore principale, dovresti comunque passare il tempo a progettare la tua applicazione, ma se nessuno sta andando a rivedere i progetti e insiste su tutte le formalità, il tuo tempo è meglio spendere l'implementazione del software.