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