requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
Lean anche io! No tu no! - Italian Agile Days 2013Andrea Scavolini
Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia:
Lean anche io!
No tu no!
Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
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.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Agile Project Management: Integrare metodologie di progetto tradizionali con ...Codemotion
Negli ultimi anni, anche secondo l'approccio Lean Startup, il modo migliore per rilasciare prodotti - non solo software - è tramite framework Agili. Quando si è agili all'interno di un organizzazione più tradizionale, questo approccio spesso si scontra con le prassi di gestione progetti più tradizionali. Nonostante lo scontro - principalmente filosofico - è in realtà possibile integrare metodologie di progetto tradizionali con quelle agili. Durante il talk, dopo una breve introduzione, saranno presentati dei modelli di ciclo di vita Agile e Tradizionale e la struttura consigliata dei team.
Il 4° punto del Manifesto Agile può essere molto complicato non solo in XP, ma anche sul piano personale, relazionale e caratteriale. Sono aspetti fondamentali e trasversali del lavoro (e non solo). Ma abbracciare il cambiamento non è esattamente nella natura umana; è sfidante, è difficile… Fortunatamente però siamo in grado di apprendere e modificare il nostro comportamento in modi infiniti. Per arrivare ad ottimi risultati.
Siete in una situazione in cui sapete di poter dare molto, ma non riuscite ad innescare la scintilla del cambiamento?
Oppure desiderate che un vostro collega, il vostro team lo facesse ed invece non sembra esserci speranza?
Nel management classico o tradizionale si leggono libri con titoli come “Gestione delle risorse umane e motivazione al lavoro”. Ma forse essere trattati come risorse e non persone non è più sufficiente, e poi non è molto efficace motivare al cambiamento attraverso trucchetti o persuasione. Qualche suggerimento per capire meglio perché è difficile, gli ingredienti utili per cambiare e per capire la motivazione.
Sempre tenendo presente che la “svolta indotta”, quella che inizia con “Da domani iniziamo a…” o “Ho deciso che da oggi…” è quella più difficile da portare avanti.
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
Lean anche io! No tu no! - Italian Agile Days 2013Andrea Scavolini
Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia:
Lean anche io!
No tu no!
Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
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.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Agile Project Management: Integrare metodologie di progetto tradizionali con ...Codemotion
Negli ultimi anni, anche secondo l'approccio Lean Startup, il modo migliore per rilasciare prodotti - non solo software - è tramite framework Agili. Quando si è agili all'interno di un organizzazione più tradizionale, questo approccio spesso si scontra con le prassi di gestione progetti più tradizionali. Nonostante lo scontro - principalmente filosofico - è in realtà possibile integrare metodologie di progetto tradizionali con quelle agili. Durante il talk, dopo una breve introduzione, saranno presentati dei modelli di ciclo di vita Agile e Tradizionale e la struttura consigliata dei team.
Il 4° punto del Manifesto Agile può essere molto complicato non solo in XP, ma anche sul piano personale, relazionale e caratteriale. Sono aspetti fondamentali e trasversali del lavoro (e non solo). Ma abbracciare il cambiamento non è esattamente nella natura umana; è sfidante, è difficile… Fortunatamente però siamo in grado di apprendere e modificare il nostro comportamento in modi infiniti. Per arrivare ad ottimi risultati.
Siete in una situazione in cui sapete di poter dare molto, ma non riuscite ad innescare la scintilla del cambiamento?
Oppure desiderate che un vostro collega, il vostro team lo facesse ed invece non sembra esserci speranza?
Nel management classico o tradizionale si leggono libri con titoli come “Gestione delle risorse umane e motivazione al lavoro”. Ma forse essere trattati come risorse e non persone non è più sufficiente, e poi non è molto efficace motivare al cambiamento attraverso trucchetti o persuasione. Qualche suggerimento per capire meglio perché è difficile, gli ingredienti utili per cambiare e per capire la motivazione.
Sempre tenendo presente che la “svolta indotta”, quella che inizia con “Da domani iniziamo a…” o “Ho deciso che da oggi…” è quella più difficile da portare avanti.
Test Driven Development su iOS è possibile e persino utile.
Invece di leggere blog post che sottointendono che TDD su iOS sia difficile e inutile venite a vedere chi lo usa sul serio e ha il coraggio di programmare ad una conferenza davanti ad altre persone.
Avvertenze:
questo talk non contiene paternali sul perché si dovrebbe (o non si dovrebbe) fare TDD
in questo talk non verranno usati strumenti complicati
in questo talk verrà scritto ed eseguito codice dal vivo
Dopo una brevissima introduzione passerò a sviluppare guidato dai test una semplice applicazione per iPhone.
Outcome not Output: A Story of Lean UX AdoptionSteve Maraspin
This presentation shares our experience with Lean UX adoption and offers some hints on how to combine User Centered Design activities within an Agile development workflow.
La comunicazione tra le persone è il primo valore dell’Agile. Trasmettere la vision di un’idea è molto difficile. Attraverso i Canvas è possibile non solo condividere la vision ma anche il viaggio che porterà alla realizzazione dell’intero prodotto.
Adottando i vari Canvas come il Business Model Canvas, il Lean Canvas e il Product Canvas è possibile definire e condividere le ipotesi iniziali, validarle sul mercato misurando i risultati e confrontarle con i risultati attesi. I Canvas quindi non solo ci aiutano nella parte iniziale del progetto ma ci accompagnano per tutto il ciclo di vita del prodotto evolvendo con esso.
Questi concetti non sono strettamente legati al software ma possono essere applicati in contesti differenti.
Durante questo workshop vedremo insieme come, partendo da un’idea, si possa realizzare un prototipo di applicazione mobile in meno di due ore… il tutto sotto forma di gioco.
La passione non è sufficiente e il talento è sopravvalutato.
La vera differenza tra chi eccelle in una disciplina e tutti gli altri è la pratica.
I risultati ottenuti facendo pratica sono funzione non solo della quantità di tempo investito ma anche della qualità della pratica stessa, è quindi importante un approccio strutturato.
Partendo dagli studi del Dr. K. Anders Ericsson sulla pratica deliberata vedremo una carrellata delle tecniche che ci permettono di migliorare nella programmazione e nell’applicazione dei metodi agili.
La ragione principale per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Eppure, si tratta di una concezione errata: applicando il DevSecOps al DB, infatti, è possibile creare in ambienti strutturati le condizioni per un rilascio sicuro degli script del database, gestendo al meglio potenziali rischi di sicurezza. Segui il webinar per apprendere come includere il DB all’interno della tua strategia DevSecOps.
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Come implementare la governance nella vostra piattaforma e lavorare felici se...Giulio Vian
DevOps Conf 2024 - Roma - 10 mag 2024
https://devopsconf.dotnetdev.it
Gli strumenti che usiamo per lo sviluppo e il rilascio sono essenziali per controllare i processi in uso e garantire che soddisfino requisiti aziendali, legali, e regolamentari.
In questa sessione illustrerò come passare da norme (policies) astratte a implementationi su piattaforme come Azure DevOps o GitHub delle stesse così da poter prevenire prima e verificare poi il corretto svolgimento delle operazioni. E diventare amici del direttore Rischi e Audit.
Moving from Monolithic to Microservice Architecture: an OSS based stack deplo...Codemotion
Realizzare un’unica piattaforma che garantisce Omni-channel, Zero-downtime, Functional-decomposition e Auto-scaling è possibile? Vi raccontiamo un caso reale di come, utilizzando Zuul, Eureka, SpringBoot, Docker abbiamo realizzato i desideri del cliente e attuato questa trasformazione.
Slide del decimo Meetup di Milano, che si è tenuto il 26 Gennaio dalle ore 10:30 alle ore 12:00 in formato virtuale.
Abbiamo parlato insieme a Davide Bonaciti di come ha realizzato un caso d'uso di automazione e CI/CD. Stefano Bernardini, Serena Galassi e Lorenzo Ornella, invece, ci parleranno di DataGraph e ci mostreranno una demo di implementazione per realizzare un'asta del fantacalcio 2.0.
Dispense del corso IN530 "Sistemi per l'elaborazione delle informazioni" presso il Corso di Laurea in Matematica dell'Università degli Studi Roma Tre.
[http://www.mat.uniroma3.it/users/liverani/IN530/]
Openatrium è certamente un'ottima distribuzione orientata all'utilizzo intranet, ma quanto è flessibile? Può essere utilizzato come backend per la produzione di contenuti che tramite moderazione vengono pubblicati nel front end? La risposta è si (avevate dubbi?), ma è nel "come" la parte interessante....
In questa sessione verranno presentate le soluzioni tecniche adottate in un complesso progetto realizzato per la PA.
Openatrium + custom features create per l'occasione + complex workflow + pressflow, integrazione con un motore semantico, tema accessibile il tutto opensource e riproducibile con un file make.
Presentazione all'incontro del 28 Novembre 2018 (organizzato dal FOIT, dall'Ordine degli Ingegneri di Torino e dal Chapter PMI di riferimento) in merito ad IoT, Agile e la loro contaminazione.
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
Nell’intervento Stefano Olivotto di Crédit Agricole Italia ha illustrato la sua esperienza nell’adozione di uno strumento di API management e di un processo di gestione delle API, con una particolare focalizzazione su metodologia di adozione, sulle principali sfide indirizzate e un verticale sul livello di automazione raggiunto mediante l’adozione di tecniche di DevOps.
Per maggiori informazioni scrivi a sales@profesia.it
Con Xebialabs affrontiamo il tema della gestione della Toolchain devops e Release/Deploy in modo orchestrato e remotizzato.
XebiaLabs, leader del mercato ARA come riportato da Gartner e
Forrester. Con XebiaLabs gestire i rilasci dal punto di vista di processo e di effettivo deploy delle applicazioni è solo un fatto di configurazione, al resto pensa l’engine di XebiaLabs.
Marco Zani: Come dimensionare Magento per raggiungere i Key Performance Indic...Meet Magento Italy
In un contesto altamente concorrenziale, le aspettative dei merchant non riguardano più unicamente uptime e possibilità di scaling dei propri shop, ma dettano anche obiettivi specifici in termini di velocità di caricamento delle pagine secondo KPI prestabiliti, al di sotto dei quali far scattare allarmi e/o azioni.
Durante lo speech Marco mostrerà come configurare e utilizzare alcuni applicativi per effettuare test di carico e per analizzare i risultati ottenuti ai fini di un corretto dimensionamento dell’infrastruttura.
Analizzerà infine benchmark di casi reali, evidenziando classiche criticità di Magento e possibili soluzioni.
Similar to Agile requirements - alla ricerca del filo rosso (iad 2013) (20)
User Experience in alien contexts, issues, challenges, opportunities with user scenarios, interviews, bias... Some SciFi masterpieces descriptions, philosophy and metaphors and dialogues by Fabio armani and Virginia Capoluongo ad FuffaDay 2022 (www.fuffaday.org)
Slides of the 'deep' talk presented @ Agile O'Day 2017 #agileoday on the topic of "Business Agility" - Business agility is the "ability of a business system to rapidly respond to change by adapting its initial stable configuration”
A collaborative talk on lean agile transitions, challenges and experiences guided by a Lean Change approach. Tao as well as music and arts are possible keys of learning.
5. Chi sono
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified ScrumMaster &
Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
5
18. Fred
Brook’s
“The
most
difficult
part
of
building
a
so7ware
system
is
to
decide,
precisely,
what
must
be
built.
No
other
part
of
the
work
can
undermine
so
badly
the
resul>ng
so7ware
if
not
done
correctly.
No
other
part
is
so
difficult
to
fix
later.”
18
19. Fred
Brook’s
“The
most
difficult
part
of
building
a
so7ware
system
is
to
decide,
precisely,
what
must
be
built.
No
other
part
of
the
work
can
undermine
so
badly
the
resul>ng
so7ware
if
not
done
correctly.
No
other
part
is
so
difficult
to
fix
later.”
19
20. RequisiF
so?ware
• Stabilire
cosa
richiede
il
cliente
ad
un
sistema
so?ware
• (Non
stabilire
come
il
sistema
verrà̀
costruito)
20
21. RequisiF
so?ware
• (so?ware
requirements):
descrizione
dei
servizi
che
un
sistema
so?ware
deve
fornire,
insieme
ai
vincoli
da
rispeTare
sia
in
fase
di
sviluppo
che
durante
la
fase
di
operaFvità
del
so?ware
21
26. • Ci
sono
due
principali
finalità
del
processo
di
requisiF,
a
prescindere
se
si
uFlizza
un
approccio
tradizionale
o
uno
agile
per
le
metodologie
di
sviluppo.
26
32. • Anche
se
il
problema
di
base
rimane
lo
stesso,
molte
soluzioni
possono
esistere
ed
i
requisiF
si
andranno
a
collegare
ad
una
tra
queste
possibili
soluzioni.
32
47. 5 livelli della pianificazione agile
Vision
Roadmap
Release
IteraFon
Day
47
48. Stesso processo @ tutti I livelli
• Lo stesso processo agile agisce (come un
frattale) a differenti scale temporali,
differenti time-box e livelli di
pianificazione.
48
50. Strategic
Theme
IniFaFve
IniFaFve
Feature
Feature
Tac>c
Feature
Epic
T
Epic
Story
Story
Story
T
Epic
Story
Story
Story
Story
Story
Story
Story
T
T
T
T
T
T
T
Story
Story
T
T
T
T
50
54. Vision
» Backlog
• Come
possiamo
passare
dalla
Vision
al
Product
Backlog?
• Ad
esempio
uFlizzando
una
serie
di
canvas
così
come
proposto
da
Roman
Pichler
54
60. Product
Backlog
• Ecco
alcune
cose
da
tenere
presenF
riguardo
il
product
backlog:
– I
requisiF
sono
emergenF
– Il
product
backlog
richiede
“grooming”
–
ovvero
un
conFnuo
raffinamento
dei
suoi
requisiF
– Il
Product
Backlog
può
essere
visto
come
un
iceberg
60
63. Product
Backlog
• Il
Product
Backlog
deve
essere
DEEP
(acronimo
suggerito
da
Mike
Cohn).
• Detailed
Appropriately
• EsFmated
• Emergent
• PrioriFzed
63
64. Backlog
item
• Dai
requisiF
ai
backlog
item
Requirement
1…*
1…*
Backlog
Item
64
65. Backlog
item
• Il
Product
Backlog
può
contenere
molteplici
Fpologie
di
elemenF
(genericamente
chiamaF
Backlog
item):
– Feature
– Epic
– Story
(user
story,
tech
story)
– Bug
– …
65
70. Feature
• Indipendentemente
dalla
forma,
il
contenuto
primario
della
Vision
è
un
insieme
di
feature
che
descrivono
quali
nuove
funzionalità
il
sistema
dovrà
fare
per
i
propri
utenF
e
quali
benefici
quesF
ulFmi
ne
trarranno.
Leffingwell
[2012]
70
72. Feature
• Una
feature
è
un
servizio
fornito
da
un
prodoTo
per
soddisfare
uno
o
più
bisogni
del
cliente.
72
73. Feature
• Per
esempio:
"Il
sistema
offre
un
database
relazionale
per
ges>re
i
da>
persisten>”
73
74. Feature
» CaraTerisFche
• Una
feature
è
un
elemento
valido
a
livello
di
strategia
e
cosFtuisce
un
elemento
del
Program
Backlog
• Inoltre
può
essere
considerato
un
elemento
di
transizione
tra
il
layer
strategico
e
quello
tajco
(di
esecuzione)
74
88. Acceptance
Tests
• Le
feature
come
le
user
story,
richiedono
acceptance
test
• Ogni
feature
richiede
uno
o
più
acceptance
test,
e
non
può
essere
considerata
done
finché
tuj
i
suoi
test
non
passano
88
89. Backlog
Item
Is
one
of
Feature
1
Realized
by
Story
0,1
1..*
1
Done
when
passes
1..*
Feature
Acceptance
Test
1..*
Story
Acceptance
Test
89
99. 1.
Scrivi
un
test
che
fallisca
RED
3.
Elimina
le
ridondanze
REFACTOR
GREEN
2.
Rendi
il
codice
funzionante
99
100. • L'uso
del
Test
Driven
Development
permeTe
non
solo
di
costruire
il
programma
assieme
ad
una
serie
di
test
di
regressione
automaFzzabili,
ma
anche
di
sFmare
in
maniera
più
precisa
lo
stato
d'avanzamento
dello
sviluppo
di
un
progeTo.
• E’
una
tecnica
di
design
e
di
coding.
100
106. Backlog
Item
Constrained
by
0..*
0..*
Non-‐funcFonal
Requirement
1..*
Compliant
when
passes
0..*
System
QualiFes
tests
106
107. NonfuncFonal
requirement
• I
nonfuncFonal
requirement
possono
essere
visF
come
dei
vincoli
sui
Backlog
Feature
Story
Feature
Story
Feature
Story
Feature
Story
Feature
Story
Feature
Epic
Feature
Epic
Feature
Epic
NFR
NFR
107
117. Requirement
Constrained
by
Backlog
Item
0…*
0…*
1…*
1…*
Is
one
of
Feature
Non-‐funcFonal
Requirements
System
QualiFes
tests
Realized
by
0,1
1…*
Story
Implemented
by
0,1
1…*
Task
Is
one
of
Feature
Acceptance
Test
User
Story
Other
work
item
Done
when
passes
Story
Acceptance
Test
Unit
Test
117
119. Chi sono
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified ScrumMaster &
Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
119
121. Strategic
Theme
IniFaFve
IniFaFve
Feature
Feature
Tac>c
Feature
Epic
T
Epic
Story
Story
Story
T
Epic
Story
Story
Story
Story
Story
Story
Story
T
T
T
T
T
T
T
Story
Story
T
T
T
T
122. Requirement
1…*
1…*
Backlog
Item
0…*
1…*
Constrained
by
Non-‐funcFonal
Requirements
Is
one
of
Feature
0,1
1…*
Realized
by
Story
0,1
1…*
Implemented
by
Done
when
passes
Acceptance
Test
Task
123. Requirement
1…*
1…*
Backlog
Item
0…*
1…*
Constrained
by
Non-‐funcFonal
Requirements
Is
one
of
Strategic
Product
Theme
1
1…*
IniFat.
Realized
by
0,1
1…*
Feature
Realized
by
0,1
1…*
Realized
by
Story
0,1
1…*
Implemented
by
Done
when
passes
Acceptance
Test
Consumer
Init.
Architecture
Init.
Task