Principi Lean di Scrum

Da David Starr. David Starr è un Chief Software Craftsman per Scrum.org in cui viene analizzato il miglioramento della professione dello sviluppo software. Ha inoltre fondato la community tecnica online, ElegantCode.com.

Luglio 2012

Controllare le qualità Lean intrinseche del framework scrum unitamente a diversi modi per consentire il miglioramento dei team scrum utilizzando il pensiero Lean.

Si applica a

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

Le discussioni correnti su Agile Software Development includono sempre gli strumenti Scrum, Lean e Kanban (tre strumenti per pianificare, monitorare e eseguire le attività di sviluppo software). Questi strumenti sono spesso confrontati e contrapposti da alcuni professionisti Agile che proclamano l'interoperabilità tra lo Scrum Framework e il pensiero Lean, mentre altri considerano questi strumenti come dei modi fondamentalmente differenti di realizzare software.

Panoramica

Scrum è molto diffusa; dei team che sostengono utilizzare metodi Agile di sviluppo, il 92% dichiara di utilizzare la metodologia scrum[1]. Grazie al campionamento dello Scrum corretto, molti team sembrano maturare la propria pratica oltre il framework Scrum di base. In questo articolo viene illustrata l'estensione di Scrum Framework con le tecniche Kanban e Lean, con i concetti di Kaizen o il continuo miglioramento.

Scrum

Scrum Framework, introdotto nel 1995 da Ken Schwaber e Jeff Sutherland, consente ai team di collaborare in modo iterativo e graduale nello sviluppo di software. I team scrum organizzano il lavoro negli intervalli di tempo chiamati sprint, che durano al massimo un mese, producendo un set di funzionalità complete e funzionanti in ogni sprint.

Scrum Framework è di semplice comprensione ed è diventato molto popolare tra i team di sviluppo software e i clienti. Scrum promuove tra i team funzionali e auto-organizzati che si concentrano per l'intero sprint per fornire un incremento di software funzionante e potenzialmente rilasciabile.

Scrum è codificata nella Guida Scrum, che documenta i ruoli, gli elementi e gli eventi di scrum. La guida Scrum è gestita dagli autori di Scrum ed è disponibile online sul sito Scrum.org.

Lean

Il concetto Lean è un metodo di approccio all'ottimizzazione del sistema che si concentra sulla riduzione dello spreco e sul miglioramento del flusso di valore globale tramite un sistema. Lean vanta una ricca storia nella produzione e ha acquisito popolarità nei circoli di sviluppo software in anni recenti.

Quando applicato allo sviluppo software, il pensiero Lean viene incorporato dai seguenti sette principi, pubblicati per la prima volta nel libro, Lean Software Development: An Agile Toolkit[2].

1. Eliminare lo spreco

2. Amplificazione dell'apprendimento

3. Decidere quanto più tardi è possibile

4. Consegnare il più rapidamente possibile

5. Concedere l'autorizzazione al team

6. Compila integrazione in

7. Vedere l'intero

L'applicazione di questi principi al lavoro di distribuzione del prodotto software non è uno scopo finale. Non si dice "esegue lean", ma utilizzare i principi lean per ottenere assistenza sul processo decisionale e scegliere le tecniche che miglioreranno in generale il sistema. Ad esempio, la procedura di TDD (Test-Driven Development) compila l'integrità nel software controllandolo al momento della creazione, pertanto supportando il principio snello di compilazione dell'integrità durante il processo di creazione.

Kanban

Una tecnica che ha radici nel concetto Lean è Kanban[3], che utilizza il concetto Lean in un metodo formale che si concentra su riduzione dello spreco, consegna JIT e evitare il sovraccarico di coloro che svolgono il lavoro. A differenza del metodo Scrum, il metodo Kanban non è iterativo e incrementale. Invece di basarsi sulle iterazioni, il metodo Kanban genera cinque attività principali.

1. Visualizzare il flusso di lavoro

2. Limitare lo stato di avanzamento lavoro (WIP)

3. Gestire il flusso

4. Rendere espliciti i criteri del processo

5. Migliorare modo collaborativo

I team diversi che utilizzano Kanban spesso dispongono di processi molto diversi. Il metodo Kanban è semplicemente un set di tecniche che permette di gestire un processo e successivamente di ottimizzarlo con calma. Kanban viene facilmente applicato ai processi già presenti, inclusi i processi scrum.

Scrum e Kaizen

Una volta che gli incrementi di software funzionante vengono consegnati con ogni sprint, i team scrum ricerca nuove modalità per migliorare la procedura. Il fulcro di uno scrum efficace è Kaizen, il concetto di continuo miglioramento. Healthy Scrum Teams quasi certamente utilizza molte procedure centrando la loro attenzione su Kaizen. La stima relativa, lo sviluppo con test preliminare, l'automazione della compilazione e la programmazione di coppia sono tutti strumenti e tecniche utilizzate dai team scrum.

Non solo altri strumenti, tecniche e procedure funzionano correttamente nel completamento di scrum, ma un modello di estensione scrum viene descritto e gestito su scrum.org. Questo modello di estensione alla metodologia Scrum incoraggia la partecipazione della community a documentare le procedure favorevoli alla Scrum e che funzionano correttamente con il framework. Al momento della scrittura, sono state proposte diverse estensioni in modo specifico applicano le procedure Lean all'interno di Scrum.

I vantaggi di applicare il Lean Thinking alla metodologia scrum sono innegabili. Non sorprende che professionisti scrum abbiano ottenuto prestazioni e qualità migliori applicando il concetto lean alla procedura scrum.

Vedere scrum tramite la lente lean

Scrum Framework è costituito dai seguenti ruoli, elementi ed eventi. Se non si ha familiarità con Scrum Framework, leggere la Guida Scrum prima di continuare.

