Il progetto di gestione del progetto Parte 1: un confronto completo tra Agile, Scrum, Kanban e Lean

Panoramica

Molte metodologie sono utilizzate oggi nello sviluppo di software. Potresti aver sentito parole d'ordine come Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, ecc.

In questo articolo, definirò questi termini, discuterò come sono correlati tra loro e come differiscono l'uno dall'altro. Molte delle suddette parole d'ordine si basano sui concetti della Lean Manufacturing, originariamente basata sul Toyota Manufacturing System (TPS), quindi ne parleremo prima.

Metodologia snella

Origini della produzione snella e snella

Il termine "Lean" ha le sue origini nella produzione, dove è stato coniato per descrivere un modello di produzione basato sul Toyota Production System (TPS) originariamente sviluppato da Sakichi Toyoda, Kiichiro Toyoda e Taiichi Ohno che furono originariamente ispirati da Henry Ford. TPS era focalizzata sulla filosofia della "completa eliminazione di tutti i rifiuti" e ha rivoluzionato la produzione negli anni '50 e '70. TPS divenne noto come "Lean Manufacturing" nel 1990 quando fu pubblicato "The Machine That Changed the World".

TPS ha identificato tre grandi tipi di rifiuti in Toyota:

• Muda: tradotto come "rifiuto". C'erano sette tipi di muda identificati alla Toyota e un ottavo è stato successivamente aggiunto. Questi sono:
  • Difetti: sforzo necessario per trovare e riparare i difetti
  • Sovraproduzione: produzione prima della domanda
  • Attesa: attesa del passaggio successivo della produzione, interruzioni, ecc.
  • Talento non utilizzato: capacità di sottoutilizzo, formazione inadeguata, ecc
  • Trasporto: parti mobili o prodotti non necessari alla lavorazione
  • Rimanenze: rimanenze finite e lavori in corso
  • Movimento: muoversi o camminare più di quanto è necessario per l'elaborazione

  • Elaborazione in eccesso: da strumenti scadenti o design del prodotto

• Muri: tradotto come "sovraccarico". Muri di solito deriva da mura ma può derivare da muda. Muri si manifesta in guasti, assenteismo, problemi di sicurezza, ecc.
• Mura: tradotto come "irregolarità". Mura può essere trovato nella fluttuazione della domanda dei clienti, nei tempi di processo per prodotto o nella variazione dei tempi di ciclo per diversi operatori. Quando mura non si riduce, si aumenta la possibilità di muri e, quindi, muda. Le mura possono essere ridotte creando apertura nella catena di approvvigionamento, modificando il design del prodotto e creando un lavoro standard per tutti gli operatori.

TPS ha lavorato per eliminare gli sprechi applicando questi due concetti fondamentali:

• Jidoka: tradotto liberamente come "automazione con un tocco umano" stabilisce che "la qualità deve essere incorporata durante il processo di produzione!" ciò significa che quando si verifica un problema, l'apparecchiatura si ferma immediatamente, impedendo la produzione di prodotti difettosi.
• Just-in-Time: fare solo "ciò che è necessario, quando è necessario e nella quantità necessaria".

Con l'evoluzione del TPS, questi pilastri e valori fondamentali si sono basati sui concetti di Jidoka e JIT e sono diventati radicati:

• Miglioramento continuo:
  • Sfida: formare una visione a lungo termine e affrontare le sfide con coraggio e creatività per realizzare i sogni
  • Kaizen: migliorare continuamente le operazioni aziendali, guidando sempre verso l'innovazione e l'evoluzione, eliminando un muda alla volta
  • Genchi Genbutsu: praticare genchi genbutsu, andare alla fonte per trovare i fatti per prendere decisioni corrette, costruire consenso e raggiungere obiettivi alla nostra migliore velocità
• Rispetto per le persone:
  • Rispetto: rispettare gli altri e fare ogni sforzo per capirsi, assumersi la responsabilità e fare del nostro meglio per costruire la fiducia reciproca
  • Lavoro di squadra: stimolare la crescita personale e professionale, condividere opportunità di sviluppo e massimizzare le prestazioni individuali e di squadra
