Storie utente - problemi che non possono essere fatte le storie degli utenti [chiusa]

Question

Sono da un background XP. So che il processo molto bene e hanno esperienza di lavoro solido con esso. Ho trovato che sia il modo migliore per sviluppare software.

mi trovo nella posizione di un medico processo di sorta e questo crea molto esame di coscienza e di rivalutazione delle mie comprensioni.

Una cosa molto comune che sento è che alcuni lavori non può essere fatta in storie. Io personalmente non credo che questo. Le scuse sono

1. La sua troppo grande (lo sviluppatore avrà nulla da mostrare fino alla fine di 5 settimane).
2. è un algoritmo complicato o concetto astratto (avrà 5 settimane per scrivere e nulla da mostrare).

Questa domanda è quello di ottenere suggerimenti, consigli o suggerimenti.

Sto cercando consigli, suggerimenti e consigli su come affrontare questi e simili problemi percepiti (e più se si può pensare di loro).

I segnerà la risposta che ha la maggior parte delle informazioni su come muoversi utenti / sviluppatori che sogliono scrivere storie e affrontare le loro molte scuse per spiegare perché non (ho solo elencato alcuni e ci sono molti di più) .

Answer 1

Quindi, in pratica, la tua domanda è: "Cosa posso fare se la gente reclama un compito è troppo grande per una storia utente, e non può essere divisa.

Nella mia esperienza, quasi ogni problema può essere diviso in su. Chiedete loro se possono implementare una versione semplificata, lasciare fuori le funzioni avanzate, forse anche utilizzare i valori di default in alcuni luoghi; in fondo tutto ciò per produrre qualcosa che dà significative (cioè verificabili) i risultati entro un iterazione.

Ricorda: Il punto di un'iterazione, non è quello di offrire funzionalità complete, ma la funzionalità solo utile e verificabile

.

Questa divisione può essere difficile, ma ti costringe a considerare che cosa si ha realmente bisogno prima, che è molto prezioso. Gli sviluppatori possono cagna su di esso (spesso faccio io stesso :-)), ma è davvero necessario. Abbattere grandi compiti in storie di utenti gestibili è nel cuore di tutti i metodi agili.

Detto questo, se il compito davvero, davvero, davvero non può essere suddiviso (si pensi complesso algoritmo matematico in un ambiente di ricerca, che richiede settimane per capire anche le basi di), allora il vostro iterazione è troppo corto. L'iterazione deve essere abbastanza a lungo per produrre risultati significativi. E se la maggior parte dei vostri problemi sono così difficili che prendono 2-3 mesi di tempo per fare qualsiasi cosa, allora questo è la lunghezza iterazione. Ma non ho mai visto un progetto in cui quello era davvero il caso ...

Answer 2

Qui ci sono alcune risorse che ho raccolto nel tempo e che potrebbe aiutare:

• Patterns per Stories Splitting utente
• Story riduzione del peso Toolkit
• Venti modi per dividere Storie
• modi per dividere le storie degli utenti

troppo grande o troppo complicato, c'è sempre un modo per mettere una storia a dieta (forse non sarà possibile ottenere il risultato finale in un'iterazione, ma questo non significa che non si può e, beh, non ci sarà più di un'iterazione).

Answer 3

Di solito quando si arriva "E 'troppo grande", che cosa realmente stanno dicendo è: "Ho solo una vaga idea di come questo dovrebbe funzionare". Hai bisogno di lavorare con loro per definire meglio fino a quando non diventa possibile dividerlo in parti logiche che possono essere più facilmente gestibili.

Answer 4

  

utenti / sviluppatori che scrivono storie wont

Gli utenti non sono tenuti a scrivere storie degli utenti. Essi non sono tenuti a raccontarvi le storie degli utenti. Ci si può aspettare loro di parlare di come funzionano, i problemi che li preoccupano e che cosa vorrebbero avere per facilitare il loro lavoro quotidiano.

, a vostra volta, si suppone che ascoltarli e prendere appunti. Se permettono, utilizzare un registratore o una videocamera. Poi si mettono le informazioni raccolte indietro quando si riproducono e identificare ciò che voi chiamate storie di utenti. Li discutere con la squadra e quando si dispone di un accordo si deve casi di utilizzo per indirizzare nel vostro sviluppo.

Che ruolo svolgono gli sviluppatori, dipende da voi. Se solo programmatori, non prendono parte al processo. Se in parte agiscono come consulenti, poi si aiutano a definire le storie degli utenti.

Answer 5

Il problema "specifica algoritmica" è comune.

Molte persone preferiscono scrivere codice e non mi importa chi è l'utente o quello che fanno.

cerco di farli mettere a fuoco da queste domande.

1. Quali azioni può prendere la persona? Cosa potrebbero mai do con le informazioni? Se hanno una parte di responsabilità, possono intervenire per negare, approvare, tenere, respingere, rielaborare, interrompere, avviare qualcosa. Se l'utente non può intraprendere alcuna azione, è necessario chiedere se sono veramente stake-holders.
2. Quale decisione cosa devono fare? Come il decidere quale azione (se presente) di prendere? Non possiamo automatizzare tale decisione -. è per questo che persone sono nel loop
3. Quali informazioni questa persona ha bisogno di prendere la decisione di agire.

Informazioni-decisione-azione.

Si scrive solo il software per preparare le informazioni per le persone a prendere decisioni in modo che possano agire.

Se questo non è il fuoco, poi le storie di uscire di controllo.

Answer 6

Il suo fondamentalmente il dovere e la responsabilità del proprietario del prodotto. E non ci può essere alcun requisiti / compito che non può essere diviso in User Stories. Ho trovato molte di queste discussioni su Scrum master Forum

Answer 7

Se il team di sviluppo sostiene che la storia è troppo grande e non può andare bene all'interno della sprint .. prendere il loro feedback e cercare di dividere la storia con deve avere e bello avere compiti e cercare di dividerlo basata su quella.

controllare questo diagramma di flusso .. può essere un aiuto: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf