Agile methodologies

SCAI S.p.A. 1

Agile Methodologies: Scrum. Kanban & Co.di

Alessandro Graps

Bologna, 28/10/2013

Project & Delivery Area

SCAI S.p.A. 2

There are no best practices...

Only good practices...

IN THE CONTEXT...


SCAI S.p.A. 3

IndiceTeorico

Metodologia tradizionaleAgile Methodologies

ScrumKanbanXPScrum vs KanbanPerche’ utilizzarle

ConclusioniWorkshop


SCAI S.p.A. 4

Brief History of Development Methodologies

WATERFALL (Royce)

Requirements, designimplementation, verification & maintenance

1960 85 9119801970

V-MODEL (Anon)

Aligns testing toWaterfall development

SPIRAL MODEL (Barry Boehm)

Iterative

RAD(James Martin)

Prototyping, iterative, time-boxed, user driven

RUP (Rational)

Object oriented, iterative, time-boxed, user driven

AGILE e.g. XP(Kent Beck)

Incremental, user driven, low process

98 99

Waterfall V-Model

Spiral Model

RAD

RUP

Metodhologies


SCAI S.p.A. 5

Metodologia Tradizionale: Waterfall

Requirements

Design

Implementation

Verification

Manteinance


SCAI S.p.A. 6

Metodologia Tradizionale

Strutturata


SCAI S.p.A. 7


StrutturataGrandi Progetti


SCAI S.p.A. 8


StrutturataGrandi ProgettiSequenziale


SCAI S.p.A. 9


StrutturataGrandi ProgettiSequenzialeAdatta a situazioni dove il cambiamento non e’ comune


SCAI S.p.A. 10



Interna


SCAI S.p.A. 11



InternaUn processo che richiede chiarezza sulla definizione dei requisiti


SCAI S.p.A. 12

Metodologia Tradizionale:Vantaggi

L’approccio a cascata cerca di acquisire ed analizzare tutti i requisiti del progetto prima di avviare il disegno dell’applicazione.


SCAI S.p.A. 13



Prevede tempi e costi in anticipo controllando il contenuto per rispettarli.


SCAI S.p.A. 14



Prevede tempi e costi in anticipo controllando il contenuto per rispettarli.

In caso di turnover tra il personale, la quantita’ di documentazione permette un minimo impatto del nuovo personale sul progetto


SCAI S.p.A. 15

Metodologia Tradizionale:Svantaggi

Una volta che uno step e’ completato,non si puo’ tornare allo step precedente


SCAI S.p.A. 16



Si basa fortemente sui requisiti iniziali. Se tali requisiti sono difettosi, il progetto e’ destinato a fallire


SCAI S.p.A. 17




Il processo iniziera’ da capo se sara’ rilevato un’errore di requisito oppure abbiamo necessita’ di un cambiamento di requisito


SCAI S.p.A. 18




Il processo iniziera’ da capo se sara’ rilevato un’errore di requisito oppure abbiamo necessita’ di un cambiamento di requisito

Test solo alla fine


SCAI S.p.A. 19


Non si prendono in considerazione le continue evoluzioni del cliente. Ogni cambiamento sara’ causa di ritardi.


SCAI S.p.A. 20

Facciamo un Test

Test di interferenza• Rosso• Giallo• Verde• Blu• Rosso • Blu • Giallo• Verde• Blu

Non leggete le parole. Provate ad elencare i colori rapidamente ad alta voce.


SCAI S.p.A. 21

Interferenza

Nel color test la maggior parte delle persone legge le parole anche se e’ stato chiesto di elencare i colori

Quando si guarda la figura si vedono sia i colori che le parole. Queste due cose sono in contrasto tra loro. E’ necessario quindi prendere una decisione


SCAI S.p.A. 22

Interferenza

Poiche’ l’esperienza insegna che il significato di una parola e’ piu’ importante del colore con cui e’ scritta c’e’ un’interferenza quando si cerca di porre attenzione al suo colore

Questo esperimento dimostra che non si ha sempre il controllo completo su cio’ sui cui si pone attenzione: il rumore di fondo interferisce


SCAI S.p.A. 23

Rumore

E’ funzione:Dei PrerequisitiDelle PersoneDella TecnologiaDei Disturbi


SCAI S.p.A. 24

Agile Methodologies


SCAI S.p.A. 25

Agile Methodologies

Cosa?


SCAI S.p.A. 26

Agile Methodologies

Cosa?I metodi agili si propongono di sviluppare software che abbia un alto valore per il cliente, rilasciandolo presto e a ritmo costante


SCAI S.p.A. 27

Agile Methodologies

Quando?


SCAI S.p.A. 28

Agile Methodologies

