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

Question

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

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 avere più progetti? Pianifichi ancora una iterazione per un singolo progetto in un determinato periodo di tempo e l'intero team ci lavora e poi passi al progetto successivo con una nuova iterazione al termine di tale iterazione? Oppure c'è un "agile" modo di gestire più progetti con le proprie iterazioni con un solo team contemporaneamente?

Answer 1

Scrum in realtà non impone che si debba lavorare su un prodotto indipendente. Indica semplicemente che c'è un mucchio di cose che devono essere fatte (il backlog del prodotto), c'è un certo tempo di sviluppo disponibile nella prossima iterazione (elaborato dalla velocità del progetto) e ci sono elementi selezionati dal cliente / business avendo la massima priorità da questo insieme di problemi / attività che verranno eseguiti nella prossima iterazione (il backlog dello sprint).

Non vi è alcun motivo per cui il backlog del prodotto e il backlog dello sprint debbano provenire dall'unico progetto: anche in un singolo progetto ci saranno unità di lavoro discrete che sono come progetti separati: l'interfaccia utente, il livello aziendale, lo schema del database , ecc. Lo sviluppo di software aziendale in particolare è come questo, in cui esistono un numero di basi di codice che tutti devono progredire. Il processo Scrum - riunioni, domande, grafico esaurito, ecc. - Funziona a prescindere dal fatto che si tratti di un progetto o multiplo.

Detto questo, in pratica è spesso utile che ogni iterazione abbia un tema principale: "fare il modulo di reporting" oppure "interfaccia con l'API del sistema XYZ" - in modo che molti dei problemi provengano da un progetto o area e alla fine dell'iterazione è possibile indicare un ampio corpus di lavoro e mettere un segno di spunta su di esso.

Answer 2

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

Se ogni progetto ha i suoi responsabili, è probabile che si verifichino dei problemi in cui ogni responsabile - più o meno consapevolmente - cercherà di favorire i suoi progetti. IMHO, dovrai disporre di un solo Product Owner con l'autorità per risolvere le priorità tramite arbitrato.

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

Answer 3

Non sono d'accordo. Penso che sia fondamentale per il processo avere un team focalizzato su un singolo progetto durante uno sprint. Se si dispone di alcuni specialisti che non possono contribuire all'intero processo di sviluppo (autori di contenuti, grafici, analisti di processi aziendali, ecc.) Li rimescolerei 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 il tuo programma. Considera questo: per motivi di semplicità, supponiamo di avere 5 progetti che utilizzano lo stesso team e che iniziano alla stessa data. Ogni progetto richiede 3 mesi di sforzo, nel migliore dei casi in parallelo, li finirai tutti in una volta e ci vorranno 15 mesi. La tua velocità verrà cremosa perché puoi inserire solo 1/5 di un mese di sforzo in un singolo sprint. Farai anche 5 incontri dimostrativi contemporaneamente. Quindi, nel migliore dei casi, consegnerai i tuoi 5 progetti in 15 mesi e la tua competizione affermerà 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% della loro manodopera disponibile. Potresti scoprire di non essere in grado di eseguire alcune attività in un singolo sprint. Se devi modificare il numero di progetti in corso da 5, il tuo team dovrà adattare le proprie abitudini di stima, danneggiando l'efficienza del team. Inoltre, il tuo team troverà difficile auto-organizzarsi quando una semplice riassegnazione di 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 ha una tale richiesta da avere un arretrato di 12 mesi e che puoi usare quel tempo per perfezionare gli obiettivi del tuo progetto. O se hai un arretrato costante, sai che è ora di iniziare ad assumere un'altra squadra. Il tuo miglior progetto, tuttavia, è terminato in 3 mesi con un cliente che ha visto rapidi miglioramenti durante il periodo attivo. Sei in grado di terminare quel progetto un anno prima e puoi inserirlo nel tuo curriculum. La velocità dello sprint si stabilizzerà in quel periodo di tempo e potresti scoprire che fa un passo avanti dopo uno o due progetti e che puoi ottenere di più in uno specifico sprint.

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

Tieni presente che EVERYBODY non ha bisogno di essere un membro del team completo. Possono coinvolgere il tuo cliente nella sala d'aspetto, preparando il processo di sviluppo. Tengo i miei analisti aziendali, architetti di rete e progettisti grafici come esperti di dominio e li allego solo a un team, se necessario. Lasciateli correre con lo sprint 0. Sareste sorpresi di quanto sia coinvolgente lavorare su aspetto e flusso di lavoro. È anche utile preparare il cliente con la consapevolezza che quando lo sviluppo inizia sul serio, il loro livello di partecipazione può effettivamente aumentare e che è importante che siano disponibili. Fai sapere loro il programma in modo che abbiano un sacco di tempo per affrontare le cose come le vacanze e le vacanze con largo anticipo.

Answer 4

Sono stato in questa situazione precisa.

Se si dispone di un proprietario del prodotto in tutti i progetti, Phillipe è assolutamente corretto; Uno sprint con una squadra dovrebbe funzionare bene.

Se hai più di un proprietario di prodotto, idealmente la parte aziendale deve scegliere un singolo 'prioritizer' a cui viene data 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 desidera dare 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 praticabili). Dividere ulteriormente come suggerisce Kenny e avere squadre di una sola persona mi sembra un po 'inutile, dato che allora non hai più una squadra, solo singoli programmatori.

Se stai dividendo la squadra, non ho trovato molto valore nel combinare gli stand-up, a meno che tu non abbia sprint separati che lavorano su gran parte della stessa base di codice, ma questo potrebbe essere un argomento per riunire quelle squadre lo scopo dello sprint.

