Chiusure del progetto in Scrum

For a group that works on multiple simultaneous projects, how do project closures fit in?

In primo luogo, "più progetti simultanei" è considerato una pessima idea. Il punto di mischia è di sprintare e di essere fatto. Cambiare i progetti per iniziare un altro sprint è di disturbo. Fare due progetti contemporaneamente non è uno sprint. È un casino.

Tuttavia, Scrum non è diverso da un metodo non agile (cascata). Quando il backlog si riduce a circa zero, hai ancora finito. Così come se avessi un approccio a cascata invece di un approccio agile.

A volte il backlog è diverso da zero, ma il cliente è contento e non ne vuole più. Quindi sei altrettanto fatto. Solitamente fatto prima e più economico di una cascata (che deve costruire tutto, anche le idee che si sono rivelate inutili.)

For a project that involves multiple groups, how does this concept apply?

Come un progetto non scrum con più gruppi. Niente cambia per le persone. A loro piace ancora una bella festa.

Or, does project closure term not apply to T&M projects at all?

Perché la fatturazione cambierà qualcosa circa la natura del lavoro o la cerimonia alla fine?

Di solito vedo metodi agili come le pratiche di scrum all'interno di un framework di gestione del progetto più strutturato. Questa non è affatto una contraddizione. Agile funziona per la consegna, il suo obiettivo è quello di fornire il software giusto più veloce. Aiuta le interazioni tra sviluppatori e stakeholder. Può essere utilizzato come parte di un programma a periodo fisso o per miglioramenti a estremità aperta.

Quindi con questo in mente, non c'è motivo per cui il resto della gestione del progetto non possa essere gestito in modo tradizionale, con un PM che gestisce la timeline, i costi e altre dipendenze. Al termine hai gli eventi di chiusura come al solito.

Lavoro in finanza, a volte avvengono nuovi regolamenti, o appare un nuovo scambio e abbiamo una data live per ciò che è scolpito nella pietra. Usiamo ancora un metodo Agile per la consegna, ma all'interno di un framework managent di progetto più traduttivo, in modo che venga consegnato in tempo.

La stima delle unità di lavoro e la selezione di una soluzione che è realizzabile nel lasso 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 minori che vanno e vengono, mentre la squadra rimane unita. Quindi non esiste un rituale di "progetto-clojure" in quanto tale. Piuttosto sul progetto cala mentre un'altra cerea. Il flusso degli elementi del backlog si sposta gradualmente da uno all'altro. La squadra conosce a malapena la differenza.

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

Se l'azienda deve cambiare la priorità dei progetti, cambia semplicemente il flusso degli elementi del backlog nei team.

Alcune delle cose che state discutendo qui sarebbero state incluse nella maggior parte dei processi agili, con cose come la documentazione e le pubblicazioni che si verificano frequentemente come ovvio, piuttosto che aspettare un trigger esterno. Ovviamente, non è sempre così, a seconda dei tipi 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 giusto per eseguire pulizie aggiuntive e, ovviamente, feste. Altre volte, anche quando il cliente è interno, l'azienda può ancora riconoscere il completamento di una pietra miliare aziendale / principale deliverable / altro che richiede di nuovo la fine del progetto di contabilità / feste. Se la tua azienda si impegna nella pianificazione del rilascio, ciò ti darà punti di rottura naturali, ma anche se non lo fai, è perfettamente appropriato avere misure di successo dettate dal 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 possono e devono ancora far parte della cultura della tua azienda.