Il nostro team di mischia è composto dai soliti ruoli di mischia. Non abbiamo un progettista UI / UX e gli sviluppatori lavorano l'interfaccia utente / UX con il proprietario del prodotto. Qui sta un problema. Ogni volta che stiamo per creare il backlog e non definiamo il design esatto dell'interfaccia utente / UX prima dell'inizio dello sprint finiamo per passare troppo tempo durante lo sprint nel tentativo di finalizzare il design dell'interfaccia utente / UX.

Questo è esattamente vero per l'analisi e l'architettura delle funzionalità. Pensi che ogni possibile dettaglio su una funzionalità dovrebbe essere dato agli sviluppatori prima dell'inizio dello sprint o dovrebbe essere un compito all'interno delle funzionalità? Abbiamo sperimentato questo e risulta in alcune caratteristiche indefinite che non hanno alcun criterio.

Primo: dai un'occhiata a questo bel discorso , Florian Haas ha tenuto al FROSCON (GER). Riguarda l'impossibilità pratica di fare la mischia.

La buona notizia : poiché la mischia è impossibile da implementare, sei libero di fare tutto ciò che vuoi.

Le cattive notizie : non chiamare quella mischia.

Questo ti libera dalla domanda: »Sto facendo la mischia giusta?« (Risposta: No, non lo fai ) e potresti passare alle domande pratiche della vita, che importa.

Non abbiamo un progettista UI / UX e gli sviluppatori lavorano l'interfaccia utente / UX con il proprietario del prodotto

Questa non è una situazione insolita. Ma la mischia di AFAIR è contro la specializzazione: tutti dovrebbero avere le stesse competenze e potrebbero lavorare in modo intercambiabile.

Ogni volta che stiamo per creare il backlog e non definiamo il design esatto dell'interfaccia utente / UX prima dell'inizio della primavera, finiamo per passare troppo tempo durante lo sprint, cercando di finalizzare il design dell'interfaccia utente / UX.

Sì, ora quella situazione è fin troppo buona. Ho lavorato in un team, dove abbiamo avuto a che fare con backlogitem molto ampi come »Come utente, voglio vedere informazioni x « e basta. Quindi l'oggetto è atterrato sulla tavola dello sprint. Uno sviluppatore l'ha preso. Risolto Dopo averlo implementato, ha avuto luogo una prima revisione tra pari, in cui è iniziata la discussione su come dovrebbe apparire l'interfaccia utente.

Poi è arrivata la fase di controllo qualità e le discussioni sono ricominciate da capo.

Dopo lo sprint, abbiamo fatto come scrum richiede la revisione in cui il progetto è stato strappato dall'OP . Sfortunatamente il nostro cliente non è arrivato alle recensioni, quindi non ha visto il software a quel punto.

Ma poi il ciclo è ricominciato tutto da capo finché PO non è stato soddisfatto.

E poi è arrivato il cliente ...

Da questa storia di guerra si vede che questo (tipo speciale) di processo è incredibilmente inefficace.

Ciò che ha funzionato per noi alla fine è stato gettare la mischia in mare.

Ma questa non è la soluzione alla tua domanda;)

Pensi che ogni possibile dettaglio su una funzionalità dovrebbe essere dato agli sviluppatori prima dell'inizio dello sprint o dovrebbe essere un compito all'interno delle funzionalità?

Una soluzione a questo dilemma implicherebbe stretti feedbackloops tra a) il cliente stesso e l' OP , in modo che i criteri siano formulati in modo relativamente stretto. b) uno stretto feedback tra lo scrum-team e l' OP per ridurre al minimo la possibilità di guidare fuori strada.

Vorrei infrangere alcune (più) regole di mischia per definire un backlogitem: un "manichino funzionante". Che potrebbe essere rapidamente rivisto da PO e cliente per ridurre al minimo il tempo di sviluppo speso per un articolo semplice.

tl; dr

Quale dovrebbe essere l'input di una squadra di mischia?

Abbastanza informazioni per soddisfare le specifiche nel minor tempo possibile.

Fuori tema:

Non facciamo più mischia. Non facciamo stime. Abbiamo mantenuto la tavola dello sprint. Non facciamo sprint. Sviluppiamo funzionalità / correggiamo i bug e rilasciamo al più presto. Quando vengono implementate nuove funzionalità, vanno al più presto a un server pubblico dove possiamo discutere di ulteriori progetti con i clienti il ​​più rigorosamente possibile.

La risposta canonica è "fai ciò che funziona per te".

Scrum è una delle metodologie agili. È esplicitamente progettato per cambiare e adattarsi al tuo team e al tuo progetto. Il tuo obiettivo dovrebbe essere:

Individui e interazioni su processi e strumenti
Software di lavoro su documentazione completa
Collaborazione con i clienti sulla negoziazione del contratto
Risposta al cambiamento dopo un piano ( manifesto Agile )