Ruoli	Elementi	Eventi
Proprietario del prodotto Scrum Master Team di sviluppo	Backlog prodotto Backlog sprint Increment	Sprint Pianificazione dello sprint Scrum giornaliero Revisione dello sprint Retrospettiva dello sprint

La guida Scrum stabilisce le regole di interazione di questi componenti, ma il concetto Lean fornisce il framework per ottimizzare l'interazione dei ruoli, degli elementi e degli eventi Scrum. I team scrum selezionano un sottoinsieme di backlog del prodotto per fornire ogni sprint e concentrarsi sulla realizzazione di un incremento con qualità e funzionalità appropriate. Il concetto Lean può agevolare il flusso di lavoro durante lo sprint e ridurre lo spreco del flusso di valore globale.

Sia la metodologia Scrum che Lean cercano di mantenere alto il livello di qualità. Questo è importante per il successo del lavoro generale che viene eseguito. Per vedere un'applicazione pratica dei principi condivisi dal Lean Software Development e dalla metodologia Scrum, è sufficiente analizzare i ruoli, gli elementi e gli eventi Scrum attraverso il pensiero Lean.

Eventi

Ad eccezione dello Sprint, che è un contenitore per tutti gli altri eventi, gli eventi scrum sono semplicemente delle riunioni. Il concetto Lean considera in genere le riunioni come spreco, che deve essere eliminato diligentemente.

Ciò potrebbe far pensare che gli eventi di scrum non siano necessari. Tuttavia, ogni evento in Scrum è progettato con attenzione per eliminare altre riunioni che altrimenti si presenterebbero in modo ad hoc o di interruzione. Se ben eseguiti, gli eventi Scrum consentono di utilizzare meno riunioni e di ridurre il tempo dedicato a risolvere interruzioni non pianificate.

Ogni evento scrum è progettato per controllare e adattare un elemento. L'ispezione supporta i principi Lean dell'amplificazione dell'apprendimento e dell'inserimento dell'integrità nel processo di creazione. L'adattamento di un piano, un requisito o un'altra risorsa durante un evento scrum supporta i principi Lean di rinvio delle decisioni e di visione globale. Nella tabella seguente sono indicati gli eventi scrum e ciò che viene analizzato e adattato durante ciascuno di questi eventi.

Evento	Ispezionato	Adattato
Pulitura backlog	Backlog prodotto	Backlog prodotto
Pianificazione dello sprint	Backlog prodotto Incrementi precedenti	Obiettivo dello sprint Backlog sprint
Scrum giornaliero	Backlog sprint Lo stato di avanzamento vero l'obiettivo dello sprint	Backlog sprint Piano giornaliero
Revisione dello sprint	L'incremento più recente L'ultimo Sprint Backlog prodotto	Backlog prodotto Altri piani di lungo termine
Retrospettiva dello sprint	L'incremento più recente L'ultimo Sprint Il team scrum Procedure tecniche	Comportamenti del team scrum Procedure tecniche Procedure di gestione del lavoro utilizzate all'interno di Scrum

Elementi

Gli elementi scrum devono essere il più semplice possibile e non più semplici. I requisiti, i piani e persino il software fornito da un team Scrum sono particolarmente utili quando includono solo i dettagli necessari a eseguire il lavoro.

Backlog prodotto

In un ambiente perfetto, non sarà necessario creare requisiti oltre alla semplice conversazione tra gli utenti. Ci dovrebbe essere un'intesa implicita tra chi richiede il software e chi lo crea, senza la necessità di un'espressione intermedia della richiesta. Questa situazione è possibile con i team di pochi membri che hanno salde relazioni con i clienti, ma per i team di grandi dimensioni non è possibile. La creazione dei requisiti prima delle consegna delle funzionalità è necessaria per la pianificazione. Lean considera i requisiti come inventario, uno spreco comune secondo il concetto Lean, e pertanto un elemento da ridurre al minimo.

In scrum i requisiti vengono gestiti nel backlog del prodotto, che richiede un form o una struttura ridotta. Non esiste alcuna necessità che gli elementi di backlog del prodotto siano altamente dettagliati o espressi perfettamente.

Sebbene la gestione del backlog del prodotto e dei requisiti sia necessaria per pianificare il lavoro, l'ideale è creare e aggiornare gli elementi di backlog del prodotto appena poco prima che il team di sviluppo li utilizzi effettivamente. I team scrum efficienti evitano la creazione dei requisiti nel backlog prodotto che non si potranno mai utilizzare.

Backlog sprint

In un ambiente perfetto, non sarà necessaria una pianificazione. Un team di sviluppo può semplicemente prendere la richiesta successiva da una coda, ignorando il contesto e il costo del requisito. Sebbene questo semplice modello di elaborazione del lavoro sia molto flessibile, manca di considerare che lo sviluppo software è un impegno intrinsecamente complesso. Lo sviluppo del prodotto di complessità significativa trae vantaggio da disporre di un piano, anche se tale piano è semplice e mancano i dettagli.

La guida Scrum definisce il backlog sprint come il sottoinsieme di elementi di backlog del prodotto selezionati per uno sprint e per un piano di distribuzione. Il backlog sprint mostra un inventario (spreco) di lavoro progettato per lo sprint, che viene perfezionato almeno giornalmente. Questo perfezionamento giornaliero assicura che il piano sia sempre realistico e consente al team di sviluppo di rinviare le decisioni relative all'implementazione fino all'ultimo momento responsabile.

I team scrum sviluppano i requisiti e i piani che sono appena sufficienti, per ridurre il costo. Questo approccio Lean rivolto alla riduzione dell'inventario consente di ritardare il processo decisionale e dà al team la facoltà di organizzarsi autonomamente all'interno dello Sprint. Anziché l'attenzione sui requisiti o sul piano, i team scrum si concentrano sul valore che viene distribuito in ogni incremento.

Increment