• Andon: un indicatore visivo di stato o problema
• Heijunka: significa livellamento o livellamento della produzione
• Hansei: significa autoriflessione. Per migliorare l'efficienza, i lavoratori dovrebbero sfidare le ipotesi alla base dei processi attuali per trovarne di migliori.
• Kanban: un'insegna utilizzata come strumento visivo per il controllo della produzione
• Poka-yoke: indicato anche come a prova di errore o a prova di errore
• Sistema di estrazione: il materiale viene trascinato in una postazione di lavoro proprio quando è necessario
• Seiri: è il principio che rispecchia lo spreco. Seiri impone che ciò che non è necessario dovrebbe essere rimosso. Questo comprende tutti i sette rifiuti originali di TPS
• Standardizzazione: organizza tutti i lavori attorno al movimento umano e crea una sequenza di produzione efficiente senza muda. Questo aiuta a portare alla qualità, a un ritmo costante e consente un miglioramento continuo.

Il diagramma seguente mostra come i concetti fondamentali ei valori fondamentali sono correlati tra loro.

Gestione snella

Il Toyota Product System e il Lean Manufacturing si sono evoluti nel tempo e sono stati applicati in una serie di aree, inclusa la gestione.

Il Lean Management ha applicato i valori fondamentali del miglioramento continuo e del rispetto per le persone e li ha distillati in una serie di cinque principi Lean prescrittivi che sarebbero stati ripetuti più volte per migliorare ed eliminare continuamente gli sprechi:

1. Identifica valore: specifica un valore dal punto di vista del cliente finale per famiglia di prodotti.
2. Mappa del flusso di valore: identifica tutti i passaggi nel flusso di valore per ciascuna famiglia di prodotti, eliminando quando possibile quei passaggi che non creano valore.
3. Crea flusso: fai in modo che le fasi di creazione del valore avvengano in una stretta sequenza in modo che il prodotto fluisca senza intoppi verso il cliente.
4. Stabilisci pull: quando il flusso viene introdotto, consenti ai clienti di estrarre valore dalla successiva attività a monte.
5. Cerca la perfezione: quando il valore viene specificato, i flussi di valore vengono identificati, i passaggi sprecati vengono rimossi e vengono introdotti flusso e attrazione, ricominciare il processo e continuarlo fino a raggiungere uno stato di perfezione in cui viene creato un valore perfetto senza sprechi.

Questi principi e altri aspetti del Lean Management sono stati formalizzati quando Womack & Jones ha pubblicato "Lean Thinking" nel 1996.

Sviluppo software snello

Da allora il Lean è stato applicato alla gestione, allo sviluppo di software e ad altri campi.

Negli anni '80 e '90, il settore dello sviluppo software si stava avvicinando a una crisi poiché i progetti eseguiti utilizzando le tradizionali metodologie a cascata richiedevano sempre più tempo. Ciò si traduceva spesso in un enorme ritardo tra l'identificazione di un'esigenza aziendale e la fornitura di una soluzione software. A volte questo ritardo è stato misurato in più anni o addirittura in decenni in alcuni settori con requisiti specifici, come l'industria aerospaziale.

Durante questi periodi di tempo pluriennali, i requisiti, i sistemi o persino intere aziende sono cambiati. Spesso, i progetti venivano annullati a metà o completavano il loro ambito, solo per scoprire che ciò che avevano consegnato non soddisfa più le esigenze aziendali identificate all'inizio del progetto.

La metodologia Waterfall ha premiato le parti interessate per aver pensato a tutto quando sono state costrette a scrivere un contratto anche se probabilmente non erano sicure di ciò di cui avevano bisogno. La metodologia Waterfall ha obbligato a prendere decisioni durante i requisiti o la fase di progettazione e queste decisioni erano molto difficili da modificare senza modificare il contratto e aggiungere costi al progetto. Un'alta percentuale di progetti software non è riuscita completamente, o è stata consegnata in ritardo e oltre il budget, o non è riuscita a fornire ciò che era necessario.

