Menu

Metodologia Agile: una guida per principianti al metodo Agile e Scrum

agile methodology beginner s guide agile method

Prova Il Nostro Strumento Per Eliminare I Problemi

Una guida completa alla metodologia Agile: (oltre 20 tutorial dettagliati sulla metodologia Agile Scrum)

Questa è la guida per sviluppatori e tester di software per comprendere e iniziare a lavorare sui famosissimi Metodologia Agile SCRUM per lo sviluppo e il test del software . Impara le terminologie di base ma importanti utilizzate nel processo Agile Scrum insieme a un esempio reale del processo completo.

Abbiamo elencato tutti i tutorial Agile di questa serie per tua comodità. Spero che ti saranno di immenso aiuto.

Argomenti trattati: Cos'è Agile, Cos'è Scrum, Metodologia Agile nello sviluppo e test di software, Test Agile, Processo Scrum Agile, Metodologia Scrum con Scrum Team e Scrum Master.

introduzione allo sviluppo agile

Cosa imparerai:

Elenco dei tutorial sulla metodologia agile

Tutorial n. 1: Metodologie Agile Scrum (Questo tutorial)
Tutorial n. 2: Agile Manifesto
Tutorial n. 3: Lo Scrum Team e i loro ruoli e responsabilità
Tutorial n. 4: Manufatti di Scrum
Tutorial n. 5: Eventi Scrum
Tutorial # 6: Valutazione dei difetti in Scrum
Tutorial # 7: Scrum Team autosufficienti
Tutorial n. 8: Principio dei tre Amigo
Tutorial n. 9: SAFe - Framework agile in scala
Tutorial n.10: Agile Scrum Quiz

ALTRE esercitazioni consigliate su Agile Scrum:

Tutorial n. 11: Le migliori tecniche di stima agile
Tutorial n. 12: Modello ibrido a cascata agile
Tutorial n.13: Kanban vs Scrum vs Agile
Tutorial n. 14: Tutorial JIRA Agile
Tutorial # 15: Riunioni retrospettive agili
Tutorial n. 16: Ruolo degli analisti aziendali in SCRUM
Tutorial n. 17: Il ruolo del QA in Scrum

Strumenti e domande dell'intervista:

Tutorial n. 18: Strumenti di test agili
Tutorial n. 19: I migliori strumenti di gestione dei progetti Agile
Tutorial n. 20: Le migliori domande di intervista Agile
Tutorial n. 21: Domande principali per l'intervista su Scrum

Cominciamo con il primo tutorial della serie - Introduzione a Agile Scrum.

Introduzione allo sviluppo agile

Agile nello sviluppo di software:

Agile è uno dei framework di sviluppo software più utilizzati e riconosciuti al mondo.

La maggior parte delle organizzazioni l'hanno adottata in una forma o nell'altra, ma c'è ancora molta strada da fare nella maturità dei loro programmi di adozione. L'unico scopo di questa serie di tutorial è quello di integrare i professionisti della tecnologia e non tecnologici nel mondo Agile.

Ti guideremo passo dopo passo attraverso il viaggio agile fino a comprendere la filosofia che sta dietro all'uso di Agile, i suoi vantaggi e come praticarlo. Questa serie mira a fornire e consentire ai lettori di applicare l'apprendimento Agile e Scrum nel loro lavoro.

Questo particolare tutorial è dedicato a spiegarti perché c'era bisogno di Agile e come è stato creato. Il fondamentale qui è farti capire il concetto di adozione agile nelle industrie di sviluppo software.

Storia di Agile

Agile è nato quando un bel giorno in cui 17 persone con background in diverse metodologie di sviluppo, si sono riunite per fare un brainstorming se esistesse una possibile soluzione alternativa allo sviluppo del software che potesse portare a tempi di sviluppo più rapidi e fosse meno pesante di documentazione.

A quel tempo, lo sviluppo del software avveniva così a lungo che quando i progetti erano pronti per essere consegnati, l'attività era andata avanti e i requisiti erano cambiati. Quindi un progetto non è stato in grado di soddisfare le esigenze aziendali anche se è stato in grado di soddisfare gli obiettivi definiti.

Così questi campioni di diverse tecniche di ingegneria del software si sono riuniti e il risultato finale del loro incontro è stato quello che hanno chiamato il 'manifesto agile' che discuteremo in dettaglio nel prossimo tutorial di questa serie.

Ma l'agile che è nato quel giorno non è quello che vediamo oggi nelle organizzazioni. La metodologia su cui gli esperti hanno concordato è stata descritta come 'leggera' e veloce. Ma la principale vittoria di questo incontro è stata l'idea che la consegna più rapida di un prodotto e un feedback costante fossero le chiavi per raggiungere il successo nello sviluppo del software.

Le tecniche a cascata esistenti erano troppo macchinose e non prevedevano feedback fino a quando il prodotto finale non era pronto per essere consegnato. Ciò significava che non c'era spazio per la correzione del corso e il cliente non aveva alcuna visione dei progressi fino a quando l'intero prodotto non era pronto. Ed era quello che questi esperti volevano evitare.