Ogni sprint include la consegna di almeno un incremento di software funzionante. L'incremento del prodotto è l'unico elemento Scrum che non è considerato uno spreco nel lean thinking. Tuttavia, l'incremento nel prodotto può contenere degli sprechi. Lo spreco può essere presente sotto forma di funzionalità inutilizzate, difetti, funzionalità incomplete, codice di difficile gestione o progettazioni di scarsa qualità.

I team Scrum con alte prestazioni eliminano bruscamente gli sprechi nel prodotto stesso. Spesso, questa operazione viene eseguita verificando spesso gli incrementi per tutto lo sprint e mantenendo sempre alto il di qualità. Ciò realizza l'essenza stessa del principio Lean dell'integrità.

I team scrum ottengono inoltre vantaggi tenendo presenti i principi lean quando forniscono un incremento. Scrum Framework stesso assicura che l'incremento sia aperto all'esame in fase di revisione dello sprint. La ricezione di feedback sull'incremento alla revisione dello sprint è fondamentale per ampliare l'apprendimento.

Ruoli

I ruoli prescritti dalla metodologia Scrum sono accuratamente bilanciati per mettere il team scrum nelle condizioni di svolgere adeguatamente il proprio lavoro e per bilanciarne le tensioni all'interno. Gli scrum master, i team di sviluppo e i proprietari del prodotto lavorano in collaborazione per il successo del processo che richiede a tutte le persone coinvolte di considerare i punti di vista degli altri. Questa collaborazione garantisce che i membri del team scrum abbiano una visione dell'intero sistema scrum e rende trasparenti tutte le decisioni che non ottimizzerebbero il team scrum favorendo un ruolo sugli altri.

Il co-creatore scrum, Jeff Sutherland, osserva che la base di un'implementazione Lean corretta è intelligenza dal basso verso l'alto e affiancare ai lavoratori responsabili facilitatori. I team di sviluppo di scrum organizzati autonomamente includono i dipendenti autorizzati dal concetto lean in grado di introdurre una conoscenza più approfondita nell'organizzazione anziché doverla apprendere da altri.

Unico nella metodologia Scrum è il ruolo dello Scrum Master, che nella Guida Scrum viene descritto nel seguente modo:

Lo Scrum Master deve garantire la comprensione e l'applicazione dello Scrum. Gli scrum master effettuano questa operazione assicurando che il team scrum soddisfi la teoria, le procedure e le regole scrum. Lo Scrum Master è uno strumento guida per il team scrum.Guida Scrum - ottobre 2011

Una delle competenze e delle attività principali di possibili lo scrum master è la semplificazione. Nella maggior parte dei casi, gli Scrum Master facilitano gli eventi scrum. Gli scrum master sono i manager, nonostante l'adozione di scrum e di conformità, non le persone.

Verso un scrum più snello

L'utilizzo del pensiero Lean per valutare e risolvere i problemi esposti dalla metodologia Scrum produce spesso ottimi risultati ed è un valido modo di sostenere la cultura Kaizen. I team scrum stanno ancora apprendendo come applicare lean alla metodologia scrum, ma molte procedure diventano sempre più diffuse in quanto hanno dimostrato di rendere i team scrum ancora più efficienti.

Esistono molte procedure e tecniche di uso comune utilizzate per creare la consapevolezza nel lavoro che supportano direttamente i principi Lean. Alcune di queste tecniche sono descritte di seguito con una particolare attenzione su come possono essere eseguite in un team scrum.

Il seguente elenco di tecniche non è certamente completo. Indica semplicemente degli esempi di come i team Scrum possono migliorare utilizzando le tecniche comuni dei sostenitori del Lean Software Development. Inoltre, ciascuna tecnica può essere applicata in modi diversi. Solo alcune tecniche Lean sono descritte qui. I team scrum possono raggiungere i seguenti scenari in modo diverso rispetto da quanto descritto in questo documento.

Eliminazione degli sprechi

Forse la procedura lean più semplice consiste nell'eliminazione dello spreco. Lean considera spreco qualsiasi cosa non strettamente necessaria per produrre il risultato desiderato. Gli sprechi comuni nello sviluppo del software includono:

1. Codice o funzionalità inutilizzate

2. Difetti che hanno portato alla rielaborazione

3. Ritardi o tempo trascorso in attesa di qualcosa

4. Consegne da una persona, un team, o un processo aziendale a un altro

5. Requisiti dettagliati

6. Requisiti insufficienti

7. Comunicazione lenta o carente

Alcuni sprechi non possono essere semplicemente evitati e sono addirittura necessari. Nella definizione più stretta, ad esempio, i documenti dei requisiti sono considerati come spreco. Una scheda che rappresenta un requisito non viene consegnata al client, dopo tutto. Pertanto la scheda è inutile. La scheda non è di per sé la funzionalità del prodotto; rappresenta il lavoro da eseguire per creare la funzionalità. La scheda dei requisiti consente agli sviluppatori di riflettere sul proprio lavoro e di tenerne traccia. Sebbene la maggior parte dei team consideri questa pratica necessaria, può essere facilmente considerata un spreco.

Sebbene un po' di spreco sia necessario, può comunque essere ridotto, ottimizzato o rimosso in gran parte. Alcuni sprechi nel flusso di valori dello sviluppo software, come attendere troppo tempo per archiviare il codice, possono essere facilmente riconosciuti ed eliminati. Altro spreco trovato nei team di sviluppo software, come la creazione di documenti dei requisiti di grandi dimensioni prima che possa iniziare lo sviluppo, è insito nella cultura e richiede tempo e impegno significativi per un cambiamento radicale.

Scenario

Scrum è presente da sei mesi. I team di sviluppo stanno creando incrementi funzionanti di software con Sprint bisettimanali e tutti gli indicatori di qualità misurata con tendenza positiva.

Approccio lean

Gli Scrum Master si incontrano per discutere della preparazione dei rispettivi team al raggiungimento di una produttività e una qualità più elevate. Uno scrum master suggerisce di eliminare gli sprechi come stabilito nel concetto Lean. Supponendo di provare l'idea, gli scrum master cercano gli esempi di spreco e li suddividono in categorie in due elenchi (quelli che possono essere eliminati immediatamente e quelle che richiedono del tempo per la gestione).

Il primo elenco contiene gli sprechi che gli scrum master stessi o i team di sviluppo devono eliminare e non richiede alcun tipo di autorizzazione o di attesa. L'altro è contrassegnato come "backlog residuo" e identifica lo spreco che tutti riconoscono ma che richiede molto tempo e un impegno significativo per essere cambiato. Gli esempi di due elenchi sono indicati di seguito:

Gestione immediata

Backlog residuo

Alcune compilazioni vengono eseguite manualmente in un computer di compilazione che deve essere gestito in particolare a questo scopo. Il pacchetto per siti Web è un processo di compressione manuale (ZIP). Automatizza. Gli sviluppatori stanno tutti utilizzando un database di sviluppo condiviso e le modifiche ai interrompono spesso il flusso di sviluppo. Spostarsi su un modello in cui ogni sviluppatore ha un database dedicato di sviluppo. I test non vengono scritti finché una funzionalità non esiste. Incoraggiare e insegnare le procedure con test preliminare per gli specialisti del test.

Modelli UML creati prima di codificare tutte le funzionalità. La comunicazione impedita dal layout di ufficio che richiede ai membri dello stesso team di sviluppo di passare tra gli uffici per piccole discussioni ad hoc. Inserire i programmi di installazione ove possibile in modo che le operazioni di distribuzione non siano manuali. Molti campi nel rapporto di rilevamento di bug sono obbligatori e raramente utilizzati. Il tempo speso per creare i dati per questi campi può essere risparmiato rendendoli facoltativi.

Con questi elenchi, lo scrum master si avvicina ai rispettivi team scrum con suggerimenti fattibili che ottenere miglioramenti immediati. Sebbene lo Scrum Master è responsabile della formazione dei team a livelli più alti di qualità, la natura auto-organizzata dei team scrum richiede a questi di stimare le modifiche e di creare un piano per metterle in atto.

La retrospettiva di sprint è un forum dedicato alla condivisione di idee per il miglioramento e al supporto per applicarle. Le analisi retrospettive efficaci di sprint generano spesso i piani per mettere in atto dei miglioramenti che supportano una cultura Kaizen. L'eliminazione o il miglioramento degli sprechi tracciati nel backlog potrebbe richiedere del lavoro all'esterno del team scrum. Questa attività è responsabilità dello scrum master, il cui il lavoro comporta migliorare l'utilizzo di Scrum e sostenere l'agilità in tutta l'organizzazione.

Limitazione dello stato di avanzamento lavoro (WIP)

Scenario

Un team di sviluppo con cinque membri sta utilizzando scrum da 12 settimane e ha completato gli Sprint della terza e della quarta settimana con risultati misti. Sebbene gli incrementi prodotti abbiano una qualità più alta del software creato prima della distribuzione Scrum, sembra che il lavoro svolto sia minore e che i membri del team di sviluppo non lavorino ancora in collaborazione. Scrum giornaliero fornisce un promemoria giornaliera che ogni persona il team sta lavorando in isolamento sulle proprie attività, sebbene la situazione non sia aggiornare.

Durante la pianificazione dello sprint, il team di sviluppo crea un elenco di cose da fare per il lavoro necessario per la consegna di ogni elemento del backlog prodotto selezionato per lo sprint. Questa tecnica genera un backlog dello sprint durante la pianificazione dello Sprint e un meccanismo per tenere traccia dello stato di avanzamento del team di sviluppo durante lo Sprint.

Il team di sviluppo utilizza un'area attività visibile sulla parete della propria area di lavoro per tenere traccia dello stato di avanzamento nello Sprint. Durante l'ultimo sprint, lo scrum master ha fatto delle foto ogni giorno prima dello scrum giornaliero. Di seguito ne sono riportate alcune foto.

Giorno 1	Giorno 4
Giorno 9	Giorno 14
Giorno 17	Giorno 20

Lo Scrum Master ha condiviso queste foto con il team di sviluppo. Alcuni aspetti sono facilmente evidenti, ad esempio:

• Sono regolarmente in corso più attività di quanti sono i membri del team di sviluppo.

• Il giorno due, uno sviluppatore ha estratto tutte le attività per la funzionalità C in stato "in corso" e li ha lasciate per la durata dello sprint.

• La funzionalità B non è stata elaborata fino alla fine dello sprint e non è stata completata.

• La funzionalità C è stata elaborata nello sprint ma non è stata completata. Lo sviluppatore che opera sulla funzione C è stato frustrato dalla mancanza della guida quando i problemi esterni vengono sorto. Nonostante l'accenno alla necessità di avere un aiuto durante lo scrum giornaliero, non si è mai materializzato perché gli altri membri del team erano concentrati sul proprio lavoro e non si sono sentiti responsabili per la funzionalità C.

• Le funzionalità sono state inserite nel backlog sprint in ordine di priorità durante la pianificazione dello sprint e il proprietario del prodotto è estremamente deluso dal fatto che la funzionalità B non è stata completata nello sprint, poiché è stato ordinata più in alto rispetto alle altre funzionalità fornite.

• Diverse funzionalità sono in corso immediatamente, causando la modifica contemporanea di parti molto diverse del codice. Durante lo sprint, questo ha portato a diversi errori e rielaborazioni della compilazione poiché gli sviluppatori hanno inavvertitamente influenzato il codice degli altri.