Quando?Nel 2001 17 proffessionisti di spicco si radunarono in una localita’ sciistica dello Utah per discutere assiame del futuro del mondo software


SCAI S.p.A. 29

Agile Methodologies

Perche’?


SCAI S.p.A. 30

Agile Methodologies

Perche’?... Stanchi di assistere ad una percentuale sempre crescente di progetti sofware che si frantumavano sulle rocce al termine della cascata o rimanevano impantanati in cicli infiniti e fallimentari lungo la strada


SCAI S.p.A. 31

Agile Methodologies

Quindi?


SCAI S.p.A. 32

Agile Methodologies

Quindi?Dall’incontro di queste persone si genero’ una riflessione profonda e limpida: il metodo ingegneristico applicato al sofware non e’ detto che funzioni in quanto lo sviluppo sofware e’ un’attivita’ creativa e non produttiva, richiede l’apporto di knowledge worker e non di operatori con una fore componente artigianale e di iterazione umana


Agile Methodologies

SCAI S.p.A. 33Project & Delivery Area

SCAI S.p.A. 34

Agile Methodologies


SCAI S.p.A. 35

Agile Methodologies

12 Regole


SCAI S.p.A. 36

Agile Methodologies

La nostra massima priorita’ e’ soddisfare il cliente rilasciando software di valore, fin subito e in maniera continua


SCAI S.p.A. 37

Agile Methodologies

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


SCAI S.p.A. 38

Agile Methodologies

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


SCAI S.p.A. 39

Agile Methodologies

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


SCAI S.p.A. 40

Agile Methodologies

Fondiamo i progetti su individui motivati.Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacita’ di portare a termine il lavoro


SCAI S.p.A. 41

Agile Methodologies

Una conversazione faccia a faccia e’ il modo piu’ efficace per comunicare con il team ed all’interno del team


SCAI S.p.A. 42

Agile Methodologies

Il software funzionante e’ il principale metro di misura di progresso


SCAI S.p.A. 43

Agile Methodologies

I processi agili promuovono uno sviluppo sostenibile.

Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitivamente un ritmo costante.


SCAI S.p.A. 44

Agile Methodologies

La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilita’


SCAI S.p.A. 45

Agile Methodologies

La semplicita’ – l’arte di massimizzare la quantita’ di lavoro non solto- e’ essenziale


SCAI S.p.A. 46

Agile Methodologies

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


SCAI S.p.A. 47

Agile Methodologies

A intervalli regolari il team riflette su come diventare piu’ efficace, dopodiche’ regola e adatta il proprio comportamento di conseguenza


SCAI S.p.A. 48

Agile Methodologies


Scr

um

Kan

ban

XP

Altr

e

Agile

SCAI S.p.A. 49

Agile Methodologies


How is agile

different?

Change in

feedback

Emphasis

(SCRUM)

Reduction in

evolution costs(KANB

AN)

Reduction in

coordination costs(XP)

SCAI S.p.A. 50

SCRUM


Scrum

SCAI S.p.A. 51

Hirotaka Takeuchi and Ikujiro Nonaka, “The New Product Development Game”, Harvard Business Review, January 1986.

“l'approccio a 'staffetta' nello sviluppo di un prodotto... potrebbe entrare in conflitto con l'obiettivo di massimizzare flessibilità & velocità. Al contrario, un approccio “olistico” (a mischia stile rugby), dove una squadra cerca di avanzare un passo alla volta, potrebbe essere più funzionale per centrare i requisiti di competitività.”

SCAI S.p.A. 52

SCRUM

CancelGift wrapReturn

Sprint2-4 weeks

ReturnSprint goal

Sprint backlog

Potentially shippableproduct increment

Productbacklog

CouponsGift wrapCoupons

Cancel

24 hours


SCAI S.p.A. 53

SCRUM:Mettiamo tutto insieme


SCAI S.p.A. 54

SCRUM:Sprint

Un progetto Scrum deve evolvere con una serie di Sprint


SCAI S.p.A. 55

SCRUM:Sprint

Un progetto Scrum deve evolvere con una serie di SprintCome in un’iterazione XP


SCAI S.p.A. 56

SCRUM:Sprint


Ha una durata di 2-4 settimane o un mese al massimo


SCAI S.p.A. 57

SCRUM:Sprint



Una durata costante di ogni Sprint aiuta a sviluppare meglio il ritmo


SCAI S.p.A. 58

SCRUM:Sprint



Una durata costante di ogni Sprint aiuta a sviluppare meglio il ritmo

Designed, sviluppo e test devono essere eseguiti durante lo sprint


SCAI S.p.A. 59

SCRUM:Nessun cambiamento durante lo Sprint