Volevano una soluzione che avesse spazio per un feedback costante al fine di evitare il costo della rilavorazione in una fase successiva.

Sfide agili

Le tecniche a cascata esistenti in quel momento erano troppo macchinose e non prevedevano feedback fino a quando il prodotto finale non era pronto per essere consegnato. È stato chiamato un modello di sviluppo a cascata perché i team hanno prima completato un passaggio completamente e solo dopo sono passati al passaggio successivo.

Ciò significava che non c'era spazio per la correzione del corso e il cliente non aveva alcuna visione dei progressi fino a quando l'intero prodotto non era pronto. Ed era quello che questi esperti volevano evitare. Volevano una soluzione che avesse spazio per un feedback costante al fine di evitare il costo della rilavorazione in una fase successiva.

Ed è per questo che agile significa anche adattamento e miglioramento continuo, tanto quanto un feedback costante e velocità di consegna.

Cosa sono le promesse agili?

Promesse agili

Agile non riguarda solo l'applicazione delle pratiche stabilite nello sviluppo del software. Apporta anche un cambiamento nella mentalità del team che li spinge verso la creazione di software migliore, lavorando insieme e alla fine facendoli diventare un cliente felice.

Valori e principi agili consentono al team di spostare la propria attenzione e modificare il processo di pensiero per la creazione di software migliore.

Cos'è esattamente Agile?

Agile non è un insieme di regole. Agile non è un insieme di linee guida. Agile non è nemmeno una metodologia. Piuttosto, Agile è un insieme di principi che incoraggiano flessibilità, adattabilità, comunicazione e software funzionante rispetto a piani e processi. È catturato molto succintamente in quello che viene chiamato il manifesto agile.

Lo sviluppo agile del software consente al team di lavorare insieme in modo più efficiente ed efficace nello sviluppo di progetti complessi. Consiste in pratiche che esercitano tecniche iterative e incrementali facilmente adottabili e che danno ottimi risultati.

Nell'applicazione Agile in azione, abbiamo vari metodi e metodologie basati su Agile. Questi metodi e metodologie soddisfano tutte le esigenze di un'industria di sviluppo software, dalla progettazione e architettura del software, sviluppo e test alla gestione e consegna dei progetti.

Non solo, i metodi e le metodologie Agile aprono anche la possibilità di miglioramento dei processi come parte integrante di ogni consegna.

Agile è un approccio di sviluppo software in cui un team autosufficiente e interfunzionale lavora per effettuare consegne continue attraverso iterazioni e si evolve durante il processo raccogliendo feedback dagli utenti finali.

Come praticare l'Agile?

Esistono varie metodologie Agile che sono in pratica in vari settori diversificati.

metodologie agili

Tuttavia, le metodologie più popolari tra tutte sono:

  • Mischia
  • Kanban
  • Programmazione estrema

Tutte queste metodologie si concentrano sullo sviluppo di software snello e aiutano a creare software migliore in modo efficace ed efficiente.

Questo è tutto con Agile Introduction. La parte è strutturata per aiutarti a comprendere i valori e i principi fondamentali che devono essere adottati affinché un team lavori in modalità e mentalità Agile.

Agile Metodologia

Introduzione ai modelli agili:

Metodologia agile

apertura di file .7z su mac

Come tutti sappiamo, Agile è una metodologia di sviluppo software.

Abbiamo anche appreso i valori e i principi che sono stati menzionati nel manifesto agile dai fondatori di agile. Nelle nostre discussioni iniziali, abbiamo anche aggirato le differenze tra i modelli agili e tradizionali a cascata.

In questo tutorial, conosceremo i vantaggi e gli svantaggi della metodologia agile.

Vedremo cos'è la mischia? e in che modo è diverso da agile. Quindi capiremo le varie metodologie Agile che vengono utilizzate da diverse organizzazioni e come possiamo implementare Agile usandole.

Sarai anche in grado di apprezzare la differenza e anche i vantaggi / svantaggi di queste metodologie.

Vantaggi della metodologia agile

Di seguito sono riportati i vari vantaggi della Metodologia Agile:

  • I clienti ottengono continuamente un aspetto e una sensazione dell'avanzamento del progetto alla fine di ogni iterazione / sprint.
  • Ogni sprint fornisce al cliente un software funzionante che soddisfa le sue aspettative secondo la definizione di fatto da lui fornita.
  • I team di sviluppo sono abbastanza reattivi ai requisiti in evoluzione e possono adattarsi ai cambiamenti anche nelle fasi avanzate dello sviluppo.
  • Esiste una comunicazione bidirezionale costante che mantiene i clienti coinvolti, quindi tutti gli stakeholder - aziendali e tecnici - hanno una chiara visibilità sullo stato di avanzamento del progetto.
  • Il design del prodotto è efficiente e soddisfa i requisiti aziendali.

Svantaggi della metodologia agile

Sebbene ci siano molti vantaggi della metodologia Agile, ci sono anche alcuni svantaggi coinvolti in essa.