Tutti questi commenti punteranno alla pratica del team di sviluppo di lavorare su molte cose contemporaneamente. Alternare l'attenzione tra attività e riprovare a concentrarsi su molti elementi contemporaneamente ha comportato per i membri del team di sviluppo una sensazione di essere sovraccarichi e oberati dal lavoro nel backlog dello sprint. Di conseguenza, ogni membro del team è incentrato sul proprio lavoro e ha agito come utente singolo anziché come membro di un team.

Approccio lean

Durante la retrospettiva dello sprint, lo scrum master ha illustrato il concetto di limitazione di WIP al team di sviluppo che ha deciso di provare la tecnica. Il team di sviluppo ha deciso di implementare tre nuove regole progettato per ridurre WIP nello sprint successivo:

1. Le funzionalità nel backlog sprint vengono implementate dall'alto verso il basso.

2. Non più di 3 elementi possono essere in esecuzione contemporaneamente. Se ne viene inserito un quarto, il team si interromperà per determinare il motivo per cui nel sistema si verifica un collo di bottiglia.

Lo Scrum Master ha scattato fotografie anche durante il successivo Sprint. Numerose fotografie sono rappresentate di seguito.

Giorno 2	Giorno 8
Giorno 12	Giorno 20

Durante la retrospettiva dello sprint, le foto sono state condivise di nuovo con il team di sviluppo che ha fatto i seguenti commenti su come le cose sono cambiate per loro nell'ultimo sprint:

1. I membri del team di sviluppo hanno lavorato insieme su elementi più complessi. Sebbene le opinioni su come lavorare siano diverse, le differenze sono state risolte e il team ha fatto, in generale, molti progressi.

2. I membri del team di sviluppo hanno iniziato a imparare la funzionalità del prodotto a cui non hanno in precedenza fatto attenzione. Ognuno ha riportato un sentimento di appartenenza collettiva all'intero prodotto. Ciò ha creato un forte sollievo rispetto alle procedure precedenti in cui gli individui si concentravano solo sulle funzionalità che capivano.

3. La complessità di coordinare le modifiche in molte aree diverse di codice immediatamente è stata notevolmente ridotta. In effetti, la produttività del team di sviluppo ne risulta aumentata notevolmente.

4. Sebbene la funzionalità E non è stata completata nello Sprint, tutte le funzionalità eseguite avevano con una priorità più alta rispetto alla funzionalità E. Il proprietario del prodotto era contentissimo e decisivo a fornire l'incremento al cliente anche senza questa funzionalità di bassa priorità.

Sebbene la creazione di un backlog Sprint durante la pianificazione Sprint limiti le dimensioni del batch del lavoro selezionato per lo Sprint, un'ulteriore limitazione del WIP nello Sprint può determinare un aumento della velocità effettiva e una maggiore produttività. La limitazione dello stato di avanzamento lavoro durante lo sprint aumenta anche la collaborazione e riduce il rischio di disporre di specialisti tecnici il cui lavoro non è compreso da altri.

Ridurre i tempi di attesa

È trascorso molto tempo in attesa che si verifichino le cose nello sviluppo software. Questa forma di spreco viene riscontrata facilmente nella maggior parte dei team di sviluppo. I nuovi team scrum si trovano in attesa di numerosi elementi durante lo sprint, tra cui:

• Autorizzazioni per eseguire un'operazione

• Un processo lungo da completare

• Una consegna da un altro team o un utente

• Test da eseguire o convalida da completare

• Accesso a una risorsa necessaria

• Cooperazione di una persona all'esterno del team

Peggio delle inefficienze dell'attesa dei team scrum è il tempo che i clienti e le aziende trascorrono ad attendere che il software sia integrato, confezionato e consegnato. Questo problema cresce con la dimensione dell'organizzazione dello sviluppo. Quando al progetto vengono aggiunti più sviluppatori o team, il costo dell'integrazione del lavoro in un singolo prodotto aumenta.

Il tempo massimo di attesa incorporato in Scrum è lo Sprint. Essendo il contenitore per tutti gli eventi scrum, l'unico requisito della durata dello sprint è che sia al massimo un mese. Ciò limita il tempo di attesa di un incremento di software funzionante a non più di un mese. La maggior parte dei team scrum fornisce incrementi funzionanti anche più spesso.

Scenario

Una società ha sei team scrum in esecuzione su un prodotto software ampio e complesso. Ogni team scrum è incentrato su un'area funzionale specifica e il suo lavoro viene coordinato tramite un backlog prodotto principale. Gli sprint durano tre settimane e includono l'integrazione di lavoro di tutti i team di sviluppo.

In passato, gli sprint duravano due settimane, ma siccome il prodotto è stato sviluppato è aumentata anche la complessità di crearlo. Sono stati aggiunti nuovi team scrum che richiedevano più tempo per integrare il lavoro, quindi la lunghezza degli sprint è stata aumentata per supportare le attività di integrazione.

La terza settimana è nota come la Settimana di integrazione. Integrazione di nuove funzionalità nella riga di codice principale è l'attività principale in questo periodo. Viene stabilito un team di integrazione ogni settimana di integrazione con rappresentanti di ogni team di sviluppo. Dirigono il lavoro di integrazione.

Il team di integrazione non accetta l'introduzione di nuove funzionalità durante la settimana dedicata all'integrazione, tuttavia può richiedere alcune piccole modifiche per risolvere problemi di integrazione. Ciò comporta una serie di modifiche al codice ad hoc durante la settimana di integrazione in risposta alle esigenze del team di integrazione.

Nell'immagine seguente viene illustrata la gestione della configurazione tipica durante uno Sprint. I team di sviluppo creano le proprie diramazioni di sviluppo all'inizio di ogni sprint. Uniscono i propri codici alla fine della settimana 2. Durante la terza settimana, i team di sviluppo facilitano le esigenze del team di integrazione in base alle necessità.

