Attualmente utilizziamo JIRA per tracciare il nostro lavoro di sviluppo. La mia direzione vuole formattare e classificare tutto come "User Story", comprese le attività relative allo sviluppo non software. Per esempio:

"In qualità di test manager, posso eseguire test dell'applicazione utilizzando solo test automatici e nessun test manuale in modo da poter testare l'applicazione nel modo più efficiente possibile?

Criteri di accettazione: 1. Convertire 50 test manuali esistenti in test completamente automatizzati 2. I test devono essere eseguiti in meno di 1 ora "

Voglio avere un senso dalla comunità se ha senso usare "user story" per lavori che supportano il processo di sviluppo del software, non sono fatti dai programmatori e non danno direttamente un codice consegnabile. O dovrebbe essere gestito / classificato in modo diverso (ad esempio, in JIRA)?

Aggiornato il 6/7/2011 - Domanda riformulata per concentrarsi sul termine "user story".

sì

qualsiasi stakeholder, qualsiasi funzionalità che migliora il sistema

[lascia che i deprezzamenti puristi abbiano inizio!]

"La mia direzione vuole utilizzare Agile per tutto, comprese le attività relative allo sviluppo non software."

Questo non significa scrivere storie utente per ogni funzione.

Se vuoi scrivere storie utente per ogni funzione, non sei necessariamente Agile. Stai solo scrivendo storie utente per ogni funzione.

User Stories! = Agile.

User Stories è un modo per raccogliere e comprendere i requisiti. Possono essere usati in modo perfettamente a cascata, se lo si desidera. Alcune persone lo fanno.

Agile è un modo per gestire i progetti. È possibile utilizzare le User Story o meno in un progetto Agile.

User Story per gestire il debito tecnico e le attività interne - ancora una volta - non ha nulla a che fare con l'essere Agile.

Molte persone sono perfettamente felici di aggiungere funzionalità "tecniche" o di "supporto" a uno sprint senza perdere tempo a scrivere una falsa "user story" per utenti puramente interni, a valore aggiunto limitato e senza stakeholder.

Se il QA non capisce la loro storia, quanta perdita reale di affari c'è?

Se i veri stakeholder non ottengono le loro storie, il business ne soffre davvero.

Questo non ha senso per me. Una "User Story" in sostanza è proprio questa, una user story, non una storia di Project Manager, non una storia per sviluppatori, non una storia per ingegneri di garanzia della qualità.

In tale nota, il software è:

1. definibile
2. testabile

I miglioramenti del processo sono aperti e in genere soggettivi.

Criteri di accettazione: 1. Miglioramento al test 1 (di x / y)

Come si misura il miglioramento dei test? Non esiste un contratto definibile per questo.

E su una nota non correlata Sinceramente spero che il tuo esempio di cui sopra,

Come responsabile dei test, posso eseguire i test dell'applicazione utilizzando solo test automatici e nessun test manuale in modo da poter testare l'applicazione nel modo più efficiente possibile?

... è solo un esempio, perché c'è così tanto di sbagliato in questo che non posso nemmeno iniziare a descriverlo.

Il debito tecnico potrebbe essere gestito in modo simile alla storia di un utente, ma a volte può diventare piuttosto brutto. Ad esempio, per avere una storia del tipo "Come sviluppatore, voglio avere test di unità di lavoro in modo da poter avere fiducia nei test per convalidare se altre modifiche rompono qualcosa", non ha molto valore per il proprietario del prodotto ma potrebbe essere una buona idea per il team fare come parte del proprio refactoring che fa parte del lavoro in uno sprint.

Mi piace l'idea di avere attività separate dalle storie degli utenti in quanto le attività non saranno qualcosa che mostreresti a un utente finale di un sistema, ma potrebbero essere qualcosa per aiutare a migliorare la manutenzione e il tempo necessario per sviluppare alcune nuove funzionalità. A seconda di quante attività, in termini di punti totali in quanto alcune attività possono essere di 2 minuti e altre possono essere di 2 settimane, è stato creato questo potrebbe essere ciò che determina se il team prende uno sprint e non inserisce nuove funzionalità ma funziona su compiti per ripulire le cose che ho visto alcune volte in cui lavoro.