Sono:

# 1) Non è preferibile una documentazione completa, il che può portare a team agili che interpretano in modo errato questo dato che l'agile non richiede documentazione. Così il rigore si perde sulla documentazione. Questo dovrebbe essere evitato chiedendoti continuamente se queste sono informazioni sufficienti per procedere o meno.

#Due) A volte, all'inizio dei progetti, i requisiti non sono chiari. I team potrebbero procedere e scoprire che la visione dei clienti è stata riallineata e in tali situazioni, i team devono incorporare molti cambiamenti ed è difficile valutare anche il risultato finale.

Tipi di metodologie agili

Esistono diverse metodologie agili nella pratica in tutto il mondo. Impareremo più in dettaglio su quattro dei più popolari.

Tipi di metodologie agili

# 1) Scrum

Scrum può essere facilmente considerato il framework agile più popolare. Il termine 'mischia' è molto considerato sinonimo di 'agile' dalla maggior parte dei professionisti. Ma questo è un malinteso. Scrum è solo uno dei framework con cui è possibile implementare l'agile.

La parola mischia deriva dal rugby sportivo. Dove i giocatori si stringono insieme in una posizione interbloccata spingendo contro gli avversari. Ogni giocatore ha un ruolo definito nella sua posizione e può giocare sia offensivo che difensivo secondo le esigenze della situazione.

Allo stesso modo, lo scrum nell'IT crede in team di sviluppo autogestiti potenziati con tre ruoli specifici e chiaramente definiti. Questi ruoli includono: Product Owner (PO), Scrum Master (SM) e il team di sviluppo composto da programmatori e tester . Lavorano insieme in periodi di tempo iterativi boxed chiamati sprint.

Il primo passo è la creazione del product backlog da parte del PO. È un elenco di cose da fare che deve essere fatto dal team di mischia. Quindi il team di mischia seleziona gli elementi con la massima priorità e cerca di finirli entro l'intervallo di tempo chiamato sprint.

Un modo più semplice per ricordare tutto questo è memorizzare il framework 3-3-5. Significa che un progetto Scrum ha 3 ruoli, 3 artefatti e 5 eventi.

Questi sono -

Ruoli: PO, Scrum master e team di sviluppo.

Artefatti: Product Backlog, Sprint BacklogeIncremento del prodotto.

Eventi: Sprint, Sprint planning, Daily Scrum, Sprint review e Sprint retrospective.

3-3-5 framework

Impareremo più in dettaglio su ciascuno di questi nei nostri tutorial successivi.

# 2) Kanban

Kanban è un termine giapponese che significa carta. Queste schede contengono i dettagli del lavoro da eseguire sul software. Lo scopo è la visualizzazione. Ogni membro del team è consapevole del lavoro da svolgere attraverso questi aiuti visivi.

I team utilizzano queste carte Kanban per la consegna continua. Proprio come Scrum, Kanban aiuta anche i team a lavorare in modo efficace e promuove team autogestiti e collaborativi.

Ma ci sono anche differenze tra questi due - come durante uno sprint di mischia, gli elementi su cui lavora un team sono fissi e non possiamo aggiungere elementi allo sprint mentre, in Kanban, possiamo aggiungere elementi se c'è capacità disponibile. Ciò è particolarmente utile quando i requisiti cambiano frequentemente.

Allo stesso modo, un'altra differenza è che mentre lo scrum ha definito i ruoli di un PO, scrum master e team di sviluppo, non ci sono tali ruoli predefiniti in Kanban.

Un'altra differenza è che mentre lo scrum suggerisce una prioritizzazione dei backlog di prodotto, Kanban non ha tale requisito ed è totalmente opzionale. Pertanto Kanban richiede meno organizzazione ed evita attività non a valore aggiunto ed è adatto per i processi che richiedono reattività ai cambiamenti.

# 3) Magra

Lean è una filosofia che punta sulla riduzione dei rifiuti. Come lo fa?

In Lean, dividi un processo in attività a valore aggiunto, attività senza valore aggiunto e attività essenziali senza valore aggiunta. Qualsiasi attività che può essere classificata come attività senza valore aggiunto è uno spreco e dovremmo cercare di rimuovere tale spreco nel processo per renderlo più snello.

Un processo più snello significa consegna più rapida e meno sforzo sprecato in attività che non aiutano a raggiungere gli obiettivi del team. Questo aiuta a ottimizzare ogni fase del ciclo di sviluppo del software. Ecco perché i principi lean sono stati adattati dalla produzione snella allo sviluppo del software.

Lo sviluppo di software snello può essere utilizzato in qualsiasi progetto IT applicando i sette principi lean mostrati di seguito:

sette principi snelli

Questi sono abbastanza autoesplicativi come suggeriscono i loro nomi. L'eliminazione degli sprechi è il primo e più importante principio snello e abbiamo visto come farlo, classifichiamo le attività come valore e non valore aggiunto.

