Scrivere storie utente per compiti tecnici interni [chiusa]

https://stackoverflow.com/questions/1707080

19-09-2019
|

Domanda

Sto tentando di gestire i miei progetti un po 'meglio quindi non vedo a tentare di applicare alcune delle (alla fine tutti) le caratteristiche di mischia .

storie di utenti specificamente formato alto livello sembra essere:

Come un utente che posso Funzione Descrizione

Artefatto è di fare qualcosa

Come faccio a scrivere "aggiornare il database"?

E 'semplicemente aggiornare il database?

Penso di essere gettato via in quanto non v'è alcuna specifica attore / cliente, il cliente è il reparto IT.

Soluzione

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value].

Per il vostro esempio una storia utente potrebbe essere simile a questo:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

Ho aggiunto un criterio di accettazione, perché senza questo non si sarà mai sapere quando il lavoro è fatto. Ora, a questo punto, si dispone di un business case per l'aggiornamento del database. Questa storia potrebbe essere scomposto in una storia in cui il ruolo è il reparto IT o DBA, in questo modo:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

Quando la storia di decomposizione viene aggiunto alla tua casella degli strumenti, la storia deve iniziare da dove l'utente è un vero e proprio parte del business, e la "in modo che" conduce ad un reale valore di business. Poi decomporre la storia in una o più storie in cui gli utenti interni fanno cose "in modo che" utenti reali ottenere i benefici nel bisogno.

Qui ci sono un paio di articoli che parlano di storia di decomposizione:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Altri suggerimenti

Scrum non è molto prescrittivo e non v'è non in Scrum che ti costringe a usare Storie utente per il Product Backlog Articoli (PBI). Si può sicuramente fare Scrum senza catturare requisiti / caratteristiche come le storie degli utenti, le storie degli utenti sono solo un modo per farlo. In realtà, le storie funzionano per molte squadre, in particolare i team di sviluppo web, ma questo non significa che lavorano in tutti i casi e in ogni progetto (molti progetti sono lo sviluppo del web, ma non tutti, come nel tuo caso). Non c'è consenso sull'utilizzo di storie.

