Come funziona Scrum quando hai più progetti? [chiuso]

Ho letto abbastanza bene i vantaggi e i processi di Scrum. Ottengo le idee sul backlog, sui grafici burndown, sulle iterazioni, sull'utilizzo di user story e su altri vari concetti del "framework" Scrum.

Detto questo ... lavoro per una società di sviluppo web che gestisce più progetti contemporaneamente, con sei membri del team che compongono il "team di produzione".

Come funziona Scrum con più progetti? Pianifichi ancora un'iterazione per un singolo progetto in un certo periodo di tempo e l'intero team ci lavora, e poi passi al progetto successivo con una nuova iterazione quando l'iterazione è completata? O esiste un modo "agile" per gestire più progetti con le proprie iterazioni con un solo team alla volta?

Scrum in realtà non impone che tu debba lavorare su un unico prodotto autonomo. Dichiara semplicemente che c'è un sacco di cose che devono essere fatte (il backlog del prodotto), c'è una certa quantità di tempo di sviluppo disponibile nella successiva iterazione (elaborata dalla velocità del progetto) e ci sono elementi selezionati dal cliente / business ha la priorità maggiore da questo pool di problemi / attività che verranno svolte nella prossima iterazione (lo sprint backlog).

Non c'è motivo per cui il backlog del prodotto e lo sprint backlog debbano provenire da un unico progetto - anche in un singolo progetto ci saranno unità di lavoro separate che sono come progetti separati - l'interfaccia utente, il livello aziendale, lo schema del database, ecc. Lo sviluppo del software aziendale in particolare è così, in cui hai un numero di basi di codice che devono essere tutte sviluppate. Il processo Scrum - riunioni, domande, grafico masterizzato, ecc. - funziona tutto sia che si tratti di un progetto o di più.

Detto questo, in pratica è spesso bene che ogni iterazione abbia un tema principale - "fai il modulo di reporting" o "interfaccia con l'API del sistema XYZ" - in modo che molti dei problemi provengano da un progetto o area e al Alla fine dell'iterazione puoi indicare un grande corpo di lavoro e mettere un segno di spunta su di esso.

Penso che la risposta dipenda da " chi darà la priorità agli elementi del backlog " (ovvero decidere prima cosa deve essere fatto). Se si tratta di una sola persona, questa persona è il Product Owner per i tuoi progetti e puoi avere un unico backlog per tutti gli elementi per tutti i progetti - o un backlog per progetto - e selezioni gli elementi del backlog da tutti i progetti quando pianifichi uno Sprint. In questo caso, Scrum "funziona" bene.

Se ogni progetto ha il proprio responsabile, è probabile che si verifichino problemi in cui ogni responsabile cercherà, più o meno consapevolmente, di favorire il proprio progetto. IMHO, dovrai avere un solo Product Owner con l'autorità per stabilire le priorità mediante arbitrato.

Una regola che deve essere seguita in tale contesto è quella di non modificare mai il contenuto dello Sprint durante lo Sprint . Se necessario, puoi abbreviare l'iterazione a due o tre settimane per ridurre il rischio di dover aggiungere un elemento urgente nello Sprint corrente.

Non sono d'accordo Penso che sia fondamentale per il processo avere un team concentrato su un singolo progetto durante uno sprint. Se hai degli specialisti che non possono contribuire all'intero processo di sviluppo (autori di contenuti, grafici, analisti dei processi aziendali, ecc.) Li rimescerei dal team quando non possono più contribuire. O meglio ancora, addestrali su alcuni compiti diversi in modo che possano contribuire a cose come i test.

