Progettisti di UX che lavorano avanti con uno Sprint

I nostri designer UX di solito hanno una storia in Sprint X che gli sviluppatori implementeranno in Sprint X + 1 (I designer UX e gli sviluppatori / tester fanno parte di un team). Penso che questo abbia senso perché se non hai modelli di schermate e specifiche chiare non puoi davvero stimare il lavoro durante Sprint Planning.

Tuttavia, in Scrum dovresti avere solo storie utente che forniscono valore all'utente. Nel nostro caso le storie di design di UX non forniscono tale valore (sono più simili a un'attività di toelettatura degli arretrati). Inoltre di solito gli allenatori Scrum non raccomandano di avere specifiche complete prima dell'inizio dello Sprint, una raccomandazione che trovo difficile da capire.

Quindi vedi degli svantaggi nel nostro approccio? Sembra funzionare per noi, ma va contro i principi Scrum.

Tuttavia, in Scrum dovresti avere solo storie utente che forniscono valore all'utente.

Il valore non viene misurato solo in righe di codice shippable.

Sembra che tu abbia implicato che avere un'interfaccia utente ben progettata non fornisca alcun valore. Certo che lo fa. Ovviamente c'è valore per l'utente finale, ma c'è anche valore per il tuo team di sviluppo, che è un stakeholder perfettamente valido. Se non disponi degli strumenti e dei materiali per svolgere il tuo lavoro, non puoi offrire valore all'utente finale.

Non rimanere impiccato sul dogma della mischia. Scrum è lì per renderti più efficiente. Se fare una storia UX uno scatto prima di implementare l'interfaccia utente ti aiuta a fornire un software migliore, fallo.

I principali svantaggi sono questi:

1. Sei in coda: se i tuoi progettisti sono in ritardo, i tuoi sviluppatori rimangono senza lavoro; se i tuoi sviluppatori sono in ritardo, il tuo progettista alla fine lavorerà più di una iterazione in anticipo. Non è una situazione stabile, non è sostenibile .

2. I tuoi designer stanno lavorando in anticipo, stai pagando i costi per storie che possono o non possono essere sviluppate. Anche se succede raramente, stai ancora buttando via i soldi.

3. I tuoi progettisti di UX stanno prendendo decisioni in anticipo senza coinvolgere gli sviluppatori. Ti mancano informazioni utili e aumenti il ​​rischio che i disegni siano completamente sbagliati o non realistici. Questo è abbastanza comune perché il design di UX non è un esercizio "astratto" - deve essere realizzato in base alle caratteristiche dell'applicazione (incluso ciò che è fattibile / consigliabile o no tecnicamente)

4. Escludere o privare di potere i tuoi sviluppatori non è un modo sostenibile per eseguire un progetto.

5. I designer non offrono valore: ciò significa che è difficile, se non impossibile, dare la priorità al proprio lavoro in modo corretto. Di solito, al lavoro degli sviluppatori viene assegnata la priorità usando diverse preoccupazioni, valore, fattibilità nel prossimo sprint, quantità di sforzo. Molte storie temporali vengono negoziate e modificate per renderle "adatte" o a causa di utili discussioni: se una di queste cose cambia l'interfaccia utente (e puoi supporre che lo faccia se non è un semplice dettaglio di implementazione), cosa fai con la storia? Non puoi più giocarci.

6. Stai supponendo che una storia che possa rientrare in una iterazione per i progettisti si adatti a una iterazione per gli sviluppatori: come puoi dividere le storie in modo che questa ipotesi sia corretta?

Mi piace, per due motivi:

1. sembra funzionare per te; è difficile discutere con successo!
2. il team di UX prende la storia e inizia la conversazione in anticipo - e le conversazioni sono un po 'il punto delle storie

Un requisito di base di Scrum è che il team di Scrum abbia tutte le competenze necessarie per creare un prodotto potenzialmente rilasciabile. Nella situazione che descrivi, questo non sta accadendo.

Il team di UX non sta producendo prodotti potenzialmente rilasciabili e il team di Scrum non è in grado di produrre sezioni verticali di funzionalità in quanto non possiede tutte le competenze richieste. Queste sono disfunzioni.