Change

SCAI S.p.A. 60

SCRUM:Nessun cambiamento durante lo Sprint


Change

Una buona pianificazione aiutera’ ad evitare i cambiamenti

SCAI S.p.A. 61

SCRUM:Framework

RuoliProduct OwnerScrum MasterTeam


SCAI S.p.A. 62

SCRUM:Ruoli:Product Owner

Definisce le caratteristiche del prodotto


SCAI S.p.A. 63


Definisce le caratteristiche del prodottoDecide la data e i contenuti del rilascio


SCAI S.p.A. 64


Definisce le caratteristiche del prodottoDecide la data e i contenuti del rilascioE’ responsabile della redditivita’ del prodotto (ROI)


SCAI S.p.A. 65



Definisce le priorita’ e le caratteristiche in base alle richieste del mercato


SCAI S.p.A. 66




Regola le caratterisitche e le priorita’ per ogni Sprint


SCAI S.p.A. 67




Regola le caratterisitche e le priorita’ per ogni Sprint

Accetta o rifiuta i risultati del lavoro


SCAI S.p.A. 68

SCRUM:Ruoli:Scrum Master

Rappresenta la gestione del progetto


SCAI S.p.A. 69


Rappresenta la gestione del progettoResponsabile dei valori e le pratiche Scrum


SCAI S.p.A. 70



Rimuove gli ostacoli


SCAI S.p.A. 71



Rimuove gli ostacoliAssicursi che la squadra sia completamente funzionale e produttiva


SCAI S.p.A. 72




Attiva una stretta collaborazione tra ruoli e funzioni


SCAI S.p.A. 73




Attiva una stretta collaborazione tra ruoli e funzioni

Scherma la squadra da interferenze esterne


SCAI S.p.A. 74

SCRUM:Ruoli:Team

Un gruppo auto-organizzato


SCAI S.p.A. 75

SCRUM:Ruoli:Team

Un gruppo auto-organizzatoNon esiste nessun titolo


SCAI S.p.A. 76

SCRUM:Ruoli:Team

Un gruppo auto-organizzatoNon esiste nessun titoloLa membership non dovrebbe mai cambiare


SCAI S.p.A. 77

SCRUM:Framework

CerimonieSprint planningSprint reviewSprint retrospectiveDaily Scrum meeting (Morning Meeting o StandUp)


SCAI S.p.A. 78

SCRUM:Cerimonie:Sprint planning


Sprint planning meeting

Sprint prioritization• Analyze and evaluate

product backlog• Select sprint goalSprint planning

• Decide how to achieve sprint goal (design)

• Create sprint backlog (tasks) from product backlog items (user stories / features)

• Estimate sprint backlog in hours

Sprintgoal

Sprintbacklog

Business conditions

Team capacityProduct backlog

Technology

Current product

SCAI S.p.A. 79



Il team seleziona gli elementi dal backlog di prodotto che possono completare

SCAI S.p.A. 80




Lo Sprint backlog viene creato

SCAI S.p.A. 81




Lo Sprint backlog viene creatoLe attivita’ vengono identificate e ciascuna stimata (1-16 ore)

SCAI S.p.A. 82





E’ un processo collaborativo, non e’ fatto solo dallo ScrumMaster

SCAI S.p.A. 83





E’ un processo collaborativo, non e’ fatto solo dallo ScrumMaster

Progettazione ad alto livello

SCAI S.p.A. 84

SCRUM:Cerimonie:Daily Meeting


Quotidiano

SCAI S.p.A. 85



Quotidiano15 minuti

SCAI S.p.A. 86



Quotidiano15 minutiStand-up

SCAI S.p.A. 87



Quotidiano15 minutiStand-upNon e’ il momento giusto per la soluzione dei problemi

SCAI S.p.A. 88




Tutti sono invitati

SCAI S.p.A. 89




Tutti sono invitatiSolo il team, SM e PO possono parlare

SCAI S.p.A. 90




Tutti sono invitatiSolo il team, SM e PO possono parlareAiuta ad evitare incontri inutili

SCAI S.p.A. 91

SCRUM:Cerimonie:Daily Meeting::3 Domande


What did you do yesterday?1

SCAI S.p.A. 92



What will you do today?2

SCAI S.p.A. 93



Is anything in your way?3

SCAI S.p.A. 94

SCRUM:Cerimonie:Sprint Review


Il Team presenta quello che ha fatto durante lo sprint

SCAI S.p.A. 95




DEMO

SCAI S.p.A. 96




DEMOInformale

SCAI S.p.A. 97




DEMOInformaleDurata di 2 ore

SCAI S.p.A. 98




DEMOInformaleDurata di 2 oreNessuna diapositiva

