Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
Semplicemente AGILE
SUPSI – 29 Aprile 2014
Stefano Gallotti
2
La Storia
L’idea
Gli strumenti
Il Progetto
Le persone
Qualche suggerimento
AGENDA
La Storia
3
4
Quecreek Mine Disaster
Un ottimo esempio di collaborazione
https://en.wikipedia.org/wiki/Quecreek_Mine_rescue
5
Modello evolutivo di una organizzazione
«Abbiamo successo perché lavoriamo Insieme»
Collaborazione
6
«Abbiamo successo creando e mantenendo il controllo»
Controllo
7
«Abbiamo successo perché siamo i migliori»
Competenza
8
«Abbiamo successo perché facciamo crescere le persone
che alimentano la nostra vision»
Incubazione - Cultura
9
Modello waterfall
10
Partiamo da 3 semplici verità
E’ impossibile raccogliere tutti i
requisiti all’inizio del progetto.
Qualsiasi requisito an...
Analizziamo il modello waterfall
Vediamo i 6 punti che lo caratterizzano
1. Descrizione vaga e grossolana dei requisiti
2....
Come è strutturato
ANALISI
DESIGN
SVILUPPO
TEST
RILASCIO
13
Principali cause del fallimento
14
15
Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa at...
I principi sottostanti al Manifesto Agile
17
La nostra massima priorità è soddisfare il cliente
rilasciando software di va...
Agile timeline
18
Waterfall
Predittivo: Fasi, document-centric, functional handoffs, fare bene la prima volta
Spiral, RAD,...
Facciamo un passo indietro...
ANALISI
DESIGN
SVILUPPO
TEST
RILASCIO
19
Come si può migliorare...
ANALISI
DESIGN
SVILUPPO
TEST
RILASCIO
20
Gli Strumenti
21
Approach SCRUM
Scrum è una delle tecniche agili più utilizzate.
Sottolinea la comunicazione la collaborazione, software fu...
I
N
V
E
S
T
ndipendent
E’ più semplice se sono indipendenti ed è possibile eseguirle in qualsiasi ordine
egotiable
Non è u...
Gestire il Product Backlog
Per avere un buon product backlog è necessario essere in grado di:
• Gestire la priorità degli ...
AGILE Architecture
Dal punto di vista architetturale, durante l'iterazione 0 l'obiettivo è
identificare una direzione pote...
26
Envision
Architetturale
iniziale
Condivisione
Architettura con
Stakeholder
Aggiornamento
deliverable
architetturali
Col...
Data Architecture
27
• Classificando i data elements (data classification)
• Considerando gli accessi ai dati (data securi...
28
Il Progetto
Fixed Price, Fixed Scope
29
Manager: Voglio ordinare qualcosa, passare ad un'altra
attività senza interruzioni e che si co...
Incomprensioni su FPFS
30
Quando viene utilizzato un metodo agile i requisiti generali di rilascio del
progetto non sono n...
31
FIXED
ESTIMATED
VALUE DRIVEN
PLAN DRIVEN
Features
Cost Time Features
Time Cost
Project Approach
Le Persone
32
Agile team
33
TUTTI
TUTTI INSIEME
FIN DALL'INIZIO
Five dysfunction of a team
34
Assenza di fiducia
Paura del conflitto
Mancanza di impegno
Evitare la responsabilità
Disatte...
35
La barca che vince ha lo stesso vento delle altre…
…ma ha un equipaggio migliore!
Qualche suggerimento
36
Software Development Delivery Methods
Agile best practice:
• Analisys & Design
• User Stories
• Impact Mapping
• Test-Driv...
AGILE delivery model
38
The change process
39
Agile software development is one tool
in a vast toolbox.
But a fool with a tool is still a fool.
40
Upcoming SlideShare
Loading in …5
×

Semplicemente Agile

866 views

Published on

AGILE Project Management.
Dall’idea alle persone, un percorso per comprendere la transizione dal modello predittivo a quello adattivo.

Semplicemente Agile

  1. 1. 1 Semplicemente AGILE SUPSI – 29 Aprile 2014 Stefano Gallotti
  2. 2. 2 La Storia L’idea Gli strumenti Il Progetto Le persone Qualche suggerimento AGENDA
  3. 3. La Storia 3
  4. 4. 4 Quecreek Mine Disaster Un ottimo esempio di collaborazione https://en.wikipedia.org/wiki/Quecreek_Mine_rescue
  5. 5. 5 Modello evolutivo di una organizzazione
  6. 6. «Abbiamo successo perché lavoriamo Insieme» Collaborazione 6
  7. 7. «Abbiamo successo creando e mantenendo il controllo» Controllo 7
  8. 8. «Abbiamo successo perché siamo i migliori» Competenza 8
  9. 9. «Abbiamo successo perché facciamo crescere le persone che alimentano la nostra vision» Incubazione - Cultura 9
  10. 10. Modello waterfall 10
  11. 11. Partiamo da 3 semplici verità E’ impossibile raccogliere tutti i requisiti all’inizio del progetto. Qualsiasi requisito andrai a raccogliere è sicuro che cambierà. Ci saranno sempre più cose da fare che soldi e tempo. 11
  12. 12. Analizziamo il modello waterfall Vediamo i 6 punti che lo caratterizzano 1. Descrizione vaga e grossolana dei requisiti 2. Valutazione e stima di effort e risorse necessarie 3. Offerta economica (out of the box - tutto compreso e senza possibili modifiche) 4. Analisi Funzionale (dove capisci cosa è andato male al punto 2) 5. Analisi Architetturale (dove i dubbi del punto 4 diventano realtà) 6. Sviluppo e Test (dove il disastro assume proporzioni irreparabili) 12
  13. 13. Come è strutturato ANALISI DESIGN SVILUPPO TEST RILASCIO 13
  14. 14. Principali cause del fallimento 14
  15. 15. 15
  16. 16. Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti: 16 Gli individui e le interazioni più che i processi e gli strumenti Il software funzionante più che la documentazione esaustiva La collaborazione con il 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.
  17. 17. I principi sottostanti al Manifesto Agile 17 La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua. Il software funzionante è il principale metro di misura di progresso. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente. I processi agili promuovono uno sviluppo sostenibile. Sponsor, Sviluppatori e Utenti in grado di mantenere indefinitamente un ritmo costante. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale. 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. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
  18. 18. Agile timeline 18 Waterfall Predittivo: Fasi, document-centric, functional handoffs, fare bene la prima volta Spiral, RAD, RUP Iterativo: process framework, fasi, tool driven, complessi artifact Scrum, XP Adattivo: Iterativo, self-organizing team, value driven, transparente 20001970 19901980
  19. 19. Facciamo un passo indietro... ANALISI DESIGN SVILUPPO TEST RILASCIO 19
  20. 20. Come si può migliorare... ANALISI DESIGN SVILUPPO TEST RILASCIO 20
  21. 21. Gli Strumenti 21
  22. 22. Approach SCRUM Scrum è una delle tecniche agili più utilizzate. Sottolinea la comunicazione la collaborazione, software funzionante, e la flessibilità necessaria per adattarsi alle realtà aziendali emergenti. Tutti attributi che soffrono nel paradigma waterfall. 22 3 Ruoli • Product Owner • Team Member • Scrum Master 4 Cerimonie • Sprint Planning • Daily Meeting • Sprint review • Retrospective 3 Artifacts • Product backlog • Sprint backlog • Burn down chart
  23. 23. I N V E S T ndipendent E’ più semplice se sono indipendenti ed è possibile eseguirle in qualsiasi ordine egotiable Non è un contratto esplicito, piuttosto i dettagli devono essere co-creati durante la definizione. aluable Deve essere utile non solo per qualcuno ma per il cliente stimable L’esatta stima non è necessaria fin dall’inizio ma sufficiente per classificare e definire l’implementazione mall Sufficientemente piccoli da permettere una stima accurata stable Ogni requisito deve essere testabile per essere considerato “Fatto” Invest in Requirement 23
  24. 24. Gestire il Product Backlog Per avere un buon product backlog è necessario essere in grado di: • Gestire la priorità degli elementi • Scambiare requisiti con lo stesso effort • Cambiare l'ordine dei requisiti fissi • Migliorare la “definizione di fatto” in ogni iterazione. Ora si è pronti per definire e pianificare gli sprints • Partendo con la definizione della Timebox (Fixed Time) • Definendo le funzionalità rilasciate (Fixed Scope) In questa fase si ha la completa visibilità del progetto e si è in grado di stimarne i costi totali. 24
  25. 25. AGILE Architecture Dal punto di vista architetturale, durante l'iterazione 0 l'obiettivo è identificare una direzione potenziale per la soluzione nonché eventuali rischi tecnici che potenzialmente saranno da affrontare. In questa fase non c’è bisogno di specifiche architetturali dettagliate. Definire l’architettura completa all'inizio di un progetto di sviluppo è infatti un rischio. Bisogna poter rispondere a domande critiche circa l’ambito, costi, tempi, e la strategia tecnica del progetto. 25
  26. 26. 26 Envision Architetturale iniziale Condivisione Architettura con Stakeholder Aggiornamento deliverable architetturali Collaborazione con team di sviluppo Models Vision Models Vision Feedback L’architettura si aggiorna ed evolve con il tempo Scott W.Amber Architecture Evolution
  27. 27. Data Architecture 27 • Classificando i data elements (data classification) • Considerando gli accessi ai dati (data security) • Identificando i Master Data (entity types, data elements, associations…) • Definendo e gestendo i metadati pertinenti ai Master Data includendo: • Primary Source(s) • Come i sistemi accedono ai MD • Lifecycles dei MD • Owners e/o data stewards • Adottando tools (repository and modeling) per gestire Master Data e metadati Come un approccio agile alla Data Architecture permette di ottenere un buon modello di MDM?
  28. 28. 28 Il Progetto
  29. 29. Fixed Price, Fixed Scope 29 Manager: Voglio ordinare qualcosa, passare ad un'altra attività senza interruzioni e che si consegni il tutto per tempo. I progetti Fixed-price sono stati promossi con il pretesto di varie ottimizzazioni: Cliente: Voglio conoscere il costo del progetto. Fornitore: Voglio definire il costo totale della commessa. Venditore: Voglio definire la commessa per ottenere la commissione completa. La principale domanda diventa quindi:
  30. 30. Incomprensioni su FPFS 30 Quando viene utilizzato un metodo agile i requisiti generali di rilascio del progetto non sono noti o stimati prima della prima iterazione. Con i metodi agili i requisiti sono sempre soggetti al cambiamento. Ci sono spesso due malintesi sul connubio FPFS ed i metodi agili: Anzi, in Scrum, già dall prima iterazione, è chiara la pianificazione dei rilasci (“product backlog”), in cui tutti i requisiti identificabili sono chiariti e stimati. Non è vero. Piuttosto, tutti i metodi agili offrono l'opportunità e il meccanismo per supportare l'apprendimento ed il cambiamento, ma non lo richiedono. Scrum può essere utilizzato con un backlog di fixed features da rilasciare. Non è vero.
  31. 31. 31 FIXED ESTIMATED VALUE DRIVEN PLAN DRIVEN Features Cost Time Features Time Cost Project Approach
  32. 32. Le Persone 32
  33. 33. Agile team 33 TUTTI TUTTI INSIEME FIN DALL'INIZIO
  34. 34. Five dysfunction of a team 34 Assenza di fiducia Paura del conflitto Mancanza di impegno Evitare la responsabilità Disattenzione al risultato Patrik Lencioni
  35. 35. 35 La barca che vince ha lo stesso vento delle altre… …ma ha un equipaggio migliore!
  36. 36. Qualche suggerimento 36
  37. 37. Software Development Delivery Methods Agile best practice: • Analisys & Design • User Stories • Impact Mapping • Test-Driven Design • Behavior-Driven Development • Development • Scrum • Test & Delivery • Scrum • Continous Delivery 37
  38. 38. AGILE delivery model 38
  39. 39. The change process 39
  40. 40. Agile software development is one tool in a vast toolbox. But a fool with a tool is still a fool. 40

×