Questa frustrazione generale ha portato vari leader del pensiero a cercare di migliorare Waterfall. I primi esempi includono il Rapid Application Development (RAD) che si è concentrato sulla riduzione degli sprechi abbreviando i requisiti e le fasi di progettazione attraverso lo sviluppo rapido di un prototipo e la collaborazione con le aziende per sviluppare ulteriormente il requisito. C'è stato anche un passaggio verso lo sviluppo iterativo in cui un piccolo progetto è stato completato e le funzionalità sono state aggiunte in continue iterazioni. Sebbene queste metodologie abbiano aiutato, non hanno risolto i problemi principali associati a Waterfall.

Negli anni '90 e all'inizio degli anni 2000, diversi autori hanno pubblicato libri sull'applicazione dei principi Lean allo sviluppo del software. Il Dr. Robert Charette ha pubblicato "Lean Software Development" nel 1993 e "12 Principles of Lean Software Development" nel 2003.

Tom e Mary Poppendieck hanno pubblicato "Lean Software Development: An Agile Toolkit" nel 2003. Questo libro descrive in dettaglio sette principi dello sviluppo snello, che sono direttamente correlati alle sette forme di spreco nella produzione snella. Le somiglianze e le differenze tra le due diverse pubblicazioni Lean e Agile (discusse nella sezione successiva) sono illustrate nel diagramma seguente.

Differenze tra Lean e Agile

Secondo il dottor Charette, una delle differenze principali tra Lean e Agile è che Agile è dal basso verso l'alto, mentre Lean è dall'alto verso il basso.

Struttura agile

Origini di Agile e Il Manifesto Agile

Più o meno nello stesso periodo in cui Charette e i Poppendiecks hanno pubblicato i loro libri, l'Agile Framework è stato creato per aiutare a risolvere gli stessi problemi. Nel febbraio 2001, un gruppo di pionieri Agile si è incontrato al famigerato incontro di Snowbird a Snowbird, Utah, per cercare di trovare una soluzione.

Il risultato è stato il Manifesto Agile che ha stabilito una serie di valori e principi per una metodologia che tenta di adattarsi ai requisiti in evoluzione e alle esigenze dei clienti, ridurre gli sprechi e fornire vantaggi più rapidamente utilizzando un approccio incrementale e iterativo.

Il Manifesto Agile recita quanto segue:

“Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati ​​a valorizzare:

• Individui e interazioni su processi e strumenti
• Software funzionante su documentazione completa
• Collaborazione con il cliente nella negoziazione del contratto
• Rispondere al cambiamento seguendo un piano

Cioè, mentre c'è valore negli oggetti a destra, apprezziamo di più gli oggetti a sinistra.

In linea con i valori del manifesto ci sono i 12 principi alla base del Manifesto Agile:

“Rispettiamo questi principi:

1. La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software di valore.
2. Benvenuto ai requisiti che cambiano, anche in fase di sviluppo avanzata. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.
3. Fornisci software funzionante frequentemente, da un paio di settimane a un paio di mesi, con una preferenza per tempi più brevi.
4. Gli uomini d'affari e gli sviluppatori devono collaborare quotidianamente durante tutto il progetto.
5. Costruisci progetti attorno a persone motivate. Offri loro l'ambiente e il supporto di cui hanno bisogno e fidati di loro per portare a termine il lavoro.
6. Il metodo più efficiente ed efficace per trasmettere informazioni a e all'interno di un team di sviluppo è la conversazione faccia a faccia.
7. Il software funzionante è la misura principale del progresso. I processi agili promuovono lo sviluppo sostenibile.
8. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente.
9. L'attenzione continua all'eccellenza tecnica e al buon design migliora l'agilità.
10. La semplicità, l'arte di massimizzare la quantità di lavoro non svolto, è essenziale.
11. Le migliori architetture, requisiti e progetti emergono da team che si auto-organizzano.
12. A intervalli regolari, il team riflette su come diventare più efficace, quindi mette a punto e adatta il proprio comportamento di conseguenza".

I valori e i principi di cui sopra sono applicazioni di principi Lean come Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka e riduzione degli sprechi.

Principi agili applicati allo sviluppo di software

Agile è un framework ombrello che si applica a qualsiasi processo che applica l'insieme di valori e principi Agile.

Alcuni esempi sono:

• Programmazione estrema
• Mischia
• Kanban

