Tempi di implementazione di Visual Design in Agile

Question

Tempi di implementazione di Visual Design in Agile

#1 da (2 voti)
#2 da (2 voti)

1

Lavoriamo in Scrum con l'avvertenza che non abbiamo un prodotto potenzialmente spedibile alla fine di ogni Sprint, richiedendo invece diversi Sprint di indurimento / stabilizzazione prima del rilascio.

Una delle ragioni di ciò è che il nostro capo progettista UX preferisce che completeremo tutto il lavoro visivo (come colori, caratteri, layout e controlli esatti) nelle fasi successive del progetto. Da una parte ha senso perché una funzionalità con un'interfaccia utente decente basata su un wireframe è in genere sufficiente per ricevere feedback dagli utenti, quindi lavorare troppo duramente sulla grafica e sugli stili finali non è necessario per la riduzione del rischio. Potrebbe anche essere uno spreco se la funzionalità fallisce nei test di usabilità o se dopo un ulteriore feedback degli utenti decidiamo di cambiare la progettazione visiva per l'intero sistema, incluse le funzionalità che sono già state implementate. D'altra parte con questo approccio avremo una lista di caratteristiche che non sono completamente sviluppate, e con i lucidi finali che vengono lasciati fuori fino agli Sprint finali.

Cosa pensi che dovremmo fare? Dovremmo andare con la raccomandazione del capo progettista UX o dovremmo optare per un prodotto potenzialmente spedibile?

Grazie.

agile scrum user-experience

posta Eugene 07.03.2014 - 22:14

fonte

2 risposte

Leggi altre domande sui tag agile scrum user-experience

Dovremmo scrivere sempre codice di controllo Null difensivo? [duplicare] Qual è il modo migliore per mantenere la struttura del documento html e la struttura del controllo php strongmente visibili nel file di visualizzazione complesso

score 2 · Answer 1

In primo luogo, considera fortunato per aver effettivamente un progettista di UX:)

Non sono sicuro di essere d'accordo con la tua definizione di "shippable", comunque. La tua definizione non è negativa, potrebbe essere un po 'severa.

Se hai tutte le funzionalità codificate con un'esperienza utente decente (ma ancora sub-ottimale), sei già alla pari con la maggior parte dei software di produzione. Considererei questo possibile.

Lasciare lo sprint di lucidatura / tempra UX fino a tardi sembra una scelta saggia. Significa che la definizione della funzione, come richiesto dal PO e dagli utenti, è piuttosto stabile. Pertanto, è improbabile che la sua implementazione cambi e il rischio di dover ripetere l'UX è accettabilmente basso.

Non vedo nulla di sbagliato con l'approccio suggerito dai ragazzi UX. Vale a dire, a condizione che non abbia effetti collaterali negativi su altri ruoli o processi. Non ne hai menzionato nessuno quindi presumo che non ci siano.

score 2 · Answer 2

Sono d'accordo sul fatto che rinviare le decisioni finali sull'interfaccia utente fino a dopo è la strada da percorrere in questo caso. Disclaimer : presumo, in base alla domanda, che "l'interfaccia utente finale" sia una storia a parte. Inoltre, il fatto che tu abbia un designer UX dedicato presta credibilità a questo dato che quella persona sarà dedicata a lavorare su queste funzionalità.

Se la storia dell'utente afferma "Caratteristica X deve fare Y e Z" ed è brutta, allora va bene, puoi soddisfare i requisiti con alcuni bordi grezzi (icone segnaposto, schema colore temporaneo, ecc.) finché lì è una storia separata in seguito per riempire le lacune dell'interfaccia utente .

La cosa più importante è non perdere di vista i requisiti. Finché vengono inseriti nel sistema di tracciamento dei requisiti, pianificato e consegnato, non importa se li differisci più tardi. Ma se l'interfaccia utente è un fattore di rischio, perché lavorarci adesso e buttare via ore di produttività in seguito?