SCRUM? Proviamo per 30 giorni a tornare bambini!

Come imparano i bambini? E se Scrum vi offrisse di tornare bambini per trenta giorni? Accettereste di provarlo?

---

Come fanno i bimbi ad apprendere così velocemente e con tanto entusiasmo? Beh, partono avvantaggiati, molto avvantaggiati.

Innanzittutto non conoscono pregiudizio. Nessuna sovrastruttura mentale che li condizioni nella loro esplorazione: solo tanta voglia di capire cosa gli stia intorno.

Poi fanno largo uso di una tecnica efficacissima: sperimentano il mondo e la sua complessità, semplicemente attraverso l’uso dei propri diretti sensori: i cinque sensi.

Ed eccoli lì a toccare tutto, prese della corrente comprese, con mani e piedi. Li troverete sempre con in bocca qualcosa (la peggiore), intenti ad assaporarne il gusto, oppure a fissare sbalorditi la coda del vostro gatto che incessantemente si muove ritmicamente al suono del pendolo appeso alla parete.

Questo tipo di esplorazione ha l’enorme pregio di giovarsi di un ciclo di feedback estremamente corto. Tra la sperimentazione e il risultato, tra l’ispezione e l’eventuale adattamento, passano pochi attimi.

Subito saranno in grado di comprendere se la sperimentazione fatta, possa e debba essere ripetuta. In caso affermativo, al prossimo giro, saranno in grado di applicarvi un adattamento capace di far evolvere il loro modo di ”essere” in rapporto a quella esperienza.

Fantastico, chi di voi ha figli, riscopre giornalmente quella magia

Bene. Cosa centra tutto questo con Scrum?

Scrum si basa su un approccio alla gestione dei progetti, di tipo empirico  basato su tre pilastri fondmentali: trasparenza, ispezione e adattamento.

La trasparenza. Nei rapporti, nei comportamenti, nel mostrare il lavoro fatto e nello scegliere e ‘accettare quello ancora da fare, nel reperire e interpretare le informazioni; insomma, nel permettere alla realtà di emergere, per come è “realmente”.

L’ispezione. In quel contesto di trasparenza, l’ispezione è il miglior modo per esplorare la complessità del mondo e capire se il tipo di approccio da noi utilizzato è quello corretto.

L’adattamento. Risultato “automatico”, obbligato, quasi imposto e forzato dalla stessa esperienza dell’ispezione. Ci permetterà, senza ombra di dubbio alcuno, di scartare ciò che non ha funzionato e reiterare e migliorare nella sua applicazione, ciò che ha funzionato.

E finalmente arriva quello che considero il vero collante di Scrum, nonché il suo valore più alto: il corto ciclo di feedback “impostoci” dalla sua organizzazione “time-boxed” del tempo.

Lo sprint: massimo trenta giorni di lavoro per fornire risultati veri, tangibili, verificabili da tutti! Membri del team, ScrumMaster, ProductOwner, management, committenti.

I daily scrum meeting: quindici minuti per raccontare cosa ho fatto ieri, cosa farò oggi e quali sono gli impedimenti che ho trovato. Quindi minuti appunto, non uno di più, per raccontare agli altri la tua esperienza e ascoltare e percepire quella degli altri. Farla tua.

Hai poco tempo, lo devi sfruttare al meglio per fornire agli altri le informazioni più importanti, condividerne l’esperienza: non più ego-centrici ma team-centrici.

Il planning meeeting. Una giornata di analisi, non di più. Il team deve scegliere dal product backlog, cosa implementare nel prossimo sprint e decidere come farlo. Non c’è tempo per i dettagli, per stime accurate, ti devi fidare di te, della tua esperienza, del gruppo.

Il review meeting. Mezza giornata in cui il team mostra cosa ha fatto, in piena trasparenza. Funzionalità realizzate e non, cosa ha funzionato e cosa no. Anche qui la realtà deve emergere, gli stakeholders coinvolti devono capire quale è la realtà dei fatti (sia in positivo sia in in negativo) perché anche per loro si metterà in moto il processo di adattamento. In base ai risultati raggiunti, alla velocità e alle performance dimostrate, alla visione “dal vivo” e “in anteprima” delle funzionalità, modelleranno nuove aspettative che si concretizzeranno per voi, in una revisione tangibile del product backlog.

Il retrospective meeting. Momento fondamentale di revisione del lavoro svolto: cosa ha funzionato? cosa invece no? cosa potrebbe essere migliorato? I giapponesi chiamano questo processo con una sola parola “Kaizen“. Noi lo chiamiamo miglioramento continuo.

Ken Schwaber, in uno dei suoi libri, ci racconta che in progetti SW complessi, permettere alla trasparenza di emergere, è piuttosto difficile. Pensate infatti ad un team di sette persone, in cui quattro sviluppano, due effettuano test e l’ultima scrive la documentazione. E’ impensabile permettere ad ognuno di loro di conoscere cosa stia facendo il collega affianco; e anche il daily scrum non permetterebbe loro di fare piena esperienza, delle esperienze degli altri.

E’ per questo che in quei casi ci può venire in aiuto la metodologia XP Programming e alcune sue specifiche tecniche, che permettono l’emersione della realtà in maniera automatica, costante e giornaliera. Quali sono queste tecniche?

• Integrazione continua del codice e build giornaliere: faranno emergere subito eventuali problemi e, quando invece le cose vanno bene, permetteranno ad altri membri del team di usufruire immediatamente del lavoro fatto dai colleghi.
• Test-driven development: scrittura dei test anticipatamente allo sviluppo del codice. Permette di verificare al termine della codifica di una routine, se quanto scritto è corretto.
• Pair programming: lavoro congiunto sullo stesso codice, da parte di due sviluppatori. Quattro mani, quattro occhi, due cervelli.
• Collective code ownership: ogni membro del team accede ed è responsabile di tutto il codice. Lo usa, modifica, visiona in piena libertà.

Allora? Torniamo bimbi per trenta giorni?

Beh, ora vi lascio… anche se mi è venuto in mente giusto ora, un parallelismo tra Scrum e Zen.

Si, ok, ho capito. Per stasera ve lo risparmio!

Agile PM Certification Suggested Books

Ecco i primi libri e papers suggeriti dal PMI per chi guarda alla certificazione Agile PM (vedi anche post precedenti: post1 e post2).

Papers (acquistabili per circa 15 dollari dal marketplace di PMI.org):

• Agile Project Management and the PMBOK® Guide by Michelle Sliger
• Agile PMP®: Managing software projects in the face of uncertainty by Mike Cottmeyer
• Challenges in Implementing Agile Project Management by Jesse Fewell
• Looking for an Edge by Jesse Fewell
• Selling Agile: How to get buy-in from your team, customers and managers by Michelle Sliger
• Utilizing Agile Principles Alongside the PMBOK® Guide for Better Project Execution and Control in Software
• Development Projects by Mike Griffiths

Libri:

• Agile Project Management by Jim Highsmith
• Effective Project Management: Traditional, Agile, Extreme by Robert K. Wysocki
• Project Management the Agile Way by John C. Goodpasture, PMP
• The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
• Running an Agile Software Development Project by Mike Holcombe
• Managing Agile Projects, First Edition by Kevin Aguanno, editor
• Agile Project Management: How to succeed in the face of changing project requirements by Gary Chin
• Agile Project Management with Scrum by Ken Schwaber

La lista sopra non è ancora quella ufficiale di riferimento per lo studio, ma essendo comunque fornita dal PMI credo non sarà molto diversa.

Io sono partito acquistando l’eBook dell’ultimo libro dell’elenco sopra (Agile Project Management with Scrum di Schwaber), perché consigliato anche da Simon Bennet, il trainer del corso Scrum a cui ho partecipato.

Buon libro. Approfondisce le tematiche Scrum con molti esempi sul campo e, cosa ancor più a valore aggiunto, cerca di tracciare legami tra le modalità di conduzione e rappresentazione di progetti standard con progetti agili (in questo caso Scrum appunto).

Per chi infine fosse interessato a seguire su Twitter la tematica, ecco il tag di riferimento: #PMIAgileCert

Nice morning!

Certified ScrumMaster Training: Done!

Sono sopravvissuto

Ieri è terminato il training inerente alla certificazione ScrumMaster.

E’ stato tanto complesso e faticoso quanto interessante e coinvolgente.

Innanzitutto l’intensità e la durata del corso: diciotto ore in totale nelle due giornate. Pause, diciamo così, ridotte al minimo per evitare dispersioni e cadute di concentrazione; in aula sempre disponibili caramelle, snack vari e ampia disponibilità di caffé e bevande, evitando di doversi allontanare per cercare “ristoro”.

La lingua: data la sede (Scozia) interamente in inglese. Ero l’unico non madre-lingua o che comunque non usava l’inglese giornalmente. Questo ha ovviamente giocato a mio svantaggio ed è stato di fatto un impedimento (termine caro a uno ScrumMaster).

Cervello in perenne stato di saturazione nel tentativo di gestire l’ingente mole di dati in input, i processi di traduzione, decodifica e di interpretazione e per finire con la memorizzazione di quanto appreso ed elaborato.
In certi momenti devo aver fatto un pò la figura del tonto, in quanto la mia reattività non era certo da guinness dei primati!

E’ stato però estremamente avvincente confrontarsi con persone così differenti in termini culturali, ma ancora di più ritrovare sé stesso in quel contesto, così diverso da quello usuale ed essere obbligati a cavarsela.

Lo svolgimento: SCRUM è una modalità agile, concreta e coinvolgente di condurre progetti.
Simon (il trainer) ha gestito il corso allo stesso modo. Le giornate pensate come fossero degli sprint, in cui gli argomenti da trattare erano riportati nella SCRUM Tasks Board e, all’inizio delle quali, abbiamo condotto gli SCRUM daily meeting (rigorosamente in piedi e entro i famosi quindici minuti) e a fine corso una specie di review meting per verificare quanto appreso.

E infine, cosa dal mio punta di vista a maggior valore aggiunto dell’intero corso, una serie di esercizi pratici in cui noi (il team) eravamo direttamente e “fisicamente” coinvolti nello svolgimento. Esempi dai quali ho tratto i più importanti spunti e insegnamenti.

La sfida: cosa c’è di più sfidante nel sostenere ritmi molto serrati, comunicando in una lingua diversa dalla tua, trovandoti coinvolto in team con persone che non conosci?
Infine, per dare ancora più senso alla sfida, uno stravolgente cambio di mentalità nel gestire i progetti! Questa di certo è la sfida nella sfida!

La creatività: SCRUM è un framework che indica regole piuttosto chiare a cui attenersi per gestire progetti in modo agile. Sebbene possa sembrare un contesto piuttosto rigido in cui muoversi, il team al fine di meglio collaborare, crescere e auto organizzarsi, deve essere molto aperto ai cambiamenti, agli adattamenti, essere molto curioso e coraggioso nello sperimentare: in una parola parola deve fare largo uso della creatività. Così anche noi durante il corso siamo stati chiamati a disegnare, trovare soluzioni innovative, avere a che fare con post-it di vario colore e forma per tracciare e gestire i task, valutare, trovare accordi.

 Una nota a margine.

Ero uno dei partecipanti più “anziani”: sono io che mi sono mosso in ritardo, oppure in generale, in Italia siamo parecchio indietro rispetto a questi argomenti?

L’aereo mi aspetta, ho diverse ore per pensarci! Be good

SCRUM & Large Projects

Come conciliare SCRUM e grossi progetti?

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

---

SCRUM? Let’s do it! (4^ parte)

Nei precedenti tre post abbiamo toccato tutte le tappe del tour di SCRUM. Certo non abbiamo raggiunto un livello di dettaglio eccessivo, per quello dovremmo organizzare sessioni di formazione specifiche però gli ingredienti per cominciare a “sporcarci le mani” ci sono tutti e sono sul tavolo.
E allora, cosa aspettate!

---

Portare SCRUM in azienda laddove SCRUM non fosse mai stato neanche nominato, non è cosa semplice. Però, con un pò di perseveranza, pazienza e “fede” si può fare (mi sento un pò Obama)!

Da dove cominciare? Da chi e con quali persone? Con quali strumenti e in che modo?

Beh, ecco cosa farei io se fossi nei vostri panni…

Innanzitutto riguardatevi tutti i precedenti post, connettetevi a http://www.scrumalliance.org/ e scaricatevi qualche guida da internet (ne troverete tante e parecchie sono fatte da persone certificate) e, soprattutto, studiate.

Non fermatevi alle solite guide “SCRUM for dummies”, una volta presa confidenza cercate anche informazioni estese e dettagliate sulla metodologie e, perché no, anche riguardo ad eventuali problemi o difficoltà che il metodo potrebbe portare con sé.

Vi aiuterà a farvi un’opinione critica e equilibrata.

Fatto questo è necessario prepararsi alla negoziazione.

Avrete bisogno di grosse doti di persuasione e di comunicazione perché diverse persone in azienda saranno restie a cambiare il loro modo di lavorare ormai “conclamato”.

SWOT Analysis

Uno degli strumenti più versatili che conosca, anche per casi come questo, è proprio la SWOT Analysis.

La si può usare per qualsiasi tematica: valutazione delle caratteristiche dei membri del team, come strumento di confronto e verifica tra progetti quando si deve decidere quale fare partire o ancora quando stiamo valutando una caratteristica del prodotto/servizio in fase di sviluppo e vogliamo ragionare sui rischi e benefici.

Come detto, dobbiamo prepararci alla negoziazione e, a tale scopo, è necessario procedere allo sviluppo di una strategia. Strategia, che potrebbe magicamente prendere corpo dopo aver svolto un’approfondita SWOT analysis sull’agomento.

Ricordate i quattro quadranti Strenght, Weakness, Opportunities and Threats?

Strenght: elencate quali caratteristiche innovative, punti di forza in genere, avete riscontrato nel framework. Concentratevi su quelli che avrebbero maggiore valore/impatto nel vostro contesto aziendale (ricordate Pareto e la legge 80/20?).

Weakness: ora tocca ai punti deboli. Elencate tutte quelle situazioni o caratteristiche, che difficilmente si sposano con il contesto aziendale in cui vi trovate.

Opportunities: qui elencate i vantaggi, le soluzioni, le opportunità che potrebbero aprirsi in caso riusciate a instaurare SCRUM. Un consiglio: quando parlerete con il management non dovrete perdere tempo eccessivo sui dettagli tecnici i metodologici; preparatevi piuttosto un’analisi che riguardi il ROI che vi aspettate sui prossimi progetti….questo aiuterà non poco a convincerli.

Threats: siamo arrivati alle note dolenti. Partite, innanzitutto, con l’essere onesti con voi stessi: fate un brainstorming ed elencatele tutte (le note dolenti o minacce) e cercate di dare loro una priorità in termini di impatti negativi sui progetti. Dato che stiamo parlando appunto di minacce, ossia di eventi che potrebbero presentarsi (rischi), dovreste anche procedere ad una vera e propria analisi dei rischi, con tanto di analisi qualitativa e studio degli eventuali impatti sul progetto (su costi, tempi, qualità e obiettivi).

Ottimo!

Ora passate al prossimo punto, che vi ricorda quanto segue: non cedete alla tentazione di applicare solo alcune delle componenti di SCRUM e di accantonare quelle “difficili”.
Ricordate quanto detto nel 3° post? SCRUM non potrà darvi i benefici promessi se lo applicherete solo parzialmente.

Andate dal capo

Con queste convinzioni, forti della vostra cultura in materia e con una fiammante strategia architettata grazie alla SWOT, potrete indossate il vestito migliore e, facendo tesoro di eventuali insegnamenti PNL, andate dal capo.

 

La riunione dovrebbe essere suddivisa in due parti.

Nella prima parte puntate tutto sull’aspetto persuasivo. Nella seconda, potreste elencare come intendete procedere.

Ora tocca a voi: dovrete essere convincenti.

Raccontate quanto può fare SCRUM per la vostra azienda, fate in modo che la vostra passione sia contagiosa.

Mostrate i calcoli fatti intorno al ritorno degli investimenti e allo scenario temporale relativo.

Poi passate ad elencare i rischi ma, da bravi project manager, non mancate di elencarne anche le risposte in caso di accadimento. Se tra le vostre risposte avete previsto dei fondi da accantonare (contengency reserve) assicuratevi che questi siano comunque in qualche modo coperti, anche se parzialmente, dal ROI del progetto corrente o che andrete ad accumulare anche sugli altri.