Un'altra cosa da tenere a mente è che l'esecuzione di progetti in parallelo uccide la tua pianificazione. Considera questo: per semplicità, diciamo che abbiamo 5 progetti che utilizzano lo stesso team e iniziano nella stessa data. Ogni progetto richiede 3 mesi di impegno, nella migliore delle ipotesi in esecuzione parallela, li finirai tutti in una volta e ci vorranno 15 mesi. La tua velocità verrà ridotta perché puoi fare solo 1/5 di un mese di sforzo in un singolo sprint. Farai anche 5 riunioni demo tutte allo stesso tempo. Quindi, nella migliore delle ipotesi, consegni i tuoi 5 progetti in 15 mesi e la concorrenza sosterrà che potrebbero fare lo stesso lavoro in 3. I tuoi team che stimano la maturità ne soffriranno perché saranno in grado di considerare solo il 20% del loro lavoro disponibile. Potresti scoprire di non essere in grado di eseguire alcune attività in un singolo sprint. Se devi cambiare il numero di progetti in lavorazione da 5, il tuo team dovrà adattare le proprie abitudini di stima che danneggeranno l'efficienza del team. Inoltre, il tuo team troverà difficile auto-organizzarsi quando una semplice riassegnazione di un'attività potrebbe richiedere la creazione di un nuovo ambiente di sviluppo prima che il lavoro possa iniziare.

Se dovessi eseguire gli stessi 5 progetti in serie, consegneresti il ​​5 ° progetto negli stessi 15 mesi, ma avresti informato il tuo cliente che il tuo team è così richiesto da avere un arretrato di 12 mesi e che puoi utilizzare quel tempo per perfezionare gli obiettivi del tuo progetto. Oppure, se hai un arretrato costante, sai che è ora di iniziare ad assumere un'altra squadra. Il tuo miglior progetto, tuttavia, è finito in 3 mesi con un cliente che ha visto rapidi miglioramenti durante il periodo attivo. Sei in grado di finire quel progetto un anno prima e puoi inserirlo nel tuo curriculum. La tua velocità di scatto si stabilizzerà in quel periodo di tempo e potresti scoprire che fa il suo passo dopo uno o due progetti e sei in grado di ottenere di più in un dato sprint.

Penso che la gestione di progetti in serie sia uno dei maggiori ostacoli che un'organizzazione tenta di adottare per affrontare la mischia. È un grande cambiamento culturale associato alla decostruzione del ruolo di project manager, ma i vantaggi del processo di scrum sono enormi.

Tieni presente che TUTTI non hanno bisogno di essere un membro a pieno titolo del team. Possono coinvolgere il tuo cliente nella sala d'attesa, preparandosi per il processo di sviluppo. Mantengo i miei analisti aziendali, architetti di rete e addetti alla progettazione grafica come esperti di dominio e li collego a un team solo se necessario. Lasciali correre con lo sprint 0. Saresti sorpreso di quanto sia coinvolgente lavorare sull'aspetto e sul flusso di lavoro. È anche utile preparare il cliente con la consapevolezza che quando lo sviluppo inizia sul serio, il suo livello di partecipazione può effettivamente aumentare e che è importante che sia disponibile. Fai loro sapere il programma in modo che abbiano tutto il tempo per occuparsi di cose come le vacanze e le vacanze con largo anticipo.

Sono stato in questa precisa situazione.

Se hai un proprietario del prodotto in tutti i progetti, Phillipe ha assolutamente ragione; Uno sprint con una squadra dovrebbe funzionare bene.

Se hai più di un proprietario del prodotto, idealmente il lato aziendale deve scegliere un unico "prioritizzatore" a cui è assegnata la responsabilità di programmare il lavoro. Questa è sicuramente la soluzione migliore.

Se (come probabilmente è il caso) l'azienda non vuole cambiare il modo in cui vuole dare la priorità alle cose (sarebbe troppo conveniente), allora puoi dividere il team ed eseguire due sprint simultanei. Tuttavia, con una squadra di sei, non lo dividerei in più di 3 squadre (non vorrei dividerlo affatto, ma penso che 2-3 squadre sarebbero lavorabili). Dividere ulteriormente come suggerisce Kenny, e avere team di una sola persona mi sembra in qualche modo inutile, poiché allora non hai più un team, solo programmatori individuali.

Se stai dividendo la squadra, non ho trovato molto valore nell'amalgamare gli stand-up, a meno che tu non abbia sprint separati che lavorano sulla stessa base di codice, ma allora questo potrebbe essere un argomento per amalgamare quei team allo scopo di lo sprint.

C'è un'altra opinione di cui ho letto ultimamente, ovvero che in un ambiente Agile il concetto di Progetto potrebbe essere controproducente e potrebbe essere eliminato. Secondo questa linea di pensiero, l'organizzazione dovrebbe invece concentrarsi sui rilasci . Questo perché i progetti sono scatole artificiali di lavoro che non producono valore finché non sono finite. Sono contrari all'obiettivo di Agile di fornire frequentemente valore per la spedizione. Una Release è più in linea con Agile perché è orientata alla fornitura di valore e perché il suo ambito può essere ridotto o ampliato in base a ciò che i team possono offrire prima della Release successiva .

Esiste una potenziale via di mezzo, in cui quello che in precedenza era chiamato un progetto nella tua azienda è ora riconfezionato come tema o caratteristica Agile comune . Il vantaggio di questo approccio è che il tema o la funzionalità possono ora essere implementati in pezzi di valore, come ritiene opportuno il proprietario del prodotto.

C'è ancora il problema di un team che lavora su più prodotti , ed è una domanda a causa di legittime preoccupazioni sulla conoscenza del dominio e sulle possibili capacità tecniche. Ma i prodotti costruiti con Agile, anche più prodotti costruiti da un unico team, sono costantemente accumulando uscita valore -abile. Al contrario, i progetti non valgono nulla finché non finiscono (e molti no).

Qualcosa a cui pensare...

Penso che anopres avesse ragione: il modo migliore è evitare più progetti contemporaneamente con Scrum. Fai di tutto per capire che correre troppo in parallelo non è efficiente.

Supponiamo 5 progetti ciascuno di circa 3 mesi per un team di 5 persone.

Approccio 1: ogni persona lavora in team su un singolo progetto

• La velocità di consegna di 1/5 per progetto garantisce 15 mesi di consegna per tutti i progetti
• Ogni singola persona è esperta ma solo nel proprio progetto
• Nessuno spirito di squadra

Approccio 2: 1 sprint per progetto, cambio di progetto

• Ogni 6 sprint lavora al progetto
• Troppo tempo tra il lavoro del progetto - valore incrementale non regolare per il progetto (per il backlog del prodotto sì), facile da dimenticare, sforzo necessario per ripristinare il contesto,
• Primo progetto consegnato dopo circa 12-13 mesi (ipotizzando uno sprint di 2 settimane)

Approccio 3: 5 progetti in singolo sprint

• Richiede una suddivisione troppo dettagliata delle attività solo per adattarsi allo sprint
• Pochissima build incrementale per progetto
• Consegna del primo progetto dopo circa 12-15 mesi

Approccio 4: consigliato - Lavoro serializzato

• Il team lavora su un singolo progetto dopo progetto
• Primo progetto avviato e consegnato dopo 3 mesi
• Secondo progetto iniziato dopo il 3 ° mese, consegnato dopo il 6 ° mese
• ...
• 5 ° progetto iniziato dopo il 12 ° mese, consegnato dopo il 15 ° mese
• Team altamente concentrato sul progetto, ricerca intensiva e collaborazione con il cliente
• L'intero team ha una buona conoscenza generale di tutti i progetti
• Nessuna perdita di tempo nel cambio di contesto
• Richiede una buona collaborazione di squadra (i conflitti possono rallentare la consegna).

Come vedi, la soluzione 4 è generalmente migliore perché i progetti vengono consegnati molto più velocemente, il team lavora insieme ed è efficiente. Altri approcci includono perdita di tempo dal cambio di contesto, nessuna collaborazione completa del team, tempi di consegna totali molto lunghi di tutti i progetti, ecc.

E per quanto riguarda il grooming degli arretrati? Se il team lavora su un singolo progetto contemporaneamente, è semplice: tutti si uniranno. Se ci sono più progetti, potrebbe essere necessario delegare singole persone a sessioni di toelettatura separate (non è coinvolto un intero team).

È importante convincere i clienti che l'avvio del secondo progetto dopo 3 mesi comporterà comunque una consegna più rapida (dopo il sesto mese) piuttosto che avviarlo immediatamente con tutti gli altri. È un'illusione che i manager vedono: iniziamo 5 progetti contemporaneamente, lavoriamo sodo e consegniamo a poco a poco. Alla fine questo non è tuttavia efficiente.