Mischia

Breve storia della feccia

Scrum è un framework che applica i principi Agile che è stato inventato separatamente da più persone, molte delle quali hanno firmato il Manifesto Agile:

• Hirotaka Takeuchi e Ikujiro Nonaka hanno inizialmente introdotto il termine "mischia" in un contesto di produzione nel loro white paper "The New Product Development Game". pubblicato nel 1986 sulla Harvard Business Review.
• Jeff Sutherland, John Scumniotales e Jeff McKenna hanno implementato Scrum presso la Easel Corporation nel 1993.
• Ken Schwaber ha utilizzato quello che sarebbe diventato Scrum nella sua azienda, Advanced Development Methods negli anni '90.

Schwaber e Sutherland hanno collaborato negli anni '90 per sviluppare e perfezionare il framework in un contesto di sviluppo software, parlando a varie conferenze. Schwaber ha lavorato con Mike Beedle per descrivere il metodo nel libro "Agile Software Development with Scrum" nel 2001.

Schwaber ha poi creato entrambe le principali autorità di certificazione Scrum:

• Scrum Alliance: creata nel 2001. Crea la serie di accreditamenti Certified Scrum .
• Scrum.org: creato nel 2009 dopo che Schwaber ha lasciato la Scrum Alliance. Impostare la serie parallela di accreditamento Professional Scrum .

Nel tempo, sono stati creati diversi framework/organismi di certificazione per indirizzare il ridimensionamento del framework Scrum a team e progetti più grandi poiché Scrum era stato originariamente progettato per team piccoli (7 più o meno 2 membri):

• SICURO: struttura agile in scala
• Meno: Scrum su larga scala
• Scrum@scale: Scrum at Scale creato da Jeff Sutherland

Valori di Scrum

Secondo Scrum Alliance:

Scrum è un insieme semplice ma incredibilmente potente di principi e pratiche che aiutano i team a fornire prodotti in cicli brevi, consentendo un feedback rapido, un miglioramento continuo e un rapido adattamento al cambiamento.

Scrum è un framework prescrittivo, incrementale e iterativo per lo sviluppo di software che applica i principi Agile. I valori ei principi di Scrum sono delineati nei grafici seguenti e hanno un allineamento significativo con i valori ei principi Lean e Agile.

Panoramica di Scrum

Il lavoro è suddiviso in brevi iterazioni time-box chiamate sprint che di solito durano da 1 a 3 settimane. Ciò è in netto contrasto con la pianificazione approfondita di Waterfall. Il lavoro pianificato per lo sprint corrente viene scelto dall'inizio di un backlog di elementi di lavoro con priorità chiamato Product Backlog (Pull System, Heijunka) e viene risolto una volta avviato lo sprint. L'obiettivo è avere un software funzionante alla fine di ogni sprint, consentendo un feedback rapido.

Alla fine dello sprint, il team si riunisce per rivedere il lavoro svolto, come è andato lo sprint e per pianificare lo sprint successivo. La lunghezza dello sprint, così come i rituali e la cadenza dello sprint, sono fissati per ogni sprint.

Gli sprint vengono eseguiti da team interfunzionali contenenti tutte le competenze necessarie per completare il lavoro nello sprint. La pianificazione quotidiana e il monitoraggio dei progressi vengono eseguiti utilizzando artefatti visivi come la Scrum Board e i grafici di burndown dello sprint.

Il lavoro in uno sprint viene estratto da un arretrato prioritario. Seguire questi metodi consente di modificare i requisiti nel tempo e incoraggia un feedback costante da parte degli utenti finali.

Il diagramma della mappa mentale di seguito delinea alcuni dei concetti principali di Scum che saranno discussi nelle prossime sezioni.

Ruoli di mischia

Scrum ha tre ruoli:

• Scrum Master : lo Scrum Master è un servitore leader del team Scrum. Sono il coach del team che aiuta a facilitare la collaborazione, rimuove gli impedimenti, fa rispettare e salvaguarda il processo Scrum e protegge il team. Questo in genere significa che organizzano e facilitano i rituali dello sprint, assicurano che il proprietario del prodotto abbia un backlog adeguatamente ordinato e ordinato, assicurano che il team non sia costretto a impegnarsi eccessivamente in uno sprint, assicura che l'ambito non venga aggiunto a un sprint, assicura che la Definizione di Fatto sia rispettata. Non assegnano compiti ai membri del team (Genchi Genbutsu) e non sono responsabili della consegna di un progetto
• Product Owner : il product owner è "l'unico collo strizzabile" responsabile della consegna del prodotto. Il product owner definisce la visione di ciò che vuole costruire e la trasmette al team e all'organizzazione. Il proprietario del prodotto possiede i requisiti aziendali e di mercato e dà la priorità a tutto il lavoro che deve essere svolto attraverso la creazione e la gestione del backlog del prodotto. Decidono quali caratteristiche spedire quando. Lavorano con il team e le altre parti interessate per assicurarsi che tutti comprendano gli elementi nel backlog del prodotto. Accettano o rifiutano il lavoro completato in uno sprint alla demo dello sprint.
• Membro del Team : Il team Scrum è un team interfunzionale auto-organizzato, generalmente composto da cinque a sette membri. Tutti i partecipanti al progetto lavorano insieme e si aiutano a vicenda e non sono necessariamente vincolati a ruoli distinti come architetto, programmatore, designer o tester. Tutti completano il set di lavoro insieme. Lo Scrum team pianifica quanto lavoro può completare ogni sprint e possiede il piano (Genchi Genbutsu).

Scrum Flow, attività e cerimonie

Come discusso in precedenza, Scrum ha un flusso definito e una serie di rituali e attività. Il flusso di uno sprint è il seguente.

Pianificazione dello sprint:

Prima dell'inizio di uno sprint, lo Scrum Master facilita un incontro con il team di Scrum e il Product Owner, chiamato sprint planning meeting, in cui il Product Owner identifica gli obiettivi dello sprint imminente e il team quindi pianifica il proprio lavoro in base agli obiettivi.

Questo di solito viene fatto con le seguenti attività:

• Capacità dello sprint: il team determina la capacità dello sprint, tenendo conto del numero di giorni, del numero dei membri del team, delle ferie, ecc.
• Obiettivi dello sprint: il product owner identifica quali sono gli obiettivi dello sprint. È fondamentale che il product backlog abbia la priorità in base agli obiettivi (cioè, le storie rilevanti sono in cima) e curato.
• Selezione del lavoro: le storie o le attività vengono estrapolate dalla parte superiore del backlog nello sprint fino al raggiungimento della capacità stimata. Man mano che le storie vengono richiamate, il product owner spiegherà la storia e risponderà alle domande del team, aggiornando la storia secondo necessità, finché il product owner e il team Scrum non avranno una buona comprensione comune della storia. Una volta completata questa attività, il team ha un ambito di sprint iniziale proposto.
• Scomposizione dei compiti: il team Scrum discute ogni storia in dettaglio con enfasi sulla pianificazione di come completeranno la storia e affronteranno tutti i criteri di accettazione e il DoD. Produrranno un elenco di attività secondarie necessarie per completare la storia. Una volta completato l'elenco delle attività secondarie, la stima della storia viene rivista e aggiornata, se necessario.
• Impegno dello sprint: una volta che tutte le storie sono state scomposte e le stime sono state aggiornate, l'ambito dello sprint iniziale proposto viene rivisto. Le storie possono essere rimosse dallo sprint e reinserite nel backlog e/o possono essere aggiunte storie aggiuntive. Fatto ciò, SOLO lo Scrum team (e non lo Scrum Master o il product owner) si impegna a completare il lavoro nello sprint e lo sprint ha inizio.

La quantità totale di lavoro o scopo impegnato per lo sprint è misurata in story point.

Esecuzione Sprint

Durante lo sprint, i membri del team estraggono gli elementi di lavoro (storie utente, attività, ecc.) dalla parte superiore dell'elenco delle attività dello sprint su cui lavorare. Vari membri del team lavoreranno sui vari elementi di lavoro o sulle loro attività secondarie. Aggiorneranno lo stato di un oggetto quando appropriato spostandolo da una colonna all'altra (tipicamente Da fare > In corso > Test > Fatto o qualche sua variazione) sulla Scrum Board fino al termine.