SCAI S.p.A. 99




DEMOInformaleDurata di 2 oreNessuna diapositivaTutta la squadra partecipa

SCAI S.p.A. 100




DEMOInformaleDurata di 2 oreNessuna diapositivaTutta la squadra partecipaTutti sono invitati

SCAI S.p.A. 101

SCRUM:Cerimonie:Retrospettiva


Periodicamente ci si confronta su cosa non e’ andato

SCAI S.p.A. 102




Di solito dura tutta la giornata

SCAI S.p.A. 103




Di solito dura tutta la giornataFatto a fine sprint

SCAI S.p.A. 104




Di solito dura tutta la giornataFatto a fine sprintTutta la squadra partecipa

SCAI S.p.A. 105




Di solito dura tutta la giornataFatto a fine sprintTutta la squadra partecipaPossibilita’ di osservatori

SCAI S.p.A. 106

SCRUM:Framework

ArtefattiProduct backlogSprint backlogBurndown charts


SCAI S.p.A. 107

SCRUM:Artefatti:Product backlog


Elenco dei requisiti

SCAI S.p.A. 108



Elenco dei requisitiLista di desideri (Richieste del cliente)

SCAI S.p.A. 109



Elenco dei requisitiLista di desideri (Richieste del cliente)Ogni elemento e’ idealmente espresso in linguaggio non tecnico

SCAI S.p.A. 110




Priorita’ per il P.O.

SCAI S.p.A. 111




Priorita’ per il P.O.Le priorita’ vengono discusse all’inizio di ogni sprint

SCAI S.p.A. 112

SCRUM:Artefatti:Sprint backlog


I componenti scelgono il lavoro

SCAI S.p.A. 113



I componenti scelgono il lavoroIl lavoro non viene mai assegnato

SCAI S.p.A. 114



I componenti scelgono il lavoroIl lavoro non viene mai assegnatoIl lavoro stimato rimanente viene aggiornato quotidianamente

SCAI S.p.A. 115




Ogni membro del team puo’ aggiungere, eliminare o modificare il backlog sprint

SCAI S.p.A. 116





Effort per lo sprint

SCAI S.p.A. 117





Effort per lo sprintSe il task di backlog non e’ chiaro bisogna chiedere maggiore dettaglio o dividere il task se troppo complesso

SCAI S.p.A. 118

SCRUM:Artefatti:Burndown chart


Rappresentazione grafica delle ore necessarie al team per ogni giorno della settimana

Lun Mar Mer Gio Ven0

10

20

30

40

50

60

SCAI S.p.A. 119



TasksCode the user interfaceCode the middle tierTest the middle tierWrite online help

Mon8

168

12

Tues Wed Thur Fri4

1216

711

81016 8

SCAI S.p.A. 120



Hour

s

40302010

0 Mon Tue Wed Thu Fri

50

SCAI S.p.A. 121

SCRUM:Scalabilita’


Un tipico team e’ formato da 7 +/- 2 persone

E’ dipendente da diversi fattori:Tipo di applicazioneDimensioni del teamDispersione del teamDurata del progetto

Esistono esempi di progetti che hanno coinvolto più di 500 persone

Scrum di Scrum



SCAI S.p.A. 124

Domande


SCAI S.p.A. 125

Kanban


SCAI S.p.A. 126

Cos’e’ Kanban?


Kan significa visuale e ban significa carta o lavagna

SCAI S.p.A. 127

Cos’e’ Kanban?


Kan significa visuale e ban significa carta o lavagna

Kanban is a physical card used in Toyota Production System (TPS) to support non-centralized "pull" production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing.

SCAI S.p.A. 128

Kanban Practices


Mappa il valore del flusso

SCAI S.p.A. 129

Kanban Practices


Mappa il valore del flussoOcchio particolare al lavoro

SCAI S.p.A. 130

Kanban Practices


Mappa il valore del flussoOcchio particolare al lavoroLimita il WIP (Work in Progress)

SCAI S.p.A. 131

Kanban Practices


Mappa il valore del flussoOcchio particolare al lavoroLimita il WIP (Work in Progress)Stabilisce una cadenza

SCAI S.p.A. 132

Kanban Boards


Source: Crisp (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf)

SCAI S.p.A. 133

Limita il Work in Progress


Riduce il multi tasking

SCAI S.p.A. 134



Riduce il multi taskingPrevenendo lo switching tra vari contesti

SCAI S.p.A. 135




Eseguire attivita’ in sequenza aumenta la produttivita’

SCAI S.p.A. 136





Massimizzazione della produttivita’

SCAI S.p.A. 137





Massimizzazione della produttivita’Migliora il lavoro di squadra

