Sprint Planning Meetings: determinare se un elemento di lavoro è "pianificato"?

4

Lavoriamo con Scrum da un po 'di tempo, generalmente con successo. Tuttavia negli ultimi tempi, quando la pressione ha iniziato a montare, abbiamo riscontrato diverse situazioni in cui gli elementi venivano durante le riunioni di pianificazione, ma quando in realtà arrivava il momento di codificare, era evidente che erano tristemente sottostimati.

Questa è una perdita di tempo fastidiosa e imbarazzante. Quindi mi chiedo, c'è qualcosa che possiamo fare per assicurarci che un oggetto di lavoro sia correttamente compreso e pianificato prima di essere incluso in uno sprint?

Non usiamo TDD, ma le mie esperienze con esso suggeriscono che è un buon modo per garantire che un programmatore comprenda un compito prima di iniziare il lavoro. Quindi ho pensato di provare a provare alcuni test automatici come possibile approccio a questo. Ma non tutti gli elementi di lavoro sono suscettibili di test automatizzati, ed è probabile che sia difficile / noioso per i non programmatori nella riunione.

Per inciso, è quando uno ha deciso sui criteri di accettazione, dovrebbe andare su un oggetto di lavoro, o su una storia di un utente, o entrambi?

    
posta Matt Thrower 26.02.2014 - 11:27
fonte

3 risposte

4

INVEST è un buon codice da usare per misurare la qualità delle tue storie e migliorare la scrittura loro. Il mnemonico afferma che una buona storia dovrebbe essere:

  • Indipendente : la trama dell'utente deve essere autonoma, in modo tale che non vi sia alcuna dipendenza intrinseca in un'altra storia utente.
  • Negoziabile : le storie degli utenti, fino a quando non fanno parte di un'iterazione, possono sempre essere modificate e riscritte.
  • Valuable : una User story deve fornire valore all'utente finale.
  • Stimabile : devi sempre essere in grado di stimare la dimensione di una User story
  • Piccolo : le storie degli utenti non devono essere così grandi da diventare impossibili da pianificare / task / prioritizzare con un certo livello di certezza.
  • Testabile : la User story o la sua descrizione correlata devono fornire le informazioni necessarie per rendere possibile lo sviluppo del test

Dovresti anche investire tempo nelle sessioni di grooming degli arretrati. Questi dovrebbero essere in anticipo prima della pianificazione dello sprint. Qui migliori le storie, scopri se hai bisogno di maggiori informazioni. Nella pianificazione dello sprint, dovresti rifiutarti di affrontare storie troppo vaghe. Per questa valutazione puoi utilizzare il summenzionato INVEST.

Spesso mi sono ritrovato a rompere una storia in due storie: la prima contiene le parti chiare e imperdibili e la seconda le caratteristiche più vaghe o "belle da avere". Il primo viene accettato al prossimo sprint e il secondo viene curato durante lo sprint con nuove informazioni raccolte dagli stakeholder e dall'implementazione della prima parte.

    
risposta data 26.02.2014 - 11:40
fonte
2

Una delle cerimonie di mischia è governare, puoi usare quell'incontro durante ogni sprint per governare i futuri PBI che la tua squadra sta per scegliere. Nell'incontro l'intero team (Ingegnere del software, Ingegnere della qualità, progettista funzionale e SM) si riunisce insieme al proprietario del prodotto e principalmente è compito di FD e PO spiegare e descrivere le storie degli utenti e il team può approfondire come è tecnicamente possibile implementare ed essere testati (assicurati di documentare questi risultati se è possibile per riferimento futuro). E nel caso in cui hai bisogno di rompere il PBI o ci sono alcune note che puoi decidere nella toelettatura.

Anche in fase di pianificazione puoi anche ricordarti l'un l'altro solo brevemente sull'implementazione blu del PBI e sull'ambito del testing.

Non sono sicuro della tecnologia che usi, ma per esempio in tfs puoi definire PBI e attività e mettere tutti i dettagli e gli esiti dell'incontro in PBI così quando il programmatore lo sceglie, lui o lei sanno di PBI e tutti i requisiti.

    
risposta data 27.02.2014 - 07:22
fonte
1

Individui e interazioni su processi e strumenti

Torna all'utente e chiedi maggiori chiarimenti, dettagli, ecc. So che questo non è sempre possibile e può essere fastidioso per entrambe le parti, ma è meglio della codifica nei ciechi. Può aiutare entrambe le parti a capire ciò che tutti hanno veramente bisogno di sapere prima della codifica.

Ci sono molte tecniche per assicurarti di avere una buona storia, ma richiede comunque un po 'di pratica su entrambi i lati.

All'inizio sembrerà inefficiente, ma non sprecherà tanto tempo nel lungo periodo. Se ti senti come se dovessi essere perfetto uscendo da ogni singola sessione di pianificazione, non finiranno mai, quindi prenditi un piccolo rischio sapendo che puoi sempre tornare indietro e chiedere. Speriamo che ci sia tempo per queste eventualità e presto saranno l'eccezione piuttosto che la regola.

    
risposta data 20.06.2014 - 15:00
fonte

Leggi altre domande sui tag