In questo articolo introduttivo a livello esaminiamo la meccanica di uno Sprint, e a come i membri del team sono tenuti a collaborare al fine di produrre un incremento di qualità di rilascio.

Il primo giorno: Sprint Planning

L’intero team, incluso il Product Owner, si riunisce il primo giorno dello Sprint e conduce una sessione di Sprint Planning. Questa è la prima cosa che accade non appena inizia lo Sprint.

Preparazione

La pianificazione sprint dovrebbe essere preparata per. La preparazione più importante è garantire che il Product Backlog sia stato perfezionato ad un livello appropriato di dettaglio, con stime e criteri di accettazione (questo è lo scopo del Product Backlog Refinement). Successivamente, il Product Owner dovrebbe aver ordinato il lavoro sul Product Backlog e avere un’idea generale di come negoziare un prezioso obiettivo Sprint con il team. Anche le opzioni per negoziare un obiettivo avrebbero dovuto essere prese in considerazione durante il perfezionamento e riflesse nell’ordinamento del backlog. Inoltre, il team dovrebbe avere un’idea della loro capacità per questo Sprint, vale a dire, quanto lavoro credono di poter assumere. Essi possono essere in grado di utilizzare la loro esperienza con Sprint precedenti per aiutarli ad accertare le dimensioni di questo bilancio.

Prima pianifica il valore che verrà consegnato

Ogni Sprint dovrebbe comportare un prezioso incremento del lavoro completato, in forma e pronto per il rilascio immediato. Il proprietario del prodotto è totalmente responsabile di ciò che significa” valore ” e dovrebbe aver ordinato il Product Backlog in modo tale che il valore possa essere massimizzato dal team, sprint-by-sprint. La prima cosa che il team deve fare è quindi pianificare quali elementi del Product Backlog dovrebbero essere lavorati in questo Sprint, in modo che il miglior valore possa essere consegnato entro la fine di esso.

Per fare ciò, il team lavora con il proprietario del prodotto per selezionare gli elementi più preziosi dal Product Backlog che si adatta alla loro capacità proiettata per lo Sprint. Tenete a mente che ogni elemento sul Product Backlog dovrebbe essere stata data una stima da parte del team, così sapranno circa quanto lavoro è probabile che sia coinvolto.

Assicurati di concordare un obiettivo Sprint

Questa selezione di lavoro dovrebbe essere coesa, e non solo un raggruppamento di elementi non correlati e disparati. Ricorda che uno Sprint è un’opportunità time-boxed per ottenere qualcosa di significativo. Ad esempio, alla fine dello Sprint potrebbe essere stata fornita una caratteristica coerente o un rischio significativo sarà stato mitigato. L’Obiettivo Sprint è una semplice espressione di questo scopo, del significato generale del lavoro selezionato e della coerenza alla base della selezione.

Un buon obiettivo Sprint permetterà al team di dimostrare attenzione e impegno, e consentire la collaborazione e la riprogettazione del lavoro in modo che sia soddisfatta.

Piano successivo come verrà eseguito il lavoro

Uno Sprint Backlog è più di una semplice selezione di lavori con un obiettivo finale in mente. È anche un piano per come sarà raggiunto tale obiettivo e come verrà eseguito il lavoro associato. Questo può essere fatto identificando e ordinando i compiti tecnici che sono suscettibili di essere coinvolti. In effetti il Backlog Sprint è un piano per raggiungere l’obiettivo Sprint e una previsione del lavoro che dovrà essere fatto.

Il Product Owner non ha bisogno di essere presente per questa parte di Sprint Planning, in quanto spetta al team pianificare questa previsione a livello tecnico. Tuttavia, il proprietario del prodotto dovrebbe essere disponibile, anche se solo da remoto, per rispondere a qualsiasi domanda il team può avere, e per fornire qualsiasi chiarimento che potrebbe essere necessario circa la portata del lavoro. Se è prevista più di una versione durante lo Sprint, questo dovrebbe essere concordato con il PO e contabilizzato nello Sprint Backlog.

Entro la fine della pianificazione Sprint, un team dovrebbe essere sicuro di aver fatto una buona previsione del lavoro che sarà necessario per raggiungere l’obiettivo Sprint. Avrà catturato quel piano nel Backlog Sprint che la squadra possiede interamente. Il team dovrebbe essere in grado di iniziare a implementare tale piano immediatamente e con una chiara comprensione – come un Burndown Sprint – di quanto lavoro rimane in un dato momento.

Ogni giorno, ogni giorno

