Sviluppo Agile 
secondo l’approccio SCRUM
@teamcantiere 
! 
! 
Matteo Papadopoulos — @spleenteo 
Stefano Verna — @steffoz 
! 
! 
Ruby Rails • WebApp • Mobile App • Design
Storia e contesto
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
Com’è andata?
1960 
1970 
1980 
Com’è andata?
Com’è andata? 
Status quo
Com’è andata? 
2009
Com’è andata? 
24% completi fallimenti 
75% over-budget
Com’è andata? 
(come è stato possibile 
cambiare il mondo?)
Software Engineering 
1. ridurre la 
complessità
smettiamo di 
scrivere codice
codice macchina 
assembler 
linguaggi programmazione 
programmazione ad oggetti 
?????
1960 - COBOL 
1990 - PROLOG 
2000 - SOA, UML2
complessità intrinseca 
non è complesso descrivere la soluzione; 
è complesso il problema
1. ridurre la 
complessità
Software Engineering 
2. ridurre l’errore 
umano
metodi formali 
! 
modellazione matematica del 
problema
“costo inaccessibile”
2000 - Polar Lander 
100.000.000$ di investimento
“sono stati scritti troppi 
pochi test”
2. ridurre l’errore 
umano
Software Engineering 
3. eliminare la 
variabilità dei progetti
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
progettazione 
! 
costruzione 
= ????????? 
! 
= ????????? 
qual’è il parallelo di queste fasi nel mondo SW?
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
Product Owner 
• È "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
Team 
• È 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
Scrum Master 
• È “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
icelog backlog current in progress done deployed accepted 
D 
a typical week of work 
A 
B 
C 
E 
F 
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 access result signed in 
the of pricing brief 
When I 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
icebox backlog current in progress done deployed accepted 
demo time: the stakeholder tests the 
stories and approves/rejects them 
A 
B 
C 
D 
E 
F 
A1 
A2 
the stakeholder 
prioritizes the stories 
team estimates and accepts a 
the works on the stories 
set following of stories 
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
team piccoli, framework sproporzionato 
“Gli individui e le interazioni più che i 
processi e gli strumenti” 
A intervalli regolari il team riflette su come 
diventare più efficace, dopodiché regola e adatta 
il proprio comportamento di conseguenza.
focus 100%?! 
32h 
settimana 
garantite
non solo programmazione: ci sono 
task, tipo la grafica, che si 
adattano meno al framework 
brief 
mood 
wireframe 
mockup
brief 
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
mood 
È 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
style tiles
wireframes 
È 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
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
what we think our quotation 
{ 
we win 
{ 
you win 
preventivo 
significa 
che qualcuno ci rimette 
working time 
idea 
qualità
come vendere l’agile? 
• “formazione” del cliente 
• definizione di un budget 
• una stima non-vincolante 
• pagamenti regolari 
• contratti “settimanali”, senza lock-in 
• garanzia di qualità interna
dubbi / domande?! 
! 
! 
! 
@teamcantiere

Sviluppo Agile secondo l'approccio SCRUM

  • 1.
    Sviluppo Agile secondol’approccio SCRUM
  • 2.
    @teamcantiere ! ! Matteo Papadopoulos — @spleenteo Stefano Verna — @steffoz ! ! Ruby Rails • WebApp • Mobile App • Design
  • 3.
  • 4.
    Storia e contesto 1968 NATO conference
  • 5.
    Storia e contesto Software Crisis
  • 6.
    Storia e contesto • in ritardo • over-budget • pessima qualità • inutili
  • 7.
    Storia e contesto Software Engineering
  • 8.
  • 9.
    1960 1970 1980 Com’è andata?
  • 10.
  • 11.
  • 12.
    Com’è andata? 24%completi fallimenti 75% over-budget
  • 13.
    Com’è andata? (comeè stato possibile cambiare il mondo?)
  • 14.
    Software Engineering 1.ridurre la complessità
  • 15.
  • 16.
    codice macchina assembler linguaggi programmazione programmazione ad oggetti ?????
  • 17.
    1960 - COBOL 1990 - PROLOG 2000 - SOA, UML2
  • 18.
    complessità intrinseca nonè complesso descrivere la soluzione; è complesso il problema
  • 19.
    1. ridurre la complessità
  • 20.
    Software Engineering 2.ridurre l’errore umano
  • 21.
    metodi formali ! modellazione matematica del problema
  • 22.
  • 23.
    2000 - PolarLander 100.000.000$ di investimento
  • 24.
    “sono stati scrittitroppi pochi test”
  • 25.
  • 26.
    Software Engineering 3.eliminare la variabilità dei progetti
  • 27.
  • 28.
    progetti ripetibili ! ! ! ! progetti unici
  • 29.
    IKEA 2011 -280 stores
  • 30.
    Casa sulla cascata 1939 - Frank Lloyd Wright
  • 31.
    costo stimato 30.000$ costo finale: 400%
  • 32.
  • 33.
  • 34.
    progettazione ! ! ! costruzione
  • 37.
    progettazione ! costruzione = ????????? ! = ????????? qual’è il parallelo di queste fasi nel mondo SW?
  • 38.
    progettazione ! costruzione = specifiche ! = programmazione qual’è il parallelo di queste fasi nel mondo SW?
  • 39.
    progettazione ! costruzione = specifiche ! = programmazione qual’è il parallelo di queste fasi nel mondo SW?
  • 40.
    progettazione ! costruzione = codice sorgente ! = compilazione qual’è il parallelo di queste fasi nel mondo SW?
  • 41.
    progettazione ! costruzione = codice sorgente ! = compilazione 10% 90% 99% 1% rapporto economico
  • 42.
  • 43.
  • 44.
    la costruzione disoftware non è un processo definibile
  • 45.
    waterfall analisi/design coding verifica/test pubblicazione
  • 46.
  • 47.
    processo empirico 1.osservazione 2. ipotesi 3. esperimento
  • 48.
  • 49.
    Gli individui ele 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.
  • 50.
    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.
  • 51.
    La collaborazione colcliente 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.
  • 52.
    Rispondere al cambiamentopiù 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.
  • 53.
    Framework Agili ! Kanban, SCRUM, XP
  • 54.
  • 55.
    • Lo sviluppoavviene 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
  • 56.
    Product owner Team ScrumMaster
  • 57.
    Product Owner •È "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
  • 58.
    Team • È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
  • 59.
    Scrum Master •È “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
  • 61.
    icelog backlog currentin progress done deployed accepted D a typical week of work A B C E F 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 access result signed in the of pricing brief When I 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
  • 62.
    icebox backlog currentin progress done deployed accepted demo time: the stakeholder tests the stories and approves/rejects them A B C D E F A1 A2 the stakeholder prioritizes the stories team estimates and accepts a the works on the stories set following of stories the given priorities
  • 64.
  • 65.
    difficoltà di applicazione team piccoli, framework sproporzionato ! focus 100%?! ! non solo programmazione: ci sono task, tipo la grafica, che si adattano meno al framework
  • 66.
    team piccoli, frameworksproporzionato “Gli individui e le interazioni più che i processi e gli strumenti” A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
  • 67.
    focus 100%?! 32h settimana garantite
  • 68.
    non solo programmazione:ci sono task, tipo la grafica, che si adattano meno al framework brief mood wireframe mockup
  • 69.
    brief Riunione diinizio 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
  • 70.
    mood È ilconcept 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
  • 71.
  • 72.
    wireframes È larappresentazione 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
  • 73.
  • 74.
  • 75.
  • 76.
    dal punto divista del cliente, il momento di maggiore incertezza è il momento peggiore per definire specifiche (incerte) e accettare clausole vincolanti.
  • 77.
    un preventivo significa ! • specifiche vincolate • frizioni
  • 78.
    what we thinkour quotation { we win { you win preventivo significa che qualcuno ci rimette working time idea qualità
  • 79.
    come vendere l’agile? • “formazione” del cliente • definizione di un budget • una stima non-vincolante • pagamenti regolari • contratti “settimanali”, senza lock-in • garanzia di qualità interna
  • 80.
    dubbi / domande?! ! ! ! @teamcantiere