Il documento discute il concetto di sviluppo software agile, evidenziando la sua evoluzione attraverso varie metodologie come Scrum e Extreme Programming. Presenta i principi e dogmi dell'approccio agile, enfatizzando la collaborazione tra team e clienti, la flessibilità e l'importanza di un software funzionante. Viene inoltre menzionata l'importanza di creare una cultura agile all'interno delle organizzazioni e di affrontare le sfide comuni che possono sorgere durante l'implementazione di tali metodologie.

1.
LUCIANO AMODIO
16 NOVEMBRE 2016
#FORUMIISL
AGILE WEB DEVELOPMENT

2. Strategia
Aziendale
Marketing
Artista Visionario
CHI SONO
Filosofo
per Hobby
Consulente
Cloud
Computing

3. DA DOVE VENGO PIETRELCINA

4. DA DOVE VENGO BARCELONA

5. DA DOVE VENGO DUBAI

6. COSA SIGNIFICA
SVILUPPO AGILE?

7. AGILITÀ
1. Capacità di cambiare direzione facilmente.
2. In fisica e nella tecnica: capacità di un sistema di variare
facilmente uno o più dei suoi parametri operativi.

8. IL MANIFESTO PER LO SVILUPPO SOFTWARE AGILE

9. PRECURSORI AGILI
1992 - Crystal Methods: consegne frequenti, miglioramento riflessivo,
comunicazioni osmotiche
1993 - Refactoring: Bill Opdyke
1994 - Dynamic Systems Development Method (DSDM): Consorzio di best practices
1995 - Scrum: Jeff Sutherland & Ken Schwaber
1997 - Feature Driven Development: Jeff De Luca
1999
The pragmatic programmer
XP: Kent Beck (User Stories, Release Planning, Continuous integration)
Adaptive So ware Development (ASD)
2002
TDD: Kent Beck
Planning Poker
Lean So ware Development: Mary and Tom Poppendieck

10. I 4 DOGMI DEL MANIFESTO AGILE
1. Gli individui e le interazioni più che i processi e gli strumenti
2. Il so ware funzionante più che la documentazione esaustiva
3. La collaborazione col cliente più che la negoziazione dei contratti
4. Rispondere al cambiamento più che seguire un piano

11. I 12 PRINCIPI AGILE
1. Soddisfare il cliente con continue consegne di so ware di valore
2. Accogliere il cambio di requisiti per il vantaggio del progetto
3. Consegnare so ware funzionante frequentemente
4. Affiancare Business e Sviluppo per la durata dei lavori
5. Costruire progetti attorno a persone motivate, offrendo supporto e fiducia
6. Conversare faccia a faccia per ottimizzare la comunicazione nel team
7. Il so ware funzionante e’ la prima misura del progresso
8. Sviluppo sostenibile: Committente, Sviluppatori, Utenti
9. L’attenzione costante alle eccellenze tecniche e ad un buon design aumentano l’agilita’
10. La semplicità: l’arte del non lavorare
11. La migliore architettura, design e requisiti emergono da team auto organizzati
12. Riflessioni regolari per correggere il tiro

12. LE METODOLOGIE
LEAN
SCRUM XP

13. LEAN

14. LEAN
Pensa in grande
Agisci nel piccolo
Fallisci rapidamente
Impara continuamente

15. LEAN
Eliminare gli sprechi
Amplificare l’apprendimento
Decidere il più tardi possibile
Consegnare il più velocemente possibile
Integrità nella costruzione
Vedere il tutto

16. SCRUM?

17. SCRUM
empirismo con sprint

18. EXTREME PROGRAMMING (XP)

19. EXTREME PROGRAMMING (XP)
I 12 PRINCIPI
Feedback
1. Pair Programming
2. Planning Game
3. Test Driven
4. Whole Team
Processo continuo
5. Continuous Integration
6. Refactoring
7. Small Releases
Conoscenza condivisa
8. Coding Standards
9. Collective Ownership
10. Simple design
11. System metaphor
Benessere dei Programmatori
12. Sustainable Pace

20. EXTREME PROGRAMMING (XP)
Linee Guida
Comunicazione (gerarchia piatta)
Semplicità (KISS)
Verifica (Test)
Coraggio (Fail early)

21. EXTREME PROGRAMMING (XP)
Fasi Progetto
Pianificazione
User Stories
Small Release Planning
Project Velocity
Load Factor
Progettazione
Metafore
Lazy Programmer
Spike solutions
Refactoring
Sviluppo
Feedback
Standards
Unit Test First
Pair Programming
Code Ownership
Collaudo (Automated Tests)

22. STRUMENTI UPSTREAM
Product Owner / Scrum Master
Small iterations (2-4 weeks)
User Story Based Requirements
Kanban
Burndown/up charts
Daily Scrum

23. USER STORY
Come [tipo di utente]
Voglio [ottenere un obiettivo]
In modo da [avere un valore]

24. USER STORY
Come utente
Voglio registrarmi alla news letter
In modo da rimanere aggiornato

25. KANBAN
esplicitare lo stato dei compiti che si muovno verso destra, work in progress limit

26. KANBAN

27. BRUNDOWN

28. STRUMENTI DOWNSTREAM
Cross functional team
Continuous Integration
Test driven development
Data driven development

29. TDD

30. TIPOLOGIE DI TESTS
Manuale
Unit
Regression
Functional
User Acceptance
Exploratory
A/B Testing
Mock & stub

31. COME DIVENTARE AGILI?

32. CREARE CULTURA
1) Gli individui più dei processi.
Cosa pensa il vostro Team dell'Agile?
2) So ware funzionante più della documentazione.
Test, test e ancora test.
3) La collaborazione col cliente
Il Management è il primo cliente: Delega e Controllo.

33. CREARE IL TEAM (HR AGILE)
Reclutamento e selezione: Social branding e community
Performance: dal basso, valutazione mensile
Training: personalizzato sul campo
Carriera: reticolare e a tempo breve
IL CANDIDATO AGILE (NON FRAGILE)
Risolve i problemi invece di discuterli
Esce dall'isolamento lavorando in gruppo
È creativo e appassionato non una macchina esecutrice
Ascolta utenti e clienti e non il proprio ego

34. ANALIZZARE LA SITUAZIONE
Architettura Monolitica vs Microservizi
Api, Rest, Open Data
Multi devices (mobile first)
Refactoring del codice Legacy

35. COMINCIARE CON UN PROGETTO PILOTA
Sufficientemente Complesso
Durata contenuta
Rilevante per gli stakeholders
Chiarezza dei ruoli (PO, SM, Team)

36. IL PILOTA
Backlog & Sprint Planning
Daily Scrum
Burndown
Sprint Demo
Retrospective
Iterate

37. TOOLS

38. PROBLEMI AGILI
PIANIFICAZIONE
Scarsa pianificazione
Troppa pianificazione
Iterazioni troppo cariche di cose
Stime inefficaci
Aggiungere storie alle iterazioni in atto

39. PROBLEMI AGILI
RUOLI E TEAM
Resistenza al cambio di cultura
Product Owner indifferente o assente
Scrum master sviluppatore
Problem solving nei daily scrum
Team non allenato
Team non Cross Functional
Mancanza di fiducia/libertà verso il team
Mancanza di focus nel team

40. PROBLEMI AGILI
TECNOLOGIE
Mancanza di test automatici
Accumulo di debiti tecnici
Mancanza di ascolto del feedback degli utenti
Mancanza di Demo e Retrospettive

41. THE END

42. CONTATTI
adamquadmon@gmail.com
facebook.com/luciano.amodio
linkedin.com/in/adamquadmon