Scrum: va bene che il design / UX della user story avvenga nello stesso sprint dell'implementazione

9

Sono attualmente in uno sprint (due settimane) in cui il designer ha il compito di definire i requisiti e la UX di una particolare storia utente.

Nello stesso sprint, devo implementare questo progetto. Durante la pianificazione dello sprint, ho dovuto fare un'ipotesi su quanto tempo sarebbe durata questa storia utente indefinita.

Oggi ho finalmente ricevuto il design. Sfortunatamente, il design è incompleto / vago ed è più simile alle esigenze di un cliente che a un design. Tuttavia, da questo, posso ancora vedere che non ho quasi stimato abbastanza.

A peggiorare le cose, questa non è la prima volta. Nell'ultimo sprint è successa esattamente la stessa cosa. L'ho segnalato nella nostra retrospettiva e il mastro scrum non aveva una risposta su come risolverlo, invece di dire "questo è solo sviluppo per te". Ironia della sorte si infastidisce se il rogo non è sul bersaglio ...

Ora dovrò chiedere / lavorare con il designer per fare il suo lavoro. Questo mi sosterrà poiché ho completato tutti gli altri miei compiti.

Quindi la mia domanda è

A) ~~come gestite le dipendenze nella pianificazione dello sprint?~~ EDIT: Va bene che il design / UX della user story avvenga nello stesso sprint dell'implementazione

B) come devo ora avvicinarmi allo sprint? Stimare nuovamente la user story corrente e guardare il burndown trasformarsi in burn-up ed essere visto come incompetente / non produttivo? Oppure aggiungi una nuova attività allo sprint corrente sulla falsariga di "aiutare il designer a creare un design adatto"

agile scrum planning

— Allan
fonte

Vale la pena ricordare che la tua domanda nella riga dell'oggetto è molto diversa dalle domande nella parte inferiore del testo. Sarebbe utile se lo modificassi per scegliere l'uno o l'altro.

— pdr

14

come gestite le dipendenze nella pianificazione dello sprint?

Idealmente, le dipendenze non di sviluppo vengono gestite prima della pianificazione dello sprint, in modo da disporre di una buona definizione dell'elemento arretrato per stimare lo sforzo.

Ma se questo fosse lo "sprint per te" solo per l'ultimo sprint, probabilmente quello sarebbe stato solo lo sviluppo per te per questo sprint, quindi avresti davvero dovuto aumentare la tua stima lì e poi su attività imminenti che si trovano in uno stato simile. Questo non è vendicativo e sarebbe un errore lasciarlo andare come tale.

Ciò che fa è mostrare l'incertezza della stima senza un progetto relativamente solido da stimare. Forse, questo incoraggerà i tuoi manager ad assicurarsi che un articolo arretrato del prodotto sia correttamente definito; ma nel peggiore dei casi ti coprirà la schiena. Nessuno si lamenta quando un lavoro rientra nel budget.

Tuttavia, non l'hai fatto, e ora la tua domanda è ...

come dovrei ora avvicinarmi allo sprint?

Lo scopo di Scrum come strumento di gestione del progetto è identificare i problemi in anticipo, cosa che hai fatto. Segnalalo alla tua direzione, lascia che decidano cosa fare dello sprint. Se cercano di biasimarti, sii umile e chiedi come ti suggeriscono di affrontare situazioni simili in futuro, per evitare lo stesso problema, anche se non credi veramente che sia giusto.

Alla fine, questi sono problemi di gestione del progetto e, se si tenta di risolverli all'interno della propria bolla, ci si prepara a fallire. E, quando lo fai, ti arrabbi perché cadrà su di te, non sui manager che non sono riusciti a risolvere il problema quando lo hai segnalato a loro.

— pdr
fonte

Grazie per la risposta. Per espandersi, il mio Scrum Master vuole che siamo davvero agili in modo da poter cambiare / iterare una user story non appena è stata codificata. Pertanto non gli piace troppa documentazione / progettazione anticipata e invece dobbiamo programmare / pianificare mentre procediamo. Naturalmente questo mi porta alla situazione in cui mi sono trovato. Il manifesto agile sembra supportare la sua posizione. Quindi siamo troppo agili per il nostro bene?

— Allan,

Ad esempio, una delle nostre storie utente potrebbe essere "L'utente vuole essere in grado di giocare contro un altro giocatore umano". Nella nostra pianificazione dello sprint probabilmente lo suddividerei in alcune attività come: mostrare i server, scegliere il server a cui connettersi, connettersi al server. Il progettista dovrebbe idealmente dirmi come vengono visualizzati i server, quali filtri di elenco sono disponibili, cosa succede se non ci sono server, ecc. Naturalmente questo elenco di cose è disponibile per me solo dopo averlo progettato e in questo caso si sta verificando nello stesso sprint. Questo elenco è anche soggetto a modifiche / iterazioni durante lo sprint.

— Allan,

1

@Allan: Quello che il tuo Scrum Master non riesce a capire è che, se il progettista deve completare il proprio lavoro prima che uno sviluppatore possa iniziare il proprio lavoro, questo è un design iniziale. La sua realizzazione all'interno dello sprint non elimina i costi del design iniziale, ma lo rende meno visibile E rende più difficile stimare il tuo sviluppo. Se riesci a trovare un modo per iterare con il tuo designer, è fantastico, rendilo parte dello sprint e fai lo sforzo appropriato per un'attività collaborativa. Ma in anticipo va bene, purché sia onesto e, preferibilmente, fatto prima dello sprint.

— pdr

Se questo è tipico delle tue storie utente, direi che le tue storie sono troppo grandi. Dato il tuo esempio, mi aspetto di vedere "l'utente può vedere l'elenco dei server", "l'utente può connettersi al server e vedere l'elenco degli avversari disponibili" come storie.

— Jules

6

Prima di tutto, c'è una grande differenza tra le dipendenze tra storie / compiti e incertezza nella portata / sforzo di una storia / compito.

Le dipendenze vengono gestite dando all'attività / storia dipendente una priorità inferiore rispetto all'attività / storia da cui dipende e possibilmente un'annotazione che non può iniziare prima che l'altra attività / storia venga eseguita.

L'incertezza dovrebbe essere affrontata nella riunione di pianificazione chiarendo il lavoro che deve essere fatto sulla storia. Se non è possibile rimuovere abbastanza dell'incertezza, la storia molto probabilmente non soddisfa la tua "Definizione di pronto" e non dovrebbe essere accettata nello sprint.
Se, per qualche motivo, la storia deve davvero andare allo sprint, l'unica opzione rimasta è quella di aggiungere un buffer di rischio alla stima.

Per lo sprint corrente, se non riesci a lavorare su una storia, segnalalo nel prossimo incontro quotidiano ed esegui tutto il lavoro possibile per raggiungere l'obiettivo di sprint complessivo della squadra. Potresti anche annotare la storia come bloccata e per cosa.
Dopo l'avvio di uno sprint, in linea di principio è impossibile aggiungere nuove attività allo sprint.
Inoltre, se un'attività risulta essere più lavoro di quanto stimato, non si modifica la stima, ma si riporta fedelmente quali sono i progressi e gli sforzi rimanenti sull'attività.

Alla fine, in Scrum, è il team che promette di consegnare qualcosa. Se quella promessa non può essere fatta, allora è un fallimento dell'intera squadra, mai di un individuo all'interno della squadra.

— Bart van Ingen Schenau
fonte

Anche questa è stata una buona risposta. Se potessi contrassegnare due risposte come corrette avrei.

— Allan,

3

Durante la pianificazione dello sprint ho dovuto fare un'ipotesi su quanto tempo sarebbe durata questa storia utente indefinita.

Questo è l'errore che hai fatto. Nessuno può costringere il team ad accettare un'attività nello sprint ed è compito tuo affermare che l'attività non può essere stimata e accettata nello sprint a meno che non ci sia almeno un wireframe (ad esempio). Sembra che il tuo Scrum Master sia in realtà un project manager, il che peggiora le cose.

Come affrontare tale compito se è necessario eseguirlo nello sprint (per validi motivi commerciali)? Bene, prima devi fissare una scadenza per il design, dopo di che non sarai in grado di implementarlo. Ad esempio: la storia è accettata, ma il progetto dovrebbe essere consegnato entro la prima settimana e implementato entro la seconda. Successivamente, devi lavorare a stretto contatto con il progettista per assicurarti che sia possibile implementarlo nello sprint. Scrum assume un team interfunzionale e sta a te organizzare il tuo lavoro con il designer. Detto questo, se si accetta l'attività nello sprint - che spetta al team decidere - spetta al team gestire il lavoro in modo che venga completato all'interno dello sprint e gestire i rischi associati. Non dovresti aspettare che un altro finisca il suo lavoro per portare a termine il tuo lavoro. È possibile che stai per rivelare una disfunzione maggiore nella tua organizzazione.