I progressi vengono monitorati utilizzando un diagramma di burndown che mostra la quantità di lavoro completata e rimanente misurata in story point. I punti della storia rimanenti vengono mostrati sull'asse Y e il tempo rimanente sull'asse X. Il diagramma di burndown viene aggiornato al termine delle storie.

Quotidianamente, lo Scrum Master si concentra su:

• Facilita la riunione quotidiana in piedi per pianificare la giornata e rivedere i progressi (vedi sotto)
• Garantisce che la squadra abbia un piano per la giornata
• Rimuove i blocchi stradali
• Protegge il mirino dello sprint e la squadra dalle distrazioni
• Aiuta il team a mantenere il proprio diagramma di burndown e altre statistiche Scrum

Stand up quotidiano

All'inizio di ogni giornata dello sprint, lo Scrum Master facilita un breve incontro di 15 minuti con lo Scrum Team e il Product Owner per pianificare la giornata e rivedere i progressi dello sprint. Questo è un breve meeting in cui tutti sono in piedi di fronte allo Scrum Board e ogni persona nella riunione risponde alle seguenti domande in 2 minuti o meno, facendo riferimento a punti specifici sullo sprint board:

• Cosa hai fatto ieri?
• Cosa hai intenzione di fare oggi?
• Ci sono impedimenti che ti impediscono di portare a termine il tuo lavoro?

Ciò consente a tutti di vedere su cosa stanno lavorando tutti, vedere quali progressi vengono compiuti o meno e identificare gli impedimenti e/o l'aiuto necessario.

Completamento dello sprint

Lo Scrum Master facilita due cerimonie per chiudere lo sprint prima di pianificare lo sprint successivo.

Sprint Demo

Alla fine dello sprint, lo Scrum Master facilita uno sprint demo meeting in cui ogni storia completata viene mostrata sul software funzionante al product owner e al resto del team. Il proprietario del prodotto accetterà la storia se tutti i criteri di accettazione sono soddisfatti, oppure rifiuterà la storia. Se una storia viene rifiutata, le carenze vengono identificate e la storia viene reinserita nel product backlog nel suo ordine di priorità per essere completata in un secondo momento o per non essere completata. Spesso, le parti di una storia che il proprietario del prodotto non accetta vengono interrotte in una o più storie separate e la storia originale viene chiusa.

Viene calcolato il numero totale di story point completati per sprint (Velocity) e lo sprint viene chiuso. La velocità viene utilizzata per tenere traccia del livello di output del team e per stimare quando le funzionalità o le versioni saranno complete.

Retrospettiva Sprint

Dopo la demo dello sprint ma prima del prossimo meeting di pianificazione dello sprint, lo Scrum Master facilita una retrospettiva dello sprint in cui il team riflette sullo sprint appena completato e discute cosa è andato bene e cosa non è andato bene in modo da poter migliorare continuamente e in modo incrementale il processo e qualità nel tempo (Kaizen, Hansei). Ci sono una miriade di formati o esercizi retrospettivi che possono essere utilizzati per aiutare il team a generare discussione.

Viene prodotto un elenco di azioni di miglioramento che talvolta comportano l'aggiunta di elementi al product backlog, modifiche al DoD o alla carta del team, ecc.

Gestione del Product Backlog

Creazione del Product Backlog

Prima che uno sprint possa essere pianificato o eseguito, il product owner deve creare un product backlog di lavoro. Il backlog di solito inizia con elementi di sviluppo delle funzionalità chiamati storie scritte dal proprietario del prodotto e nel tempo si popola anche di attività di sviluppo o QA, picchi e difetti, ecc. potenzialmente creati da qualsiasi membro del team. Tutti gli articoli nel backlog sono disposti in ordine di priorità.

Toelettatura arretrata

Una volta che il backlog di prodotto iniziale è stato creato e assegnato le priorità, il processo di ripulitura del backlog in corso prende il sopravvento. L'obiettivo è avere sempre, come minimo, un numero sufficiente di elementi in cima all'arretrato curato e stimato in modo che siano pronti per essere inseriti in uno sprint durante una riunione di pianificazione dello sprint. Questo viene in genere fatto tenendo riunioni regolari di preparazione del backlog in corso con il product manager e il team facilitati dallo Scrum Master.