Sebbene l'integrazione durante lo Sprint sia necessaria, un terzo della capacità di sei team scrum viene al momento utilizzato per eseguire l'integrazione. Durante questo intervallo, la maggior parte della capacità dei team viene utilizzata in attività al di fuori dello sprint. Si noti che nell'esempio precedente il team 5 non ha alcun lavoro durante la settimana di integrazione.

L'aumento del costo di Settimana di integrazione comporta l'interruzione del flusso nei team scrum che devono passare spesso da un contesto all'altro. Alcuni team creano privatamente righe di codice di branching e forking nel tentativo di rimanere produttivi per tutta la settimana, aumentando la complessità globale e sovvertendo la trasparenza necessaria per assumere decisioni accurate.

Approccio lean

Gli Scrum Master dei team si incontrano per discutere delle opzioni. Una metodologia scrum master collega il team ha esito positivo in gran parte della limitazione di WIP nelle prime due settimane di ogni sprint. Gli Scrum Master osservano che se ogni team limita il WIP una funzionalità alla volta, potrebbe potenzialmente integrare il proprio lavoro al completamento di ogni funzionalità.

Se questa procedura fosse stata utilizzata in tutti i team di sviluppo, nessun team avrebbe dovuto attendere fino alla fine della seconda settimana per integrare il proprio lavoro. Anziché aspettare di integrare le nuove funzionalità, ogni team può ora considerare l'integrazione nella parte della riga di codice principale della definizione di Done1 per ogni funzionalità utilizzata.

La definizione di risultato è un concetto in scrum in cui i team di sviluppo AES su cosa deve essere true per ogni elemento di backlog del prodotto selezionato per lo sprint per considerare tale elemento di backlog del prodotto “a„. Per ulteriori informazioni sulla definizione di eseguito, vedere l'articolo MSDN Operazioni completate e non completate.

Durante le retrospettive dello sprint successivo, i team di sviluppo si sono accordati a provare a integrare il proprio lavoro al completamento di ogni funzionalità. Stabiliscono e adottano le seguenti nuove regole:

1. Ogni team di sviluppo limita WIP a una funzionalità alla volta.

2. Una funzionalità non è completa fino a che non è integrata nella riga di codice principale.

3. Prima di iniziare a lavorare su una nuova funzionalità, i team di sviluppo aggiorneranno le righe di codice con una copia aggiornata della riga principale.

L'attività risultante è rappresentata nell'immagine che segue:

Le nuove regole hanno semplificato il flusso di produzione di funzionalità. Ai team di sviluppo non viene più richiesto di fare lunghe pause durante la terza settimana dello sprint poiché non esiste la settimana di integrazione.

Il tempo impiegato per integrare modifiche durante lo Sprint è inizialmente superiore ma, man mano che ciascun team di sviluppo acquisisce familiarità con il modello di integrazione continua, la produttività aumenta. Nel tempo le funzionalità aggiunte per sprint aumentano.

Poiché l'esecuzione con una funzionalità significa che tale funzionalità è integrata nella riga di codice principale, non c'è più alcuna domanda relativa all'esecuzione effettiva della funzionalità. Ora la definizione di risultato include l'integrazione al codice principale per ogni singola funzionalità. Il rischio di errori di integrazione è diminuito in modo significativo.

Infine, la decisione di ridurre il tempo che un team di sviluppo deve attendere per integrare il codice ha aumentato la produttività globale dei team di sviluppo e ha reso obsoleta la necessità di una settimana di integrazione. Pertanto i team scrum possono tornare a Sprint più brevi, consentendo al proprietario del prodotto di offrire il prodotto più spesso del normale.

Rinvio di un impegno

Il rinvio di un impegno è uno dei principi snelli originali espressi come valore di Lean Software Development. Questo principio è spesso descritto come "attesa fino all'ultimo momento responsabile" per prendere una decisione.

Concettualmente, ha ben poco valore prendere una decisione che spingere a un'azione prematura. Perché non attendere il più possibile a prendere la decisione in modo da ottenere più informazioni possibili sul problema? In questo modo il rischio di decisioni errate viene limitato e c'è tempo per valutare ulteriori opzioni o percorsi di azione.

Scenario

Durante la pianificazione dello sprint, il team di sviluppo crea piani dettagliati per come implementare i PBI selezionati per lo sprint. Spesso, il piano cambia durante lo sprint mentre si apprendono ulteriori informazioni. Il team nota che quando il lavoro è meno chiaro, il piano subisce sempre più cambiamenti. Sapendo che i requisiti sono inutilizzati sono uno spreco, il team vorrebbe evitare la rielaborazione della pianificazione.

L'esecuzione del commit a un'operazioni da eseguire richiede la rimozione delle altre opzioni. Questo spinge spesso coloro che sono consci dell'impegno a scartare delle idee. Possono esistere diversi modi per implementare una funzionalità specifica ma nel momento in cui è già stato scelto l'approccio da seguire, gli sviluppatori potrebbero smettere di considerare altri metodi per affrontare un problema, con la conseguente diminuzione del potenziale di innovazione.

Approccio lean

Il team di sviluppo decide di consentire più grandi e meno elementi definiti nel backlog dello sprint. Infatti, decidono che un Elemento backlog prodotto può essere accettato nello sprint senza alcun programma dettagliato.

Il team di sviluppo attende ora per creare un secondo momento il programma quando più dettagliato è noto. Per questi, ciò significa suddividere il grande elemento Backlog sprint in sezioni più piccole quando il lavoro è effettivamente iniziato o in esecuzione. La pianificazione dettagliata viene così posticipata fino a quando non è effettivamente necessaria e ciò consente al team di cambiare opinione sull'implementazione quando si trova più vicino al momento di lavoro effettivo. Assicura inoltre l'utilizzo del il piano migliore invece di eseguire un piano che potrebbe non essere più valido.

