Chi avesse letto tutti gli episodi delle nostre pillole di Scrum si sarà ormai fatto un’idea di massima sul funzionamento di questo framework. Continuando nel nostro percorso, riprendiamo il concetto con cui avevamo chiuso il precedente appuntamento: in Scrum la creazione di incrementi di prodotto/servizio/deliverable in ogni Sprint ha un preciso scopo, ed esattamente quello di poter consegnare valore al cliente potenzialmente al termine di ogni Sprint. Questo obiettivo si raggiunge attraverso la convalida dello Sprint, e quello che c’è da sapere lo troviamo, come di consueto, nella Guida SBOK® Ed. III, tradotta da PME in lingua Italiana per conto di SCRUMstudy, e scaricabile gratuitamente dal sito ufficiale di SCRUMstudy.
Nell’ambito di ciascuno Sprint, una volta chiusa la fase di creazione dei deliverable, si apre quella di revisione e retrospettiva, che riguarda appunto la revisione dei deliverable e del lavoro che è stato fatto e la determinazione dei modi per migliorare le pratiche e i metodi usati per eseguire il lavoro di progetto.
I membri dello Scrum Core Team e gli Stakeholder pertinenti partecipano agli Sprint Review Meeting per accettare i deliverable che soddisfano i Criteri di Accettazione delle singole User Story e per rifiutare i deliverable non accettabili. Queste riunioni sono convocate alla fine di ogni Sprint. Lo Scrum Team illustra i risultati dello Sprint, incluse le nuove funzionalità o i nuovi prodotti creati. Questo offre l‘opportunità al Product Owner e agli Stakeholder di esaminare ciò che è stato completato fino a quel momento e di stabilire se devono essere apportati eventuali cambiamenti al progetto o ai processi negli Sprint successivi. Deliverable che soddisfano i Criteri di Accettazione delle singole User Story sono accettati dal Product Owner. L‘obiettivo di uno Sprint è quello di creare deliverable potenzialmente consegnabili, o incrementi di prodotto, che soddisfano i Criteri di Accettazione definiti dal cliente e dal Product Owner. Questi sono appunto considerati Deliverable Accettati, che possono essere rilasciati al cliente, secondo il programma di rilascio concordato. Questi deliverable vengono inseriti in una lista dei Deliverable Accettati che viene aggiornata dopo ogni Sprint Review Meeting. Se un deliverable non soddisfa i Criteri di Accettazione stabiliti, non si considera accettato e di norma sarà riportato in uno Sprint successivo per correggere tutti gli eventuali problemi. Una situazione di questo tipo è altamente indesiderabile, perché l‘obiettivo di ogni Sprint è che i deliverable soddisfino i criteri di accettazione. I Deliverable che non soddisfano i Criteri di Accettazione sono rifiutati. Le User Story associate con tali Deliverable Rifiutati vengono aggiunti al Prioritized Product Backlog, e potranno essere nuovamente presi in esame per uno Sprint successivo.
Solo i deliverable accettati creano valore per il cliente e costituiranno la corretta misura dell’avanzamento fisico in caso di utilizzo della Analisi dell’Earned Value (in una logica 0%-100%).
Questo modo di procedere sostanzia ulteriormente il concetto della customer value driven delivery.
Gli output del processo Illustrare e Convalidare lo Sprint (deliverable accettati, deliverable rifiutati, rischi aggiornati, risultati dell’Analisi dell’Earned Value) forniscono informazioni preziose durante l‘esecuzione del processo di Retrospettiva dello Sprint. Il Retrospect Sprint Meeting è un elemento importante del concetto di ispezione-adattamento del framework Scrum e costituisce il passo finale di uno Sprint. Tutti i membri dello Scrum Team partecipano alla riunione, che viene facilitata o moderata dallo Scrum Master. È consigliata, ma non obbligatoria, la partecipazione del Product Owner. Uno dei membri del team funge da segretario verbalizzante e documenta le discussioni e i punti delle azioni future. È fondamentale tenere questa riunione in un ambiente aperto e rilassato per incoraggiare la piena partecipazione di tutti i membri del team. L‘obiettivo primario della riunione è quello di identificare tre elementi specifici:
1) Cose che il team desidera continuare a fare: best practice
2) Cose che il team desidera iniziare a fare: miglioramenti dei processi
3) Cose che il team desidera non fare più: problemi e ‘colli di bottiglia’ dei processi.
Queste aree vengono discusse e viene creato un elenco di Miglioramenti Fattibili Concordati.
Ma come avviene la consegna al cliente dei deliverable accettati? Per la risposta continuate a seguirci …
Lo Staff di PME
Chi avesse letto tutti gli episodi delle nostre pillole di Scrum si sarà ormai fatto un’idea di massima sul funzionamento di questo framework. Continuando nel nostro percorso, riprendiamo il concetto con cui avevamo chiuso il precedente appuntamento: in Scrum la creazione di incrementi di prodotto/servizio/deliverable in ogni Sprint ha un preciso scopo, ed esattamente quello di poter consegnare valore al cliente potenzialmente al termine di ogni Sprint. Questo obiettivo si raggiunge attraverso la convalida dello Sprint, e quello che c’è da sapere lo troviamo, come di consueto, nella Guida SBOK® Ed. III, tradotta da PME in lingua Italiana per conto di SCRUMstudy, e scaricabile gratuitamente dal sito ufficiale di SCRUMstudy.
Nell’ambito di ciascuno Sprint, una volta chiusa la fase di creazione dei deliverable, si apre quella di revisione e retrospettiva, che riguarda appunto la revisione dei deliverable e del lavoro che è stato fatto e la determinazione dei modi per migliorare le pratiche e i metodi usati per eseguire il lavoro di progetto.
I membri dello Scrum Core Team e gli Stakeholder pertinenti partecipano agli Sprint Review Meeting per accettare i deliverable che soddisfano i Criteri di Accettazione delle singole User Story e per rifiutare i deliverable non accettabili. Queste riunioni sono convocate alla fine di ogni Sprint. Lo Scrum Team illustra i risultati dello Sprint, incluse le nuove funzionalità o i nuovi prodotti creati. Questo offre l‘opportunità al Product Owner e agli Stakeholder di esaminare ciò che è stato completato fino a quel momento e di stabilire se devono essere apportati eventuali cambiamenti al progetto o ai processi negli Sprint successivi. Deliverable che soddisfano i Criteri di Accettazione delle singole User Story sono accettati dal Product Owner. L‘obiettivo di uno Sprint è quello di creare deliverable potenzialmente consegnabili, o incrementi di prodotto, che soddisfano i Criteri di Accettazione definiti dal cliente e dal Product Owner. Questi sono appunto considerati Deliverable Accettati, che possono essere rilasciati al cliente, secondo il programma di rilascio concordato. Questi deliverable vengono inseriti in una lista dei Deliverable Accettati che viene aggiornata dopo ogni Sprint Review Meeting. Se un deliverable non soddisfa i Criteri di Accettazione stabiliti, non si considera accettato e di norma sarà riportato in uno Sprint successivo per correggere tutti gli eventuali problemi. Una situazione di questo tipo è altamente indesiderabile, perché l‘obiettivo di ogni Sprint è che i deliverable soddisfino i criteri di accettazione. I Deliverable che non soddisfano i Criteri di Accettazione sono rifiutati. Le User Story associate con tali Deliverable Rifiutati vengono aggiunti al Prioritized Product Backlog, e potranno essere nuovamente presi in esame per uno Sprint successivo.
Solo i deliverable accettati creano valore per il cliente e costituiranno la corretta misura dell’avanzamento fisico in caso di utilizzo della Analisi dell’Earned Value (in una logica 0%-100%).
Questo modo di procedere sostanzia ulteriormente il concetto della customer value driven delivery.
Gli output del processo Illustrare e Convalidare lo Sprint (deliverable accettati, deliverable rifiutati, rischi aggiornati, risultati dell’Analisi dell’Earned Value) forniscono informazioni preziose durante l‘esecuzione del processo di Retrospettiva dello Sprint. Il Retrospect Sprint Meeting è un elemento importante del concetto di ispezione-adattamento del framework Scrum e costituisce il passo finale di uno Sprint. Tutti i membri dello Scrum Team partecipano alla riunione, che viene facilitata o moderata dallo Scrum Master. È consigliata, ma non obbligatoria, la partecipazione del Product Owner. Uno dei membri del team funge da segretario verbalizzante e documenta le discussioni e i punti delle azioni future. È fondamentale tenere questa riunione in un ambiente aperto e rilassato per incoraggiare la piena partecipazione di tutti i membri del team. L‘obiettivo primario della riunione è quello di identificare tre elementi specifici:
1) Cose che il team desidera continuare a fare: best practice
2) Cose che il team desidera iniziare a fare: miglioramenti dei processi
3) Cose che il team desidera non fare più: problemi e ‘colli di bottiglia’ dei processi.
Queste aree vengono discusse e viene creato un elenco di Miglioramenti Fattibili Concordati.
Ma come avviene la consegna al cliente dei deliverable accettati? Per la risposta continuate a seguirci …
Lo Staff di PME