A mio modesto parere, sì, è possibile utilizzare le storie degli utenti per progetti di sviluppo non software, non solo attività di miglioramento dei processi. Ad esempio, 3 anni fa sono stato il migliore uomo al matrimonio del mio amico e ho usato la metodologia Agile e le storie degli utenti per pianificare il matrimonio. Tutte le attività che dovevamo completare sono state scritte come storie utente con criteri di persona, intento, giustificazione e successo per ciascuna storia utente. Tutte le parti coinvolte hanno preso parte alla nostra mischia quotidiana per discutere di ciò che abbiamo fatto il giorno precedente e di ciò che avremmo fatto quel giorno. Tutti erano geograficamente dispersi, quindi abbiamo tenuto delle teleconferenze per le nostre riunioni quotidiane di scrum, pianificazione dello sprint, retrospettive, storie di scrittura e sessioni di stima ... tu lo chiami, l'abbiamo fatto. Abbiamo avuto 6 sprint in totale (3 mesi) e il matrimonio è stato un successo strabiliante senza lasciare nulla di intentato.

Hai un problema profondo quando metti "user story" interne nel mix con user story reali.

Ti preghiamo di rileggere quante più definizioni di "stakeholder" puoi trovare.

http://en.wikipedia.org/wiki/Scrum_(sviluppo )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Leggili molto, molto attentamente in modo da poter vedere la differenza tra polli e maiali.

Le "storie degli utenti" interne sono scritte da polli.

Le storie degli utenti reali sono scritte da maiali.

Le storie degli utenti "orientate al pollo" non sono molto importanti. Non importa quanto la direzione voglia seguirli come se fossero storie utente reali con valore reale, non sono storie utente reali e non creano valore allo stesso modo.

Al limite sfocato dell'argomento c'è il problema del QA. Il QA è importante e senza di esso nulla funziona.

Ciò non rende magicamente il QA all'improvviso un maiale. Li rende ancora non stakeholder. Forniscono supporto, infrastrutture e una base essenziale per il resto del lavoro. Ma sono "storie utente" sostanzialmente diverse dalle storie utente reali dell'utente.

Se il controllo qualità non mostra un miglioramento dei test, nessuno fallisce. Il denaro non è perso.

Se l'utente non è in grado di svolgere attività commerciali in primo luogo, sei fuori dal mercato. Il denaro è perso L'intera operazione è un fallimento totale.

Non mescolare parti interessate interne ("pollo") e reali ("maiale").

Il commento su "polli e maiali" non è pertinente. Gli stakeholder interni sono polli quando si tratta del prodotto in fase di sviluppo (a meno che non sia stato sviluppato per loro), ma sono maiali quando si tratta del processo di sviluppo.

La domanda che stai ponendo è se la formula della frase "Come a , Vorrei poterlo fare _ , in modo che io possa __ "sarebbe utile per definire e migliorare i processi aziendali in cui i miglioramenti non richiedono la scrittura di nuovo codice software. Ho trovato questo thread perché sto pensando di fare la stessa cosa e sto cercando le migliori pratiche, ma la mia forte intuizione è che la risposta alla tua domanda è "sì". Lo scopo della struttura della frase è davvero quello di costringere lo scrittore a sottrarre soluzioni che potrebbe già avere in mente e concentrarsi su ciò che l'utente - in questo caso, l'utente del processo - vuole essere in grado di farlo. Non vedo alcun motivo per cui la user story non sarebbe utile quando applicata al processo.

Il punto sui criteri di accettazione è buono, ma non è necessario che sia dogmatico (che è comunque Agile). È un buon esercizio nel progettare qualsiasi processo aziendale chiedere: "Come faccio a sapere se il cambiamento nel processo ha raggiunto il mio obiettivo?" È vero che non è sempre possibile eseguire un test automatico per rispondere a questa domanda, ma non è un motivo per squalificare la user story come strumento.