Un'attività senza valore aggiunto può essere qualsiasi parte del codice che potrebbe renderlo meno robusto, aumentare lo sforzo richiesto e richiedere molto tempo senza aggiungere un valore aziendale giustificabile. Possono anche essere storie utente vaghe o test scadenti o l'aggiunta di funzionalità che non sono richieste nel quadro generale.

Il secondo principio che amplifica l'apprendimento è ancora una volta facile da capire poiché un team ha bisogno di varie abilità per fornire prodotti in un ambiente in rapida evoluzione con nuove tecnologie che spuntano in tempi rapidi.

Prendere decisioni tardive può essere gratificante in circostanze in cui riduce la rielaborazione, ad esempio se sono previsti cambiamenti, è meglio ritardarla in modo che il team non debba ripetere il lavoro quando le esigenze aziendali cambiano.

Ma qui c'è sempre un compromesso in quanto le squadre devono bilanciare questo con il quarto principio di consegnare più velocemente. Il ritardo delle decisioni non dovrebbe influire sulla consegna complessiva e non deve ridurre il ritmo del lavoro. Un occhio dovrebbe essere sempre sull'immagine completa.

Avere team responsabilizzati è anche molto comune al giorno d'oggi e questo è qualcosa che suggerisce anche l'agile. I team autorizzati sono più responsabili e possono prendere decisioni più velocemente. Il senso di appartenenza in una squadra autorizzata porta a risultati migliori. Per potenziare un team, dovrebbe essere consentito loro di organizzarsi e prendere decisioni da soli.

Quindi vediamo che snello e agile hanno molto in comune con una netta differenza: mentre i team snelli possono aiutare a perfezionare un prodotto, i team agili sono quelli che effettivamente costruiscono il prodotto.

# 4) Extreme Programming (XP)

La programmazione estrema è un'altra delle tecniche agili più popolari. Secondo extremeprogramming.org, il primo progetto XP è stato avviato il 6 marzo 1996. Si dice anche che XP influisce sullo sviluppo del progetto software in 5 modi diversi: comunicazione, semplicità, feedback, rispetto e coraggio. Questi sono chiamati i valori di XP.

Da questi, tutto inizia con la comunicazione. I team XP collaborano regolarmente con team aziendali e colleghi programmatori e iniziano a creare codice sin dal primo giorno. L'attenzione qui è sulla comunicazione faccia a faccia, per quanto possibile, con l'aiuto degli altri ausili visivi.

I programmatori estremi creano anche un codice semplice e iniziano a ricevere feedback su di esso dal primo giorno stesso. L'obiettivo è non esagerare o prevedere requisiti che non sono stati condivisi. Ciò mantiene il design semplice e produce solo il prodotto minimo che soddisferà i requisiti.

Il feedback aiuta il team a migliorare e produrre una migliore qualità del lavoro. Questo li aiuta a creare rispetto reciproco mentre imparano gli uni dagli altri e imparano a condividere le loro opinioni.

Questo dà loro anche il coraggio perché sanno di aver raccolto le migliori idee di tutti e di aver prodotto un buon prodotto con il feedback degli altri. Pertanto non hanno nemmeno paura di includere modifiche o ricevere ulteriori feedback sul loro lavoro.

Ciò è particolarmente utile nei progetti in cui i requisiti cambieranno spesso. Un feedback costante aiuterà i team a includere questi cambiamenti con coraggio.

Così abbiamo visto le diverse metodologie agili come Scrum, XP, Kanban e Lean insieme ai rispettivi vantaggi e svantaggi.

Ora, possiamo facilmente distinguere tra loro e apprezzare anche le differenze più sottili tra loro. Abbiamo anche appreso i fondamenti di ciascuna di queste metodologie e abbiamo visto come applicarle nei nostri progetti come e quando richiesto.

Nella parte successiva, capiamo tutto su Scrum.

Metodologia Scrum

SCRUM è un processo in metodologia agile che è una combinazione del modello iterativo e del modello incrementale.

Uno dei maggiori handicap del tradizionale Modello a cascata era che - fino al completamento della prima fase, l'applicazione non passa all'altra fase. E per caso, se ci sono alcuni cambiamenti nella fase successiva del ciclo, allora diventa molto difficile implementarli, poiché comporterebbe la rivisitazione delle fasi precedenti e la ripetizione delle modifiche.

Test di mischia agile

Alcune delle caratteristiche chiave di SCRUM includono:

  • Team auto-organizzato e concentrato.
  • Nessun documento con requisiti enormi, piuttosto hanno una storia molto precisa e al punto.
  • I team interfunzionali lavorano insieme come una singola unità.
  • Stretta comunicazione con il rappresentante dell'utente per comprendere le funzionalità.
  • Ha una tempistica definita di massimo un mese.
  • Invece di fare l'intera 'cosa' alla volta, Scrum fa un po 'di tutto a un dato intervallo.
  • La capacità e la disponibilità delle risorse sono considerate prima di impegnare qualsiasi cosa.

Per comprendere bene questa metodologia, è importante comprendere le terminologie chiave in SCRUM.