Questo è il motivo per cui non credo che Scrum sia efficiente per più progetti in parallelo, è molto difficile combinarlo nel framework e lavorare secondo le regole di Scrum. A volte può essere utile avere 2 progetti per tenere tutte le persone occupate, ma più progetti aggiungiamo, meno efficiente sarà lo scrum. Forse il kanban è un'alternativa solo per vedere i progressi e il lavoro di squadra (non così forte come nel team Scrum)?

Saluti, Adam

Come ha detto @Chris, un progetto normale ha dei sottoprogetti all'interno. Hai solo un arretrato però.

Pensa a un arretrato con tutti i tuoi progetti. Primo problema: stai assegnando priorità a compiti o progetti? Preferisco un backlog per progetto. Almeno per avere chiare le priorità che ha il product owner.

Avere proprietari di prodotti diversi e per il fatto che questi proprietari di prodotti non saranno d'accordo su quanto tempo dedicare a ciascun progetto. "Qualcuno" dovrà assorbire la decisione su come gestire le priorità tra i progetti. Nota: gli sviluppatori non dovrebbero farlo.

Ecco che arriva il nostro project manager "S" che bilancia le risorse necessarie ai product owner e il tempo che i membri del team possono dedicare. Il product owner A ha pagato un mese di lavoro, ma il product owner B aggiorna sempre il suo progetto (e paga bene anche te). Ci sono alcuni modi per bilanciare la tua squadra affinché A abbia il suo mese (tempo di sviluppo) e non impedire a B di riempirti le tasche.

Nel caso del software interno (una società, mille progetti). I diversi proprietari dei prodotti dovrebbero concordare il tempo loro concesso. Non vivono isolati, ma nella tua stessa barca (responsabile del progetto "S"). Ti semplificheranno la vita potendo rimandare alcuni compiti, ma allo stesso tempo non dovresti mai dimenticare i loro bisogni.

Bene, sto ancora cercando di capire il modo migliore per farlo. Ma questo è ciò che stiamo spingendo adesso. Spero possa essere d'aiuto.

I membri del team possono dividere il loro tempo tra i progetti di Scrum, ma è molto più produttivo avere membri del team completamente dedicati. I membri del team possono anche cambiare da uno sprint all'altro, ma ciò riduce anche la produttività del team. I progetti con team più grandi sono organizzati come più mischie, ciascuna focalizzata su un aspetto diverso dello sviluppo del prodotto, con uno stretto coordinamento dei loro sforzi.

Suggerirei di eseguire uno Sprint per ogni progetto e di tenere 1 riunione quotidiana in piedi per gestire tutte le molle / progetti attivi.

Mi piacerebbe contribuire. Questo è il modo in cui lo faccio:

• C'è un product owner e un product backlog per team. Il product owner non deve essere una sola persona, ma questa "entità" del product owner è responsabile del product backlog.
• Il backlog del prodotto contiene le storie degli utenti di ogni progetto (tutti i progetti qui). Ogni user story ha uno sforzo / story points (responsabilità del team) e un valore aziendale (responsabilità del product owner).
• Abbiamo un "product backlog grooming" che soddisfa ogni sprint. Prima di questo incontro, il product owner ha aggiornato i valori aziendali delle storie (se hanno bisogno di qualche cambiamento per qualsiasi motivo aziendale - che non ci interessa e non dovremmo preoccuparci -) e include alcune nuove storie. In questo incontro vengono spiegate le nuove storie e vengono aggiornati anche gli sforzi. Questo incontro dura circa un'ora (tranne la prima volta, circa 4 ore).
• Quando pianifichiamo un nuovo sprint, apriamo il backlog del prodotto, ordiniamo le storie in base al ROI (questo è il valore / impegno aziendale) e pianifichiamo le storie fino allo scadere del tempo.

E questo è tutto. Posso dire che funziona abbastanza bene. Usiamo un paio di fogli di calcolo Google (il backlog del prodotto e quelli dello sprint backlog, sia con grafici che cose del genere) per farlo, e redmine (con una semantica specifica) per un'organizzazione online ogni giorno: tempo, avanzamento dell'attività, ecc.

Il problema con questo approccio è che ho duplicato le attività nel foglio di calcolo del backlog sprint e nel redmine. Ma non trovo alcuno strumento online per farlo completamente online. Mi manca un product backlog in redmine (nessun altro lavoro semantico per me), una singola scheda in jira, più storie in taiga, eccetera