Una volta che il team ha pianificato il proprio Backlog Sprint, può iniziare a lavorare. Se hanno pianificato le cose come attività, collaboreranno tra loro, come una squadra, per assicurarsi che tali attività siano completate. Saranno in grado di monitorare i loro progressi utilizzando la loro scheda attività e il loro Burndown Sprint del lavoro rimanente.

Ogni membro del team sarà sicuro di mantenere la scheda attività Scrum e il Burndown Sprint aggiornati, in modo che le informazioni possono essere invocate da altri. Un radiatore di informazioni dovrebbe sempre dire la verità.

Tenere una mischia quotidiana

Ogni giorno lavorativo, allo stesso tempo, il team di sviluppo si riunirà e pianificare ciò che faranno per portarli più vicino all’obiettivo Sprint. Questo incontro si chiama Daily Scrum e non dovrebbe mai richiedere più di 15 minuti.

Solo i membri del team di sviluppo dovrebbero partecipare, poiché il piano di lavoro appartiene interamente a loro. Si tratta di un’opportunità time-boxed per ri-pianificare il Backlog Sprint a seguito di nuove scoperte e lezioni apprese durante lo Sprint. L’intera squadra dovrebbe partecipare. Ogni membro della squadra deve essere in grado di tenere conto:

• Quello che hanno fatto ieri per aiutare la squadra a soddisfare le Sprint Obiettivo
• che Cosa hanno intenzione di fare oggi per aiutare la squadra a rispettare la Sprint Obiettivo
• in caso di impedimenti che sono sempre nel loro modo

alla fine del Daily Scrum, la squadra dovrebbe avere un piano chiaro per le prossime 24 ore e una comprensione di come dovranno collaborare per il raggiungimento di esso. Dovrebbero anche avere un elenco di eventuali impedimenti che richiedono l’attenzione del Master Scrum.

Affina il Product Backlog

In Scrum, il Product Backlog Refinement non è un evento formale ma un’attività in corso: il processo di aggiunta di dettagli, ordini e stime agli elementi del Product Backlog, come le User Story. Spetta ai team di Scrum decidere quanto spesso farlo, anche se è certamente una buona idea per loro costruire raffinatezza nella loro routine quotidiana. Il perfezionamento non dovrebbe richiedere più del 10% del tempo totale di una squadra durante uno Sprint. Per la maggior parte delle squadre, mezz’ora al giorno può essere adeguata anche se alcuni potrebbero preferire trascorrere un’ora o due un paio di volte a settimana. La cosa importante è assicurarsi che il Product Backlog sia perfezionato in modo tempestivo in modo che la pianificazione Sprint possa avvenire senza impedimenti. L’intero team, incluso il proprietario del prodotto, dovrebbe partecipare.

Una sessione di perfezionamento inizia in genere con il proprietario del prodotto che presenta il backlog di prodotto corrente al team. Il backlog può essere tenuto in una serie di forme, come una scheda Scrum elettronica o altro strumento di collaborazione, o può essere semplicemente un foglio di calcolo. Un proiettore o uno schermo condiviso può essere molto utile.

Il team inizia nella parte superiore del Product Backlog e lavora verso il basso, perfezionando ogni articolo a turno. Esamineranno ciascuno di essi e ne discuteranno la portata e i criteri di accettazione che saranno necessari per il suo completamento. Ogni elemento sarà quindi stimato utilizzando una tecnica come la pianificazione Poker. Un oggetto di grandi dimensioni può essere suddiviso in quelli più piccoli che catturano maggiori dettagli. Epics possono essere scomposti in storie utente, per esempio.

Il team si ferma una volta che la casella temporale della sessione si esaurisce. Essi riprenderanno da dove avevano lasciato la prossima volta, alla fine a partire dalla parte superiore di nuovo in modo che il backlog è tenuto aggiornato.

Collabora sempre

Nella pratica agile, i membri del team non lavorano mai in isolamento – se lo facessero, non sarebbero una squadra. In realtà, il lavoro di squadra è così importante che il ruolo è Team di sviluppo piuttosto che Sviluppatore.

Ciò significa che ogni membro del team di sviluppo deve collaborare con i suoi colleghi per tutto il giorno, in quanto sono congiuntamente responsabili per lo stato di avanzamento del lavoro. Eventuali problemi o fallimenti sono di proprietà congiunta della squadra, così come i loro successi. La collaborazione non è qualcosa che è limitato ad eventi come il Daily Scrum, ma si applica a tutto ciò che il team fa durante ogni intero Sprint.

Esempi di collaborazione includono:

• Aiutare i coetanei, per completare i lavori in corso prima di portare nel nuovo lavoro da un backlog
• Coppia di programmazione, come ad esempio prendere a turno per utilizzare la tastiera e l’assistenza e il controllo di lavoro
• Peer review
• Chiedere aiuto, e di essere interessati a dare
• Andando dove il lavoro e aiutare, invece di aspettare che il lavoro per essere passati loro
• assicurarsi che tutti i lavori, infatti, soddisfano la Definizione di Fatto
• la Chiamata di una Mischia in ordine per risolvere i problemi di cui ha bisogno la squadra di attenzione immediata
• La impedimenti lo Scrum Master che così possono essere gestiti in maniera tempestiva
• l’Aggiornamento di una Mischia Attività del consiglio e burndown chart in modo che le informazioni up-to-data e può essere invocata
• le competenze e la condivisione della conoscenza

Il giorno finale: Recensione ed Retrospettiva

Tenere una Sprint Review

Se un team ha collaborato in modo efficiente, ti hanno lavorato insieme, per affrontare lo Sprint Obiettivo, della gestione di eventuali rischi e regolando i loro piani come necessario. Avranno dimostrato il controllo per tutto lo Sprint attraverso un burndown anche di lavoro rimanente, dove ogni membro ha visto come la loro responsabilità personale per aiutare a completare il lavoro in corso. Avranno un prezioso incremento da dimostrare al proprietario del prodotto e agli eventuali stakeholder invitati. Una recensione è qualcosa che una squadra dovrebbe guardare al futuro.

È anche qualcosa per cui una squadra deve prepararsi. Occorre concedere un tempo sufficiente per una dimostrazione del lavoro svolto. Le attività possono essere pianificate su un backlog Sprint per questo scopo, per assicurarsi che la revisione renda giustizia al lavoro svolto e al valore che è ora disponibile. Inoltre, se il proprietario del prodotto pensa che sarebbe una buona idea invitare le parti interessate, allora quegli inviti dovrebbero essere stati inviati. La recensione è un’opportunità per celebrare il lavoro che è stato fatto e per mostrare i loro successi, quindi la fiducia è ispirata e un investimento continuo nella squadra potrebbe essere giustificato.

Una revisione Sprint è anche un’opportunità di ispezione e adattamento. E ‘ un buon momento per il proprietario del prodotto per spiegare quanto bene il prodotto sta eseguendo, per ottenere un feedback di prima mano da eventuali parti invitate, e di trarre tutte le lezioni che potrebbero essere utilizzati per migliorare ulteriormente il Product Backlog. Se qualche lavoro non è stato completato, per qualsiasi motivo, questo sarà anche rivisto e rivalutato sul Product Backlog per una possibile pianificazione in sprint futuri.

Quindi condurre una retrospettiva Sprint

La Recensione Sprint ha esaminato il Prodotto e il valore consegnato, il lavoro che è stato fatto, e onestamente e candidamente a qualsiasi lavoro che non è stato fatto, qualunque sia la ragione.
La prossima cosa da fare è condurre una retrospettiva Sprint. Una retrospettiva considera il processo che il team sta seguendo. Stanno lavorando nel modo più efficace possibile? In genere è meglio tenere la retrospettiva subito dopo la revisione, perché la prima può introdurre idee da prendere in considerazione nella seconda.

L’intero team di sviluppo, il Product Owner e lo Scrum Master devono tutti partecipare alla Retrospettiva, perché ognuno è corresponsabile del successo del lavoro del team. E ‘ davvero importante avere una sessione libera e aperta che arriva al cuore di eventuali problemi e identifica le azioni che aiuteranno a risolverli. Una retrospettiva può iniziare con la seguente dichiarazione:

“Indipendentemente da ciò che scopriamo, comprendiamo e crediamo veramente che tutti abbiano fatto il miglior lavoro possibile, dato ciò che sapevano in quel momento, le loro abilità e abilità, le risorse disponibili e la situazione a portata di mano.”

In un” Retro”, tutti hanno una voce uguale. Un approccio, che lo Scrum Master può facilitare, è quello di identificare:

• Cose che sono andate bene
• Cose che non sono andate così bene
• Idee di miglioramento
• Grida per i membri del team che hanno fatto qualcosa di eccezionale

Stabilire una linea temporale può aiutare i ricordi dei partecipanti a fare jogging sugli eventi significativi durante lo Sprint.