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

Waterfall V-Model

Spiral Model

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

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

SCAI S.p.A. 49

Agile Methodologies

How is agile

different?

Change in

feedback

Emphasis

(SCRUM)

Reduction in

evolution costs(KANB

Reduction in

coordination costs(XP)

SCAI S.p.A. 50

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

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

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

SCAI S.p.A. 119

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

Tues Wed Thur Fri4

81016 8

SCAI S.p.A. 120

40302010

0 Mon Tue Wed Thu Fri

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

SCAI S.p.A. 187

Kanban:Esempio

SCAI S.p.A. 188

Kanban:Esempio

SCAI S.p.A. 189

Kanban:Esempio

SCAI S.p.A. 190

Kanban:Esempio

SCAI S.p.A. 191

Kanban:Esempio

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)

Kanban

SCAI S.p.A. 208

Scrum vs Kanban

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

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

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-

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 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 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

Agile methodologies

Technology

Project methodologies - Waterfall and Agile

Agile Methodologies in Software

Practical Implementation of Agile Methodologies

Agile Methodologies Crystal Refer to: .

Agile Methodologies XP and Scrum - Chair for …€¦ ·...

Methodologies - Transitioning Waterfall to Agile

Agile methodologies - EXIN

A Survey of Agile Development...

Planned Methodologies vs. Agile Methodologies under the...

Agile Methodologies - 1 Venkat Subramaniam...

Comprehensive Evaluation Framework for Agile Methodologies

Agile methodologies - Capgemini · PDF file5 Figure 2 - Con....

Lecture 9: Agile Methodologies - Scrum

Broad Introduction Agile Methodologies · Broad...

Agile Methodologies: Introduction to Scrum .

Project management methodologies Waterfall vs. agile vs....