SCAI S.p.A. 138






Lavorare insieme per fare le cose ben fatte

SCAI S.p.A. 139






Lavorare insieme per fare le cose ben fatte

Aumenta le cross-functionality

SCAI S.p.A. 140

Pull, Don’t Push


SCAI S.p.A. 141

WIP Limite Strategico


Partiamo con valori iniziali:

SCAI S.p.A. 142



Partiamo con valori iniziali:Piccole costanti

SCAI S.p.A. 143



Partiamo con valori iniziali:Piccole costantiNumero di sviluppatori

SCAI S.p.A. 144



Partiamo con valori iniziali:Piccole costantiNumero di sviluppatoriNumero di tester

SCAI S.p.A. 145




Misuriamo il tempo medio per completare un task:

SCAI S.p.A. 146




Misuriamo il tempo medio per completare un task:Ottimizziamo per renderlo il piu’ piccolo e prevedibile possibile

SCAI S.p.A. 147




Misuriamo il tempo medio per completare un task:Ottimizziamo per renderlo il piu’ piccolo e prevedibile possibile

Adattiamo ai nostri limiti

SCAI S.p.A. 148

La Cadenza


“A regular cadence, or heartbeat, establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

SCAI S.p.A. 149

Kanban Metrics


Stories in progress (SIP) When story enters stories queue set

entry date (ED) When story enters first process step set

start processing date (SPD) When story is done set finish date (FD) Cycle time (CT) = FD – SPD Waiting time (WT) = SPD – ED Throughput (T) = SIP / CT

SCAI S.p.A. 150

Workflow Diagram


SCAI S.p.A. 151

Kanban:5 Ragioni errate per applicare Kanban


User stories diversity

SCAI S.p.A. 152



User stories diversity User stories vary in size a lot, large stories don’t

feet into an iteration

SCAI S.p.A. 153




feet into an iteration Failed iterations

SCAI S.p.A. 154





Many stories are not completed in a single iteration

SCAI S.p.A. 155






Failed retrospective meetings

SCAI S.p.A. 156






Failed retrospective meetings Retrospective meetings are waste

SCAI S.p.A. 157







Shared people

SCAI S.p.A. 158







Shared people We have a single pool of developers for some

projects

SCAI S.p.A. 159








projects Simplicity

SCAI S.p.A. 160








projects Simplicity

Kanban is so simple, no planning, no retrospectives, no estimations

SCAI S.p.A. 161

Kanban:5 Ragioni per applicare Kanban


Ability to release anytime

SCAI S.p.A. 162



Ability to release anytime When user story is ready you may release it

SCAI S.p.A. 163




Ability to change priorities on the fly

SCAI S.p.A. 164




Ability to change priorities on the fly Not started stories queue is always changeable

SCAI S.p.A. 165





No need in iterations

SCAI S.p.A. 166





No need in iterations Iterate first then flow

SCAI S.p.A. 167






No need to estimate

SCAI S.p.A. 168






No need to estimate Release when it is ready, do most important story

SCAI S.p.A. 169







Perfect flow visualization

SCAI S.p.A. 170







Perfect flow visualization Clear view of current work in progress

SCAI S.p.A. 171

Kanban:When no Need in Iterations?


Ability to release anytime

SCAI S.p.A. 172




SCAI S.p.A. 173




Ability to change priorities on the fly

SCAI S.p.A. 174





SCAI S.p.A. 175





No need in iterations

SCAI S.p.A. 176






SCAI S.p.A. 177






No need to estimate

SCAI S.p.A. 178







SCAI S.p.A. 179







Perfect flow visualization

SCAI S.p.A. 180







Perfect flow visualization Clear view of current work in progress

SCAI S.p.A. 181

Kanban:When no Need to Estimate?


You are new to the project

SCAI S.p.A. 182



You are new to the project Estimations don’t change plans

SCAI S.p.A. 183



You are new to the project Estimations don’t change plans Velocity is not taken into account

SCAI S.p.A. 184



You are new to the project Estimations don’t change plans Velocity is not taken into account Team is very experienced in breaking tasks

SCAI S.p.A. 185



You are new to the project Estimations don’t change plans Velocity is not taken into account Team is very experienced in breaking tasks Average cycle time is enough for the customer

SCAI S.p.A. 186

Kanban:Esempio


1

2


SCAI S.p.A. 187

Kanban:Esempio



3

4

SCAI S.p.A. 188

Kanban:Esempio



5

6

SCAI S.p.A. 189

Kanban:Esempio



7

8

SCAI S.p.A. 190

Kanban:Esempio



9

10

SCAI S.p.A. 191

Kanban:Esempio



11

12

SCAI S.p.A. 192

Kanban per il P.O.