Prima della riunione, al team viene inviato un elenco di storie in modo che possano rivedere e prepararsi per la riunione di toelettatura. Durante il grooming meeting, ogni elemento viene discusso in termini di criteri di accettazione, complessità, rischio, dimensioni, strategia di implementazione, ecc. I criteri di accettazione e altri dettagli della storia vengono rivisti e rivisti fino a quando il team, il product owner e lo Scrum Master avere una comprensione comune della storia. A quel punto, la storia viene stimata in story point usando una tecnica chiamata poker di pianificazione.

Stima dei punti della storia

I punti della storia sono un'unità di sforzo che utilizza il dimensionamento relativo in cui le storie vengono confrontate con lavori precedenti, noti e ben compresi. Ti poni sempre la domanda "questa storia è più grande, più piccola o all'incirca della stessa dimensione" di qualche altro lavoro.

La scala di Fibonacci (1, 2, 3, 5, 8, 13, 21...) è la scala più comunemente usata in cui ogni incremento è circa il doppio del precedente (cioè, una storia di cinque punti è più o meno il doppio di grande come una storia in tre punti). A volte vengono utilizzate altre squame come le taglie delle magliette (XS, S, M, L, XL) o persino i pesci (pescerini, pesci rossi, trote, tonni, balene, ecc.). Qualsiasi scala che ti permetta di confrontare le dimensioni di qualcosa rispetto a un'altra funzionerà.

I punti della storia rappresentano l'intero sforzo del team per implementare una storia, inclusi sviluppo, test, progettazione e altre attività varie necessarie per la definizione di fatto. La stima tiene conto della quantità di lavoro, complessità e rischio. Una volta determinata la dimensione relativa della storia, viene assegnata una dimensione sulla scala come stima.

I team si preparano per il processo di stima dei punti storici stabilendo prima una linea di base per la stima selezionando una storia di dimensioni "più medie" che l'intero team capisca come una storia di riferimento. Vengono anche scelte alcune storie di riferimento aggiuntive che sono sempre più piccole.

La stima dei punti della storia viene eseguita durante le riunioni di toelettatura e talvolta durante la pianificazione dello sprint utilizzando Planning Poker:

1. Ogni membro del team/stimatore ha un set di carte.
2. Gli elementi del backlog vengono discussi uno alla volta come descritto sopra.
3. Una volta che l'articolo è stato completamente discusso, ogni estimatore sceglie privatamente una carta per rappresentare la propria stima.
4. Quando tutti gli estimatori hanno fatto le loro stime, rivelano le loro carte contemporaneamente.
   • Se tutte le stime corrispondono, gli estimatori selezionano un altro elemento del backlog e ripetono lo stesso processo.
   • Quando le stime differiscono, gli estimatori discutono la questione per raggiungere un consenso.

I vantaggi della stima dello story point sono:

• Rapido: le stime sono relative a voci di product backlog già completate.
• Abbastanza accurato: sufficientemente accurato da fornire una panoramica dell'ambito, pianificare il lavoro futuro, stabilire le priorità e gestire le aspettative.
• Abbraccia l'incertezza: i punti storia specificano un intervallo di tempo sconosciuto. La selezione da una specifica sequenza di punti della storia simile a Fibonacci consente di catturare l'incertezza.
• Sport di squadra: coinvolge tutti (sviluppatori, designer, QA, product manager). Utilizza più prospettive per determinare la dimensione del lavoro, ma solo i membri del team che svolgono il lavoro possono stimare
• Misura la velocità del team: misura quanto lavoro fa un team in uno sprint rispetto alla quantità di tempo speso a fare il lavoro. Man mano che il team migliora, completerà più rapidamente storie della stessa dimensione, risultando in una maggiore velocità di story point nel tempo.

Stima e monitoraggio dei rilasci

La stima dei punti della storia viene utilizzata anche in un contesto di pianificazione dei rilasci utilizzando la tecnica seguente:

1. Elenca tutte le storie da ridimensionare
2. Mettili in ordine dal più piccolo al più grande
   • Prendi la prima e la seconda user story.
   • Decidi quale è più grande e metti quello più grande sotto
   • Quindi prendi il prossimo e decidi dove si adatta rispetto agli altri due
   • Ripeti il ​​processo fino a quando tutte le storie sono ora nell'elenco (in una sequenza dalla più piccola alla più grande)
3. Misura le storie

Le stime delle storie per tutte le storie in una versione combinate con la velocità del team ti permetteranno di stimare quando una versione sarà completa e di seguirne l'avanzamento. Questo è spesso mostrato in un grafico di burn-up delle versioni.

Gli artefatti e i termini di Scrum

• Product Backlog: un elenco del backlog di tutti gli elementi di lavoro per un determinato prodotto che può includere funzionalità (storie), attività tecniche, picchi e difetti
• Burn-up di rilascio: un grafico grafico utilizzato per mostrare i progressi a livello di rilascio e per prevedere quando un rilascio sarà terminato utilizzando Sprint Velocity. I punti della storia completati vengono visualizzati sull'asse Y e gli sprint sull'asse X.
• Sprint Backlog: un elenco di backlog di tutti gli elementi di lavoro da completare in un determinato sprint. I contenuti dello sprint backlog vengono concordati durante lo sprint planning meeting.
• Scrum Board: una tavola in stile tavolo che tiene traccia dell'avanzamento del lavoro impegnato per lo sprint. Gli stati vengono mostrati in alto nelle colonne verticali e gli elementi di lavoro vengono spostati in ogni stato fino al completamento. La Scrum Board viene popolata durante lo sprint planning meeting e viene ripristinata alla fine di uno sprint.
• Sprint Burndown: un grafico che mostra la quantità di lavoro completato e rimanente misurata in story point per tutta la durata dello sprint. I punti della storia rimanenti vengono mostrati sull'asse Y e il tempo rimanente sull'asse X.
• Sprint Velocity: il numero di story point che un team Scrum completa in uno sprint.
• Impediments Backlog: Un elenco di impedimenti che devono essere affrontati dallo Scrum Master affinché il team possa continuare a lavorare. Quando un membro del team viene bloccato, aggiungerà un elemento al backlog degli impedimenti per fornire visibilità al team e allo Scrum Master.
• Epica: un'epopea è un ampio corpus di opere costituito da più storie di utenti correlate.
• Storia dell'utente: una storia dell'utente è una descrizione di una funzionalità del software dal punto di vista dell'utente finale. La storia dell'utente descrive il tipo di utente, cosa vuole e perché. Una user story aiuta a creare una descrizione semplificata di un requisito e include criteri di accettazione. Le storie degli utenti vengono create e mantenute dal proprietario del prodotto.
• Compito: un compito è un pezzo di lavoro inserito dallo Scrum Master o da un membro del team che può essere direttamente o indirettamente correlato alle storie degli utenti. Di solito sono di natura tecnica e includeranno criteri di accettazione.
• Spike: uno spike è un tipo speciale di attività che viene utilizzato quando è necessario ricercare, prototipare e/o progettare prima di poter decidere come implementare o stimare una user story.
• Sottoattività: una sottoattività è un'attività che viene immessa come passaggio di implementazione per il completamento di una storia utente o di un'attività. Di solito vengono inseriti dal team durante una riunione di pianificazione dello sprint.
• Stime dei punti della storia: una scala di stima delle dimensioni relative basata sulla scala di Fibonacci (1, 2, 3, 5, 8, 13, 21...)
• Criteri di accettazione: l'elenco di elementi testabili specifici per la storia inclusi in ogni storia che devono essere completati prima che un proprietario di prodotto accetti una storia come completata.
• Definition of Done (DoD): un elenco di passaggi o criteri comuni che devono essere completati prima che qualsiasi storia possa essere considerata completata. Il team è d'accordo su questo e lo documenta in modo che non debba essere elencato in ogni storia.

Vantaggi e svantaggi di Scrum

Il vantaggio principale di Scrum è l'applicazione di valori e principi Agile, nonché concetti Lean come Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System e Iterazioni. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.