Ciò comporta una migliore comprensione delle opzioni di implementazione nel momento in cui occorre implementare la funzionalità. Il team di sviluppo ha come ulteriori informazioni sul prodotto nel corso del tempo che implementi le funzionalità precedenti nello sprint e concesso il tempo per l'analisi se necessario.

Visualizzazione del flusso di lavoro

Il primo passaggio nel metodo Kanban richiede la visualizzazione del flusso di lavoro effettivo utilizzato da un team. Questo realizza il principio Lean del "vedere l'insieme" e richiede che sia mostrato il flusso di lavoro effettivo, non una versione idealizzata prescritta da un documento di processo aziendale o un altro modello pre-esistente. Una visualizzazione utile rappresenta cosa effettivamente si verifica.

Una volta che esiste la visualizzazione del lavoro, è possibile tenerne traccia al suo interno. Un modello di esempio di un tipico processo di sviluppo gestito dalle fasi o Waterfall viene di seguito riportato con diverse funzionalità in corso.

I team scrum utilizzano la visualizzazione del flusso di lavoro da anni per visualizzare il lavoro dello sprint. La forma più comune di visualizzazione del flusso di lavoro nei team di sviluppo Scrum è l'"area attività" Scrum o semplicemente l'"area Scrum". Questa visualizzazione è in genere più semplice del modello illustrato in precedenza e può risultare simile al seguente modello.

Questo modo tipico di visualizzare il flusso di lavoro è fortemente influenzato dalla prescrizione Scrum dei team di sviluppo interfunzionali. L'attenzione sul team di sviluppo interfunzionale è una caratteristica di definizione del framework scrum. Un team interfunzionale dispone di tutte le competenze necessarie per fornire un incremento completo del software funzionante in ogni Sprint. I membri del team eseguono molte attività di sviluppo di software contemporaneamente.

I team interfunzionali possono fare un po' di tutto contemporaneamente poiché implementano una funzione insieme. È molto diverso dal modello basato sul piano in cui gli specialisti si concentrano sull'eseguire tutto ciò che riguarda un'attività contemporaneamente. Inoltre, i membri dei team interfunzionali possono avere specializzazioni, ma tutti i membri del team lavorano regolarmente a tutte le attività necessarie per la distribuzione del software, indipendentemente dal fatto che le attività siano all'interno dell'area di specializzazione del singolo. I team di sviluppo software interfunzionali tendono a superare le prestazioni dei team di specialisti dedicati.

Scenario

Un team di sviluppo sta consegnando gli incrementi del software di lavoro ma i membri del team non stanno collaborando correttamente. I codificatori agiscono sui problemi isolati prima di passare il codice ai tester che devono velocizzare la convalida alla fine dello sprint.

Ne risulta che il testing alla fine dello sprint è limitato dalla mancanza di tempo, così il team di sviluppo salta questa fase e distribuisce l'incremento con i test di regressione incompleti. Sono stati rilevati errori nella produzione. Questi sarebbero stati rilevati prima se fosse stato consentito il completamento del test di regressione funzionale.

Approccio lean

Lo Scrum Master collabora con il team di sviluppo per modellare il flusso di lavoro corrente all'interno di ogni Sprint. Anche se il team utilizza una scheda tipica scrum nello scrum giornaliero, diventa evidente che il flusso di lavoro effettivo è un processo gestito dalle fasi. Il team genera il seguente modello per riflettere il flusso di lavoro effettivo:

Lo Scrum Master consente al team di capire l'aumento potenziale nella produttività ottenuto mediante un lavoro interfunzionale. I membri del team acconsentano a provare a migliorare il flusso di lavoro affinché sia più interfunzionale, sebbene sia un'operazione dubbia.

Il team di sviluppo consente la visualizzazione invariata e lo utilizza per monitorare il lavoro nello sprint, ma si desidera trovare ogni possibile comprimere le fasi. Ovvero il team ricerca le possibilità in cui due fasi possono essere combinati in una, quindi sostituire un handoff con la collaborazione. Il team agisce poco per volta modificando deliberatamente il modo in cui gli individui all'interno del team di sviluppo collaborano. A ogni analisi retrospettiva sprint viene esaminato il modello in modo da riflettere i miglioramenti apportati dal team.

Innanzitutto, Arnie e Kyle sono d'accordo a collaborare all'unione delle fasi di progettazione e codifica. Provano diverse tecniche per migliorare la collaborazione e presto scoprono che il flusso di lavoro ha subito dei cambiamenti:

Il team di sviluppo impara presto a creare test di regressione funzionali non superati prima di distribuire il codice, con le seguenti modifiche:

Durante i mesi prossimi, il team di sviluppo cerca opportunità di ridurre il numero delle fasi della pipeline di consegna. La cultura del team effettivamente cambia via via che gli specialisti condividono le conoscenze e ognuno interviene per consentire un flusso più agevole del lavoro tramite il team. I membri del team iniziano a considerasi "non specializzati in fase di specializzazione" via via che la collaborazione procede.

La collaborazione in team aumenta, insieme alla consapevolezza collettiva sul software che si sta creando e sulle informazioni dettagliate sui membri del team nelle rispettive responsabilità. Questa collaborazione naturalmente comprime le fasi di lavoro durante lo Sprint e si riflette in una visualizzazione più semplice del flusso di lavoro all'interno dello Sprint. Il team di sviluppo è interfunzionale e visualizza il relativo effettivo flusso di lavoro di conseguenza come indicato di seguito.

La riflessione iterativa del team sull'eliminazione delle fasi del processo che è risultata nel flusso di lavoro Scrum suggerisce per prima cosa un'unica fase di sviluppo di Attività in corso. In questo modo viene mostrato come una bacheca kanban ottimizzata si presenta in ultima analisi come una scheda Scrum tradizionale.

Integrità di compilazione in

Molte tecniche di padronanza del software si concentrano sulla compilazione dell'integrità nel processo di creazione. Modelli di progettazione software, tecniche di sviluppo con test preliminare, refactoring e programmazione di coppia sono tutti mirati a migliorare la qualità del software al momento della creazione. L'utilizzo delle tecniche che consentono di migliorare la qualità nelle prime fasi del processo di creazione assicura che i team non si affidino a controlli di qualità tardivi per verificare la qualità in un secondo momento.

Scenario

Un team di sviluppo ha sperimentato le prime tecniche di sviluppo con test preliminare e sta utilizzando correttamente l'espressione Given/When/Then dei criteri di accettazione in unit test creati dagli sviluppatori durante lo sviluppo.

Formato criteri di accettazione Given/When/Then
Una volta specificato <un determinato contesto iniziale> Quando <si verifica un'azione> Quindi <risultato>

Il team dispone di gruppi di test unit di buon livello e comprensibili a cui si affidano gli sviluppatori come guida nella progettazione e per testare il codice frequentemente con una struttura di test automatizzati.

Sebbene questo approccio funzioni a livello di unit test, gli specialisti del test nel team di sviluppo utilizzano ancora i documenti di Microsoft Word per creare criteri di accettazione per eseguire test funzionali. Vengono convalidati manualmente dopo che le funzionalità sono state codificate e completate. Poiché questi test non vengono eseguiti fino a che i codificatori non ritengono che una funzionalità è completata, viene trovato un numero significativo di difetti dagli specialisti del test. Ciò causa la necessità di ripetere dei lavori all'interno dello Sprint e talvolta porta ad avere funzionalità che non sono completate prima della fase della revisione dello Sprint.

Approccio lean

Durante la discussione sul flusso di lavoro dei criteri di accettazione nella fase di Retrospettiva dello sprint, il team di sviluppo decide di eseguire le operazioni seguenti:

1. Gli specialisti di testing creeranno i criteri di accettazione non come documenti di Microsoft Word, ma come test automatizzati non superati privi di implementazione interna.

2. I nuovi test automatizzati verranno eseguiti quotidianamente alle 5.00 e alle 15.00 e genereranno un rapporto sugli esiti e sugli errori riscontrati. I nuovi test creati non riescono mai.

3. Quando i codificatori selezionano una nuova funzionalità su cui lavorare, iniziano implementando la funzionalità di test di accettazione sottoposto a stub.

4. Il test può essere perfezionato dal codificatore, ma in collaborazione con lo specialista di testing che lo ha creato, in modo che ne venga mantenuto lo scopo originale.

5. La funzionalità non è completa fino al superamento del test.

6. Tutti i test devono riuscire alla fine dello Sprint.

Dopo un paio di Sprint in cui si è utilizzata questa tecnica, gli errori e le rielaborazioni sono diminuiti. Il team di sviluppo esamina il rapporto aggiornato da esecuzioni di test due volte al giorno automatizzare ed eseguire che il passo e test non superati possono essere visualizzati come tendenza. Il team crea un rapporto che viene aggiornato con ogni esecuzione dei test automatizzati. Il report mostra gli esiti positivi e negativi dei test di accettazione con la tendenza nel corso dello sprint bisettimanale. Di seguito viene riportato il grafico.

Il team di sviluppo si individua trova più valore in rivedere il rapporto la loro scrum giornaliero che il grafico burn-down tipico. Lo Scrum Master conferma che questo nuovo grafico può fungere da parte fondamentale del backlog sprint.

La guida Scrum specifica che backlog sprint è il set di elementi di backlog del prodotto selezionati per lo sprint, più un piano di distribuzione. Per il team di sviluppo, il piano viene costruito dai test di accettazione non superati e lo stato di avanzamento verso il completamento viene tracciato grazie al numero di test superati e non superati. Così come con l'utilizzo di attività nel backlog sprint, è possibile aggiungere, eliminare o correggere i test nello sprint. La creazione di un test specifico determina spesso l'implementazione della funzionalità corrispondente per alcuni giorni alcuni giorni.

L'utilizzo dei test automatizzati a questo punto sia come requisiti che come meccanismo di regressione funzionale indica che i test sono i requisiti. Ciò consente inoltre di vedere il lavoro dello Sprint come una progressione nella creazione di una sessione di test automatizzati. La tecnica di sviluppo con test preliminari ha ridefinito il modo di utilizzare lo Scrum da parte del team e ha portato all'inserimento nel processo di creazione stesso la convalida dei requisiti, facendo così dell'integrità parte del prodotto.

Molti aspetti dei principi estremamente comuni di Scrum Framework supportano i principi Lean. Crescendo e migliorando, i team scrum si rendono conto che il Lean Thinking è uno strumento efficace per trovare più valore nello sviluppo iterativo e incrementale.

Le tecniche specifiche possono cambiare nel tempo, ma l'attenzione costante al miglioramento è fondamentale per mantenere l'integrità dei team di sviluppo software. Scrum Framework è sufficientemente flessibile da accogliere i metodi di miglioramento Lean come quelli presenti in Kanban. Considerare lo Scrum dal punto di vista del pensiero Lean porta spesso a ottenere una qualità e una produttività superiori, con un minore spreco.

L'ottimizzazione volontaria di un'implementazione di un team di scrum può essere fuorviante. Nella ricerca dei modi per migliorare, è importante cercare sempre la perfezione. La perfezione di scrum è molto meno importante della consegna di software funzionante di alta qualità che è apprezzato dai clienti, quindi concentrarsi innanzitutto sulle operazioni che effettivamente migliorano il prodotto.

Riferimenti

1. West, D. (2011). XXXXX. Forrester Research

2. Poppendieck, M. P. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.

3. Anderson, D. (2010). Kanban - Successful Evolutionary Change for your Technology Business. Premere il foro blu.