New Prioritized buffer Unlimited size

Preparing Work in Progress Limited to PO capacity Cycle time Promotion model

Ready Prioritized buffer 1-2 Team Velocity

In Progress Work in Progress Limited to Team WIP limit

SCAI S.p.A. 193

Kanban:Best Practices


Bugs get top priority

SCAI S.p.A. 194



Bugs get top priority Set so minimal WIP as possible

SCAI S.p.A. 195



Bugs get top priority Set so minimal WIP as possible Stories should be ”minimal marketable

features”

SCAI S.p.A. 196




features” Create separate column with goals

SCAI S.p.A. 197




features” Create separate column with goals Add Scrum practices (daily scrum,

retrospectives, demos)

SCAI S.p.A. 198




features” Create separate column with goals Add Scrum practices (daily scrum,

retrospectives, demos) Add XP engineering practices

SCAI S.p.A. 199

Uses Stories Mapping


SCAI S.p.A. 200

Kanban:Issues


Mancanza di goal e di focus

SCAI S.p.A. 201

Kanban:Issues


Mancanza di goal e di focus Meno prevedibilita’

SCAI S.p.A. 202

Kanban:Issues


Mancanza di goal e di focus Meno prevedibilita’ Meno livello di impegno

SCAI S.p.A. 203

Kanban:Issues


Mancanza di goal e di focus Meno prevedibilita’ Meno livello di impegno Disciplina

SCAI S.p.A. 204

Kanban:Caso reale


SCAI S.p.A. 205

Domande


SCAI S.p.A. 206

Scrum vs Kanban


Kanban e’ meno prescrittivo

SCAI S.p.A. 207

Scrum vs Kanban


Task flowSource: Crisp (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf)

Scrum

Kanban

SCAI S.p.A. 208

Scrum vs Kanban


CadenzaSource: Crisp (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf)

Scrum

Kanban

SCAI S.p.A. 209

Scrum vs Kanban:Somiglianza


Sono Lean ed Agile

SCAI S.p.A. 210



Sono Lean ed Agile Utilizzano la schedulazione dei task

SCAI S.p.A. 211



Sono Lean ed Agile Utilizzano la schedulazione dei task Entrambi limitano il WIP

SCAI S.p.A. 212



Sono Lean ed Agile Utilizzano la schedulazione dei task Entrambi limitano il WIP Trasparenza per monitorare e

migliorare i processi

SCAI S.p.A. 213




migliorare i processi Focus su rilasci frequenti

SCAI S.p.A. 214




migliorare i processi Focus su rilasci frequenti Gruppi auto-organizzati

SCAI S.p.A. 215




migliorare i processi Focus su rilasci frequenti Gruppi auto-organizzati Task

SCAI S.p.A. 216

Scrum vs Kanban:Differenze


ScrumBan

SCAI S.p.A. 217

Applicazione della tecnica Kanban nel ambito del Framework Scrum (Scrum non limita gli item per stato in quanto ha un numero totale di item limitato, limita il tempo) Rappresentazione visiva delle operazioni:

Da svolgere In svolgimentoConcluse


SCAI S.p.A. 218

Domande


SCAI S.p.A. 219

Extreme Programming


An agile development methodology

SCAI S.p.A. 220

Extreme Programming: What is XP?


An agile development methodology Created by Kent Beck in the mid 1990’s

SCAI S.p.A. 221



An agile development methodology Created by Kent Beck in the mid 1990’s A set of 12 key practices taken to their

“extremes”

SCAI S.p.A. 222




“extremes” A mindset for developers and

customers

SCAI S.p.A. 223




“extremes” A mindset for developers and

customers A religion?

SCAI S.p.A. 224



SCAI S.p.A. 225

Extreme Programming


Customer

Developers

communicationsimplicityfeedbackcourage

XP values

planning gameshort releasessimple designtest-first codingrefactoringpair programmingcontinouos integrationno overtimeon-site customercoding standard

XP practices

The Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-Hour Workweek On-site Customer Coding Standards

SCAI S.p.A. 226

Extreme Programming: The 12 Practices


Planning for the upcoming iteration Uses stories provided by the customer Technical persons determine schedules,

estimates, costs, etc A result of collaboration between the

customer and the developers

SCAI S.p.A. 227

Extreme Programming: 1 – Planning Game


Reduction in time wasted on useless features

Greater customer appreciation of the cost of a feature

Less guesswork in planning

SCAI S.p.A. 228

Extreme Programming: 1 – Planning Game - Advantages


Customer availability Is planning this often necessary?

SCAI S.p.A. 229

Extreme Programming: 1 – Planning Game - Disadvantages


Small in terms of functionality Less functionality means releases