Come e cosa fare?

Nella seconda parte mostrate come e cosa vorrete fare per arrivare a governare i progetti attraverso SCRUM.

Tenete in considerazione questi piccoli suggerimenti:

• Scelta di un progetto abbordabile
• Selezione delle persone “adatte” (Product Owner e team members)
• Sessioni di formazione mirate sull’argomento
• Scelta di un tool agile di project management
• Predisposizione della war room
• Sponsorship attiva del management
• Pieno commitment dei membri del team

 

(1) Il progetto selezionato non deve essere troppo rischioso; punta su: tecnologie conosciute, finestre temporali richieste non troppo stringenti, obiettivi e requirements chiari.

(2) Se possibile, scegli i membri del team più curiosi, meno “statici” e problematici: evita quelli che alla macchinetta del caffé si lamentano del capo che troppo pretende, dei colleghi che nulla capiscono, del lavoro che troppo annoia.

(3) Ora hai un team, lo devi formare…come fare? Dai un’occhiata agli spunti di formazione sotto riportati.

(4) Non è necessario avere a disposizione tool troppo complessi; ricorda che SCRUM è agile per sua stessa natura. Avrai solo a che fare con piani analitici snelli, fogli di excel, calendari di outlook, tabelle in Access. Ma se proprio vuoi meglio organizzarti, esistono diversi tool gratuiti o opensource. Oppure perché non usare  sharepoint services 3.0?

(5) Ora il team lo devi collocare nella stessa stanza/ufficio. Questa stanza dovrà essere isolata dagli altri uffici, avere spazio sufficiente sui muri, per appenderci alcune lavagne, la burndown chart e la sprint task board.

(6) Assicurati che lo sponsor del progetto che stai per fare partire sia completamente coinvolto e percepisca l’importanza dell’esperimento che state compiendo.

(7) Lavora molto sul team, crea una vision di team, di prodotto, di progetto e poi una vision anche per ciascuno sprint: che sia allo stesso momento sfidante e accattivante. Sfidante perché le persone danno il meglio di sé quando il loro talento e le loro energie sono ben impiegate, stimolate e occupate (attenzione però a instaurare ritmi lavorativi sostenibili!). Accattivante, non tanto in termini economici, quanto come valore personale di ritorno dall’esperienza e perché no, universalmente riconosciuto tra i colleghi, in azienda.

Spunti Formativi

Ecco alcuni degli argomenti formativi che affronto in casi come questo:

• Agile values
• Agile team values
• Team self organization
• Colocation
• Emersione dei problemi
• SCRUM artifacts
• SCRUM time boxes
• SCRUM roles
• SCRUM rules
• Agile estimations (planning poker e affinity estimating)
• Definizione di lavoro terminato (DONE) e come comportarsi in presenza di lavoro non terminato (WORK NOT DONE ACTIVITIES)

 

Evasi i punti sopra non rimane che cominciare.

Prova a partire con questa checklist.

• Verifica delle info analitiche di progetto a supporto
• Fissare l’orizzonte temporale analitico, questo scandirà i tempi dello sprint
• Fissare la durata degli sprint
• Stabilire le vision
• Scrivere le user stories
• Creare il product backlog
• Analizzare i rischi
• Assegnare le priorità alle feature del backlog
• Creare la release backlog
• Cominciare lo sprint
• Procedere allo sprint planning meeting
• Verificare le stime dei task a seguito della scomposizione
• Verificare tempistiche e decidere eventuali IN/OUT delle features
• Cominciare il lavoro
• Eseguire i daly meeting
• Aggiornare burndown chart e la sprint task board
• A chiusura dello sprint, effettuare review e retrospective meeting

 

Qualche annotazione finale

I lavori di preparazione allo SCRUM potrebbero anch’essi essere implementati con SCRUM.

Prevedi per quelle attività sprint corti, da 2 settimane; questo permette frequente controllo, possibilità ravvicinate di revisione dei processi e permette al team di farsi le ossa.

Esegui la prima volta almeno tre sprint prima di fare qualsiasi revisione al processo.

Con questo termino la saga “SCRUM”.

Spero vi abbia appassionato e convinto di praticarlo anche nelle vostre aziende.

Qualora voleste essere affiancati da un formatore o da un coach per fare lo start-up, non avete che da chiedere!

A presto e in bocca al lupo!

SCRUM (2^ parte)

Ecco la seconda parte della saga “SCRUM”.

Avevamo iniziato qui (http://www.emilianosoldipmp.info/2010/11/08/scrum-1-parte/) parlando in generale di SCRUM e di una delle sue componenti principali: gli artefatti.
Oggi parleremo di altre due componenti: time boxes e ruoli.

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

---

Vorrei cominciare enunciando i diversi “perché” potresti, o dovresti,  decidere di utilizzare SCRUM per gestire i progetti nella tua azienda.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

 

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

   

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

   

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening

Pronti, partenza…..via!

Scrum è una metodologia agile che pone il focus sull’esecuzione incrementale del lavoro (release), in tempi brevi, caratterizzati da grossa coesione e spirito di iniziativa del team.

In fase analitica utilizza linee di comunicazione molto corte e, in fase di sviluppo, tempi decisionali molto brevi al fine di non dover dedicare troppo tempo allo sviluppo di documentazione analitica e reinvestire quel tempo nello sviluppo effettivo del prodotto.

Esistono tre ruoli/figure fondamentali:

• Product owner, colui che è responsabile del prodotto (solitamente il committente)
• ScrumMaster, colui che governa il processo di produzione (project manager)
• Team, gli sviluppatori che eseguono il lavoro

Le features del prodotto solitamente vengono tutte raccolte dallo ScrumMaster a seguito di interviste effettuate con il committente, gli utenti finali, gli stessi membri del team. Questa lista di funzionalità è chiamata “product backlog“.

Il secondo step è di decidere, con il product owner, quali funzionalità enteranno nelle diverse release (deliverable) ; la lista di funzionalità a capo di una release viene chiamata “release backlog“.

A questo punto entra in gioco il team che con lo ScrumMaster assegna priorità alle singole feature della release ed effettua la stima dei tempi per ciascuna.

Finalmente, in funzione del tempo in cui si vogliono suddividere gli sprint (solitamente da 2 giorni sino a 30 giorni), si scelgono le singole features e si raggruppano, appunto, in sprint.

Le singole attività vengono assegnate ai membri del team e finalmente si parte con lo sviluppo.

 La scorsa settimana abbiamo deciso di utilizzare tale tecnica per un cambio importante di release del nostro framework applicativo che ci supporta nello sviluppo delle soluzioni. L’ultimo intervento innovativo al progetto era stato fatto più di un anno fà e le segnalazioni di anomalie, bug, revisioni o migliorie erano piuttosto corpose.

Io, in quanto product owner, e il mio collega Massimiliano, ScrumMaster, abbiamo fatto la cernita di tutte le possibili features (product backlog) che potevano essere implementate.

E’ stata fatta una prima scrematura (legge 80/20 di Pareto, ricordate?) che ci ha portati ad avere una lista di features più importanti da sviluppare (release backlog).

A quel punto lo ScrumMaster e il team, hanno prioritizzato tali attività e suddiviso in sprint (che per noi era di 2 giorni), terminando con l’assegnazione dei compiti alle singole persone.

A quel punto è stato il momento del via!

Quali i risultati? Beh, oggi ho parlato con Massimiliano per avere un feedback in merito.

Cosa ha funzionato:

• I tempi sono stati rispettati tranne piccole varianze
• Praticamente tutte le feature sono state implementate
• Il lavoro del team a stretto contatto, su tematiche comuni, ha permesso la nascita di buone idee/suggerimenti
• La condivisione e la comunicazione attiva ha permesso di creare persone di backup su alcune aree di codice sino ad allora conosciute solo da singoli

Cosa non ha funzionato:

• Non tutte le persone che inizialmente erano state scelte per far parte dello “sprint team” hanno potuto partecipare attivamente, cause incombenze e urgenze lavorative

In generale comunque possiamo ritenerci soddisfatti.

Il prossimo sprint lo faremo probabilmente il prossimo mese, e lavorare molto di più sulla qualità dei processi che utilizziamo per produrre soluzioni.

ByeBye