— Maxim Krizhanovsky
fonte

Grazie Darhazer. Sì, lo Scrum Master è anche il project manager. Il mastro scrum ha dichiarato che ci deve essere una pianificazione e una documentazione minime. Invece dobbiamo costruire funzionalità mentre procediamo, con continue revisioni durante lo sprint per iterare / modificare ciò che è stato costruito come determinato dalla mangiatoia del progetto (da cui la progettazione e l'implementazione che si verificano nello stesso sprint). Essendo venuto da un ruolo in cui il design era abbastanza solido all'inizio, mi sto adattando difficilmente a questa cultura code-by-the-wire.

— Allan,

3

"... scrum master è anche il project manager." - non bene. "... pianificazione e documentazione minime ..." - che cosa è esattamente nelle tue Definizioni di Pronto e / o Fatto? "... revisioni durante lo sprint per iterare / cambiare ciò che è stato costruito come determinato dalla mangiatoia del progetto ..." - quella dovrebbe essere la decisione del Team, non lo scrum master, certamente non il project manager e (se DEVE essere qualcuno ) dovrebbe essere il proprietario del prodotto!

— Phill W.

@PhillW. Non abbiamo una definizione di pronto. Abbiamo solo un backlog con vari stati di dettaglio per una funzione. Il dettaglio si rafforza mentre andiamo. Fatto ufficialmente quando le parti interessate firmano, ma in realtà è per pietre miliari ed è il manager / scrum master / produttore (la stessa persona) che dice quando è fatto. Ormai faccio "mischia" da un anno, non molto tempo dopo aver iniziato a studiare da solo sulla mischia perché pensavo che il nostro modo di fare fosse strano. Più leggo, più mi sento come se stessi facendo una mischia "Cargo cult". Ma la politica mi rende difficile fare qualsiasi cosa al riguardo ...

— Allan,

1

I compiti sul design sono espressi come storie e quali sono le definizioni del tuo team

una storia è pronta
una storia è fatta

Ogni storia dovrebbe avere i suoi requisiti e le sue condizioni di accettazione, ma penso che sia una buona pratica avere un insieme di regole applicabili a tutte le storie. Ad esempio, una storia è pronta se (e solo se!): Gli studi di architettura end-to-end sono finiti, il design è disponibile, la storia è stata stimata dal team. Le condizioni minime di accettazione potrebbero essere: il test automatizzato è stato eseguito, OK ed è stato integrato nella tuta del test, la revisione del codice è stata eseguita.

Se una storia non è pronta, non incorporarla nel tuo sprint. Se le condizioni di accettazione non sono soddisfatte, allora non è finito.

Nel tuo caso, il team potrebbe decidere che per essere pronto, una storia di sviluppo deve avere un design completo (almeno un wireframe, adattarlo alla tua realtà). In tal caso, non è possibile gestire il design e lo sviluppo nello stesso sprint. Il team potrebbe anche decidere che una storia di UX / design dovrebbe almeno produrre un design wireframe. In caso contrario, la storia non viene accettata e quindi le storie che dipendono da essa non possono essere avviate.

Dovresti facilmente convincere i tuoi manager che avere regole forti per essere pronti è una buona cosa: rivalutare la complessità durante lo sprint è una cattiva pratica. Significa che la velocità della squadra è incerta e quindi che, come manager, hanno una cattiva visione del lavoro della squadra e del futuro.

— Keufran
fonte

0

Uno Sprint di solito inizia quando la storia è chiara - in questa fase il Product Backlog è stabilito e prioritario. Se hai iniziato senza avere il design di quanto avrebbe dovuto essere chiaro cosa si può fare senza il design e cosa no ...

Se devi improvvisare mentre il design è "bumping" tra il cliente e il PO, il tuo PO deve informare il team su eventuali nuove funzionalità non appena compaiono: questo è il significato di "flessibilità" in Scrum - adattarsi al continuo situazione. Il team di sviluppo, lo Scrum Master e il Product Owner devono comunicare in modo permanente, altrimenti non vi è alcuna reazione in tempo reale al cambiamento.

Un po 'più di allenamento non può nuocere ... Forse lavorare con il progettista sarebbe un'opportunità per te di acquisire alcune nuove abilità UX? ... osservando che il bicchiere è mezzo pieno invece che mezzo vuoto :))

— ScrumMasterChangeFacilitator
fonte