Sklivvz ha scritto un eccellente post sui problemi che le disfunzioni di cui sopra potrebbero portare. In sintesi, non penso che tu stia praticando Scrum.

Ma non c'è assolutamente nulla di sbagliato in questo. Se hai scoperto un modo di lavorare che offre valore a tutti voi e ne siete tutti contenti, continuate a farlo. Il mio unico consiglio sarebbe di ispezionare e adattarmi frequentemente.

Nota, tuttavia, che se il tuo obiettivo è fornire software utilizzando Scrum, dovrai affrontare le disfunzioni identificate.

Ci sono due problemi qui, uno sulla progettazione centrata sull'utente e l'altro sull'allineamento dello sprint.

Primo : le storie degli utenti dovrebbero essere allineate con le esigenze degli utenti, non solo degli arretrati. Le storie di UX devono avere un chiaro valore per gli utenti. Ciò non richiede specifiche complete e una breve dichiarazione come,

"Gli utenti avranno un accesso più facile all'attività dell'account su una singola pagina anziché divisa tra più pagine"

è suscettibile e adattabile a varie implementazioni e tuttavia ancora chiaro sul valore per l'utente (accesso più facile all'attività dell'account).

Secondo : allineamento Sprint. UX progetta funzionalità in Sprint X che gli sviluppatori implementano nella primavera X + 1. In pratica, ciò accade in molti negozi e talvolta può essere più simile all'implementazione nello sprint X + 2 o X + 3. Con un team nitido ed esperto questa configurazione può funzionare. Diventa difficile se hai un nuovo team o nuovi membri che non hanno familiarità con le competenze, le preferenze, le abitudini, gli stili di lavoro e le tendenze degli altri membri del team. Se lavori insieme da meno di 6 mesi, è probabile che ciò costituisca un problema.

Fai un passo indietro e rivaluta. Il lato positivo è che i designer e gli sviluppatori di UX lavorano fianco a fianco, il che è un vantaggio. Inizia assicurandoti che le tue storie abbiano un chiaro valore per gli utenti.

Uno dei possibili problemi che vedo è che in Scrum l'ambito per lo sprint N + 1 è normalmente determinato prima dell'inizio. Quindi, come puoi fare UX per lo sprint N + 1 storie nello sprint N prima di sapere quali storie saranno incluse. Se decidi di fissare l'ambito per lo sprint N + 1 all'inizio dello sprint N, perdi un po 'di flessibilità.

Tuttavia, in Scrum dovresti avere solo storie utente che forniscono valore all'utente. Nel nostro caso le storie di design di UX non forniscono tale valore (sono più simili a un'attività di toelettatura degli arretrati).

Per come la vedo io, stanno fornendo molto valore al loro utente. Il fatto è che il loro utente non è l'utente finale dell'azienda, il loro utente è il team di sviluppo che implementerà la funzione allo sprint X + 1.

Ti stai bloccando nella religione del processo e lungo la strada vedo mischiare / agile essere abusato e gli utenti etichettati erroneamente. Scrum non è uno strumento universale, è un mezzo per raggiungere un fine.

Penso che il tuo gruppo abbia etichettato erroneamente chi sono i tuoi utenti e stanno pianificando il pubblico sbagliato.

Il gruppo UX sta usando la mischia in modo classico, il valore dell'utente e l'adattamento agile agli input di alcuni utenti finali magici. Sono quelli con gli utenti. Il tuo gruppo sta abusando della mischia perché stai semplicemente compilando la meccanica per far funzionare una progettazione esistente, non c'è nulla di agile richiesto e la mischia sta riempiendo il ruolo del monitoraggio della gestione.

Ecco perché ti sembra sbagliato, in realtà non hai bisogno o benefici della mischia in alcun modo perché sei in un gruppo di servizio e il tuo lavoro scorre in avanti dalle persone della UX che hanno già fatto le parti agili / mischia.

Non c'è nulla di veramente brutto lì, esiste solo un processo diverso da quello che ti è stato detto.