Archive for the ‘ Scrum ’ Category

#Agile: Già, perché dovremmo usare Agile?

E-quality Italia, Accredited Training Organization di APMG-International per AgilePM® e per molti altri prodotti, è lieta di invitarvi al webinar “Why Agile?”, organizzato da APMG-International con la partecipazione di Alex Gray di Radtac.

Agile

Perché Agile?

La domanda “Già, perché dovremmo utilizzare Agile?” è molto interessante, sia che abbiate appena incominciato a cercare informazioni su Agile, sia che lo abbiate già considerato come un possibile nuovo modo di lavorare.
Continua a leggere

#Agile: i ruoli in Scrum

I team di progetto in Scrum prevedono tre ruoli principali (core roles) ed alcuni ruoli secondari (ancillary roles). Spesso i ruoli principali vengono indicati con il termine maiali (pigs) mentre i ruoli secondari vengono indicati con il termine galline (chicken). Questa definizione scherzosa deriva dalla storiella della gallina che cerca di coinvolgere il maiale in un progetto per realizzare un english breakfast.

Scrum
Vediamo di seguito i ruoli in dettaglio.
Continua a leggere

#Agile, toolkit #38: Definition of done

Il Project Management Institute ha da poco reso disponibile il nuovo Exam Content Outline per la certificazione PMI-ACP®. Il nuovo esame è entrato in vigore a partire dal 15/10/2015, dopo un periodo pilota.
Prosegue la lunga serie di post nei quali tratteremo tutti gli elementi del Toolkit PMI-ACP®; oggi parliamo di Definition of done.

Il concetto di Definition of done è uno dei concetti fondamentali in Scrum. Ad ogni iterazione il team dovrebbe rilasciare un incremento del software completamente terminato. Un team Scrum ideale consegna il software ad ogni iterazione direttamente nelle mani del cliente, dopo essere riuscito a gestire la formazione, a stampare la documentazione e così via.

La maggior parte dei team del mondo reale, però, si accontentano di molto meno. Ciò che sarà davvero consegnato dal team al termine di ciascuna iterazione dipende dalla definition of done concordata.

Esistono molte checklist differenti, e molte definition of done raccomandate, ma non ce n’è una che possa essere applicata da tutti i team del mondo. Si può solo suggerire di standardizzare ciò che il team è davvero in grado di ottenere, e migliorare via via lo standard senza adottare prassi che non si è in grado di applicare in concreto.

La definition of done e più semplice possibile è “Il Product Owner ha espressamente accettato gli elementi del backlog che sono stati rilasciati”. Questa definizione può essere estesa in molti modi, ad esempio “sono stati inclusi alcuni test automatici”, “il codice critico è stato sottoposto a riesame”, “tutte le modifiche sono state sviluppate in test-driven mode”, e così via.

Si parla estesamente della tecnica MoSCoW nei nostri corsi Agile & Scrum in aula e in e-learning.

Ti è piaciuto questo post? Per ricevere ogni 2-4 settimane aggiornamenti da E-quality Italia fai click qui.

#Agile, toolkit #36: Gestione delle priorità con #MoSCoW

Il Project Management Institute ha da poco reso disponibile il nuovo Exam Content Outline per la certificazione PMI-ACP®. Il nuovo esame è entrato in vigore a partire dal 15/10/2015, dopo un periodo pilota.
Prosegue la lunga serie di post nei quali tratteremo tutti gli elementi del Toolkit PMI-ACP®; oggi parliamo della tecnica MoSCoW.

La tecnica MoSCoW è un metodo di gestione delle priorità che classifica gli obbiettivi come: “must have” (necessari, “da avere”), “should have” (opportuni), “could have” (possibilmente da ottenere) e “would like to have” (graditi, “che sarebbe gradito avere”). Alcune fonti suggeriscono che la lettera “W” sia da intendere con il significato di “Won’t have” (“non si avrà”).
Questo approccio è strettamente collegato con l’approccio alla pianificazione detto “timebox” utilizzato nel metodo di project management AGILE. Entro ogni “timebox” ( o sprint; lasso di tempo definito) le priorità degli obbiettivi sono organizzate in modo che:

• i requisiti degli obiettivi “must have” sono fondamentali per il sistema in fase di sviluppo e senza questi non funzionerà.

• i requisiti degli obiettivi “should have” sono importanti, ma se non vengono completati v’è un’alternativa;

• i requisiti degli obiettivi “could have” non sono essenziali nel timebox corrente e possono essere posposti al timebox successivo;

• le caratteristiche degli obiettivi “would like to have” consistono in requisiti che hanno valore se possono essere raggiunti in questo timebox, ma si prevede che non saranno conseguiti fino ad un timebox successivo.

Si parla estesamente della tecnica MoSCoW nei nostri corsi Agile & Scrum in aula e in e-learning.

Ti è piaciuto questo post? Per ricevere ogni 2-4 settimane aggiornamenti da E-quality Italia fai click qui.

#PRINCE2: Danieli sceglie E-quality Italia

Si è concluso con successo lo scorso sabato 14 maggio dopo quattro mesi di lavoro il primo progetto di formazione in cui Danieli ha coinvolto E-quality Italia.

Danieli (nome completo: Danieli & C.Officine Meccaniche SpA) è una multinazionale italiana con sede a Buttrio (Udine) ed è il leader mondiale nella produzione di impianti siderurgici, e in modo particolare nel settore dei prodotti lunghi, del cui mercato mondiale detiene oltre il 90% di quota.
IMG_0510

Il principale obiettivo dell’intervento formativo era valutare l’applicabilità delle Global Best Practice® di AXELOS alle attività dell’IT di gruppo, iniziando ovviamente con ITIL® e PRINCE2®, e con un occhio di riguardo per Scrum. Danieli utilizza per i propri progetti di business PMI®.

L’approccio scelto da Danieli per la formazione è anch’esso una best practice; corsi e-learning della durata di due mesi sulla piattaforma Articulate Storyline di E-quality, intervallati da incontri di approfondimento con i nostri docenti e conclusi da una full immersion di una giornata in preparazione all’esame di certificazione.

Ovviamente tutti i partecipanti hanno superato con successo gli esami di certificazione. Grazie Danieli, ci vediamo alla prossima!

#Agile, toolkit #34: Burn Down Chart e Burn Up Chart

Il Project Management Institute ha da poco reso disponibile il nuovo Exam Content Outline per la certificazione PMI-ACP®. Il nuovo esame è entrato in vigore a partire dal 15/10/2015, dopo un periodo pilota.
Prosegue la lunga serie di post nei quali tratteremo tutti gli elementi del Toolkit PMI-ACP®; oggi parliamo dei Burn Down Chart e Burn Up Chart.

Un burn down chart è una rappresentazione grafica del lavoro rimanente rispetto al tempo a disposizione. Il semplice principio del grafico è che esso si concentra su ciò che resta da fare piuttosto che ciò che è stato fatto. Mentre la valutazione di ciò che è stato fatto crea un sentimento di soddisfazione, la valutazione di ciò che resta da fare crea un senso di urgenza.

Burn down chart

La scala verticale può essere misurata con diverse unità. Le scale più utilizzate sono l’effort (indicato in ore o giorni) o la dimensione dei prodotti consegnati. Alcuni approcci Agile usano i cosiddetti ‘story points‘ su questa scala.

Allo stesso modo un burn up chart è la rappresentazione grafica del lavoro svolto dal team (in termini di prodotti rilasciati). I due grafici insieme consentono di visualizzare facilmente lo stato di avanzamento del lavoro nel timebox, applicando così il principio dell’Information Radiator.

I burn up/down chart sono comunemente impiegati negli approcci Agile, in cui si riferiscono ad un singolo timebox (o sprint). In questo caso l’intervallo temporale di riferimento è breve (in genere da 2 a 4 settimane) ed il grafico permette così di avere una reale percezione di ciò che deve essere fatto prima che il timebox sia terminato.
Il principio dei burn up/down chart può essere utilizzato insieme ad altre tecniche come la creazione di tempi buffer nella pianificazione della catena critica.

Si parla estesamente di Burn Up Chart e Burn Down Chart nei nostri corsi Agile & Scrum in aula e in e-learning.

Ti è piaciuto questo post? Per ricevere ogni 2-4 settimane aggiornamenti da E-quality Italia fai click qui.

#Agile, toolkit #32; Backlog grooming and refinement

Il Project Management Institute ha da poco reso disponibile il nuovo Exam Content Outline per la certificazione PMI-ACP®. Il nuovo esame è entrato in vigore a partire dal 15/10/2015, dopo un periodo pilota.
Prosegue la lunga serie di post nei quali tratteremo tutti gli elementi del Toolkit PMI-ACP®; oggi parliamo del backlog grooming.
In un tipico progetto Agile il Product Backlog conterrà tutte le User Story, le relative stime di effort e lo stato dei requisiti a priorità più elevata. Nel Product Backlog saranno anche inserite le User Story nuove o modificate sviluppate a causa di nuovi requisiti di business, richieste dei clienti, condizioni di mercato e/o lezioni apprese durante gli Sprint precedenti.
Continua a leggere