1
Semplicemente AGILE
SUPSI – 29 Aprile 2014Stefano Gallotti
2
La Storia
L’idea
Gli strumenti
Il Progetto
Le persone
Qualche suggerimento
AGENDA
La Storia
3
4
Quecreek Mine DisasterUn 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 andrai a raccogliere
è sicuro che cambierà.
Ci saranno sempre più cose da fare che
soldi e tempo.
11
Analizziamo il modello waterfall
Vediamo i 6 punti che lo caratterizzano
1. Descrizione vaga e grossolana dei requisiti2. Valutazione e stima di effort e risorse necessarie3. 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
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 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.
I principi sottostanti al Manifesto Agile
17
La nostra massima priorità è soddisfare il clienterilasciando 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.
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
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 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
I
N
V
E
S
T
ndipendentE’ più semplice se sono indipendenti ed è possibile eseguirle in qualsiasi ordine
egotiableNon è un contratto esplicito, piuttosto i dettagli devono essere co-creati durante la definizione.
aluableDeve essere utile non solo per qualcuno ma per il cliente
stimableL’esatta stima non è necessaria fin dall’inizio ma sufficiente per classificare e definire l’implementazione
mallSufficientemente piccoli da permettere una stima accurata
stableOgni requisito deve essere testabile per essere considerato “Fatto”
Invest in Requirement
23
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
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
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
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
Il Progetto
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:
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
FIXED
ESTIMATED
VALUE DRIVEN
PLAN DRIVEN
Features
Cost Time Features
Time Cost
Project Approach
Le Persone
32
Agile team
33
TUTTITUTTI INSIEMEFIN DALL'INIZIO
Five dysfunction of a team
34
Assenza di fiducia
Paura del conflitto
Mancanza di impegno
Evitare la responsabilità
Disattenzione al risultato
Patrik Lencioni
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-Driven Design
• Behavior-Driven Development
• Development
• Scrum
• Test & Delivery
• Scrum
• Continous Delivery
37
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