Come gestire più progetti in un piccolo team

Question

Abbiamo appena iniziato a utilizzare scrum per la gestione del nostro progetto. Siamo un team molto piccolo (2 sviluppatori, 1 UI/deisgner Web) e abbiamo molti progetti in esecuzione contemporaneamente.

Come gestisci l'esecuzione contemporanea di più progetti nel modello di Scrum? Il più delle volte abbiamo un progetto principale e alcuni piccoli. Come si combinano più sprint in modo efficiente?

modifica: non essere fissato su mischia. siamo una piccola struttura e molto flessibile con quello. Scrum era solo il mio punto di partenza. Se hai altri sistemi che funzionano bene per una tua piccola squadra, sono totalmente aperto a qualsiasi tipo di input.

Answer 1

AFAIK il fondamento di Scrum è che il team è coinvolto in un singolo progetto alla volta. Indipendentemente dalle metodologie, l'overhead di commutazione delle attività rende molto inefficiente lavorare su più progetti "in parallelo".

Quello che potresti fare è provare a pianificare i diversi progetti in sprint separati, ovvero fare uno sprint dedicato interamente a project1, quindi lo sprint successivo interamente a progetto2 ecc. Se i progetti hanno uno scopo molto diverso, potresti considerare variando la lunghezza degli sprint, ad es fai uno sprint di 3 settimane su un grande progetto, quindi magari uno sprint di 1 settimana su uno piccolo.

In puro Scrum la lunghezza degli sprint è scolpita nella pietra, ma poi di nuovo, IMO il punto non è quello di ottenere il badge "puro Scrum implementor", piuttosto un processo di vita reale della tua squadra.

(disclaimer: io non sono un maestro Scrum :-)

aggiornamento sulla base di un commento: vedo il problema. È necessario rispondere rapidamente a piccole richieste di supporto (miglioramento/correzione di bug) da parte di clienti di altri prodotti, mentre è ancora necessario lavorare su un progetto più ampio in modo prevedibile.

Una possibilità sarebbe quella di pianificare gli sprint del grande progetto in Scrum, ma "timebox" parte del tuo tempo per le attività di supporto in entrata. Per esempio. se in media si spendono 5 giorni in ogni sprint mensile a supporto di altri progetti, si assegnano 5 giorni di risorse (tuttavia si conta il tempo) per il supporto in ogni sprint.

Un'altra opzione può essere quella di prendere in considerazione altri metodi, come Kanban, in cui non vi è alcuna sprint o pianificazione, invece il team funziona esclusivamente (o principalmente) in base alla domanda dei clienti.

Answer 2

Se si dispone di molti piccoli lavori che devono essere eseguiti rapidamente, la gestione dei progetti non è il paradigma giusto. Ciò di cui si ha a che fare è la gestione delle operazioni che, generalmente, comporta procedure di lavoro standardizzate e collaudate e ben collaudate. Suggerisco, quindi, di separare, dal punto di vista della gestione, quelle attività che richiedono la gestione del progetto e quelle che richiedono la gestione delle operazioni. Se non hai ancora definito le procedure di lavoro (e provato e testato ecc.), Allora potresti dover impostare un progetto per svilupparle (o codificarle se vuoi pensarle in questo modo).

C'è una grande differenza tra il modo in cui i progetti di sviluppo software sono (o dovrebbero essere) eseguiti e come, per esempio, viene eseguito un help desk. Solo perché sei uno sviluppatore di software esperto nel paradigma di gestione del progetto (come penso che la maggior parte di noi sia) non significa che sia l'approccio giusto per tutto.

Una volta effettuato il turno, si dovrebbe scoprire che è possibile continuare a scrutare verso il basso (o qualunque sia il termine) sui propri 1 o 2 progetti e ruotare le maniglie sulla macchina per consegnare il resto.

Answer 3

Sono necessari 1 settimana di sprint. 1 progetto solo per sprint. È un errore che puoi consegnare il software più velocemente lavorando su più progetti contemporaneamente. Il progetto più grande potrebbe richiedere diversi sprint per sviluppare un rilascio in cui, come con i tuoi piccoli, potresti rilasciare dopo ogni sprint.

Se i progetti sono per diversi PO/clienti, è ancora più importante lavorare su uno alla volta; altrimenti le tue priorità saranno quasi sempre in conflitto.

Answer 4

Come gestisci l'esecuzione contemporanea di più progetti nel modello di Scrum? Il più delle volte abbiamo un progetto principale e alcuni piccoli. Come si combinano più sprint in modo efficiente?

Un'opzione consiste nell'eseguire più scatti in parallelo e, anche se non è l'ideale, far parte di più team (ovviamente non dedicati al 100%). Non sono sicuro che ciò abbia senso nel tuo contesto, tuttavia, non sono convinto che la gestione dei piccoli progetti con Scrum dia valore aggiunto.

Un'altra opzione (forse più appropriata) sarebbe quella di avere un articolo nel backlog del prodotto per il lavoro richiesto dai progetti/attività satellite e quindi dedicare loro del tempo. Se ti serve quella volta, brucialo. E se no, prendi alcuni oggetti extra di backlog dal progetto principale alla fine dello sprint.

Answer 5

Ingannevole. La tua situazione potrebbe non essere perfetta per Scrum, ma penso che in Scrum ci siano elementi applicabili alla tua situazione.

Ad esempio, l'unica cosa che trovo più utile in Scrum sono le Retrospettive poiché è in quelle sessioni in cui si migliora il modo in cui si lavora. Tuttavia, al fine di rendere utili le Retrospettive, è necessario misurare il lavoro che si sta facendo con un gruppo di elementi che si è deciso di fare. Quindi, perché non avere qualcosa di simile agli sprint e fare una pianificazione sprint per gli articoli che intendi fare nelle prossime 1-2 settimane (le settimane più brevi sembrano essere più appropriate per il tuo caso). Fai una riunione quotidiana di Scrum in modo che tutti e tre di voi sappiano cosa stanno facendo gli altri e possono compilare come appropriato. Poi, dopo lo sprint, puoi sederti e pensare a come puoi migliorare. Se non altro, il risultato delle Retrospettive ti dirà se questo ha funzionato o meno per te.

Non credo nel tentativo di adattare un rigido schema di progetto Scrum se ciò significa eseguire gli sprint in parallelo o fare sprint più brevi con un solo progetto alla volta lasciando gli altri intatti ogni due settimane.