Chiusure di progetti in Scrum

In un tipico ambiente di sviluppo software, le chiusure di progetti segnano la fine di un progetto.

1. I record del progetto sono completati e archiviati,
2. risorse rilasciate,
3. i problemi e le lezioni sono documentati e
4. una cena / festa formale tenuta per la celebrazione.

L'ultimo passo è facoltativo, sebbene sia molto motivante per i partecipanti. :-)

In contrasto con Scrum. So che la mischia si basa su storie di arretrati . Quindi, tecnicamente, ogni iterazione chiude certe storie. Quindi, ci sono due domande qui.

1. Per un gruppo che lavora su più progetti simultanei , come si adattano le chiusure dei progetti?
2. Per un progetto che coinvolge più gruppi , come si applica questo concetto?

Oppure, il termine di chiusura del progetto non si applica affatto ai progetti di MT&M ?

Per un gruppo che lavora su più progetti simultanei, come si adattano le chiusure dei progetti?

Innanzitutto, i "progetti multipli simultanei" sono considerati una pessima idea. Il punto di mischia è quello di correre ed essere fatti. Passare da un progetto all'altro per iniziare un altro sprint è dirompente. Fare due progetti contemporaneamente non è uno sprint. È un casino.

Tuttavia, Scrum non è diverso da un metodo non agile (a cascata). Quando il backlog è ridotto a circa zero, il gioco è ancora fatto. Proprio come se avessi un approccio a cascata anziché un approccio agile.

A volte il backlog è diverso da zero, ma il cliente è felice e non ne vuole più. Quindi hai appena finito. Di solito fatto prima e più economico di una cascata (che deve costruire tutto, anche le idee che si sono rivelate inutili).

Per un progetto che coinvolge più gruppi, come si applica questo concetto?

Come un progetto non scrum con più gruppi. Non cambia nulla delle persone. A loro piace ancora una bella festa.

Oppure, il termine di chiusura del progetto non si applica affatto ai progetti di MT&M?

Perché la fatturazione cambierebbe qualcosa sulla natura dell'opera o della cerimonia alla fine?

Di solito vedo metodi agili come le pratiche di mischia in un quadro di gestione del progetto più strutturato. Questa non è affatto una contraddizione. Agile lavora per la consegna, il suo obiettivo è fornire il software giusto più velocemente. Aiuta con le interazioni tra gli sviluppatori e gli stakeholder. Può essere utilizzato come parte di un programma a periodo fisso o per miglioramenti aperti.

Quindi, tenuto conto di ciò, non vi è alcun motivo per cui il resto della gestione del progetto non possa essere gestito in modo tradizionale, con un PM che gestisce i tempi, i costi e le altre dipendenze. Al termine hai gli eventi di chiusura come al solito.

Lavoro nella finanza, a volte accadono nuovi regolamenti o appare un nuovo scambio e abbiamo una data di partenza per ciò che è fissato nella pietra. Utilizziamo ancora un metodo Agile per la consegna, ma all'interno di un framework di gestione del progetto più tradizionale, in modo da consegnarlo in tempo.

La stima delle unità di lavoro e la selezione di una soluzione realizzabile nel periodo di tempo disponibile è ciò che ci rende buoni sviluppatori (una delle cose che dovrei dire).

In Scrum, come in tutte le tecniche Agile, i progetti sono cose secondarie che vanno e vengono, mentre il team sta insieme. Quindi non esiste un rituale di "chiusura del progetto" in quanto tale. Piuttosto, il progetto diminuisce mentre un'altra cresce. Il flusso di elementi di arretrato si sposta gradualmente dall'uno all'altro. Il team conosce a malapena la differenza.

In effetti, il team potrebbe lavorare su due o tre progetti diversi contemporaneamente. Ancora una volta, a malapena conoscono la differenza. Gli elementi arretrati entrano nel team all'inizio di ogni sprint e il team li implementa. Possono appartenere tutti a un progetto o possono essere equamente divisi tra più progetti. Alla squadra non importa. Il team implementa semplicemente gli elementi arretrati che gli vengono dati.

Se l'azienda deve modificare la priorità dei progetti, cambia semplicemente il flusso di articoli arretrati nei team.

Alcune delle cose che stai discutendo qui sarebbero riassunte dalla maggior parte dei processi agili, con cose come la documentazione e le pubblicazioni che si verificano frequentemente come una cosa ovvia, piuttosto che aspettare un trigger esterno. Questo non sarà sempre il caso, ovviamente, a seconda del tipo di clienti che hai e del tipo di attività in cui ti trovi. Ad esempio, se stai creando una singola parte di un sistema più grande di proprietà di un'entità esterna, di solito c'è una data che guida il processo e quella data sarebbe il momento opportuno per eseguire le pulizie aggiuntive e, naturalmente, la festa. Altre volte, anche quando il cliente è interno, l'azienda potrebbe ancora riconoscere il completamento di una pietra miliare aziendale / consegna importante / altro che richiede ancora la fine della contabilità / festa del progetto. Se la tua azienda si impegna nella pianificazione dei rilasci, questo ti darà punti di interruzione naturali, ma anche se non lo fai, è perfettamente appropriato avere misure di successo orientate al business. Cioè, i progetti potrebbero non essere più una caratteristica del tuo processo di ingegneria, ma certamente possono far parte del tuo business e celebrare / trattare con loro può e dovrebbe comunque essere parte della cultura della tua azienda.