Come organizzare i diversi frammenti in un ambiente agile?

Quando inizi il progetto, le storie epiche vanno in JIRA OnDemand con poco più di un titolo e forse una descrizione di base per consentire la definizione delle priorità e alcune stime molto approssimative.

Quindi i nostri proprietari di prodotti iniziano a discutere dall'alto per preparare le storie compilando i criteri di accettazione nella descrizione della storia e allegando qualsiasi screenshot, PDF, ecc. di wireframe o disegni che sono stati completati per quella storia direttamente a la storia in JIRA.

A questo punto, stiamo ancora usando solo la vista Piano della scheda Agile e non abbiamo creato attività secondarie.

I nostri team passano quindi attraverso il processo di stima per aggiungere i punti storia ad ogni storia. Poiché la stima e la pianificazione dello sprint avvengono, le storie possono essere suddivise in più storie più piccole sulla plan plan per supportare il lavoro nel prossimo sprint.

Una volta pronto uno sprint, iniziamo a creare le sotto-attività sulle storie per gli articoli. Manteniamo questi sotto-compiti molto leggeri (di solito solo un titolo per ricordarcelo) ma a volte se il team ha delle idee di implementazione, lo aggiungeremo all'attività appropriata.

I nostri file di progettazione di origine non sono conservati in JIRA, ma nell'area di progettazione appropriata sulla nostra rete, o sul nostro cliente, o DropBox, o ovunque sia stato concordato per il progetto.

Questa è una panoramica approssimativa di ciò che stiamo facendo, ma in relazione diretta con il tuo elenco:

• Design UI / UX: file di origine nel proprio repository, output appropriati direttamente sulle storie in JIRA
• Criteri di accettazione: Avevamo combinato con l'utilizzo di attività secondarie per questi, ma abbiamo scoperto che il mantenimento direttamente nella storia della descrizione è stato più facile per il monitoraggio.
• Vincoli: a seconda del vincolo, questo viene annotato direttamente nella storia (se specifico della storia) o viene tracciato come una propria storia che deve essere soddisfatta con sforzi di sviluppo e test specifici (ad esempio, supporto per l'accessibilità).
• Casi di utilizzo: manteniamo i nostri casi di test / casi d'uso come un tipo speciale di sotto-attività sotto la trama in modo che il team possa facilmente trovare tutti i casi che dovranno essere supportati e testati, e può anche monitorare l'avanzamento del completamento spostandoli attraverso il test e completandoli.
• Specifiche aggiuntive: le memorizziamo direttamente sulla storia, se brevi. Se è richiesto un foglio di lavoro visivo o completo, questi sono allegati come file nella storia.

Su storie pesanti relative all'interfaccia utente, alleghiamo PDF, risorse e altri elementi direttamente dai designer nel problema JIRA. Una discussione tende a svilupparsi nella sezione commenti del problema e nelle sue sotto-attività in quanto i vincoli, i criteri di accettazione e le specifiche vengono chiariti. Troviamo che questo è piuttosto semplice e non interferisce troppo. A volte incolliamo anche il contenuto delle email nel problema. Il {quote} wrapper funziona bene per questo.

Ciò che funziona per me e la mia azienda potrebbe non funzionare per il tuo (o per gli altri).

Prendiamo un approccio pragmatico e prendiamo le parti del "processo di sviluppo" che funzionano meglio per noi. Alcuni di questi saranno agili, alcuni saranno cascata.

Su alcuni progetti con alcuni client, alcune parti del processo avranno maggiore enfasi.

Potrebbe sembrare un'eresia su un sito di programmatori, ma ti consiglio di abbandonare gli strumenti e andare manualmente.

Buona lettura della Guida di Scrum (disponibile gratuitamente al link ) Lunga solo 17 pagine e molto semplice per capire.

Quindi prova a utilizzare elementi manuali come le schede per scrivere storie utente, spazi piatti grandi per le mischie, post-it per le attività, ecc.

Se desideri un avvio rapido, ecco un articolo sulla creazione di un backlog del prodotto . (Divulgazione: questo link ad un articolo sul mio sito web)

Questa operazione impedisce manualmente agli strumenti di pervertire ciò che stai cercando di fare. Successivamente, con l'esperienza, se ancora vuoi utilizzare uno strumento, puoi piegarlo a piacere, piuttosto che il contrario.