happen more frequently Support the planning game

SCAI S.p.A. 230

Extreme Programming: 2 – Small Releases


Frequent feedback Tracking Reduce chance of overall project

slippage

SCAI S.p.A. 231

Extreme Programming: 2 – Small Releases - Advantages


Not easy for all projects Not needed for all projects Versioning issues

SCAI S.p.A. 232

Extreme Programming: 2 – Small Releases - Disadvantages


The oral architecture of the system A common set of terminology

SCAI S.p.A. 233

Extreme Programming: 3 – Metaphor


Encourages a common set of terms for the system

Reduction of buzz words and jargon A quick and easy way to explain the

system

SCAI S.p.A. 234

Extreme Programming: 3 – Metaphor - Advantages


Often the metaphor is the system Another opportunity for

miscommunication The system is often not well understood

as a metaphor

SCAI S.p.A. 235

Extreme Programming: 3 – Metaphor - Disadvantages


K.I.S.S. “Keep It Simple, Stupid!” Do as little as needed, nothing more

SCAI S.p.A. 236

Extreme Programming: 4 – Simple Design


Time is not wasted adding superfluous functionality

Easier to understand what is going on Refactoring and collective ownership is

made possible Helps keeps programmers on track

SCAI S.p.A. 237

Extreme Programming: 4 – Simple Design - Advantages


What is “simple?” Simple isn’t always best

SCAI S.p.A. 238

Extreme Programming: 4 – Simple Design - Disadvantages


Unit testing Test-first design All automated

SCAI S.p.A. 239

Extreme Programming: 5 – Testing


Unit testing promote testing completeness

Test-first gives developers a goal Automation gives a suite of regression

test

SCAI S.p.A. 240

Extreme Programming: 5 – Testing - Advantages


Automated unit testing isn’t for everything

Reliance on unit testing isn’t a good idea

A test result is only as good as the test itself

SCAI S.p.A. 241

Extreme Programming: 5 – Testing - Disadvantages


Extreme Programming: 6 – Refactoring

Changing how the system does something but not what is done

Improves the quality of the system in some way

Project & Delivery Area SCAI S.p.A. 242

Extreme Programming: 6 - Refactoring – Advantages

Prompts developers to proactively improve the product as a whole

Increases developer knowledge of the system


Extreme Programming: 6 - Refactoring – Disadvantages

Not everyone is capable of refactoring Refactoring may not always be

appropriate Would upfront design eliminate

refactoring?


Extreme Programming: 7 – Pair Programming

Two Developers, One monitor, One Keyboard

One “drives” and the other thinks Switch roles as needed


Extreme Programming: 7 - Pair Programming – Advantages

Two heads are better than one Focus Two people are more likely to answer

the following questions: Is this whole approach going to

work? What are some test cases that may

not work yet? Is there a way to simplify this?


Extreme Programming: 7 - Pair Programming – Disadvantages

Many tasks really don’t require two programmers

A hard sell to the customers Not for everyone


Extreme Programming: 8 – Collective Ownership

The idea that all developers own all of the code

Enables refactoring


Extreme Programming: 8 - Collective Ownership – Advantages

Helps mitigate the loss of a team member leaving

Promotes developers to take responsibility for the system as a whole rather then parts of the system


Extreme Programming: 8 - Collective Ownership - Disadvantages

Loss of accountability Limitation to how much of a large

system that an individual can practically “own”


Extreme Programming: 9 – Continuous Integration

New features and changes are worked into the system immediately

Code is not worked on without being integrated for more than a day


Extreme Programming: 9 - Continuous Integration - Advantages

Reduces to lengthy process Enables the Small Releases practice


Extreme Programming: 9 - Continuous Integration – Disadvantages

The one day limit is not always practical

Reduces the importance of a well-thought-out architecture


Extreme Programming: 10 – 40-Hour Week

The work week should be limited to 40 hours

Regular overtime is a symptom of a problem and not a long term solution


Extreme Programming: 10 - 40-Hour Week – Advantage

Most developers lose effectiveness past 40-Hours

Value is placed on the developers well-being

Management is forced to find real solutions


Extreme Programming: 10 - 40-Hour Week - Disadvantages

The underlying principle is flawed 40-Hours is a magic number Some may like to work more than 40-

Hours


Extreme Programming: 11 – On-Site Customer

Just like the title says! Acts to “steer” the project Gives quick and continuous feedback

to the development team


Extreme Programming: 11 - On-Site Customer – Advantages

Can give quick and knowledgeable answers to real development questions

Makes sure that what is developed is what is needed

Functionality is prioritized correctly


Extreme Programming: 11 - On-Site Customer – Disadvantages

Difficult to get an On-Site Customer The On-Site customer that is given

may not be fully knowledgeable about what the company

May not have authority to make many decisions

Loss of work to the customer’s company


Extreme Programming: 12 – Coding Standards

All code should look the same It should not possible to determine

who coded what based on the code itself


Extreme Programming: 12 - Coding Standards – Advantages

Reduces the amount of time developers spend reformatting other peoples’ code

Reduces the need for internal commenting

Call for clear, unambiguous code


Extreme Programming: 12 - Coding Standards – Disadvantages

Degrading the quality of inline documentation


Extreme Programming - Manager and Customer Bill of Rights

You have the right to an overall plan, to know what can be accomplished, when, and at what cost.




You have the right to get the most value out of every programming week.





You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.






You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.






You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.

You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can cancel at any time and be left with a useful working system, reflecting investment to date.


Extreme Programming - Programmer Bill Of Rights

You have the right to know what is needed, with clear declarations of priority.




You have the right to produce quality work at all times.





You have the right to ask for and receive help from peers, superiors, and customers.






You have the right to make and update your own estimates.






You have the right to make and update your own estimates.

You have the right to accept your responsibilities instead of having them assigned to you.


Extreme Programming - Advantages

Built-In Quality



Built-In Quality Overall Simplicity



Built-In Quality Overall Simplicity Programmer Power



Built-In Quality Overall Simplicity Programmer Power Customer Power



Built-In Quality Overall Simplicity Programmer Power Customer Power Synergy Between Practices


Extreme Programming - Disadvantages

Informal, little, or no documentation



Informal, little, or no documentation Scalability



Informal, little, or no documentation Scalability Contract Issues



Informal, little, or no documentation Scalability Contract Issues Misconception on the cost of change



Informal, little, or no documentation Scalability Contract Issues Misconception on the cost of change Tailoring


Extreme Programming - Application – Advantageous

Highly uncertain environments



Highly uncertain environments Internal projects



Highly uncertain environments Internal projects Joint ventures


Extreme Programming - Application – Disadvantageous

Large, complex environments



Large, complex environments Safety critical situations



Large, complex environments Safety critical situations Well understood requirements



Large, complex environments Safety critical situations Well understood requirements Distant or unavailable customer


Extreme Programming - Who benefits from XP?

get clear requirements & priorities

can do a good job can make technical

decisions don’t work overtime

get most business value first get accurate feedback can make informed business

decisions can change their mind

Programmers: Customers:


SCAI S.p.A. 291

Domande


… IN THE CONTEXT

Le agile methodologies vengono considerate come condizione necessaria e sufficiente per portare a termine e con SUCCESSO un progetto.

PURTROPPO QUESTO NON E’ CORRETTO!!!


… IN THE CONTEXT

Si possono seguire tutte le pratichi agili (essere il “guro” delle metodologie) e FALLIRE. Il fallimento puo’ essere dovuto alle condizioni ereditate dal team e dall’azienda


… IN THE CONTEXT

Affinche’ un progetto abbia successo, e’ necessario che tutti remino nella stessa direzione e che in aggiunta ogni team abbia gli attributi fondamentali, come ad esempio le competenze degli sviluppatori, la conoscenza del business da parte del P.O., etc.


… IN THE CONTEXT

Analogamente un progetto software puo’ avere successo anche senza usare nessuna pratica agile. Se tutto va bene in questo modo, sono il primo a dire: “continuate in questa direzione, magari aggiungendo qualche processo che possa giovare e non distruggere il progetto”.


… IN THE CONTEXT

Non scegliete di cambiare il proprio modus operandi per un capriccio o per una moda, si rischiera’ di portare solo problemi



There are no best practices...

Only good practices...

IN THE CONTEXT...

Non dimenticate!!!

ANY process or methodology (that is not actively destructive), applied to a skilled,disciplined, high-functioning,

motivated team, will succeed, regardless of the process.

Likewise, any process applied to a low-functioning team will likely fail.


SCAI S.p.A. 299

Domande


SCAI S.p.A. 300

Grazie


SCAI S.p.A. 301

Workshop:Cooking


SCAI S.p.A. 302

Workshop:Cooking


Pizza Kanban

SCAI S.p.A. 303

Workshop:Cooking


Durata:Turni da 10 minutiRetrospettiva

SCAI S.p.A. 304

Workshop:Cooking


Ingredienti pizza1 base3 fette di mozzarella3 fette di prosciutto

SCAI S.p.A. 305

Workshop:Cooking


Punteggio:Ogni pizza vale 5 puntiProdotti non usati: -Punti

Base di pizza non usata -2 punti - 0.5 per ogni pezzo di prosciutto o

mozzarella avanzati