Leggi anche => Come fornire funzionalità software di alto valore in un breve periodo di tempo utilizzando Agile Scrum Process

Terminologie importanti di SCRUM

1) Scrum Team

Il team di mischia è un team composto da 7 con + o - due membri. Questi membri sono un misto di competenze e comprendono sviluppatori, tester, persone di database, persone di supporto ecc. Insieme al proprietario del prodotto e uno scrum master.

Tutti questi membri lavorano insieme in stretta collaborazione per un intervallo ricorsivo e definito, per sviluppare e implementare le suddette caratteristiche. La disposizione delle sedute del team SCRUM gioca un ruolo molto importante nella loro interazione, non si siedono mai in cubicoli o cabine, ma su un tavolo enorme.

Scrum Team

2) Sprint

Lo sprint è un intervallo predefinito o un lasso di tempo in cui il lavoro deve essere completato e renderlo pronto per la revisione o pronto per la distribuzione in produzione. Questa casella temporale di solito è compresa tra 2 settimane e 1 mese.

come visualizzare i file swf sul pc

Nella nostra vita quotidiana, quando diciamo che seguiamo il ciclo di Sprint di 1 mese, significa semplicemente che lavoriamo per un mese sulle attività e lo prepariamo per la revisione entro la fine di quel mese.

3) Proprietario del prodotto

Il proprietario del prodotto è lo stakeholder chiave o l'utente principale dell'applicazione da sviluppare. Il product owner è la persona che rappresenta il lato cliente. Ha l'autorità finale e dovrebbe essere sempre disponibile per la squadra.

Dovrebbe essere raggiungibile quando qualcuno ha dubbi che necessitano di chiarimenti. È importante che il product owner capisca e non assegni alcun nuovo requisito nel mezzo dello sprint o quando lo sprint è già iniziato.

4) Scrum Master

Scrum Master è il facilitatore del team di scrum. Si assicura che il team di mischia sia produttivo e progressista. In caso di impedimenti, lo scrum master li segue e li risolve per la squadra. SCRUM Master è il mediatore tra il PO e il team.

Tiene informato il PO sull'andamento dello Sprint. Se ci sono ostacoli o dubbi per il team, discute con il PO e li risolve. Come il Daily Standup del team, ogni giorno si verifica uno standup del Master SCRUM con il PO.

Lettura consigliata => Come essere un buon mentore di squadra, allenatore e un vero difensore di squadra in un mondo di test Agile?

5) Analista aziendale (BA)

Un analista aziendale gioca un ruolo molto importante in SCRUM. Questa persona è responsabile della finalizzazione e della bozza del requisito nei documenti dei requisiti (in base ai quali vengono create le storie degli utenti).

Se ci sono ambiguità nelle storie degli utenti / criteri di accettazione, è lui / lei che viene avvicinato dal team tecnico (SCRUM) e poi lo porta al PO o altrimenti se possibile si risolve da solo. In progetti su larga scala, ci può essere più di 1 BA, ma in progetti su piccola scala, il Master SCRUM può agire anche come BA.

È sempre una buona pratica avere un BA all'inizio del progetto.

6) Storia dell'utente

Le storie degli utenti non sono altro che i requisiti o le funzionalità che devono essere implementate.

In Scrum, non abbiamo questi enormi documenti sui requisiti, piuttosto i requisiti sono definiti in un singolo paragrafo, in genere con il formato come:

Come un
voglio
Realizzare

Per esempio :

In qualità di amministratore voglio avere un blocco della password nel caso in cui l'utente inserisca una password errata per 3 volte consecutive per limitare l'accesso non autorizzato.

Ci sono alcune caratteristiche delle storie degli utenti che dovrebbero essere rispettate. Le storie degli utenti dovrebbero essere brevi, realistiche, stimabili, complete, negoziabili e verificabili. Una user story non viene mai alterata o cambiata durante lo Sprint.

È responsabilità del Master SCRUM e del BA (se applicabile) assicurarsi che il PO abbia redatto correttamente le User Story con una serie adeguata di Criteri di Accettazione ”. Se devono essere apportate modifiche che influiranno sul rilascio dello sprint, tali storie vengono estratte dallo sprint o vengono eseguite secondo le ore disponibili.

Ogni user story ha un criterio di accettazione che dovrebbe essere ben definito e compreso dal team.

I criteri di accettazione descrivono in dettaglio la user story che fornisce i documenti di supporto. Aiuta a perfezionare ulteriormente la user story. Tutti i membri del team possono annotare i criteri di accettazione. Il team di test basa i propri casi / condizioni di test su questi criteri di accettazione.

7) Epiche

Le epiche sono user story equivoche oppure possiamo dire che queste sono le user story che non sono definite e vengono conservate per sprint futuri.

Prova solo a metterlo in relazione con la vita, immagina di andare in vacanza. Mentre andate la prossima settimana, avete tutto a posto, come le prenotazioni degli hotel, le visite turistiche, i travellers cheque, ecc. Hai solo una vaga idea che potresti andare in XYZ, ma non hai un piano dettagliato.