Answer 5

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 su Rilasci . Questo perché Progetti sono scatole di lavoro artificiali che non producono alcun valore fino a quando non sono finite. Sono in contrasto con l'obiettivo di Agile di fornire frequentemente valore spedibile. Una versione è più in linea con Agile perché è orientata alla consegna di valore e perché il suo ambito può essere ridotto o ampliato in base a ciò che i team possono offrire prima della prossima versione .

Esiste una potenziale via di mezzo, in cui quello che in precedenza era chiamato un Progetto nella tua azienda è ora riconfezionato come Tema o Funzionalità comune strong>. Il vantaggio di questo approccio è che il tema o caratteristica può ora essere implementato in parti di valore, come ritiene opportuno il proprietario del prodotto.

C'è ancora la domanda di un team che lavora su più Prodotti , ed è una domanda a causa di legittime preoccupazioni sulla conoscenza del dominio e sulle possibili competenze tecniche. Ma Prodotti costruiti con Agile, anche più Prodotti creati da un singolo team, accumulano costantemente valore in grado di Release . Al contrario, Progetti non valgono nulla fino alla fine (e molti non lo fanno).

Qualcosa a cui pensare ...

Answer 6

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

Assumiamo 5 progetti ciascuno di circa 3 mesi per team con 5 persone.

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

• 1/5 di velocità di consegna per progetto offre 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 progetti

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

Approccio 3: 5 progetti in singolo sprint

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

Approccio 4: raccomandato - Lavoro serializzato

• Il team lavora su un singolo progetto dopo progetto
• Primo progetto avviato e consegnato dopo 3 mesi
• Il secondo progetto è iniziato dopo il 3 ° mese, consegnato dopo il 6 ° mese
• ...
• 5 ° progetto avviato dopo il 12 ° mese, consegnato dopo il 15 ° mese
• Team fortemente focalizzato sul progetto, ricerca intensiva e collaborazione con il cliente
• L'intero team ha una buona conoscenza generale di tutti i progetti
• Nessuno spreco di tempo nel cambio di contesto
• Richiede una buona collaborazione di gruppo (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 la perdita di tempo dovuta al cambio di contesto, nessuna collaborazione completa del team, tempi di consegna totali molto lunghi di tutti i progetti ecc.

E per quanto riguarda la cura degli arretrati? Se il team lavora su un singolo progetto contemporaneamente, è semplice: tutti si uniranno. Se sono presenti più progetti, potrebbe essere necessario delegare singole persone a sessioni separate di toelettatura (non è coinvolto l'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 se lo avvieremo 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, tuttavia, non è efficace.

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

Saluti, Adam

Answer 7

Come diceva @Chris, un normale progetto ha dei sotto-progetti all'interno. Hai un solo arretrato però.

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

Avere proprietari di prodotti diversi e in quanto tali proprietari di prodotti non saranno d'accordo su quanto tempo dovrebbero dedicare a ciascun progetto. & Quot; Qualcuno " dovrà assorbire la decisione su come gestire le priorità dell'interprogetto. Nota: gli sviluppatori non dovrebbero farlo.

Ecco che arriva il nostro progetto "S" manager che bilancerà le risorse necessarie ai proprietari dei prodotti e il tempo che i membri del team possono dedicare. Il proprietario del prodotto A ha pagato per un mese di lavoro, ma il proprietario del prodotto B aggiorna sempre il suo progetto (e lo paga anche bene). Ecco come bilancerai la tua squadra affinché A abbia il suo mese (tempo di sviluppo) e non fermi B dal riempirti le tasche.

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

Beh, sto ancora cercando di capire il modo migliore per farlo. Ma questo è ciò che stiamo spingendo in questo momento. Spero che sia d'aiuto.

Answer 8

I membri del team possono dividere il loro tempo tra progetti di mischia, ma è molto di più produttivo per avere membri del team completamente dedicati. I membri del team possono anche cambiare da uno sprint per il prossimo, ma ciò riduce anche la produttività della squadra. I progetti con team più grandi sono organizzati in più scrum, ognuno incentrato su un aspetto diverso del prodotto sviluppo, con uno stretto coordinamento dei loro sforzi.

Answer 9

Suggerirei di eseguire uno Sprint per ciascun progetto e di avere una riunione standup giornaliera per gestire tutte le molle / i progetti attivi.

Answer 10

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

• Esiste un proprietario di prodotto e un backlog di prodotto per squadra. Il proprietario del prodotto non deve essere una sola persona, ma questo proprietario del prodotto "entità". è responsabile del portafoglio ordini del prodotto.
• Il backlog del prodotto contiene le storie utente di ogni progetto (tutti i progetti qui). Ogni user story ha uno sforzo / punti story (responsabilità del team) e un valore aziendale (responsabilità del proprietario del prodotto).
• Abbiamo una "quotazione di backlog di prodotti" " incontrando ogni sprint. Prima di questo incontro il proprietario del prodotto ha aggiornato i valori commerciali delle storie (se hanno bisogno di qualche cambiamento per qualsiasi motivo commerciale - che non ci interessa e non dovrebbe interessarci) e includendo alcune nuove storie. In questo incontro vengono spiegate le nuove storie e anche gli sforzi vengono aggiornati. Questo incontro dura circa un'ora (tranne la prima volta, circa 4 ore).
• Quando pianificheremo un nuovo sprint apriamo il backlog del prodotto, ordiniamo le storie in base al ROI (questo è valore / sforzo commerciale) e pianifichiamo le storie fino a quando non sarà trascorso il tempo.

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

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