View source for Corso Metodologie Agile per lo sviluppo di applicazioni

=Appunti=
''Appunti relativi al corso seguito il 07/04/2017'' presso il Politecnico di Milano, sponsor [https://www.spindox.it/it/ Spindox S.p.A.]<br />Prime due sessioni tenute da ''[http://www.agilereloaded.it/chi-siamo/fabio-ghislandi/ Fabio Ghislandi]'' (CERFIELD)<br />'''Coach Agile'''. (Ruolo di accompagnatore di Team all'implementazione della [https://it.wikipedia.org/wiki/Metodologia_agile metodologia AGILE]).<br />
In questi appunti con <span style="color: #800080;">(''tempo h:mm:ss'')</span> 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 ...).<br />
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 [https://www.spindox.it/it/ Spindox S.p.A.]<br />Prime due sessioni tenute da ''[http://www.agilereloaded.it/chi-siamo/fabio-ghislandi/ Fabio Ghislandi]'' (CERFIELD)<br />'''Coach Agile'''. (Ruolo di accompagnatore di Team all'implementazione della [https://it.wikipedia.org/wiki/Metodologia_agile metodologia AGILE]).<br />
In questi appunti con <span style="color: #800080;">(''tempo h:mm:ss'')</span> 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 ...).<br />
Partecipanti:

* Aino Giuseppe (Spindox);
* Cerri Francesco (Spindox);
* Giansante Fabio (Spindox);
* Pasqualicchio Gianluca (Spindox);
* Sanfilippo Fabrizio (Spindox);
* Roberta (Studentessa universitaria).
==Risorse del corso==
{| class="wikitable"
|-
! colspan="2"|Audio
|-
!|Descrizione
!|Risorsa
|-
||1° Giorno
||[http://www.aino.it/Downloads/Corsi/Agile/Audio/agile_scrum.m4a agile_scrum.m4a]
|-
||2° Giorno
||
[http://www.aino.it/Downloads/Corsi/Agile/Audio/agile_scrum_2day_1.m4a agile_scrum_2day_1.m4a]

[http://www.aino.it/Downloads/Corsi/Agile/Audio/agile_scrum_2day_1.m4a agile_scrum_2day_2.m4a]

|-
||3° Giorno
||
[http://www.aino.it/Downloads/Corsi/Agile/Audio/agile_scrum_3day_1.m4a agile_scrum_3day_1.m4a]

[http://www.aino.it/Downloads/Corsi/Agile/Audio/agile_scrum_3day_1.m4a agile_scrum_3day_2.m4a]

|-
! colspan="2"|Slide
|-
!|Descrizione
!|Risorsa
|-
||
||[http://www.aino.it/Downloads/Corsi/Agile/Slide/04_Agile_una_lunga_storia.pdf 04_Agile_una_lunga_storia.pdf]
|-
||
||[http://www.aino.it/Downloads/Corsi/Agile/Slide/07_Kanban_Board_simulation.pdf 07_Kanban_Board_simulation.pdf]
|-
||
||[http://www.aino.it/Downloads/Corsi/Agile/Slide/15_Kanban_metrics.pdf 15_Kanban_metrics.pdf]
|-
||
||[http://www.aino.it/Downloads/Corsi/Agile/Slide/Corso_Agile_Project_Management.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.: <span style="color: #800080;">('''''2g f1, tempo 8:00''''')</span> dove 2g = secondo giorno, f1 = primo file, tempo 8:00 = 8 minuto secondo 00 della registrazione
* <span style="color: #0000ff;">'''Interazioni'''</span> = Esperimenti o giochi eseguiti in classe

==Riferimenti teorici==
* Agile definizione [https://it.wikipedia.org/wiki/Metodologia_agile Wikipedia]
* [http://agilemanifesto.org/iso/it/manifesto.html Manifesto Agile]
* [https://www.scrumalliance.org/ Scrum alliance]

==Metodologia Agile==
'''Che cos'è?'''<br />E' un metodo per lo sviluppo software che si fonda su [http://agilemanifesto.org/iso/it/principles.html 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.
<br />
E' un approccio ''meno strutturato rispetto'' alle pratiche precedenti come il ''Waterfall'', attuabile con ''t'''eam 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)

====<span style="color: #0000ff;">'''(1) Interazione. Stato di partenza''' <span style="color: #800080;">(''tempo 13:09'')</span></span>====
<span style="color: #0000ff;">'''il gruppo discute si problematiche dell'attuale metodologia usata ed aspettative della nuova metodologia'''</span><br />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 <span style="color: #3366ff;">Azzurro</span> i post-it sulle <span style="color: #3366ff;">'''Issues/Problemi'''</span>, in <span style="color: #ff00ff;">Viola</span> le <span style="color: #ff00ff;">'''Wishes\aspettative'''</span>.

[[File:Agile_Interazione_cartellone_con_Issues_e_Wisches.jpg|none]]
Interventi esplicativi di quanto riportato sul cartellone:

* Fabio, <span style="color: #800080;">(''tempo 19:50'')</span>
* Giuseppe, <span style="color: #800080;">(''tempo 24:41'')</span>
* Gianluca, <span style="color: #800080;">(''tempo 31:27'')</span>
* Francesco, <span style="color: #800080;">(''tempo 34:00'')</span>
* Fabrizio, <span style="color: #800080;">(''tempo 36:00'')</span>
* Roberta, <span style="color: #800080;">(''tempo 40:55'')</span>

<br />
Si riprende al <span style="color: #800080;">(''tempo 42:30'')</span><br />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.<br />
Alcuni principi fondamentali da assumere saranno: l'autorganizzazione del team e la iterazione continua.

====<span style="color: #0000ff;">'''(2) Interazione. Esperimento-Gioco''' <span style="color: #800080;">(''tempo 45:23'')</span></span>====
<span style="color: #0000ff;">'''Si effettua un Gioco\Esperimento, metafora per parlare delle difficoltà e possibili soluzioni nell'affrontare un progetto con l'approccio più produttivo'''</span><br />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.<br />
Dati i due gruppi vince per pochi cm il gruppo A con la seguente struttura:
[[File:Agile_Costruzione_gruppo_A_particolare.png|none]]
Struttura del gruppo B, secondo classificato.
[[File:Agile_Costruzione_gruppo_B.jpg|none]]
Fine del gioco al tempo <span style="color: #800080;">(''tempo 1:10:00'')</span> Considerazioni finali dell'esperimento al <span style="color: #800080;">(''tempo 1:11:20'')</span>

=====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'''
[[File:Cosrso_Agile_statistiche_di_successo.png|none]]


In Agile abbiamo '''un tempo (come durata) noto''' entro cui cerchiamo di erogare il massimo del valore per il cliente.<br />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.<br />
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''' <span style="color: #800080;">(''tempo 1:19:00'')</span><br />
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.

<span style="color: #800080;">'''Problemi nei progetti'''</span>:

* 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'''!

[[File:Cosrso_Agile_ottimismo.png|none]]

===Principi Agile===
Di seguito elencati man mano che nel corso son citati.<br />VERIFICARE CONTINUAMENTE, TESTARE CONTINUAMENTE<br />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====
<span style="color: #800080;">(''tempo 1:25:00'')</span><br />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====
<span style="color: #800080;">(''tempo 1:29:00'')</span>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)[[File:Modello_sviluppo_waterfall.jpg|none]]

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. <br />
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====

[[File:Cosrso_Agile_confronto_Agile_WF.png|none]]

<span style="color: #800080;">(''tempo 1:33:36'')</span>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.<br />Con i principi Agile è accettato che '''il requisito possa cambiare''' nel tempo.<br />
<span style="color: #800080;">(''tempo 1:36:00'')</span><br />
Fattori di successo agile:

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

[[File:Cosrso_Agile_fattori_di_successo_01.png|none]]

<span style="color: #800080;">(''tempo 1:38:00'')</span><br />
Il '''VALORE''' è misurato dal cliente in termini di soddisfazione

[[File:Cosrso_Agile_il_valore.png|none]]

<span style="color: #800080;">(''tempo 1:41:00'')</span><br />
(''slide più importanti'')<br />
'''Approccio adattivo'''<br />
Consente di superare la variabilità dei requisiti che il cliente non è capace di formalizzare.

[[File:Cosrso_Agile_approccio_adattativo.png|none]]

<span style="color: #800080;">(''tempo 1:43:00'')</span><br />
E' utile iniziare conoscendo la definizione dei costi per adattare lo sviluppo usando prototipi.
'''Approccio predittivo'''<br />
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.
[[File:Cosrso_Agile_approccio_predittivo.png|none]]

<span style="color: #800080;">(''tempo 1:54:00'')</span><br />
'''Approccio Deming'''<br />
Deming è uno studioso (ha lavorato in Toyota) che propose un ciclo: Pianifica -> Esegui -> Verifica -> Accetta.
Con lo schema mentale del cambiamento continuo.<br />
In Agile: '''''o hai successo o impari'''''. Si procede per sperimentazioni.


<span style="color: #800080;">(''tempo 2:00:38'')</span><br />
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====
<span style="color: #800080;">(''tempo 2:06:34'')</span><br />Da [http://agilemanifesto.org/iso/it/manifesto.html 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.
[[File:Cosrso_Agile_metafora_divertente_del_perche.png|none]]
=====<span style="color: #0000ff;">'''(3) Interazione. Ordinare i principi''' <span style="color: #800080;">(''tempo 2:28:00'')</span></span>=====
Si discute su come collocare in un sistema di assi cartesiani gli 8 del manifesto (4 di sx e 4 di dx). <br />Sulle ascisse il punto di vista del Team di sviluppo, sulle ordinate il punto di vista della azienda.<br />
c'è un confronto 2 a 2 tra i principi per aiutarci a scegliere.<br /><br />
????

===Manifesto Agile===
<span style="color: #800080;">(''tempo 2:06:34'')</span><br />Creato nel 2001, composto da 12 '''principi''' [http://agilemanifesto.org/iso/it/principles.html fonte]:

# La nostra massima priorità è '''soddisfare il cliente''' rilasciando software di '''valore''', fin da <span style="text-decoration: underline;">subito e in maniera continua</span>.
# '''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====
<span style="color: #800080;">(''tempo 2:45:00'')</span><br />....<br /><span style="color: #800080;">(''tempo 2:46:00'')</span><br />
(1) Soddisfazione sin da subito rilasciando continuamente<br />
(3) Si rilascia software funzionante (rilasci in 2 settimane)<br />
Le ''iterazioni'' (dette anche ''sprint'') son generalmente da 1 a 4 settimane.<br />
(4) Accogliamo i cambiamenti (non li subiamo). Va riconosciuto il costo del cambio del requisito. Il cambiamento va tra uno sprint e l'altro

<span style="color: #800080;">(''tempo 2:55:00'')</span><br />
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: [https://it.wikipedia.org/wiki/Dependency_injection Dependency Injection], Inversion of control ([https://it.wikipedia.org/wiki/Inversione_del_controllo IOC]).<br />
Il cambiamento si accoglie in funzione della soddisfazione del cliente che non può che apprezzare.<br />
<span style="color: #800080;">(''tempo 2:58:00'')</span> Il management può fare da Proxy nei confonti del Team ma sponsorizzandolo sempre<br />
(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.

<span style="color: #800080;">(''tempo 3:09:00'')</span>
(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.<br />
<br />
(8) Sviluppo sostenibile che sottende il ritmo costante di lavoro (non oltre le 8 ore di lavoro).<br />
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).

<span style="color: #800080;">(''tempo 3:18:00'')</span>
(9) Eccellenza nella tecnica con una buona progettazione.<br />
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.

<span style="color: #800080;">(''tempo 3:25:10'')</span>
(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.

<span style="color: #800080;">(''tempo 3:30:00'')</span>
(10) Architettura. E' il team che si deve autorganizzare con piena disponibilità al confronto. '''I requisiti escono grazie al dialogo'''.

<span style="color: #800080;">(''tempo 3:30:00'')</span>
(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''.

===<span style="color: #0000ff;">'''(4) Interazione. Il proprio stato attuale e proposte''' <span style="color: #800080;">(''tempo 3:37:25'')</span></span>===
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.<br />Tabellone di risultato:[[File:Agile_stato_attuale_di_applicazione_dei_principi_e_proposte.jpg|none]]

====Commento ai risultati====
<span style="color: #800080;">(''tempo 4:03:00'')</span><br />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.
# 

<span style="color: #800080;">(''tempo 4:28:00'')</span><br />
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 [https://it.wikipedia.org/wiki/Scrum_(informatica) Scrum]

[[File:Cosrso_Agile_ombrello_metodologie.png|none]]

<span style="color: #800080;">(''tempo 4:38:58'')</span><br />Agile è come un ombrello sotto il quale abbiamo diversi strumenti come: Scrum, Kanban etc.<br />'''Canvas''' introduce l'organizzazione delle attività in un tabellone (tool di esempio è ''Trello'')<br />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.

====<span style="color: #0000ff;">'''(5) Interazione. Esperimento-Gioco''' <span style="color: #800080;">(''tempo 4:46:00'')</span></span>====
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.<br />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.<br />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:

{| class="wikitable"
|-
!|
<span style="color: #008080;">Esecutori -</span>

<span style="color: #008080;">Dimensione singolo task</span>

!|20 mattoncini
!|5 mattoncini
!|1 mattoncino
|-
||Fabio
| style="text-align: center;"|19,9 s
| style="text-align: center;"|24,9 s
| style="text-align: center;"|30,6 s
|-
||Gianluca
| style="text-align: center;"|16,6 s
| style="text-align: center;"|24,5 s
| style="text-align: center;"|-
|-
||Giuseppe
| style="text-align: center;"|25,2 s
| style="text-align: center;"|26 s
| style="text-align: center;"|29,45 s
|-
||Francesco
| style="text-align: center;"|20 s
| style="text-align: center;"|24,7 s
| style="text-align: center;"|28,1 s
|-
||
<span style="color: #0000ff;">'''TEMPI affinché tutti i mattoncini affluiscano'''</span>

<span style="color: #0000ff;">''' all'ultimo esecutore'''</span>

| style="text-align: center;"|<span style="color: #0000ff;">'''1:22'''</span>
| style="text-align: center;"|<span style="color: #0000ff;">'''42'''</span>
| style="text-align: center;"|<span style="color: #0000ff;">'''33,3'''</span>
|-
||'''Metodologia'''
| style="text-align: center;"|'''Waterfal'''
| style="text-align: center;"|'''Scrum'''
| style="text-align: center;"|'''Kanban'''
|}
<span style="color: #800080;">(</span><em style="color: #800080;">tempo 4:58:00</em><span style="color: #800080;">)</span>

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. <br />
Con le metodologie Agile aumenta l'''effort'' degli attori ma si riduce il ''time to market''.<br />
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''':<br />
Con le metodologie Agile aumenta l'''effort'' degli attori ma si riduce il ''time to market''.<br />
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.
[[File:Cosrso_Agile_gioco_piccoli_lotti_01.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_02.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_04.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_05.png|none]]

====Concetti e principi====
<span style="color: #800080;">(''tempo 5:10:30'')</span><br />Motto: "Stop starting start finishing"<br />[https://en.wikipedia.org/wiki/Dave_Snowden Dave Snowden] definì un ecosistema con cui rappresentare le realtà soggette alle metodologie di sviluppo software (framework [https://en.wikipedia.org/wiki/Cynefin_framework Cynefin]):

[[File:Cosrso_Agile_cynedin_01.png|none]]

* 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.



<span style="color: #800080;">(''tempo 5:21:05'')</span> Rappresentazione 3D

<span style="color: #800080;">(''tempo 5:24:00'')</span> Scrum è rappresentabile come una mischia del Rugby

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

<span style="color: #800080;">(''tempo 5:29:30'')</span> <br />
Pilastri di Scrum:

* '''Trasparenza''';
* '''Ispezione''';
* '''Adattamento'''.

Motto: "Inspect and adapt"

<span style="color: #800080;">(''tempo 5:31:00'')</span> Ruoli di Scrum<br />
Sprint di 1-4 settimane con obiettivo fisso. La durata è una scelta specifica!

<span style="color: #800080;">(''tempo 5:35:00'')</span> <br />
Il backlog è un elenco di attività opportunamente spaccate per ridurre la complessità e sono selezionate per rispettare la tempistica dello sprint.<br />
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=====
<span style="color: #800080;">(''tempo 5:45:30'')</span> 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''': <span style="color: #800080;">(''tempo 5:55:30'')</span> è 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.

<span style="color: #800080;">(''tempo 6:07:00'')</span> <br />
Lo '''sprint backlog''': è un insieme di attività attinte dal Prodct backlog, creato con la presenza dell'Owner.

<span style="color: #800080;">(''tempo 6:17:00'')</span> <br />
Un esempio vincite rispetto alla metodologia Waterfall è l'adozione del metodo del '''chiarimento'''.

<span style="color: #800080;">(''tempo 6:21:00'')</span> <br />
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''.

<span style="color: #800080;">(''tempo 6:27:30'')</span> <br />
Nei '''daily meeting''' ciascuno esprime:

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

<br />
La '''Story''' è la funzionalità.

<span style="color: #800080;">(''tempo 6:30:00'')</span> <br />
Il '''product owner''' deve essere sempre interpellabile anche prima di brutte novità.<br />
Alla '''review''' è opportuno ci sia il cliente ma che NON DEVE PARLARE lo potrà fare dopo la riunione e col Product owner.

<span style="color: #800080;">(''tempo 6:33:00'')</span> <br />
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.

<span style="color: #800080;">(''tempo 6:35:00'')</span> <br />
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.


<span style="color: #800080;">(''tempo 6:41:04'')</span> <br />
Fine

====Scrum (<span style="color: #ff00ff;">2 Giorno</span>)====

[[File:Cosrso_Agile_scrum_framework_01.png|none]]

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

Abbiamo analizzato le differenze tra i processi:

* '''Predittivi''' <span style="color: #800080;">(''2g f1, tempo 8:00'')</span>, come il ''Waterfall'';
* '''Adattativi''' <span style="color: #800080;">(''2g f1, tempo 10:08'')</span>, 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. <span style="color: #800080;">(''2g f1, tempo 10:08'')</span> 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=====
<span style="color: #800080;">(''2g f1, tempo 28:50'')</span>

===Kanban===
Da Wikipedia [https://en.wikipedia.org/wiki/Kanban_(development) Kanban]
<span style="color: #800080;">(''2g f2, tempo 8:00'')</span> ''ToDo'', da sbobbinare ..

==Aspetti tecnici della Metodologia==
===XP Extreme Programming===

[[File:Cosrso_Agile_Pratiche_XP.png|none]]

Ultima parte del corso, 1 giorno (8 ore), corso tenuto da [http://www.agilereloaded.it/chi-siamo/gianluca-padovani/ Gianluca PADOVANI].<br />In questa giornata si approfondiscono i principi della [https://it.wikipedia.org/wiki/Extreme_programming XP] ('''Extreme Programming''') e in seno alla XP si dettagliano gli aspetti della ''pratica'' dello sviluppo [https://en.wikipedia.org/wiki/Test-driven_development TDD] ('''Test-driven Developping'''). <br />Si esegue una esercitazione pratica TDD, in questa [[CSharp:Unit Test | pagina Wiki]] alcuni dettagli: [http://wiki.aino.it/index.php?title=CSharp:Unit_Test#Da_TDD how-to e codice C# per gli unitTest].

=Dizionario=
{| class="wikitable"
|-
!|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''':

==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.: <span style="color: #800080;">('''''2g f1, tempo 8:00''''')</span> dove 2g = secondo giorno, f1 = primo file, tempo 8:00 = 8 minuto secondo 00 della registrazione
* <span style="color: #0000ff;">'''Interazioni'''</span> = Esperimenti o giochi eseguiti in classe

==Riferimenti teorici==
* Agile definizione [https://it.wikipedia.org/wiki/Metodologia_agile Wikipedia]
* [http://agilemanifesto.org/iso/it/manifesto.html Manifesto Agile]
* [https://www.scrumalliance.org/ Scrum alliance]

==Metodologia Agile==
'''Che cos'è?'''<br />E' un metodo per lo sviluppo software che si fonda su [http://agilemanifesto.org/iso/it/principles.html 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.
<br />
E' un approccio ''meno strutturato rispetto'' alle pratiche precedenti come il ''Waterfall'', attuabile con ''t'''eam 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)

====<span style="color: #0000ff;">'''(1) Interazione. Stato di partenza''' <span style="color: #800080;">(''tempo 13:09'')</span></span>====
<span style="color: #0000ff;">'''il gruppo discute si problematiche dell'attuale metodologia usata ed aspettative della nuova metodologia'''</span><br />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 <span style="color: #3366ff;">Azzurro</span> i post-it sulle <span style="color: #3366ff;">'''Issues/Problemi'''</span>, in <span style="color: #ff00ff;">Viola</span> le <span style="color: #ff00ff;">'''Wishes\aspettative'''</span>.

[[File:Agile_Interazione_cartellone_con_Issues_e_Wisches.jpg|none]]
Interventi esplicativi di quanto riportato sul cartellone:

* Fabio, <span style="color: #800080;">(''tempo 19:50'')</span>
* Giuseppe, <span style="color: #800080;">(''tempo 24:41'')</span>
* Gianluca, <span style="color: #800080;">(''tempo 31:27'')</span>
* Francesco, <span style="color: #800080;">(''tempo 34:00'')</span>
* Fabrizio, <span style="color: #800080;">(''tempo 36:00'')</span>
* Roberta, <span style="color: #800080;">(''tempo 40:55'')</span>

<br />
Si riprende al <span style="color: #800080;">(''tempo 42:30'')</span><br />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.<br />
Alcuni principi fondamentali da assumere saranno: l'autorganizzazione del team e la iterazione continua.

====<span style="color: #0000ff;">'''(2) Interazione. Esperimento-Gioco''' <span style="color: #800080;">(''tempo 45:23'')</span></span>====
<span style="color: #0000ff;">'''Si effettua un Gioco\Esperimento, metafora per parlare delle difficoltà e possibili soluzioni nell'affrontare un progetto con l'approccio più produttivo'''</span><br />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.<br />
Dati i due gruppi vince per pochi cm il gruppo A con la seguente struttura:
[[File:Agile_Costruzione_gruppo_A_particolare.png|none]]
Struttura del gruppo B, secondo classificato.
[[File:Agile_Costruzione_gruppo_B.jpg|none]]
Fine del gioco al tempo <span style="color: #800080;">(''tempo 1:10:00'')</span> Considerazioni finali dell'esperimento al <span style="color: #800080;">(''tempo 1:11:20'')</span>

=====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'''
[[File:Cosrso_Agile_statistiche_di_successo.png|none]]


In Agile abbiamo '''un tempo (come durata) noto''' entro cui cerchiamo di erogare il massimo del valore per il cliente.<br />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.<br />
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''' <span style="color: #800080;">(''tempo 1:19:00'')</span><br />
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.

<span style="color: #800080;">'''Problemi nei progetti'''</span>:

* 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'''!

[[File:Cosrso_Agile_ottimismo.png|none]]

===Principi Agile===
Di seguito elencati man mano che nel corso son citati.<br />VERIFICARE CONTINUAMENTE, TESTARE CONTINUAMENTE<br />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====
<span style="color: #800080;">(''tempo 1:25:00'')</span><br />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====
<span style="color: #800080;">(''tempo 1:29:00'')</span>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)[[File:Modello_sviluppo_waterfall.jpg|none]]

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. <br />
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====

[[File:Cosrso_Agile_confronto_Agile_WF.png|none]]

<span style="color: #800080;">(''tempo 1:33:36'')</span>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.<br />Con i principi Agile è accettato che '''il requisito possa cambiare''' nel tempo.<br />
<span style="color: #800080;">(''tempo 1:36:00'')</span><br />
Fattori di successo agile:

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

[[File:Cosrso_Agile_fattori_di_successo_01.png|none]]

<span style="color: #800080;">(''tempo 1:38:00'')</span><br />
Il '''VALORE''' è misurato dal cliente in termini di soddisfazione

[[File:Cosrso_Agile_il_valore.png|none]]

<span style="color: #800080;">(''tempo 1:41:00'')</span><br />
(''slide più importanti'')<br />
'''Approccio adattivo'''<br />
Consente di superare la variabilità dei requisiti che il cliente non è capace di formalizzare.

[[File:Cosrso_Agile_approccio_adattativo.png|none]]

<span style="color: #800080;">(''tempo 1:43:00'')</span><br />
E' utile iniziare conoscendo la definizione dei costi per adattare lo sviluppo usando prototipi.
'''Approccio predittivo'''<br />
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.
[[File:Cosrso_Agile_approccio_predittivo.png|none]]

<span style="color: #800080;">(''tempo 1:54:00'')</span><br />
'''Approccio Deming'''<br />
Deming è uno studioso (ha lavorato in Toyota) che propose un ciclo: Pianifica -> Esegui -> Verifica -> Accetta.
Con lo schema mentale del cambiamento continuo.<br />
In Agile: '''''o hai successo o impari'''''. Si procede per sperimentazioni.


<span style="color: #800080;">(''tempo 2:00:38'')</span><br />
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====
<span style="color: #800080;">(''tempo 2:06:34'')</span><br />Da [http://agilemanifesto.org/iso/it/manifesto.html 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.
[[File:Cosrso_Agile_metafora_divertente_del_perche.png|none]]
=====<span style="color: #0000ff;">'''(3) Interazione. Ordinare i principi''' <span style="color: #800080;">(''tempo 2:28:00'')</span></span>=====
Si discute su come collocare in un sistema di assi cartesiani gli 8 del manifesto (4 di sx e 4 di dx). <br />Sulle ascisse il punto di vista del Team di sviluppo, sulle ordinate il punto di vista della azienda.<br />
c'è un confronto 2 a 2 tra i principi per aiutarci a scegliere.<br /><br />
????

===Manifesto Agile===
<span style="color: #800080;">(''tempo 2:06:34'')</span><br />Creato nel 2001, composto da 12 '''principi''' [http://agilemanifesto.org/iso/it/principles.html fonte]:

# La nostra massima priorità è '''soddisfare il cliente''' rilasciando software di '''valore''', fin da <span style="text-decoration: underline;">subito e in maniera continua</span>.
# '''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====
<span style="color: #800080;">(''tempo 2:45:00'')</span><br />....<br /><span style="color: #800080;">(''tempo 2:46:00'')</span><br />
(1) Soddisfazione sin da subito rilasciando continuamente<br />
(3) Si rilascia software funzionante (rilasci in 2 settimane)<br />
Le ''iterazioni'' (dette anche ''sprint'') son generalmente da 1 a 4 settimane.<br />
(4) Accogliamo i cambiamenti (non li subiamo). Va riconosciuto il costo del cambio del requisito. Il cambiamento va tra uno sprint e l'altro

<span style="color: #800080;">(''tempo 2:55:00'')</span><br />
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: [https://it.wikipedia.org/wiki/Dependency_injection Dependency Injection], Inversion of control ([https://it.wikipedia.org/wiki/Inversione_del_controllo IOC]).<br />
Il cambiamento si accoglie in funzione della soddisfazione del cliente che non può che apprezzare.<br />
<span style="color: #800080;">(''tempo 2:58:00'')</span> Il management può fare da Proxy nei confonti del Team ma sponsorizzandolo sempre<br />
(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.

<span style="color: #800080;">(''tempo 3:09:00'')</span>
(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.<br />
<br />
(8) Sviluppo sostenibile che sottende il ritmo costante di lavoro (non oltre le 8 ore di lavoro).<br />
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).

<span style="color: #800080;">(''tempo 3:18:00'')</span>
(9) Eccellenza nella tecnica con una buona progettazione.<br />
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.

<span style="color: #800080;">(''tempo 3:25:10'')</span>
(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.

<span style="color: #800080;">(''tempo 3:30:00'')</span>
(10) Architettura. E' il team che si deve autorganizzare con piena disponibilità al confronto. '''I requisiti escono grazie al dialogo'''.

<span style="color: #800080;">(''tempo 3:30:00'')</span>
(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''.

===<span style="color: #0000ff;">'''(4) Interazione. Il proprio stato attuale e proposte''' <span style="color: #800080;">(''tempo 3:37:25'')</span></span>===
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.<br />Tabellone di risultato:[[File:Agile_stato_attuale_di_applicazione_dei_principi_e_proposte.jpg|none]]

====Commento ai risultati====
<span style="color: #800080;">(''tempo 4:03:00'')</span><br />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.
# 

<span style="color: #800080;">(''tempo 4:28:00'')</span><br />
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 [https://it.wikipedia.org/wiki/Scrum_(informatica) Scrum]

[[File:Cosrso_Agile_ombrello_metodologie.png|none]]

<span style="color: #800080;">(''tempo 4:38:58'')</span><br />Agile è come un ombrello sotto il quale abbiamo diversi strumenti come: Scrum, Kanban etc.<br />'''Canvas''' introduce l'organizzazione delle attività in un tabellone (tool di esempio è ''Trello'')<br />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.

====<span style="color: #0000ff;">'''(5) Interazione. Esperimento-Gioco''' <span style="color: #800080;">(''tempo 4:46:00'')</span></span>====
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.<br />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.<br />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:

{| class="wikitable"
|-
!|
<span style="color: #008080;">Esecutori -</span>

<span style="color: #008080;">Dimensione singolo task</span>

!|20 mattoncini
!|5 mattoncini
!|1 mattoncino
|-
||Fabio
| style="text-align: center;"|19,9 s
| style="text-align: center;"|24,9 s
| style="text-align: center;"|30,6 s
|-
||Gianluca
| style="text-align: center;"|16,6 s
| style="text-align: center;"|24,5 s
| style="text-align: center;"|-
|-
||Giuseppe
| style="text-align: center;"|25,2 s
| style="text-align: center;"|26 s
| style="text-align: center;"|29,45 s
|-
||Francesco
| style="text-align: center;"|20 s
| style="text-align: center;"|24,7 s
| style="text-align: center;"|28,1 s
|-
||
<span style="color: #0000ff;">'''TEMPI affinché tutti i mattoncini affluiscano'''</span>

<span style="color: #0000ff;">''' all'ultimo esecutore'''</span>

| style="text-align: center;"|<span style="color: #0000ff;">'''1:22'''</span>
| style="text-align: center;"|<span style="color: #0000ff;">'''42'''</span>
| style="text-align: center;"|<span style="color: #0000ff;">'''33,3'''</span>
|-
||'''Metodologia'''
| style="text-align: center;"|'''Waterfal'''
| style="text-align: center;"|'''Scrum'''
| style="text-align: center;"|'''Kanban'''
|}
<span style="color: #800080;">(</span><em style="color: #800080;">tempo 4:58:00</em><span style="color: #800080;">)</span>

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. <br />
Con le metodologie Agile aumenta l'''effort'' degli attori ma si riduce il ''time to market''.<br />
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''':<br />
Con le metodologie Agile aumenta l'''effort'' degli attori ma si riduce il ''time to market''.<br />
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.
[[File:Cosrso_Agile_gioco_piccoli_lotti_01.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_02.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_04.png|none]]
[[File:Cosrso_Agile_gioco_piccoli_lotti_05.png|none]]

====Concetti e principi====
<span style="color: #800080;">(''tempo 5:10:30'')</span><br />Motto: "Stop starting start finishing"<br />[https://en.wikipedia.org/wiki/Dave_Snowden Dave Snowden] definì un ecosistema con cui rappresentare le realtà soggette alle metodologie di sviluppo software (framework [https://en.wikipedia.org/wiki/Cynefin_framework Cynefin]):

[[File:Cosrso_Agile_cynedin_01.png|none]]

* 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.



<span style="color: #800080;">(''tempo 5:21:05'')</span> Rappresentazione 3D

<span style="color: #800080;">(''tempo 5:24:00'')</span> Scrum è rappresentabile come una mischia del Rugby

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

<span style="color: #800080;">(''tempo 5:29:30'')</span> <br />
Pilastri di Scrum:

* '''Trasparenza''';
* '''Ispezione''';
* '''Adattamento'''.

Motto: "Inspect and adapt"

<span style="color: #800080;">(''tempo 5:31:00'')</span> Ruoli di Scrum<br />
Sprint di 1-4 settimane con obiettivo fisso. La durata è una scelta specifica!

<span style="color: #800080;">(''tempo 5:35:00'')</span> <br />
Il backlog è un elenco di attività opportunamente spaccate per ridurre la complessità e sono selezionate per rispettare la tempistica dello sprint.<br />
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=====
<span style="color: #800080;">(''tempo 5:45:30'')</span> 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''': <span style="color: #800080;">(''tempo 5:55:30'')</span> è 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.

<span style="color: #800080;">(''tempo 6:07:00'')</span> <br />
Lo '''sprint backlog''': è un insieme di attività attinte dal Prodct backlog, creato con la presenza dell'Owner.

<span style="color: #800080;">(''tempo 6:17:00'')</span> <br />
Un esempio vincite rispetto alla metodologia Waterfall è l'adozione del metodo del '''chiarimento'''.

<span style="color: #800080;">(''tempo 6:21:00'')</span> <br />
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''.

<span style="color: #800080;">(''tempo 6:27:30'')</span> <br />
Nei '''daily meeting''' ciascuno esprime:

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

<br />
La '''Story''' è la funzionalità.

<span style="color: #800080;">(''tempo 6:30:00'')</span> <br />
Il '''product owner''' deve essere sempre interpellabile anche prima di brutte novità.<br />
Alla '''review''' è opportuno ci sia il cliente ma che NON DEVE PARLARE lo potrà fare dopo la riunione e col Product owner.

<span style="color: #800080;">(''tempo 6:33:00'')</span> <br />
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.

<span style="color: #800080;">(''tempo 6:35:00'')</span> <br />
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.


<span style="color: #800080;">(''tempo 6:41:04'')</span> <br />
Fine

====Scrum (<span style="color: #ff00ff;">2 Giorno</span>)====

[[File:Cosrso_Agile_scrum_framework_01.png|none]]

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

Abbiamo analizzato le differenze tra i processi:

* '''Predittivi''' <span style="color: #800080;">(''2g f1, tempo 8:00'')</span>, come il ''Waterfall'';
* '''Adattativi''' <span style="color: #800080;">(''2g f1, tempo 10:08'')</span>, 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. <span style="color: #800080;">(''2g f1, tempo 10:08'')</span> 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=====
<span style="color: #800080;">(''2g f1, tempo 28:50'')</span>

===Kanban===
Da Wikipedia [https://en.wikipedia.org/wiki/Kanban_(development) Kanban]
<span style="color: #800080;">(''2g f2, tempo 8:00'')</span> ''ToDo'', da sbobbinare ..

==Aspetti tecnici della Metodologia==
===XP Extreme Programming===

[[File:Cosrso_Agile_Pratiche_XP.png|none]]

Ultima parte del corso, 1 giorno (8 ore), corso tenuto da [http://www.agilereloaded.it/chi-siamo/gianluca-padovani/ Gianluca PADOVANI].<br />In questa giornata si approfondiscono i principi della [https://it.wikipedia.org/wiki/Extreme_programming XP] ('''Extreme Programming''') e in seno alla XP si dettagliano gli aspetti della ''pratica'' dello sviluppo [https://en.wikipedia.org/wiki/Test-driven_development TDD] ('''Test-driven Developping'''). <br />Si esegue una esercitazione pratica TDD, in questa [[CSharp:Unit Test | pagina Wiki]] alcuni dettagli: [http://wiki.aino.it/index.php?title=CSharp:Unit_Test#Da_TDD how-to e codice C# per gli unitTest].

=Dizionario=
{| class="wikitable"
|-
!|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''':