Un Epic è proprio come il tuo piano di vacanza del prossimo anno, dove sai solo che potresti voler andare, ma dove, quando, con chi, tutti questi dettagli non hai idea in questo momento.

Allo stesso modo, ci sono caratteristiche che devono essere implementate in futuro i cui dettagli non sono ancora noti. Per lo più una funzionalità inizia con un'epica e poi viene suddivisa in storie che potrebbero essere implementate.

8) Backlog di prodotto

Il backlog del prodotto è una sorta di bucket o fonte in cui vengono conservate tutte le storie degli utenti. Questo è gestito dal Product Owner. Il backlog del prodotto può essere immaginato come una lista dei desideri del proprietario del prodotto che gli dà la priorità in base alle esigenze aziendali.

Durante la riunione di pianificazione (vedere la sezione successiva), una user story viene presa dal product backlog, quindi il team fa il brainstorming, lo comprende e lo perfeziona e decide collettivamente quali user story prendere, con l'intervento del product owner.

9) Sprint Backlog

In base alla priorità, le storie degli utenti vengono prese dal Product Backlog una alla volta. Il team di Scrum fa un brainstorming su di esso determina la fattibilità e decide sulle storie su cui lavorare su un particolare sprint. L'elenco collettivo di tutte le storie degli utenti su cui il team di Scrum lavora su un particolare sprint è noto come Sprint backlog.

Sprint Backlog

10) Punti della storia

I punti della storia sono un'indicazione quantitativa della complessità di una user story. In base al punto della storia, vengono determinati la stima e gli sforzi per una storia.

Un punto della storia è relativo e non assoluto. Per assicurarci che la nostra stima e i nostri sforzi siano corretti, è importante verificare che le storie degli utenti non siano grandi. Più precisa e piccola è la user story, più accurata sarà la stima.

Ogni storia dell'utente è assegnata a un punto della storia basato sulla serie di Fibonacci (1, 2, 3, 5, 8, 13 e 21). Più alto è il numero, il complesso è la storia.

Per essere precisi

  • Se dai 1/2/3 story point significa che la storia è piccola e di bassa complessità.
  • Se dai punti 5/8, è un medio complesso e
  • 13 e 21 sono molto complessi.

Qui la complessità consiste nello sviluppo e nello sforzo di test.

Per decidere un punto della storia, il brainstorming avviene all'interno del team di mischia e il team decide collettivamente un punto della storia.

Può accadere che il team di sviluppo dia uno story point 3 a una storia particolare, perché per loro potrebbero essere 3 righe di modifica del codice, ma il team di test dà 8 story point perché ritengono che questa modifica del codice influenzerà i moduli più grandi, quindi lo sforzo di test sarebbe maggiore. Qualunque sia il punto della storia che stai dando, devi giustificarlo.

Quindi, in questa situazione, avviene il brainstorming e il team concorda collettivamente su un punto della storia.

Ogni volta che stai decidendo un punto della storia, tieni a mente i seguenti fattori:

  • La dipendenza della storia con altre applicazioni / moduli.
  • L'insieme di abilità della risorsa.
  • La complessità della storia.
  • Apprendimento storico.
  • Criteri di accettazione della user story.

Se non sei a conoscenza di una storia in particolare, non ridimensionarla.

Ogni volta che una storia è = o> 8 punti, viene suddivisa in 2 o più storie.

11) Brucia il grafico

Il grafico Burn down è un grafico che mostra lo sforzo effettivo stimato rispetto a quello delle attività di Scrum.

È un meccanismo di tracciamento mediante il quale per un particolare sprint vengono tracciate le attività quotidiane per verificare se le storie stanno procedendo verso il completamento degli story point impegnati o meno.

Esempio : Per capire questo, controlla la figura seguente:

Grafico Burn Down 1

Ho assunto:

  • 2 settimane Sprint (10 giorni)
  • 2 risorse effettive che lavorano sullo sprint.

'Storia' -> Questa colonna mostra le storie degli utenti prese per lo sprint.

'Compito' -> Questa colonna mostra l'elenco delle attività associate alla user story.

'Sforzo' -> Questa colonna mostra lo sforzo. Ora, questa misura è lo sforzo totale per completare l'attività. Non descrive lo sforzo compiuto da un individuo specifico.

'Giorno 1 - Giorno 10' -> Questa colonna mostra le ore rimanenti per completare la storia. Si prega di notare che l'ora NON è l'ora che è già stata fatta MA le ore che sono ancora rimaste.

'Sforzo stimato' -> È il totale dello sforzo. Per 'Start' è semplicemente la somma dell'intera attività individuale: SUM (C5: C15)

Un numero totale di sforzi che deve essere completato in 1 giorno è 70/10 = 7. Quindi alla fine del giorno 1, lo sforzo dovrebbe ridursi a 70 - 7 = 63. In modo simile, viene calcolato per tutti i giorni fino al giorno 10, quando lo sforzo stimato dovrebbe essere 0 (riga 16)

'Effort Effort Left' -> Come suggerisce il nome, è lo sforzo effettivamente lasciato per completare la storia. Può anche accadere che gli sforzi effettivi aumentino o diminuiscano di quelli stimati.

È possibile utilizzare le funzioni integrate e il grafico in Excel per creare questo grafico burndown.

I passaggi di Burn Down Chart sarebbero:

  1. Inserisci tutte le storie (Colonna A5 - A15).
  2. Immettere tutte le attività (Colonna B5 - B15).
  3. Immettere i giorni (giorno 1 - giorno 10).
  4. Inserisci gli sforzi iniziali (somma i compiti C5 - C15).
  5. Applicare la formula per calcolare gli 'sforzi stimati' per ogni giorno (dal giorno 1 al giorno 10). Immettere la formula in D15 (C16- $ C $ 16/10) e trascinarla per tutti i giorni.
  6. Per ogni giorno, inserisci gli sforzi effettivi. Immettere la formula in D17 (SUM (D5: D15)) per sommare gli sforzi effettivi rimasti e trascinarla per tutti gli altri giorni.
  7. Selezionalo e crea il grafico come segue:

Grafico Burn Down 2

12) Velocità

Il numero totale di story point archiviati da un team di mischia in uno sprint si chiama Velocity. Il team Scrum viene giudicato o referenziato in base alla sua velocità. Detto questo, va tenuto presente che l'obiettivo qui NON è raggiungere i massimi punti della storia, ma avere un risultato di qualità, rispettando il livello di comfort del team di mischia.

Per esempio : Per uno sprint particolare: il numero totale di storie utente è 8 con story point come mostrato di seguito.

Velocità di mischia

Quindi qui la velocità sarà la somma dei punti della storia = 30

Definizione di Fatto:

Uno Sprint è contrassegnato come Fatto quando tutte le storie sono state completate, tutte le attività di sviluppo, ricerca, QA sono contrassegnate come 'Completate', tutti i bug sono corretti-chiusi, altrimenti quelli che possono essere eseguiti in seguito (come non completamente correlati o meno importanti) vengono estratti e aggiunti al backlog, la revisione del codice e il test unitario sono completati, le ore stimate hanno soddisfatto le ore effettive impiegate nelle attività e, soprattutto, è stata fornita una demo di successo al PO e agli stakeholder.

Attività svolte nella metodologia SCRUM

# 1) Riunione di pianificazione

Un meeting di pianificazione è il punto di partenza di Sprint. È l'incontro in cui si riunisce l'intero team di Scrum, lo SCRUM Master seleziona una user story in base alla priorità dal backlog del prodotto e il team fa brainstorming su di essa.

Sulla base della discussione, il team di Scrum decide la complessità della storia e la dimensiona secondo la serie di Fibonacci. Il team identifica le attività insieme agli sforzi (in ore) che sarebbero stati fatti per completare l'implementazione della user story.

Molte volte, l'incontro di pianificazione è preceduto da un 'incontro di pre-pianificazione'. È proprio come i compiti che il team di mischia fa prima di sedersi per la riunione di pianificazione formale. Il team cerca di annotare le dipendenze o altri fattori che vorrebbero discutere nella riunione di pianificazione.

# 2) Esecuzione di Sprint Tasks

Come suggerisce il nome, questo è il lavoro effettivo svolto dal team di Scrum per portare a termine il proprio compito e portare la user story nello stato 'Fatto'.

# 3) Standup quotidiano

