Come deve essere gestito all'interno di JIRA un progetto del team Scrum e singoli progetti Kanban?

Naviga le tue risposte
2

Riepilogo

Siamo un'azienda di medie dimensioni con un team di sviluppo di cinque membri del team. Recentemente abbiamo iniziato a studiare / impiegare il metodo Scrum nel nostro dipartimento R & D.

Il nostro team principale ha un progetto, mentre ogni dipendente ha compiti e progetti individuali. Alcuni di questi singoli progetti sono sufficienti per un singolo sviluppatore da completare.

Inoltre, un singolo sviluppatore potrebbe supportare un prodotto che ha rilasciato individualmente.

Inoltre, al momento utilizziamo una lavagna Scratch JIRA per monitorare i nostri progressi nel nostro progetto di core team, mentre ognuno di noi usa singole schede Kanban JIRA per gestire i nostri singoli compiti / progetti.

Abbiamo scoperto che è facile andare oltre il progetto del core team durante la revisione sprint, ma è difficile avere visibilità nelle nostre attività quotidiane e nei progetti non correlati al progetto principale.

Dovremmo utilizzare una singola scheda Kanban che coinvolga tutti i nostri problemi dei core board Scrum e tutte le altre attività / progetti del team non-core?

Quindi esamineremo tutti i problemi della scheda Kanban tutto incluso durante la nostra riunione di revisione sprint? In tal caso, come dovremmo filtrare la nostra scheda Kanban? Aggiornato entro un certo periodo di tempo, etichette, ecc.

O dovremmo usare una singola scheda Scrum e forzare l'intero team a pianificare e stimare sia il progetto del core team che tutti i singoli compiti / progetti? Cosa succede quando si verificano nuovi problemi di supporto durante la metà dello sprint? Regoliamo lo sprint scope mid-sprint?

Domanda

Quale metodo di raggruppamento dovremmo utilizzare per presentare sia il progetto condiviso del nostro core team, sia i singoli compiti / progetti di ogni sviluppatore preservando la stima e la pianificazione di Scrum?

    
posta Speakeasys 15.08.2017 - 16:30
fonte

2 risposte

1

Il team di mischia dovrebbe avere un obiettivo fisso per lo sprint a cui tutti stanno contribuendo. Costruisci questa funzionalità, completa questa versione ... perché questo è reale I membri del team hanno altri impegni per il business, va bene - ma tutti devono giudicare quanto tempo / impegno possono impegnarsi per il gruppo di scrum ogni sprint. Sembra che tu stia gestendo abbastanza bene suddividendo questo lavoro aggiuntivo.

Tuttavia, la successiva conclusione logica di questo è che solo il lavoro che fa parte dei progetti del team di Scrum dovrebbe essere tracciato sulla lavagna di base e discusso in situazioni di stand up quotidiane . Non c'è assolutamente alcun punto nel tuo team che parla di interviste o del tuo ragazzo delle infrastrutture che parla di server in una situazione quotidiana per una squadra che si concentra sul completamento della prossima funzione.

Questo non vuol dire che questo lavoro non dovrebbe essere tracciato. Ma questo dovrebbe essere fatto in team differenti o in 1: 1 con il project manager / line manager e può essere portato ai membri del team attraverso chat, vite e comunicazioni ufficiali senza occupare quei preziosi 15 minuti.

Le schede Kanban possono essere usate (se vuoi) ma non metterle sulla scheda madre, creare un'altra scheda in JIRA o persino far girare alcune pagine di trello.

Qualcosa che abbiamo usato di recente è l'uso di un monitor durante lo stand-up, il display mostra la mischia e se non è sulla scheda non viene discusso (ovviamente, ovviamente). Questo aiuta a focalizzare l'incontro e mantiene la sintesi quotidiana breve e concisa.

    
risposta data 29.01.2018 - 10:50
fonte
0

Prova una combo board Scrum / Kanban basata su Scrum:

ThetacticistoemploybothaScrumboardandaKanbanboardtogetheronyourteam’swall.Here’showthatmaywork.HavetheproductowneroperatetheplannedSprintforecastcommitmentsthroughyournormalScrumprocessandboardorwall.Now,passtheever-emerginghoney-doneedsthroughanothershortprocessofworkflowcontrol:a)abriefdiscussionaboutthe‘story’withtheScumMasterandteameitherduringthedailyScrumorinaseparatehuddle,andb)doastorypointestimationontheitem(s)theproductownerbrings.ThenplacethoseonaKanbanportionoftheteam’swallorboard.

ounalavagnaScrumBanbasatasuKanban:

StartwithaKanbanboardandaddtheProductBacklogtoit.ConverttheReleaseProductBacklogtoaTODOlistviaasmallplanningsession.CallforplanningwhentheTODOlistisgettingempty.

Riferimenti

risposta data 29.01.2018 - 04:21
fonte

Leggi altre domande sui tag

Come comportarsi con le persone che non trovano il tempo per fare le revisioni del codice? Riattacco di grafici di entità completa per applicazioni frontend / backend che comunicano usando REST API / JSON?