Upload
matteo-papadopoulos
View
323
Download
1
Embed Size (px)
DESCRIPTION
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
Citation preview
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