Come si evita di interrompere il flusso di lavoro quando il Product Owner richiede una release?

Question

Come si evita di interrompere il flusso di lavoro quando il Product Owner richiede una release?

#1 da (9 voti)

6

Il mio team utilizza Scrum da anni con l'obiettivo di fornire una build potenzialmente rilasciabile per ogni sprint. Recentemente abbiamo iniziato a utilizzare una scheda Kanban che si sposta dalla consegna in time box alla consegna in modalità caratteristica. Finora, questo sembra adattarsi meglio al modo naturale di lavorare delle squadre. Con la consegna in serie, le storie vengono estratte dal backlog quando un individuo si sente pronto per iniziare a lavorarci.

Il tempo medio di realizzazione della storia delle squadre è di tre settimane. Quindi, teoricamente, al momento il proprietario del prodotto chiede un rilascio, il team dovrebbe essere in grado di consegnarlo tre settimane più tardi.

Quando l'OP imposta il trigger "stop allo sviluppo", le persone che hanno il tempo dovrebbero iniziare ad aiutare con le storie già in corso per iniziare a chiarire il tabellone. Le persone liberate per prime sono in genere le persone "front-end" ... Quelle più abili nell'analisi e nello sviluppo. In genere viene chiesto di aiutare con il lavoro di back-end, come test di sistema.

I team lavorano il flusso o le cadenze cambiano ogni volta che viene impostato il trigger di arresto. Che cosa fai per minimizzare questo cambiamento e mantenere la squadra al lavoro nel modo più efficiente possibile? Come eviti l'interruzione causata dal proprietario del prodotto che richiede un rilascio?

development-process agile scrum kanban

posta GuyR 22.10.2011 - 20:52

fonte

1 risposta

Leggi altre domande sui tag development-process agile scrum kanban

Visualizzazione dei livelli di temperatura in una città Popolarità della lingua di programmazione: esistono dati sulle tendenze della migrazione?

score 9 · Accepted Answer

Il modo in cui descrivi la preparazione per un rilascio è un'interruzione significativa del tuo flusso di lavoro che sembra funzionare diversamente.

Dato che avevamo una richiesta simile nel nostro team, abbiamo introdotto la seguente soluzione. Ha principalmente a che fare con la gestione delle filiali nel tuo sistema di controllo delle versioni. Il concetto mi è noto come "No Junk In The Trunk". In pratica, significa che hai un ramo "pulito" in quanto contiene solo il lavoro che ha superato con successo il controllo qualità (QA). Usando Subversion questo ramo può essere chiamato 'tronco' da cui il nome. Naturalmente questo funziona anche con altri sistemi di controllo delle versioni, ad es. GIT.

Quando iniziamo a lavorare su una nuova funzione, creiamo un ramo di funzionalità. Questo ramo di funzionalità viene aggiornato con un'unione dal tronco almeno una volta al giorno per mantenere la differenza al minimo. Tutti i test, la garanzia della qualità, l'approvazione da parte di varie parti sono interamente eseguiti sul ramo delle funzionalità. Una volta che la funzionalità è stata completata, viene riunita in "trunk", seguita da un rapido test di integrazione, incentrato su dove la nuova funzionalità si integra con ciò che è già presente.

Quando rilasciamo creiamo rami di rilascio da "trunk". Dal momento che 'trunk' è 'clean' possiamo praticamente rilasciare in qualsiasi momento. Poiché le versioni non dipendono dalla cancellazione di tutte le storie dalla scheda Kanban, possiamo preparare una versione in qualsiasi momento senza interrompere il normale flusso di lavoro di sviluppo.

Questo processo funziona molto bene per noi. La creazione del ramo di rilascio richiede circa 10 secondi poiché è completamente automatizzata. L'elemento più significativo nel ramo di rilascio è la revisione delle note di rilascio da parte di un madrelingua inglese. Questo è sfortunatamente un processo manuale e richiede circa una o due ore a seconda della quantità di nuove funzionalità e correzioni di bug nella nuova versione.

Come sempre, potresti avere fattori nel tuo ambiente che potrebbero rendere le altre soluzioni per la sfida un'opzione migliore.