Appunti

Appunti relativi al corso seguito il 07/04/2017 presso il Politecnico di Milano, sponsor Spindox S.p.A.
Prime due sessioni tenute da Fabio Ghislandi (CERFIELD)
Coach Agile. (Ruolo di accompagnatore di Team all'implementazione della metodologia AGILE).
In questi appunti con (tempo h:mm:ss) indicherò il momento della sequenza di registrazione in cui un concetto è trattato in modo da potere riascoltare esattamente quel che si vuole (disponendo del file di registrazione ...).
Partecipanti:

Aino Giuseppe (Spindox);
Cerri Francesco (Spindox);
Giansante Fabio (Spindox);
Pasqualicchio Gianluca (Spindox);
Sanfilippo Fabrizio (Spindox);
Roberta (Studentessa universitaria).

Appunti

Appunti relativi al corso seguito il 07/04/2017 presso il Politecnico di Milano, sponsor Spindox S.p.A.
Prime due sessioni tenute da Fabio Ghislandi (CERFIELD)
Coach Agile. (Ruolo di accompagnatore di Team all'implementazione della metodologia AGILE).
In questi appunti con (tempo h:mm:ss) indicherò il momento della sequenza di registrazione in cui un concetto è trattato in modo da potere riascoltare esattamente quel che si vuole (disponendo del file di registrazione ...).
Partecipanti:

Aino Giuseppe (Spindox);
Cerri Francesco (Spindox);
Giansante Fabio (Spindox);
Pasqualicchio Gianluca (Spindox);
Sanfilippo Fabrizio (Spindox);
Roberta (Studentessa universitaria).

Risorse del corso

Audio
Descrizione	Risorsa
1° Giorno	agile_scrum.m4a
2° Giorno	agile_scrum_2day_1.m4a agile_scrum_2day_2.m4a
3° Giorno	agile_scrum_3day_1.m4a agile_scrum_3day_2.m4a
Slide
Descrizione	Risorsa
	04_Agile_una_lunga_storia.pdf
	07_Kanban_Board_simulation.pdf
	15_Kanban_metrics.pdf
	Corso_Agile_Project_Management.pdf

1a Giornata

"Dal PM tradizionale all'Agile Project Management":

Perché Agile?
Il Manifesto Agile
Panoramica dei framework Agili
Complessità e processi adattivi
Scrum: Introduzione e Ruoli

2a Giornata

"Framework, pratiche di Agile Project Management":

Scrum: Artifatti e Cerimonie
Backlog, stime e pianificazione
Lean e Kanban

3a Giornata

"Agile in pratica

XP, Extreme Programming"
Pair Programming
TDD, Test-driven Programming

Legenda del documento

Il riferimento assoluto al file audio avviene mediante il testo come ad es.: (2g f1, tempo 8:00) dove 2g = secondo giorno, f1 = primo file, tempo 8:00 = 8 minuto secondo 00 della registrazione
Interazioni = Esperimenti o giochi eseguiti in classe

Riferimenti teorici

Metodologia Agile

Che cos'è?
E' un metodo per lo sviluppo software che si fonda su 12 principi ma sostanzialmente propone un approccio:

focalizzato sull'obiettivo (rispettando la consegna e dando il massimo valore per il cliente);
mediante consegne frequenti e brevi (dalle 2-4 settimane);
consegnando software funzionante e di qualità.

Agile è:

velocizzare il time to market;
allineare business e tecnologia;
creare valore per il cliente finale.

E' un approccio meno strutturato rispetto alle pratiche precedenti come il Waterfall, attuabile con team di sviluppo piccoli, cross-funzionali e auto-organizzati, lo sviluppo è iterativo ed incrementale, la pianificazione adattativa, e c'è il coinvolgimento diretto e continuo del cliente nel percorso di sviluppo.

Presupposti al cambiamento - la nuova Metodologia

Prima parte del corso composto da 2 giorni (16 ore)

(1) Interazione. Stato di partenza (tempo 13:09)

il gruppo discute si problematiche dell'attuale metodologia usata ed aspettative della nuova metodologia
Si chiede di esplicitare le problematiche dando come traccia i seguenti argomenti:

Tempo
Metodologia adottata
Periodicità
Pianificazione (ad es. se è realistica o disattesa)
Comunicazione (ad es. se utile, propositiva, se esistono metriche di valutazione)
Burocrazia (se buona o cattiva)
Processi

Ecco il risultato: in Azzurro i post-it sulle Issues/Problemi, in Viola le Wishes\aspettative.

Agile Interazione cartellone con Issues e Wisches.jpg

Interventi esplicativi di quanto riportato sul cartellone:

Fabio, (tempo 19:50)
Giuseppe, (tempo 24:41)
Gianluca, (tempo 31:27)
Francesco, (tempo 34:00)
Fabrizio, (tempo 36:00)
Roberta, (tempo 40:55)

Si riprende al (tempo 42:30)
L'immagine rappresentativa di Agile può essere un coltellino Svizzero in cui ogni lama è suo strumento Agile (es Scrum Kanban, pomodoro Techinique). Non è un blocco da assumere totalmente ma trattasi di strumenti a cui attingere anche in parte.
Alcuni principi fondamentali da assumere saranno: l'autorganizzazione del team e la iterazione continua.

(2) Interazione. Esperimento-Gioco (tempo 45:23)

Si effettua un Gioco\Esperimento, metafora per parlare delle difficoltà e possibili soluzioni nell'affrontare un progetto con l'approccio più produttivo
Consiste nel realizzare una costruzione con:

20 spaghetti
Un metro spago, un metro di nastro adesivo.
Un marshmallow

in un tempo definito. Il marshmallow deve essere posto in cima alla costruzione fatta di spaghetti. La costruzione deve essere più alta di quella del gruppo concorrente, non deve poggiarsi ad oggetti dell'arredo tranne che per il piano del tavolo su cui poggia, il tutto in 18 minuti.
Dati i due gruppi vince per pochi cm il gruppo A con la seguente struttura:

Agile Costruzione gruppo A particolare.png

Struttura del gruppo B, secondo classificato.

Fine del gioco al tempo (tempo 1:10:00) Considerazioni finali dell'esperimento al (tempo 1:11:20)

Considerazioni

Unico requisito certo è il tempo noto, altro sono le risorse limitate;
Non abbiamo fatto una azione iniziale di progettazione;
è stata prevalente la fase sperimentale, dopo un accordo iniziale si è partiti cambiando l'intento iniziale in corso d'opera;
S'è adottato approccio adattivo. S'è cambiato il punto di vista in base al contesto.

Statistiche sull'andamento dello stesso esperimento tra varie categorie di lavoratori

Cosrso Agile statistiche di successo.png

In Agile abbiamo un tempo (come durata) noto entro cui cerchiamo di erogare il massimo del valore per il cliente.
In Agile il requisito non è fisso, è variabile. E' quel che accade nella realtà in cui il Cliente stesso non sa cosa vuole, il requisito andrà a definirsi. Il cliente può non capire il requisito oltre che non riuscire ad esprimerlo.
In questi casi ad esempio è la prototipazione che può aiutare noi ma soprattutto il cliente a capire e definire i requisiti del prodotto richiesto. Il requisito potrà essere definito nel tempo. Nell'esperimento fatto è utile da subito capire quando e come va messo il marshmallow e lo si scopre sperimentando; in particolare se da subito si prova a metterlo su uno spaghetto, quindi avendo da subito chiaro e testabile l'obiettivo. Invece la tendenza è quella di rimandare alla fine il momento in cui si pone il marshmallow e che può esser disastroso, facendo l'analogia con lo sviluppo software (waterfall) questo è identificabile col momento del test che è posto solitamente alla fine quando può essere troppo tardi.

Altro (tempo 1:19:00)
La curiosità è dimostrato essere fondamentale come nel nostro esperimento. I bambini lo sono e in più vogliono sperimentare (scoprendo subito che il peso del marshmallow può essere distruttivo), sono ansiosi e provano subito quel che fanno, quindi adottano il test continuo.

Problemi nei progetti:

Mancanza della gestione del cambiamento dei requisiti
Cattiva comunicazione
Inadeguatezza del Team
Requisiti non ben definiti
Stime non accurate
Mancanza di un piano di gestione dei Rischi
Cattiva definizione di cosa significa “Finito”
Non dedicare il giusto tempo alla gestione del progetto
Mancanza della conoscenza di come si gestisce un progetto
Essere sempre troppo ottimisti!

Principi Agile

Di seguito elencati man mano che nel corso son citati.
VERIFICARE CONTINUAMENTE, TESTARE CONTINUAMENTE
Noi che abbiamo una mentalità strutturata non ci concentriamo sulla struttura e non sul risultato. E' questa dimensione che con Agile vogliamo recuperare. Mettersi nelle condizioni di verificare continuamente come stà andando il nostro lavoro. Ci piace vedere il prodotto finito ad ogni iterazione.

Elenco di cose statisticamente che non vanno

(tempo 1:25:00)
Problematiche più ricorrenti:

Mancanza della gestione del cambiamento dei requisiti;
cattiva comunicazione
Inadeguatezza del team
Requisiti non ben definiti
Stime non accurate
Mancanza di un piano di gestione dei rischi
Cattiva definizione di cosa significa finito, mancato accordo in merito. (quando si scopre che non ci sono test, test con scarsa copertura)
Non dedicare il giusto tempo alla gestione del progetto oppure mancanza della conoscenza di come si gestisce un progetto
Essere troppo ottimisti

Waterfall

(tempo 1:29:00)E' il modello a cascata, in cui ogni fase deve essere finita atomicamente per poter passare alla successiva (di solito con la produzione di un documento)

Ad ogni cambiamento si rifa il giro, risalendo la cascata. Non risponde ad esigenze di rapidità. E' facile il fraintendimento anche perché si parla attraverso documenti, la produzione dei documenti fa spendere troppo tempo. Nullo il tempo per il test, o lo riduco.
Il waterfall management institute, che fornisce le certificazioni PMI, ha introdotto una certificazione ACP agile per la parte IT (proprio per riconoscere nel contesto IT una sorta di fallimento).

Differenze Waterfall - Agile

(tempo 1:33:36)Sostanzialmente in Agile il solo 9% di insuccesso risalta. Possibili motivazioni sono nel continuo test (anche inteso come valutazione dello stesso requisito) e nel coinvolgimento del cliente.
Con i principi Agile è accettato che il requisito possa cambiare nel tempo.
(tempo 1:36:00)
Fattori di successo agile:

Il team
Sponsorship management. (capacità di reazione)
Interazione col cliente

(tempo 1:38:00)
Il VALORE è misurato dal cliente in termini di soddisfazione

(tempo 1:41:00)
(slide più importanti)
Approccio adattivo
Consente di superare la variabilità dei requisiti che il cliente non è capace di formalizzare.

(tempo 1:43:00)
E' utile iniziare conoscendo la definizione dei costi per adattare lo sviluppo usando prototipi. Approccio predittivo
Ad esempio si cita l'esempio dell'implementazione di una app semplicissima (ricerca delle fonti di un piccolo testo\citazione) con cui da questo piccolo risultato si verifica il mercato (livello di interesse) e di conseguenza si prosegue con lo sviluppo orientato.

(tempo 1:54:00)
Approccio Deming
Deming è uno studioso (ha lavorato in Toyota) che propose un ciclo: Pianifica -> Esegui -> Verifica -> Accetta. Con lo schema mentale del cambiamento continuo.
In Agile: o hai successo o impari. Si procede per sperimentazioni.

(tempo 2:00:38)
Per problema di budget si può procedere al una vendita a Sprint (con continui feedback). I Clienti dopo un blocco iniziale, capiscono e poi ritornano.

I 4 valori Agile

(tempo 2:06:34)
Da agilemanifesto,"Siamo arrivati a considerare importanti":

Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.

Cosrso Agile metafora divertente del perche.png

(3) Interazione. Ordinare i principi (tempo 2:28:00)

Si discute su come collocare in un sistema di assi cartesiani gli 8 del manifesto (4 di sx e 4 di dx).
Sulle ascisse il punto di vista del Team di sviluppo, sulle ordinate il punto di vista della azienda.
c'è un confronto 2 a 2 tra i principi per aiutarci a scegliere.

????

Manifesto Agile

(tempo 2:06:34)
Creato nel 2001, composto da 12 principi fonte:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.
Il software funzionante è il principale metro di misura di progresso.
I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità.
La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.
Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Analisi di ciascun principio

(tempo 2:45:00)
....
(tempo 2:46:00)
(1) Soddisfazione sin da subito rilasciando continuamente
(3) Si rilascia software funzionante (rilasci in 2 settimane)
Le iterazioni (dette anche sprint) son generalmente da 1 a 4 settimane.
(4) Accogliamo i cambiamenti (non li subiamo). Va riconosciuto il costo del cambio del requisito. Il cambiamento va tra uno sprint e l'altro

(tempo 2:55:00)
Il sw va sviluppato bene in modo da preservarci sul fatto che il cambiamento deve avere uno sviluppo sostenibile. Si cerca di lavorare in eccellenza quindi adottare i principi classici della programmazione ad oggetti, adottare pattern architetturali tipo: Dependency Injection, Inversion of control (IOC).
Il cambiamento si accoglie in funzione della soddisfazione del cliente che non può che apprezzare.
(tempo 2:58:00) Il management può fare da Proxy nei confonti del Team ma sponsorizzandolo sempre
(5) Gli sviluppatori del Team sono gli artigiani del software. Mentre nella società preindustriale gli artigiani erano Thinker e Dooer poi sè passati a scindere i due ruoli. Ora ci siamo accorti che questi ruoli devono riunirsi non solo per evitare l'alienazione delle persone coinvolte ma anche per esser maggiormente resilienti al cambiamento.

Le persone devono esser motivate. (6) Comunicazione. E' da preferire il colloquio faccia a faccia è deprecabile l'uso delle email.

(tempo 3:09:00) (7) Produzione di sw funzionante. E' auspicabile che il team sia unito ad ogni iterazione e non subisca distrazioni. E' stato calcolato in un costo del 20% ogni volta che una persona venga distolta da una attività per farla dedicare ad un'altra.

(8) Sviluppo sostenibile che sottende il ritmo costante di lavoro (non oltre le 8 ore di lavoro).
I team son formati con persone che si scelgono tra loro e le competenze devono esser trasversali (es. funzionali prendendo ad es. dalle interfacce grafiche sino al DataBase).

(tempo 3:18:00) (9) Eccellenza nella tecnica con una buona progettazione.
Si può pensare di creare delle tribù di persone unite con stessi interessi e con competenze trasversali. Queste posson esser viste come dei motori di autofromazione e per fare ricerca ed innovazione. Tribù chiamate anche GILD.

(tempo 3:25:10) (10) Semplicità. Occorre concentrarsi su cosa è importante. Questa deve essere la strada maestra. Creare moduli più piccoli, non deve essere la singola parte complessa ma l'insieme.

(tempo 3:30:00) (10) Architettura. E' il team che si deve autorganizzare con piena disponibilità al confronto. I requisiti escono grazie al dialogo.

(tempo 3:30:00) (12) Riflettere sull'efficacia. E' una sorta di tagliando che il team deve fare. Sono riunioni che si fanno in cui si elencano i successi e le cose da rivedere nel team, deve essere coinvolto anche il product owner.

(4) Interazione. Il proprio stato attuale e proposte (tempo 3:37:25)

Dati due gruppi ciascuno prende 6 principi della metodologia e riflette dando un punteggio sull'attuale livello di applicazione nel proprio contesto lavorativo e la proposta affinché da domani si possa migliorare.
Tabellone di risultato:

Agile stato attuale di applicazione dei principi e proposte.jpg

Commento ai risultati

(tempo 4:03:00)
Per ciascun principio:

Adottare il commerciale in un ruolo da proxy. Far capire al cliente che è meglio classificare le sue richieste dando delle priorità e attendendo l'opportuno sprint per le implementazioni;
La scelta delle persone del Team spetta al Team, le persone del Team devono esser stabili. E' opportuno anche un ambiente di lavoro favorevole, no openspace, cercare un modo per comunicare più efficacemente gli errori.
Meno email più conversazione. (una email in cui ci son almeno 2 risposte richiedono un colloquio).
Occorre più curiosità ed attenzione
Ha un ruolo solo inizialmente.

(tempo 4:28:00)
Ci sono 4 attività che un fornitore di solito fa e son da far capire al cliente in occasioni dei cambiamenti tecnologici da far passare:

attività standard. Che sono quelle per cui data una richiesta questa viene implementata.
attività fixed. Quelle in cui c'è una scadenza perentoria ed utile (promozione di Natale).
attività expedit. Bug fixing, critical ..
attività intangible. Attività che il team si sente di dover fare per non accumulare debito tecnico. Il Cliente non è dato che debba capire ma che altrimenti si pagherà dopo. Si posson giustificare col fatto che se fatte ci faranno guadagnare di velocità, di affidabilità. Ci son cose utili già fatte che non dobbiam implemetare noi. Ci consentiranno di aderire a determinati standard. Il cliente non può misuralo ora, non è un problema attuale ma è uno in meno che avrà dopo.

La responsabilità tecnica è del team e deve esser lasciato libero di decidere con opportune riunioni, anche stesse iterazioni della metodologia.

Scrum

Da wikipedia Scrum

(tempo 4:38:58)
Agile è come un ombrello sotto il quale abbiamo diversi strumenti come: Scrum, Kanban etc.
Canvas introduce l'organizzazione delle attività in un tabellone (tool di esempio è Trello)
I framework Scrum, Kanban sono i più diffusi. Sono framework (basi su cui innestare il nostro lavoro) organizzativi alternativi tra loro;

Scrum è introdotto solitamente per nuovi progetti o quando il team è nuovo alle metodologie Agile. E' un pò più rigido rispetto all'altro.
mentre Kanban è utilizzato in altri casi ed è appunto quello preferito quando la macchina organizzativa è a regime.

(5) Interazione. Esperimento-Gioco (tempo 4:46:00)

Si effettua un gioco con dei mattoncini Lego di forma uguale ma colore diverso. I mattoncini dello stesso colore sono in numero uguale. Questo gioco si compone di tre iterazioni, lo scopo in ciascuna e quella di passare tutti i mattoncini nel più breve tempo possibile.
Le performance sono misurate in modo che si quantifichi il tempo di ciascun soggetto del gruppo e anche il tempo complessivo per trasferire i mattoncini dal primo all'ultimo attore.
Gli attori sono messi in sequenza, uno accanto all'altro, ognuno ha come attività di organizzare i mattoncini e passarli al compagno (attore) accanto. Seguono i 3 diversi metodi di organizzazione del lavoro per raggiungere lo stesso scopo:

prima con tutti i mattoncini dello stesso colore si rivoltano e nonappena son tutti rivoltati si passa fare la stessa cosa col colore successivo, solo ora si passano tutti i mattoncini al compagno accanto;
come nel procedimento precedente si rivoltano i mattoncini dello stesso colore ma nonappena questi son tutti pronti si passano in blocco subito al compagno accanto e si ripete il procedimento per i colori restanti;
ciascun compagno rivolta il singolo mattoncino e subito lo passa al compagno accanto avendo cura di finire prima i mattoncini dello stesso colore.

Conclusioni

Tabella di comparazione dei risultati sul "time to market" delle tre metodologie:

Esecutori - Dimensione singolo task	20 mattoncini	5 mattoncini	1 mattoncino
Fabio	19,9 s	24,9 s	30,6 s
Gianluca	16,6 s	24,5 s	-
Giuseppe	25,2 s	26 s	29,45 s
Francesco	20 s	24,7 s	28,1 s
TEMPI affinché tutti i mattoncini affluiscano all'ultimo esecutore	1:22	42	33,3
Metodologia	Waterfal	Scrum	Kanban

(tempo 4:58:00)

Il primo procedimento (20 mattoncini per task) è analogo all'approccio waterfall e sebbene i tempi di ciascun attore sono inferiori, il risultato finale è il doppio rispetto al procedimento 3 (1 solo mattoncino) che è l'applicazione del Kanban. Il secondo procedimento è l'applicazione dello scrum, anche da questo metodo si capisce che si ha un tempo inferiore per il raggiungimento dell'obiettivo finale.
Con le metodologie Agile aumenta l'effort degli attori ma si riduce il time to market.
Con la metodologia Agile è la staffetta che gira più veloce. Il team deve lavorare bene perché il risultato finale sia maggiore della somma dei singoli risultati degli elementi che costituiscono il gruppo.

Risultati:
Con le metodologie Agile aumenta l'effort degli attori ma si riduce il time to market.
Con la metodologia Agile è la staffetta che gira più veloce. Il team deve lavorare bene perché il risultato finale sia maggiore della somma dei singoli risultati degli elementi che costituiscono il gruppo.

Concetti e principi

(tempo 5:10:30)
Motto: "Stop starting start finishing"
Dave Snowden definì un ecosistema con cui rappresentare le realtà soggette alle metodologie di sviluppo software (framework Cynefin):

Realtà semplici. In cui chiunque potrebbe predire il comportamento atteso.
Realtà composte. Il dominio è tenuto da alcuni soggetti che con la comunicazione trasmettono il know ho necessario.
Realtà complesse. L'analisi è eseguibile mediante delle prove iterative.
Realtà caotiche. In cui è fondamentale l'azione.

Le prime due sono nel campo deterministico mentre è nelle seconde due che c'è il campo d'azione delle metodologie Agile.

(tempo 5:21:05) Rappresentazione 3D

(tempo 5:24:00) Scrum è rappresentabile come una mischia del Rugby

Questi strumenti hanno una efficacia relativa e tendono al miglioramento continuo.
I team si autocontrollano come avviene in natura (scrum guide).

(tempo 5:29:30)
Pilastri di Scrum:

Trasparenza;
Ispezione;
Adattamento.

Motto: "Inspect and adapt"

(tempo 5:31:00) Ruoli di Scrum
Sprint di 1-4 settimane con obiettivo fisso. La durata è una scelta specifica!

(tempo 5:35:00)
Il backlog è un elenco di attività opportunamente spaccate per ridurre la complessità e sono selezionate per rispettare la tempistica dello sprint.
Ogni feature dello sprint è spaccata in n attività. Nello sprint planning, che è una riunione apposita, si seleziona come creare lo sprint backlog. Lo sprint planning rientra in quel che fa parte delle "cerimonie".

Ruoli

(tempo 5:45:30) Ruoli

Product owner: è il conoscitore del dominio. Definisce il "cosa" e "perché". E' l'interfaccia col cliente se non appartenente direttamente al cliente stesso. Non deve appartenere al Team, non può essere lo scum master. Può seguire più Team per più progetti ma deve essere una persona. Dice cosa si deve fare e l'ordine.
Scrum master: (tempo 5:55:30) è un facilitatore del processo. Garante del metodo.
Team di sviluppo: definisce il "come". Ha una responsabilità tecnica collettiva, in esso risiedono tutte le competenze. Non più di 9 persone.

(tempo 6:07:00)
Lo sprint backlog: è un insieme di attività attinte dal Prodct backlog, creato con la presenza dell'Owner.

(tempo 6:17:00)
Un esempio vincite rispetto alla metodologia Waterfall è l'adozione del metodo del chiarimento.

(tempo 6:21:00)
Ci sono degli sprint prepartori che magari coinvolgono attori diversi rispetto a quelli del Team di sviluppo ma che servono a creare i presupposti per la partenza del progetto. Si creano i primi insiemi sul Product Backlog per i primi sprint. Partono quando il sistema deve ancora essere implementato. I primi sprint quindi sono per organizzare il lavoro.

(tempo 6:27:30)
Nei daily meeting ciascuno esprime:

Cosa ha fatto ieri;
Cosa farà oggi;
Che impedimenti si sono avuti.

La Story è la funzionalità.

(tempo 6:30:00)
Il product owner deve essere sempre interpellabile anche prima di brutte novità.
Alla review è opportuno ci sia il cliente ma che NON DEVE PARLARE lo potrà fare dopo la riunione e col Product owner.

(tempo 6:33:00)
In Scrum non ci sono figure che impongono dictat ma vige una uguaglianza di fondo tra gli attori. C'è invece chi aiuta a prendere delle decisioni.

(tempo 6:35:00)
Una metrica che si può valutare dopo i primi sprint è la VELOCITY che servirà per fare delle stime sul Futuro pur essendo in gioco un approccio adattativo.

(tempo 6:41:04)
Fine

Scrum (2 Giorno)

Si riprendono i concetti sviluppati nella prima giornata con lo stesso Fabio Ghislandi.

Abbiamo analizzato le differenze tra i processi:

Predittivi (2g f1, tempo 8:00), come il Waterfall;
Adattativi (2g f1, tempo 10:08), secondo le metodologie Agile. Es. Scum, Kanban. Il prodotto è realizzato secondo un piano incrementale che ha l'effetto di realizzare una prototipazione a vari livelli.

Abbiamo messo in risalto i valori Agile a confronto con quelli ritenuti importanti in altre metodologie.

Si esalta l'importanza delle persone piuttosto che gli strumenti.
Si tende alla realizzazione software funzionante piuttosto che scrivere un contratto ed una documentazione esaustiva. Si produce documentazione ma che debba servire. (2g f1, tempo 10:08) Si predilige un clima collaborativo col cliente piuttosto che tendere a scrivere un contratto esaustivo che non lo sarà mai.
Si punta a rispondere al cambiamento piuttosto che altro.

ToDo

Cos'è Scrum

(2g f1, tempo 28:50)

Kanban

Da Wikipedia Kanban (2g f2, tempo 8:00) ToDo, da sbobbinare ..

Aspetti tecnici della Metodologia

XP Extreme Programming

Ultima parte del corso, 1 giorno (8 ore), corso tenuto da Gianluca PADOVANI.
In questa giornata si approfondiscono i principi della XP (Extreme Programming) e in seno alla XP si dettagliano gli aspetti della pratica dello sviluppo TDD (Test-driven Developping).
Si esegue una esercitazione pratica TDD, in questa pagina Wiki alcuni dettagli: how-to e codice C# per gli unitTest.

Dizionario

Termine	Definizione
Artefatto	Lavoro concreto
Daily scrum meeting	Ogni giorno di attività si effettua una riunione breve di tutti i componenti del team. Che cosa è stato fatto ieri. Che cosa si farà domani. Quali sono gli impedimenti / ostacoli incontrati.
Framework	E' la base su cui innestare il nostro lavoro. Nelle metodologia Agile esempi sono: Scrum e Kanban
Product backlog	E' una lista ordinata dei "requisiti" relativi ad un prodotto.
Product owner	E' la voce del cliente. Membro interno alla azienda software oppure appartenente al cliente il cui ruolo è quello di definire le priorità col team di sviluppo, e definire anche i requisiti. È responsabile per assicurare che il team fornisca valore al business.
Scum master	Garante della metodologia. Lo ScrumMaster non è il team leader, ma piuttosto colui che facilita una corretta esecuzione del processo.
Sprint	Anche detta Iteration. E' un'unità di base (una attività) dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro settimane.
Sprint backlog	E' la lista del lavoro che il team di sviluppo deve effettuare nel corso dello sprint successivo.
Sprint retrospective	E' l'occasione per il Team Scrum per ispezionare se stesso e creare un piano di miglioramento da attuare durante il prossimo Sprint.
Team di sviluppo	Insieme di tecnici composto al più da 9 persone. Sviluppatori, Analisti, Testers.
Time to market	(o TTM) indica il tempo che intercorre dall'ideazione di un prodotto alla sua effettiva commercializzazione.
UX	User Experience

Mappa e Link

Seminari Incontri Progetti Relazioni

Risorse varie

Parole chiave: