Chi fa la UX in un progetto di mischia?

OK. Supponiamo che tu stia lavorando a un progetto di mischia per libri di testo. Hai un maestro di scrum che collabora con un proprietario del prodotto. Il prossimo sprint è UI-pesante - per il momento i vostri programmatori iniziare a costruire schermi, si vuole veramente avere qualche idea di che cosa stanno andando a guardare come.

Chi fa il wireframing e quando? Il proprietario del prodotto? Qualcuno che supporta il proprietario del prodotto? Il maestro della mischia? Se hai un esperto di UX, lavorano a fianco dei programmatori dopo l'inizio dello sprint o forniscono wireframe e mock-up in anticipo che si trovano accanto alle tue storie e ai vincoli per guidare e informare il lavoro che gli sviluppatori stanno facendo?

Sono abbastanza sicuro che abbiamo bisogno di aiuto per la UX, vedi, ma non sono sicuro di dove applicarlo ...

EDIT: Lasciami riformulare la domanda.

Come offrite un'esperienza utente coerente e di alta qualità in un progetto agile?

Il designer dell'interazione

UX! = UI È necessario un designer di interazioni esperto per offrire una buona esperienza utente, contrariamente alla credenza popolare che non è un programmatore. Per tutti voi programmatori che pensano di poter fare UX (incluso me), lasciatemelo dire. Ottimizzare la progettazione dell'interazione richiede almeno tanto tempo quanto essere bravo a programmare. Quanto tempo hai dedicato alla progettazione dell'interazione pura?

Nella fase iniziale è responsabilità dei progettisti di interazioni:

1. Estrarre gli obiettivi reali della soluzione dal proprietario del prodotto
2. Definire le persone che useranno la soluzione.
3. Scrivi scenari che sono storie su come verrà utilizzata la soluzione.
4. Compilare un documento di progettazione che lasci poco spazio all'ambiguità dal punto di vista UX

Durante il progetto è compito dei progettisti delle interazioni assicurarsi che vengano seguite tali linee guida e che affrontino eventuali problemi aggiuntivi che sorgeranno (e lo faranno).

Molti programmatori prenderanno di nuovo parte a questo approccio, ne sono sicuro, poiché tutti pensano che siano l'eccezione in grado di progettare interfacce "meravigliose", probabilmente no. D'altra parte, una buona relazione tra designer dell'interazione e programmatore è spesso molto piacevole per il programmatore, in quanto non devono combattere contro una "specifica stupida". Purtroppo nella mia esperienza è difficile trovare buoni designer di interazioni, ma sono là fuori.

Come sempre consiglio vivamente i libri di Alan Coopers sull'argomento ("A proposito di Face" e "I detenuti gestiscono l'asilo")

Suggerisco di organizzare il lavoro del ragazzo UX allo stesso modo del resto della squadra. Dovrebbe essere considerato un membro paritario del team, partecipare a stand-up e comunicare a stretto contatto con i programmatori.

Idealmente, i mock-up dovrebbero essere fatti almeno uno sprint in anticipo, ma per funzionalità più piccole potrebbe avere senso considerare la creazione di mock-up come sottoattività di una storia pianificata per l'attuale iterazione.

Come sempre con agilità, usa il buon senso, sperimenta approcci diversi e atteniti a quello che funziona bene per la tua situazione particolare.

Secondo me questo è in qualche modo un caso speciale che deve essere gestito in modo speciale. Scrum master non parteciperà sicuramente a questo - non è affatto il suo ruolo. Il team di solito è un gruppo di sviluppatori e la maggior parte di loro non ha esperienza con UX e sarà una perdita di tempo costringerli a farlo. Assumerai un esperto di UX e l'esperto non farà parte del team - il team dovrebbe essere interfunzionale e probabilmente l'esperto di UX non sarà uno sviluppatore. Anche l'esperto di UX non sarà presente nel progetto per tutta la sua durata. L'esperto di UX lavorerà con il proprietario del prodotto uno sprint in avanti per preparare modelli e wireframe per aggiornare le storie degli utenti in modo che il team sappia cosa dovrà essere fatto nel prossimo sprint: i modelli saranno disponibili durante la riunione di pianificazione.

Modificare:

Ho fatto qualche ricerca aggiuntiva perché sapevo di averlo letto da qualche parte e finalmente lo trovo in Riuscire con Agile: sviluppo software usando Scrum di Mike Cohn . Mike discute esattamente il ruolo del designer UX nel team. La sua descrizione iniziale è simile alla mia e considera il suo spostamento naturale quando la società cambia il metodo di sviluppo da cascata a Scrum, ma in seguito lo conclude come un metodo non raccomandato. Il motivo è che se i progettisti di UX non fanno parte del team, possono pensare a se stessi come team separato e non devono condividere l'impegno del team di sviluppo.

Nonostante ciò, la risposta di @Adam Byrtek sembra quella corretta. Rendi UX guy parte del team e lascialo collaborare con gli sviluppatori su user story attualmente implementate. Non ci vorrà tutto il tempo del ragazzo UX, quindi collaborerà anche con il proprietario del prodotto o il cliente per preparare modelli e wireframe per l'upgrade di uno o due sprint.

Sono iscritto all'allerta di Jakob Nielsen (principalmente a causa delle sue critiche sulle fastidiose pratiche di web design) e ricordo di aver recentemente letto alcuni articoli sull'argomento (anche se difficilmente ho una minima comprensione dell'intero processo di sviluppo agile), forse sarebbero di qualsiasi utilità per te:

• Progetti di esperienza utente agili
• Progetti di sviluppo agile e usabilità

Per "Scrum del libro di testo":

Prima di tutto, Scrum Masters non collabora con i Product Owner - beh, in nessun modo diverso da quello che l'intero team, inclusi SM e PO, collaborano per costruire il sistema.

In secondo luogo, i team Scrum dovrebbero essere omogenei con i membri del team interfunzionali. Quindi non avresti un "UX Guy".

Inoltre, probabilmente non costruiresti l'UX uno Sprint prima del codice funzionale. Le funzionalità vengono fornite completamente in un singolo Sprint. Se la UX associata a una funzione è troppo complessa per essere consegnata insieme al codice funzionale in un singolo Sprint, scolpisci l'intera funzione fino a qualcosa che può essere fatto, inclusi gli elementi UX, in un singolo Sprint.

Chi fa UX su un progetto a cascata? Chi fa lo sviluppo di mainframe su un progetto XP?

La metodologia del progetto non ha importanza. Ogni progetto tecnologico richiede determinati ruoli specializzati. A volte, un progetto può cavarsela senza un "designer dell'interazione" pienamente autorizzato e vincolato (qualunque cosa ciò significhi). A volte hai bisogno di qualcuno specializzato. Ma lo stesso si potrebbe dire per ogni altro ruolo.

Quindi sulla tua seconda domanda su come offrire un'esperienza utente di alta qualità usando l'agile. L'abbiamo gestito nell'ultimo progetto di mischia a cui sono stato coinvolto coinvolgendo l'analista aziendale e il cliente in anticipo e spesso. Inoltre, avevamo uno sviluppatore che aveva un occhio particolarmente interessante per UX. Tendeva a apportare piccole modifiche alle interfacce utente su cui gli sviluppatori stavano lavorando dopo che avevano fatto i commit.

Non abbiamo offerto una UX perfetta alla fine di ogni sprint. Le demo in genere hanno rivelato un problema o due da una prospettiva UX. Ma abbiamo risolto quelli per il prossimo sprint (se ne valgono la pena per il cliente) e quando siamo entrati in produzione avevamo una UX molto solida.

Se per UX intendi il progettista di interfacce utente, sono solo un altro ruolo o risorsa per il team. Il design dell'interfaccia utente, come qualsiasi altro design, taglia un progetto. C'è una quantità ragionevole di lavoro di architettura / design che dovrebbe essere fatto in anticipo e c'è una quantità che può essere fatta mentre vai avanti.

Va notato che le attività di progettazione dell'interfaccia utente spesso non rientrano nello stesso ambito di uno sprint di sviluppo. Nella progettazione di un componente UI, la progettazione può richiedere numerosi sprint da implementare.

In pratica, tendo a scoprire che i progettisti di UI / UX hanno bisogno di un tempo di consegna ragionevole per affrontare aspetti che devono essere coerenti in tutta la soluzione. Mi piace pensarlo come un'architettura software. Spesso è possibile eseguire uno sprint sulla progettazione di componenti specifici prima dell'implementazione, ma tendo a scoprire che, una volta avviati i progettisti, possono accelerare l'implementazione. Gli sprint successivi tendono ad essere un buon posto per implementare / esplorare look & feel e ottenere feedback sull'usabilità quando la soluzione inizia a prendere forma. I risultati di questi esercizi successivi vengono ricondotti alla pianificazione del prossimo sprint.