Detto questo, il modello consigliato per User Stories è in realtà Come , voglio in modo che . Non voglio dire di essere troppo esigente, ma, se si sceglie di utilizzare storie, mi piacerebbe vivamente consiglio di usarlo così com'è, senza rimuovere alcuna parte. In primo luogo, utilizzando un ruolo di aiutano (uno stesso utente / persona può avere diversi ruoli) per scoprire storie. Poi specificando le vantaggi è veramente importante per esporre il valore di business di una storia al fine di dare la priorità loro bene. Per quanto riguarda il valore, si dovrebbe pensare ad esso come l'utente finale / cliente ( " metti gli occhiali dei clienti " --Mary Poppendieck). In realtà non è sempre così facile esprimere i benefici, ma alcuni strumenti potrebbe aiutare e il mio preferito è uno dei 5 whys (che viene utilizzato per l'analisi delle cause).

Nel vostro caso, questo potrebbe portare a qualcosa di simile: Come il reparto IT, voglio il database da aggiornare in modo che gli utenti possano beneficia delle più recenti funzionalità dell'applicazione e [fare un lavoro migliore | avere una migliore esperienza utente ] (non molto soddisfacente, però, utilizzare i 5 whys).

Ma personalmente non trovo che le storie degli utenti sono il mezzo migliore per compiti di natura tecnica, anche se è chiaramente possibile di usarli e se hanno i loro punti di forza. Teoricamente, storie catturano l'essenza, non i dettagli e dovrebbero essere un supporto per la discussione. Posso sbagliarmi, ma non trovo che i compiti tecnici offrono molto spazio per la discussione e la creatività. Quindi, a seconda di chi li leggerà, quello che la dovrebbe trasmettere, li potrebbe utilizzare o meno. Un'altra opzione potrebbe essere quella di mescolare le storie con un altro formalismo per la PBI. Come ho detto, il punto non è quello di utilizzare le storie, il punto è quello di avere un elenco di elementi prioritari e stimati .

aggiornare il database può essere uno dei compiti necessari nell'implementazione un'altra storia che porta valore diretto per l'utente, ad esempio I come un utente può aggiungere un nuovo foo al mio bar .

Se si aggiunge un pippo per un bar richiede l'aggiornamento di un database dietro le quinte, allora si dovrebbe includere che il lavoro nell'attuazione quella storia dell'utente.

Storie di utenti sono formulati in questo modo per contribuire a garantire che qualsiasi intervento diretto vantaggio del cliente finale in qualche modo.

Questo diventa alla ribalta del perché le storie degli utenti sono così grandi.

Quali sono i vantaggi di aggiornare il database danno per l'utente finale? Nessuna? Quindi non spendere tempo e soldi per farlo. Trascorrere il tempo e denaro fornendo qualcosa che darà valore al vostro utente finale.

Se lo fa? Poi pensare il contrario. Forse si può implementare solo una nuova funzione quando si ha la versione x del software di database? In dipendenza della storia, si potrebbe dire che l'aggiornamento del database necessaria per fornire questa funzionalità.

tl; dr Non solo aggiornamento per il gusto di farlo. Assicurarsi che l'aggiornamento aggiunge valore tangibile per i vostri clienti.

In generale, le attività tecniche nel PB sono disapprovate perché molto raramente direttamente fornire valore di business per il cliente. Ecco perché user story sono popolari, perché ti costringono a pensare al valore di business della storia, e che è in fase di trasportato a.

Quindi, perché stai eseguendo l'aggiornamento del database? Si può identificare il valore di business in aggiornamento, e perché dovrebbe il Product Owner accettare di lasciare che si aggiorna il database invece di costruire nuove funzionalità?

E 'a causa di una nuova funzionalità che renderà possibile o rendere più facile per fare qualcosa nella vostra applicazione? In tal caso, che qualcosa dovrebbe essere la voce PB, e l'aggiornamento del database dovrebbe essere un compito all'interno di quella storia. Se si dispone già di storie sul PB che potrebbero trarre beneficio da l'aggiornamento, quindi è necessario aumentare le stime per una o più di quelle storie, e aggiungere l'aggiornamento come un compito tecnico alla storia.

E 'perché il fornitore del database è tagliare una vecchia versione di un sostegno? In questo caso si potrebbe avere l'aggiornamento come la storia; qualcosa di simile, "Come il responsabile del reparto, voglio essere sicuro che abbiamo il supporto per tutto il software in modo che la continuità del business non è a rischio se qualcosa va storto". Anche questo sta spingendo, però. In generale, questo tipo di ragione non è in realtà parte di un progetto, a meno che il progetto è in corso da molto tempo il software di sistema si spegne di supporto.

E 'per le prestazioni? Poi la storia dovrebbe essere di circa alcuni aspetti della performance dell'applicazione che deve essere migliorato per fornire valore di business. Qualcosa di simile, "Come CSR ho bisogno di essere in grado di recuperare le informazioni sui clienti in un tempo ragionevole in modo che i clienti al telefono sono soddisfatti con il nostro servizio". Poi l'aggiornamento diventa un compito in quella storia.

E 'per qualche motivo totalmente tecnica? Se non è possibile identificare come l'aggiornamento sta per fornire valore di business, allora perché lo faresti? Perché il proprietario del prodotto sarebbe selezionarlo per uno Sprint?

E 'semplicemente "aggiornare il database" o forse "Quando si installa la nuova versione, ci deve essere un modo per eseguire la migrazione del database esistente". Se già conoscete Maggiori informazioni su questo passo, poi includerli. Ma la storia esiste principalmente per assicurarsi che qualcosa non è stato dimenticato; non è per essere dettagliata.

Più tardi, quando si arriva a implementare questa storia, si può carne fuori (quali tabelle, abbiamo bisogno di uno o più backup, c'è una caduta di nuovo scenario, ecc).

OTOH, se il progetto è più complesso, questo può diventare un "tag", come un post-it notare che deve essere collegato a molte storie. Ciò significa che è necessario includere questo come un "sub storia" per tutte le storie che cambiano il database. Come si può vedere, queste "storie di progetto-spanning" sono un po 'difficile da monitorare con metodi agili.

storie di infrastrutture non hanno bisogno di seguire il modello di storia prescritto. Basta scrivere quello che deve essere fatto e stimare di conseguenza

Come su:

Come la persona di supporto applicazione Voglio essere sull'ultima versione di database perché è più affidabile / più sicuro / qualunque cosa .

Si potrebbe anche frase refactoring del genere:

Come sviluppatore applicazione che voglio tutte le classi di dati in un modulo in modo che possa aggiungere nuovi campi per l'applicazione molto velocemente .

A chi giova
Che cosa si vuole fare
Qual è il vantaggio

Idealmente non volete tutte le storie di avere 1 essere sviluppatori, ma alcuni ha senso (affilare l'ascia invece di tagliare gli alberi e tutto il resto).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow