Sviluppo Agile secondo l’approccio SCRUM

@teamcantiere !!

Matteo Papadopoulos — @spleenteo Stefano Verna — @steffoz

!!

Ruby Rails • WebApp • Mobile App • Design

Storia e contesto

1968 NATO conference

Storia e contesto

Software Crisis

Storia e contesto

• in ritardo • over-budget • pessima qualità • inutili

Storia e contesto

Software Engineering

Storia e contesto

Com’è andata?

1960

1970

1980

Com’è andata?

Status quo

Com’è andata?

2009

Com’è andata?

24% completi fallimenti

75% over-budget

Com’è andata?

(come è stato possibile cambiare il mondo?)

Com’è andata?

1. ridurre la complessità

Software Engineering

smettiamo di scrivere codice

codice macchina

assembler

linguaggi programmazione

programmazione ad oggetti

?????

1960 - COBOL

1990 - PROLOG

2000 - SOA, UML2

non è complesso descrivere la soluzione; è complesso il problema

complessità intrinseca

1. ridurre la complessità

2. ridurre l’errore umano

Software Engineering

metodi formali !

modellazione matematica del problema

“costo inaccessibile”

2000 - Polar Lander100.000.000$ di investimento

“sono stati scritti troppi pochi test”

2. ridurre l’errore umano

3. eliminare la variabilità dei progetti

Software Engineering

ingegneria industriale/civile

progetti ripetibili !

!

!

!

progetti unici

IKEA 2011 - 280 stores

Casa sulla cascata 1939 - Frank Lloyd Wright

costo stimato 30.000$

costo finale: 400%

pessima qualità statica

inagibile

ricostruita nel ‘90

progettazione !

!

!

costruzione

qual’è il parallelo di queste fasi nel mondo SW?

progettazione !

costruzione

= ????????? !

= ?????????

progettazione !

costruzione

= specifiche !

= programmazione

qual’è il parallelo di queste fasi nel mondo SW?

progettazione !

costruzione

= specifiche !

= programmazione

qual’è il parallelo di queste fasi nel mondo SW?

progettazione !

costruzione

= codice sorgente !

= compilazione

qual’è il parallelo di queste fasi nel mondo SW?

progettazione !

costruzione

= codice sorgente !

= compilazione

10%

90%

99%

1%

rapporto economico

20 programmatori

20 architetti

la costruzione di software non è un processo

definibile

waterfall

analisi/design

coding

verifica/test

pubblicazione

Software Engineering

processo empirico

1. osservazione 2. ipotesi 3. esperimento

2001 Agile

Gli individui e le interazioni più che i processi e gli strumenti

• Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

• Fondiamo i progetti su individui motivati, dando loro l'ambiente e il supporto di cui hanno bisogno.

• I processi agili promuovono uno sviluppo sostenibile. Tutti i soggetti coinvolti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

Il software funzionante più che la documentazione esaustiva

• Il software funzionante è il principale metro di misura di progresso

• La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

• Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

La collaborazione col cliente più che la negoziazione dei contratti

• Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.

• Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.

Rispondere al cambiamento più che seguire un piano

• Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.

• A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Framework Agili !

Kanban, SCRUM, XP

SCRUM

• Lo sviluppo avviene in cicli di lavoro chiamati Sprint della durata di 1-4 settimane

• Ogni fase è time-boxed e non allungabile

• Il Cliente decide le features, il team la fattibilità

• Il team si impegna per consegnare un sottoinsieme di features, per entro il termine dello Sprint

• Ad ogni Sprint, il team revisiona il lavoro con il cliente, iterando

Product owner

Team

ScrumMaster

• È "Il Cliente", o chi per esso, responsabile delle scelte

strategiche e funzionali del prodotto

• Mantiene una lista di features da implementare

ordinata per priorità

• Può giocare su qualità esterna e scope delle features

per massimizzare il ROI (Return-On-Investment)

• Dev'essere presente e disponibile durante tutto lo

Sprint

Product Owner

• È responsabile dell'implementazione del prodotto ai

massimi livelli di qualità interna

• Non esistono team managers o project managers interni

• Ha un alto grado di autonomia e si auto-organizza al suo

interno

• Ogni membro del team decide quale feature vuole

implementare tra quelle concordate con il Product

Owner

• Ogni membro lavora su un solo progetto alla volta

Team

• È “L’Arbitro", il responsabile di un'efficace esecuzione

delle varie fasi del processo Scrum

• Lavora affinché i principi Scrum vengano compresi e

applicati

• Controlla che ogni fase sia stata portata a termine

con dovizia dai responsabili

• L'efficacia dello Scrum sta nella capacità di reattività e

di autorevolezza dello ScrumMaster

Scrum Master

icelog backlog current in progress done deployed accepted

D

a typical week of work

A

B

C

E

F

result of brief

Story: User purchases a premium plan!

As a Registered User, I want to purchase a premium plan So that I can access advanced features !

Scenario: Successful payout!Given I’m signed in When I access the pricing page And I select one of the premium plans And I proceed to the checkout Then the premium plan should be enabled And I should receive a confirmation email

demo time: the stakeholder tests the

stories and approves/rejects them

icebox backlog current in progress done deployed accepted

D

A

B

C

E

F

A1

A2

the stakeholder

prioritizes the stories

the team estimates and accepts a

set of stories

the team works on the stories

following the given priorities

agile agency?

difficoltà di applicazione

team piccoli, framework sproporzionato !

focus 100%?! !

non solo programmazione: ci sono task, tipo la grafica, che si adattano meno al framework

A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta

il proprio comportamento di conseguenza.

“Gli individui e le interazioni più che i processi e gli strumenti”

team piccoli, framework sproporzionato

focus 100%?!

32h settimana

garantite

non solo programmazione: ci sono task, tipo la grafica, che si

adattano meno al framework

brief mood

wireframe mockup

Riunione di inizio progetto in cui il product

owner racconta e discute la visione del progetto

a tutto il team, sia grafici che sviluppatori i quali

si rendono parte attiva del progetto fin da subito

brief

È il concept design, un passo oltre il “colpo

d’occhio”. Definisce, senza tenere conto del

contenuto ma solo della vision, lo stile del

progetto in termini di font, icone, tipo di immagini

mood

style tiles

È la rappresentazione dello scheletro di una app, una griglia

che non tiene conto della grafica/mood bensì del contenuto.

Il WF è creato con l’intento di disporre gli oggetti al posto

giusto per il raggiungimento di un determinato obiettivo

wireframes

wireframes

come vendere l’agile?

preventivi?!

dal punto di vista del cliente, il

momento di maggiore

incertezza è il momento

peggiore per definire

specifiche (incerte) e accettare

clausole vincolanti.

un preventivo significa

!

• specifiche vincolate

• frizioni

{we win

{

you win

what we think our quotation

preventivo significa

che qualcuno ci rimette

working time

idea

qualità

• “formazione” del cliente • definizione di un budget • una stima non-vincolante • pagamenti regolari • contratti “settimanali”, senza lock-

in • garanzia di qualità interna

come vendere l’agile?

dubbi / domande?! !

!

!

@teamcantiere