Non è una domanda su ciò che il tuo team dovrebbe iniziare su una storia, è una domanda su quale input consente al tuo team specifico di risolvere le particolari esigenze aziendali.

Nella mia esperienza personale, dipende dall'obiettivo aziendale. Alcune storie arrivano già con ricerche UI / UX e progetti completi, e va bene. Alcune storie presentano requisiti vaghi, perché l'azienda ha solo bisogno di risolvere un problema. Anche questo va bene.

Ci sono anche altri fattori, ovviamente. Ad esempio se i tuoi designer fanno parte del team di sviluppo, del marketing o dello sviluppo del prodotto, ecc. Molti fattori. Fai semplicemente ciò che è necessario per soddisfare il business, sii flessibile e assicurati di discutere di queste cose durante le tue retrospettive, adattando il processo secondo necessità.

Ho avuto un respingimento simile da parte degli sviluppatori. Il problema dal loro punto di vista era che erano diffidenti nei confronti del tempo impiegato dalla parte UX per implementare. Se accettano di provare a consegnare N storie in uno sprint ma alcune delle storie impiegano molto più tempo del previsto a causa di andare avanti e indietro sulla UX, allora sentono che si riflette male su di loro.

Ciò che ha funzionato per noi è:

1. Qualcuno lavora con il product owner per creare mock up degli schermi da sviluppare. Questi vengono esaminati durante il normale processo di perfezionamento della storia prima che la storia venga trascinata in uno sprint che dà a tutti la possibilità di avere una discussione onesta.
2. Non provare a finalizzare il progetto prima della codifica, basta farlo uscire e quindi parlare di ciò che deve cambiare. I costi per apportare la modifica sono quindi più chiari, il che aiuta il proprietario / cliente del prodotto a decidere se valga la pena.
3. Fiducia tra il proprietario / i clienti del prodotto e gli sviluppatori. Alla fine tutti cercano di consegnare roba al cliente. L'OP non può lamentarsi del fatto che la squadra non consegni tutto da uno sprint. Gli sviluppatori non possono essere deliberatamente ostruttivi perché sono preoccupati di non consegnare.
4. Pratica. Abbiamo appena migliorato una stima delle dimensioni della storia e siamo in grado di individuare probabili problemi.

Tl; DR: non definire completamente l'UX prima della codifica. Attendi che gli utenti lo vedano e ci giochino.

Pensi che ogni possibile dettaglio su una funzionalità dovrebbe essere dato agli sviluppatori prima dell'inizio dello sprint o dovrebbe essere un compito all'interno delle funzionalità?

In poche parole, se il proprietario del prodotto non è in grado di fornire il design ui / ux prima dello sprint, lo sviluppo di ui / ux dovrebbe essere una storia , non un compito.

I risultati finali dello sprint non devono sempre essere codici funzionanti e il team stesso può essere il "chi" nella storia. Puoi avere una storia come "In qualità di membro del team di sviluppo, abbiamo bisogno di modelli dell'interfaccia utente per poter implementare l'interfaccia utente". Quindi stimerai quanto tempo impiegherà il tuo team a consegnare i modelli e questo diventa una delle prime storie su cui lavori.

Non è necessario precisare l'interfaccia utente, è sufficiente accettare la richiesta funzionale (storia) e assegnarla come punteggio sapendo che è necessario pensare a un'interfaccia utente. Far specificare al cliente che l'interfaccia utente richiede problemi.

Ora che sai che l'interfaccia utente ti costerà un po 'di tempo, dovresti essere in grado di pianificare meglio, la prossima volta che intraprendi un'attività che include il lavoro dell'interfaccia utente, gli assegnerai alcuni punti extra della trama.

Se sei mischia chiunque può essere un designer UI / UX.

L'interfaccia utente / UX non dovrebbe essere un ripensamento. Dovrebbe essere un risultato. Dovrebbe essere approvato dal proprietario del prodotto. Dovrebbe apparire, anche se solo come GIF, al momento della consegna.

Ciò non significa che non possa cambiare. È qualcosa che cambierà spesso. È anche qualcosa su cui vuoi ricevere feedback in anticipo. Non lasciare che il codice guidi la progettazione dell'interfaccia utente. Lascia che il cliente lo guidi. Respingi solo quando il cliente chiede magia. Altrimenti, rendili consapevoli della quantità di lavoro richiesta e di quanto costerà.

L'unica UI / UX finalizzata è su software non funzionante.

Dal tuo commento:

"Dovrebbe essere approvato dal proprietario del prodotto." Questo è esattamente dove sorge il problema. C'è un sacco di tempo speso per questo processo di approvazione e finiamo per passare giorni invece di poche ore inizialmente stimate. - Rashid

Elimina tutto ciò che ti rallenta inutilmente.

Hai un'idea Dillo al proprietario del prodotto. Dovrebbero essere seduti accanto a te.

