Storie utente per esigenze funzionali [chiusa]

Question

Dato che siamo una piccola società, io lavoro sia come project manager e sviluppatore. Le specifiche che creo per i clienti contengono devono essere inclusi per definire il progetto di un certo numero di elementi utilizzati per descrivere e definire il progetto, tra cui le storie degli utenti insieme a tutti gli altri elementi mi sento (ad esempio wireframe, userflows, sitemap, ecc) al client.

Se una specifica funzionale “viene descritto come un prodotto funzionerà completamente dal punto di vista dell'utente. Non importa come la cosa è implementata. Si parla di caratteristiche. “. Poi qualcuno vede alcun problema con l'utilizzo user story per definire una specifica funzionale per un sito web? C'è qualcuno che effettivamente fare specifiche funzionali in questo modo?

In realtà sto cercando del mio gioco un po ', e si chiede se questo approccio potrebbe funzionare per i clienti più grandi che magari hanno idee più severe su quello che una specifica funzionale dovrebbe contenere, per cui un approccio formale può essere richiesto. Sicuramente in questo momento i nostri clienti rispondono bene al nostro metodo di produzione di documentazione.

Sono interessato a sentire quello che le persone che fanno la gestione del progetto pensano professionalmente su questo.

Answer 1

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

Per prima cosa il bit sono d'accordo con - storie sono un ottimo modo di affermare requisiti funzionali. Per i miei soldi sono uno dei modi migliori di requisiti in realtà comunicare in modo gli utenti finali saranno davvero prendere in. Ho visto troppe specifiche che vengono firmato fuori senza aver mai stato letto.

L'unica cosa che posso dire che si potrebbe desiderare di aggiungere ad essi non è funzionale esigenze - che coprono le prestazioni, la sicurezza, i volumi di dati, audit, archivio e così via. Mentre possono essere coperti nelle storie, a volte sono meglio coperto in modo che attraversa tutte le storie.

In termini di se è adatto per le grandi aziende questo è dove sono in disaccordo. Nella mia esperienza (e ho fatto progetti per la Shell, American Express, un paio di banche multi-nazionali e altri) sono spesso non più formale rispetto alle imprese più piccole in modo da essere bene con storie. La realtà è che un utente in una grande azienda non è migliore è dotato (o interessati) nei diagrammi di classe e di sequenza di lettura di quello che sono altrove.

La dimensione e la complessità del progetto possono richiedere requisiti più dettagliati, ma è la dimensione del progetto, non la dimensione della società che conta quando si è determinare come documentare i requisiti.

Per me la migliore documentazione requisiti è la documentazione che è adatto alla sua audience, e per me le storie degli utenti colpito il chiodo sulla testa la maggior parte del tempo - sono abbastanza breve e sufficiente che al momento di firmare loro fuori significano qualcosa di chiaro perché hanno letto e capito (in contrasto con il segno fuori di un 100 pagina delle specifiche che significa invariabilmente che non hanno realmente leggerlo), ma abbastanza buono per gli sviluppatori di lavorare da troppo.

Answer 2

Sì, è possibile utilizzare le storie degli utenti per il vostro richiede funzionale. Io lo faccio tutto il tempo, e sono stati per anni. A mio parere, funziona davvero bene, e meglio di altri sistemi che ho usato.

Sarebbe questo lavoro approccio per i clienti più grandi? Per fare una generalizzazione lordo, n. Stanno per avere qualche sistema che usa per definire i requisiti, e probabilmente non le sue storie di utenti. Se venite con le storie degli utenti, ci sta per essere uno scollamento con le pratiche attuali, che si dovrà lavorare.

Ho avuto successo con le storie degli utenti con le organizzazioni più grandi, ma ci vuole uno sforzo concertato, che entrambe le parti devono essere impegnati a.

Answer 3

Quello che stai descrivendo sono gli scenari dei casi d'uso che definiscono le caratteristiche, questo è ciò che è richiesto dal punto di vista dell'usabilità ed è esattamente ciò che il cliente avrà compreso e accettato. mockup schermo e diagrammi di flusso sarà sicuramente aiutare sia il cliente e gli sviluppatori.

Una specifica applicazione può quindi essere richiesto per istruire gli sviluppatori su ciò che deve essere incluso nella costruzione vera e propria, la profondità di questo sarà determinato dalla vostra capacità di sviluppatori che includono la loro conoscenza della casa dell'architettura / quadro e metodologie / convenzioni e possono includere specifiche su quali conseguenze diverse parti dell'applicazione.

Lavoriamo anche in piccoli gruppi (a volte uno o due sviluppatori) e crediamo che la sopra è tutto quello che serve in questo caso.

Le grandi aziende con squadre molto più grandi possono utilizzare software di modellazione, diagrammi UML e di altre specifiche più dettagliate. Nel caso in cui si lo sviluppatore primario, si dovrebbe comunque passare il tempo a progettare la vostra applicazione, ma se nessuno sta andando a rivedere i disegni e insistere su tutte le formalità, il vostro tempo è meglio spendere l'attuazione del programma.