Durante il ciclo di sprint, ogni giorno il team di mischia si riunisce per non più di 15 minuti (potrebbe essere una chiamata in piedi, consigliata durante l'inizio della giornata) e indicare 3 punti:

  1. Cosa ha fatto ieri il membro del team?
  2. Cosa intendeva fare il membro del team oggi?
  3. Eventuali ostacoli (blocchi stradali)?

È lo Scrum master che facilita questo incontro. Nel caso in cui un membro del team si trovi ad affrontare qualsiasi tipo di difficoltà, lo scrum master segue per risolverlo. In Stand up, anche la tavola viene rivista e di per sé mostra l'andamento della squadra.

# 4) Riunione di revisione

Alla fine di ogni ciclo di sprint, il team SCRUM si incontra di nuovo e mostra al proprietario del prodotto le user story implementate. Il proprietario del prodotto può effettuare una verifica incrociata delle storie secondo i suoi criteri di accettazione. È nuovamente responsabilità dello Scrum master presiedere questo incontro.

Anche nello strumento SCRUM, lo Sprint è chiuso e le attività sono contrassegnate come completate.

# 5) Riunione retrospettiva

La riunione retrospettiva avviene dopo la riunione di revisione.

Il team SCRUM incontra, discute e documenta i seguenti punti:

  • Cosa è andato bene durante lo Sprint (Best practice)?
  • Cosa non è andato bene nello Sprint?
  • Lezioni imparate
  • Elementi di azione.

Il team Scrum dovrebbe continuare a seguire la best practice, ignorare le “non best practice” e implementare le lezioni apprese durante i conseguenti sprint. La riunione retrospettiva aiuta a implementare il miglioramento continuo del processo SCRUM.

Come viene svolto il processo? Un esempio!

Dopo aver letto i gerghi tecnici di SCRUM. lasciatemi provare a dimostrare l'intero processo con un esempio.

Esempio:

Passo 1 : Disponiamo di un team SCRUM di 9 persone composto da 1 proprietario del prodotto, 1 master Scrum, 2 tester, 4 sviluppatori e 1 DBA.

Passo 2 : Lo Sprint deve seguire un ciclo di 4 settimane. Quindi abbiamo uno Sprint di 1 mese dal 5 giugno al 4 giugnothdi luglio.

Passaggio 3 : Il Product Owner ha l'elenco prioritario delle storie degli utenti nel backlog del prodotto.

Passaggio 4: La squadra decide di incontrarsi il 4thGiugno per l'incontro “Pre Planning”.

  • Il proprietario del prodotto prende 1 storia dal backlog del prodotto, la descrive e lascia che il team faccia un brainstorming su di essa.
  • L'intero team discute e comunica direttamente al proprietario del prodotto per aver compreso chiaramente la user story.
  • In modo simile, vengono prese varie altre storie degli utenti. Se possibile, il team può andare avanti e valutare anche le storie.

Dopo tutta la discussione, i singoli membri del team tornano alle loro postazioni di lavoro e

  • Identifica i loro compiti individuali per ogni storia.
  • Calcola il numero esatto di ore in cui lavoreranno. Controlliamo come il membro conclude queste ore.

Numero totale di ore di lavoro = 9
Meno 1 ora per una pausa, meno 1 ora per le riunioni, meno 1 ora per e-mail, discussioni, risoluzione dei problemi, ecc.
Quindi le ore di lavoro effettive = 6.
Un numero totale di giorni lavorativi durante lo Sprint = 21 giorni.
Numero totale di ore disponibili = 21 * 6 = 126.
Il membro è in ferie per 2 giorni = 12 ore (questo varia per ogni membro, alcuni possono prendere un congedo e altri no).
Numero di ore effettive = 126 - 12 = 114 ore.

Ciò significa che il membro sarà effettivamente disponibile per 114 ore per questo sprint. Quindi suddividerà il suo compito di sprint individuale in modo tale da raggiungere un totale di 114 ore.

Passaggio 5 : Il 5thdi giugno l'intero team Scrum si incontra per il “Planning Meeting”.

  • Il verdetto finale della user story dal backlog del prodotto è fatto e la storia viene spostata nello Sprint Backlog.
  • Per ogni storia, ogni membro del team dichiara le attività identificate, se necessario può avere una discussione su quelle attività, può ridimensionarla o ridimensionarla (ricorda la serie di Fibonacci !!).
  • Lo Scrum master o il team inseriscono le proprie attività individuali insieme alle ore per ogni storia in uno strumento.
  • Dopo che tutte le storie sono state completate, Scrum master annota la velocità iniziale e avvia formalmente lo Sprint.

Passaggio n. 6 : Una volta avviato lo Sprint, in base alle attività assegnate, ogni membro del team inizia a lavorare su quelle attività.

Passaggio 7 : Il team si incontra ogni giorno per 15 minuti e discute di 3 cose:

  • Cosa hanno fatto ieri?
  • Cosa intendono fare oggi?
  • Eventuali ostacoli (blocchi stradali)?

Passaggio 8 : Lo scrum master tiene traccia dei progressi su base giornaliera con l'aiuto di 'Burn down chart'.

Passaggio 9 : In caso di impedimenti, lo Scrum master segue per risolverli.

Passaggio 10 : Il 4thLuglio, la squadra si riunisce di nuovo per la riunione di revisione. Un membro dimostra la user story implementata al proprietario del prodotto.

Passaggio 11 : Il 5thLuglio, il Team si ritrova per la Retrospettiva, dove si discute

  • Cosa è andato bene?
  • Cosa non è andato bene?
  • Elementi di azione.

Passaggio 12 : Il 6thLuglio, il Team si riunisce di nuovo per la riunione di pre-pianificazione per il prossimo sprint e il ciclo continua.

processo metodologico agile di scrum

Strumenti di attività SCRUM

Esistono diversi strumenti che possono essere ampiamente utilizzati per monitorare le attività di Scrum.

Alcuni di loro includono:

Nel prossimo tutorial, faremo luce sul Manifesto Agile, una nozione che guida i team Agile efficaci.

Tutorial successivo

Riguardo agli Autori: Questa serie è stata scritta dai seguenti membri del team STH: Shruti Shrivastava - A Scrum Master professionista con 9 anni di esperienza nei domini BFSI, E-commerce e B2B. Shruti è un esperto in test di automazione e leader di team di scrum.

Anshul Kumar Srivastava - Un professionista della gestione dei prodotti orientato ai risultati e un praticante Agile con 7 anni di esperienza nei settori BFSI e Telecom.

Lettura consigliata

^