Lo odiano? Vai avanti. Lo adoro? Fallo. Non lo capisci? Mostrali.

Brevi incontri frequenti non programmati. Parlare. Doodle su una lavagna o carta. Mock up in un programma di pittura usando schermate. Comunicare, approvare, implementare e rivedere rapidamente le idee.

Se il proprietario del prodotto non è in giro, prendi un essere umano conveniente e chiediglielo. Qualunque cosa sia necessaria per iniziare l'iterazione. Riporta il proprietario del prodotto al più presto possibile.

Non passare un secondo a renderlo carino. Basta arrivare al punto. Mantieni le tue idee piccole e incrementali e puoi farlo prima ancora che qualcuno chieda un preventivo.

Nella mia esperienza:

• Un'analisi iniziale insufficiente provoca uno sviluppo inefficiente e stop-start
• Troppa analisi iniziale provoca paralisi dell'analisi (lo Sprint non inizia mai)

Cosa facciamo:

• Definire alcuni criteri " Pronto per lo sviluppo "
• Per le storie di UX, questo potrebbe essere "abbiamo un wireframe che è ben compreso dal team"

Durante la pianificazione Sprint:

• Tutte le storie che non sono pronte per lo sviluppo vengono eliminate (sarebbero troppo distruttive per il team e tornerebbero per ulteriori analisi)
• Tutte le storie limite sono dichiarate "ad alto rischio" e intraprese proprio all'inizio dello Sprint
• Le storie ben comprese sono stimate e consentite nello Sprint

Questo sistema ci consente di dedicare la maggior parte di ogni Sprint all'esecuzione, ovvero lavoriamo in modo molto più efficiente.

Qualsiasi compito nella tua mischia deve avere una stima per il lavoro totale coinvolto e un risultato verificabile.

Se inserisco un compito nella tua mischia "implementa la funzione X con un'interfaccia utente di cui il product manager è soddisfatto", questo avrà un risultato verificabile, ma è chiaramente impossibile stimare la quantità di lavoro coinvolto. Quindi questo compito non può essere ragionevolmente messo in una mischia.

Ora inserisco un compito nella tua mischia "progettare un'interfaccia utente per la funzione X". Ciò può essere stimato e il risultato è verificabile. Questo è un compito Ok all'interno di una mischia. Al termine dell'attività, l'hai eseguita.

Ora, una volta terminata l'attività, il responsabile del prodotto può dire che non gli piace il risultato. Va bene. C'era un compito nella mischia, l'hai fatto e questo è il tuo lavoro. Può mettere un altro compito nella mischia successiva. Forse con un po 'più di direzione quale tipo di interfaccia utente vorrebbe effettivamente. Questo è il suo lavoro. Impostazione di attività che danno risultati utili . A volte è difficile e il lavoro svolto risulta inutile. Ecco perché lo chiamano "agile"; i compiti vengono svolti e risultano inutili, quindi si passa a una direzione migliore.

Inoltre, il design UX, in particolare un buon design UX, è un lavoro a tempo pieno per qualcuno che ha praticato il design UX. Molti bravi sviluppatori di software possono fare un lavoro accettabile creando una UX, ma non lo faranno altrettanto bene ed economicamente come un buon designer UX (se potessero, allora creerebbero progetti UX e non svilupperebbero software). Quindi non avere un designer UX è inefficace - di nuovo un problema per il proprietario del prodotto.

Non sono sicuro che stai seguendo principi agili, ma ecco come dovrebbe essere gestito.

non definiamo il design esatto dell'interfaccia utente / UX prima dell'inizio dello sprint

L'obiettivo non è quello di essere perfetto a questo punto. Ottieni il massimo input per i requisiti in modo che gli sviluppatori possano creare qualcosa che corrisponda a ciò che è stato chiesto il più vicino possibile. Non apportare modifiche o cercare di progettare cose che non sono state richieste. Sprecherai il tuo tempo.

finiamo per passare troppo tempo durante lo sprint cercando di finalizzare il design dell'interfaccia utente / UX.

Lavora su un modo per determinare quando le cose sono fatte. Ho la sensazione, qualcuno sta continuando a fare molta valutazione avanti e indietro dell'interfaccia utente / UX. Troppe persone hanno opinioni su UX / UI senza nulla da parte del client per supportare i loro presupposti.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Questo genere di cose può continuare all'infinito. Non è un difetto di Scrum. Qualcuno si sta intromettendo con i requisiti durante lo sprint. Torna a decidere cosa desidera il cliente, determina quanto tempo ci vorrà e lavora con loro per stabilire le priorità. Se pensano che ci vorrà troppo tempo, chiedi loro di cosa sbarazzarsi.

C'è una società che progetta loghi a tariffa forfettaria. Limitano il numero di richieste di modifica perché sanno che alcuni clienti le uccideranno a morte da mille tagli con tutte le loro modifiche. Fermalo o carica di più. Si chiama business.