Scrum and Xp From the Trenches Italian

7/24/2019 Scrum and Xp From the Trenches Italian

http://slidepdf.com/reader/full/scrum-and-xp-from-the-trenches-italian 1/157



EDIZIONE GRATUITA ON

LINE

Se ti piace il libro, supporta l'autore e InfoQ

acquistando il libro stampato (in

lingua originale!http://www.lulu.com/content/ 899349

(solo "##$%&

Gentilmente offerto da

Questo libro è distribuito gratuitamente su

InfoQ.com, se hai ricevuto questo libro da altre

fonti ti invitiamo a supportare l'autore e l'editoreregistrandoti su InfoQ.com.

'isita la omepage di questo libro su!

http://infoq.com/minibooks/ scrum-xp-from-

the-trenches

http://www.lulu.com/content/899349


http://infoq.com/minibooks/scrum-xp-from-the-trenches









Scrum e XP !lle

"rincee

#ome f!cci!mo Scrum

)critto da!*enri+ ,niberg

Versione gratuita Online.Supporta questo lavoro, acquistane unacopia su carta (in lingua originale):http://infoq.com/minibooks/ scrum-xp-from-the-trenches







© 2! "#$edia Inc%utti i diritti riservati.

&ll rights reserved.

"#$edia, ublisher of InfoQ.com.

Questo libro è parte della serie di libri InfoQ (nterprise Soft)are*evelopment.

er informa+ioni o per ordinare questo o altri libri InfoQ, perpiacere contattare boos-c#media.com

essuna parte di questa pubblica+ione pu/ essere riprodotta,memori++ata in un sistema automatico o trasmessa in alcun modocon alcun me++o, elettronico, fotocopiatrice, di registra+ione,scanner o altro eccetto quanto previsto dalle Se+ioni 0! o 01 del"opright &ct degli Stati 3niti del 04!5, non sen+a il permessoscritto dell'(ditore.

6e denomina+ioni utili++ate dalle a+iende per distinguere i loro

prodotti sono spesso dichiarate come marchi. In tutte lecircostan+e in cui "#$edia Inc. è a conoscen+a di tali diritti, i nomidei prodotti compaiono con Ini+iali $aiuscole o con %3%%( 6(6(%%(7( $&I3S"86(. I lettori, comunque, dovrebbero contattarele specifiche a+iende per informa+ioni complete riguardanti marchie registra+ioni ufficiali.

$anaging (ditor9 *iana lesa

%radu+ione di9 &ntonio 6ucca :http9;;ton<+t.blogspot.com;=6uca $inudel :http9;;))).linedin.com;in;lucaminudel=

6ibrar of "ongress "ataloguing>in>ublication *ata9

IS?9 4!1>0>#@@>225#>0

Stampato negli Stati 3niti d'&merica

http://www.linkedin.com/in/lucaminudel

http://www.linkedin.com/in/lucaminudel



Ringra-iamenti

Per scrivere la prima boa !i questo testo mi ci " voluto un solo#eeken!, e! " stato proprio un #eek en! impegnativo$ %n focus factor!el &' :o)

*ingraio mia moglie Sofia e i miei figli +ave e enn per non avermifatto pesare la mia asocialit !i quel #eek en!, e ringraio i genitori !iSofia, va e 0rgen, per essere stati nel frattempo con la famiglia.

*ingraio anche i miei colleghi in 1risp, a Stoccolma, e le persone !elgruppo !i ahoo scrum!evelopment per aver fatto un po2 !i correioniaiutan!omi a migliorare il testo.3nfine, ringraio tutti i miei lettori che hanno fornito un flusso costante !ifee!back utili. Sono particolarmente felice !i sentire che questo testoabbia fatto scattare in cos4 tanti !i voi quella scintilla che ha !ato unimpulso all2agile$



Indice generale

Prefazione di Jeff Sutherland.....................................................i

Prefazione di Mike Cohn..........................................................iii

Introduzione - Hei, Scrum ha funzionato...............................!

Intro............................................................................................."

5vvertene...............................................................................6

Perch7 l2ho scritto.....................................................................68a cosa " Scrum9....................................................................Come facciamo i #roduct $acklog...........................................%&

%lteriori campi per le storie...................................................&;1ome teniamo il pro!uct backlog in un linguaggio vicino al

business .................................................................................&<Come ci #re#ariamo #er lo s#rint #lanning...........................%'

Come facciamo lo s#rint #lanning..........................................%(

Perch7 il pro!uct o#ner !eve partecipare..............................&=Perch7 la qualit non " negoiabile........................................&6>uan!o gli sprint planning meeting vanno avanti per lelunghe?.................................................................................&@2agen!a !ello sprint planning meeting.................................;+efinire la !urata !ello sprint.................................................;&+efinire l2obiettivo !ello sprint..............................................;;+eci!ere quali storie inclu!ere nello sprint ...........................;<

1ome puA il pro!uct o#ner influire sulla !ecisione !elle storie!a inclu!ere nello sprint9.......................................................;B1ome fa il team a !eci!ere quali storie inclu!ere nello sprint9................................................................................................;=>uale tecnica usiamo per le stime9........................................<;Perch7 usiamo le carte............................................................<;+efiniione !i CfinitoD............................................................<'Stimare i tempi usan!o il planning poker...............................<=1hiarire le storie.....................................................................<6Speare le storie in storie piE piccole...................................<



Su!!ivi!ere le storie in task...................................................B+efinire orario e luogo !el !ail scrum.................................B;+ove fissiamo !ei paletti........................................................B;Storie tecniche........................................................................B<Fug tracking sstem vs. pro!uct backlog...............................B=@o sprint planning meeting " finalmente terminato$..............BG

Come comunichiamo gli s#rint...............................................')

Come facciamo gli s#rint $acklog...........................................*%

3l formato !ello sprint backlog...............................................'&1ome funiona la taskboar!...................................................'<

sempio & H !opo il primo !ail scrum.................................'Bsempio ; H !opo qualche giorno..........................................''1ome funiona il burn!o#n...................................................'GSegnali !2allarme !ella taskboar!...........................................'6Iei, e la tracciabilit9$...........................................................=Stimare in giorni vs. stimare in ore........................................=

Come organizziamo l+area del team.......................................(%

@2angolo !el !esign.................................................................=&

3 membri !el team !evono stare insieme$..............................=<Jenere il pro!uct o#ner alla larga..........................................=BJenere i manager e i coach alla larga.....................................='

Come facciamo i dail scrum..................................................("

1ome aggiorniamo la taskboar!.............................................=G>uan!o qualcuno " in ritar!o.................................................=6>uan!o qualcuno !ice CKon so cosa farA oggiD...................=6

Come facciamo le s#rint demo................................................"%

Perch7 insistiamo affinch7 tutti gli sprint finiscano con una!emo.......................................................................................G&1hecklist per le sprint !emo...................................................G;Sulle funionalit Cnon !imostrabiliD.....................................G;

Come facciamo le retros#etti!e..............................................."'

Perch7 insistiamo affinch7 tutti i team facciano le retrospettive................................................................................................GB1ome organiiamo le retrospettive.......................................G'

1on!ivi!ere con gli altri team le leioni imparate.................GG



1ambiare o non cambiare.......................................................G6sempi !i cose che possono emergere !urante le retrospettive................................................................................................G6

Stacchi tra uno s#rint e l+altro................................................)%

Come facciamo i #iani di rilascio #er i contratti a #rezzo

fisso............................................................................................)'

Stabilire la soglia !i accettaione...........................................6BStimare i tempi !egli item piE importanti..............................6'Stimare la velocit..................................................................6G

8ettere tutto insieme in un piano !i rilascio..........................665!attare il piano !i rilascio....................................................6Come com$iniamo Scrum con P..........................................&

3l pair programming...............................................................Jest-!riven !evelopment (J++)............................................&

J++ sul co!ice nuovo .......................................................<J++ sul co!ice vecchio.....................................................<

+esign incrementale...............................................................B

1ontinuous integration...........................................................BPropriet collettiva !el co!ice................................................'Lorkspace informativo..........................................................'1o!ing stan!ar!......................................................................'Pace sostenibile/lavoro energiato.......................................=

Come facciamo i test................................................................"

Probabilmente non si puA fare a meno !ella fase !ei test !iaccettaione............................................................................G

8inimiare la fase !i test !i accettaione.............................65umentare la qualit facen!o entrare !ei tester nel teamScrum.....................................................................................

3l tester " il Csignor noD......................................................1osa fa il tester quan!o non c2" niente !a testare9...........&

5umentare la qualit facen!o meno nello sprint..................&&@a fase !ei test !i accettaione !ovrebbe far parte !ello sprint9..............................................................................................&;

1icli !i sprint vs. cicli !i test !i accettaione ......................&<



5pproccio &: CKon fare cose nuove finch7 quelle vecchienon sono entrate in pro!uioneD.......................................&'5pproccio ;: CMa bene iniiare nuovi sviluppi, ma la

priorit " quella !i mettere in pro!uione le cose vecchieD..........................................................................................&'%n approccio sbagliato - Cfocaliarsi sulle cose nuoveD&=

Kon an!are piE veloce !ell2anello piE lento !ella catena... ..&=*itorno alla realt.................................................................&G

Come organizziamo team Scrum multi#li...........................%%&

>uanti team mettere in pie!i................................................&&

Jeam virtuali....................................................................&&&@a !imensione ottimale !i un team..................................&&;Sprint sincroniati H o no9..................................................&&<Perch7 abbiamo intro!otto il ruolo !el Cteam lea!D.............&&'1ome !istribuiamo le persone tra i team..............................&&=Jeam specialiati H o no9...................................................&&G

5pproccio &: team specialiati per componenti.............&&65pproccio ;: team cross-component................................&&

*iorganiare i team a! ogni sprint H o no9.........................&;8embri part-time.................................................................&;&1ome facciamo lo Scrum !egli Scrum.................................&;;

@o Scrum !egli Scrum !i pro!otto...................................&;<@o Scrum !egli Scrum aien!ale.....................................&;<

3ntervallare i !ail scrum......................................................&;B3l team !ei pompieri.............................................................&;'+ivi!ere il pro!uct backlog H o no9.....................................&;=

Strategia &: un pro!uct o#ner, un backlog.......................&;=Strategia ;: un pro!uct o#ner, piE backlog......................&;Strategia <: PiE pro!uct o#ner, .......................................&<un backlog per o#ner.......................................................&<

1o!e branching....................................................................&<&*etrospettive multi-team......................................................&<;

Come gestiamo i team distri$uiti geograficamente.............%/'

Nffshoring............................................................................&<'

8embri !el team che lavorano !a casa................................&<G0a checklist dello Scrum master...........................................%/



3niio !ello sprint.................................................................&<Ngni giorno..........................................................................&<Oine !ello sprint....................................................................&B

1#ilogo.....................................................................................%'%

0etture consigliate..................................................................%'2

0+autore...................................................................................%''



.re/a-ione di 0e// )uterland

necessario che i team conoscano le basi !ello Scrum. 1ome si crea e sistima un Pro!uct Facklog9 1ome se ne ricava uno Sprint Facklog9 1omesi gestisce un grafico !el Furn!o#n e si calcola la velocit !el proprioteam93l libro !i Ienrik " uno starter kit !i pratiche esseniali che aiutano i teama! an!are oltre, !al provare a! implementare Scrum al riuscire a farlo

bene.seguire bene Scrum sta !iventan!o sempre piE importante per i team incerca !i investimenti. 1ome coach agile per un gruppo !i CventurecapitalD, ho !ato loro una mano a realiare l2obiettivo !i investire solo inaien!e agili che applicassero per bene le pratiche agili. 3l Senior Partner!el gruppo chie!e a tutte le aien!e !el portafoglio se conoscono lavelocit !ei loro team. >ueste hanno qualche !ifficolt a !are una prontarisposta. Per !elle opportunit !i investimenti futuri si richie!e che i team!i sviluppo conoscano la loro velocit nel pro!urre soft#are.

Perch7 " cos4 importante9 Se i team non conoscono la loro velocit, ilPro!uct N#ner non puA creare una tabella !i marcia con !elle !ate !irilascio cre!ibili. Sena !elle !ate !i rilascio affi!abili, l2aien!a potrebbefallire e gli investitori per!ere i loro sol!i$

un problema che si pone per le aien!e gran!i e piccole, nuove evecchie, soli!e e non soli!e. 3n una recente !iscussione sullaimplementaione !i Scrum in Qoogle in una conferena a @on!ra, chiesia! una platea !i &<' persone quanti utiliassero Scrum e < risposero positivamente. >uin!i chiesi se facessero sviluppo incrementale secon!ogli stan!ar! !i Kokia. @o sviluppo incrementale " fon!amentale nel8anifesto 5gile - rilasciare soft#are funionante presto e spesso. +opoanni !i retrospettive con centinaia !i team Scrum, Kokia ha sviluppatoalcuni requisiti !i base per lo sviluppo incrementale:

• @e iteraioni !evono essere !i una !urata fissa minore !i seisettimane.

• 3l co!ice alla fine !ell2iteraione !eve essere testato !al >5 efunionare correttamente

+elle < persone che asserivano !i a!ottare Scrum, solo la met!ichiararono !i attenersi al primo principio !el 8anifesto 5gile secon!ogli stan!ar! !ella Kokia. 5llora chiesi loro se seguissero gli stan!ar! Kokia relativi a Scrum:



ii R Scrum P +5@@ J*3K1

• %n team Scrum !eve avere un Pro!uct N#ner, e sapere chi ".• 3l Pro!uct N#ner !eve avere un Pro!uct Facklog con !elle stime

fatte !al team.• 3l team !eve avere un grafico Furn!o#n e conoscere la propria

velocit.• Kon !eve esserci nessuno al !i fuori !el team a! interferire con il

team stesso !urante uno Sprint.

+elle trenta persone che facevano Scrum, solo tre avrebbero superato iltest previsto !a Kokia per i team Scrum. >uesti sono gli unici team cheavrebbero ricevuto futuri investimenti !ai miei partner !i ventura.

3l valore !el libro !i Ienrik " che seguen!o le pratiche che lui !elinea, sihanno un Pro!uct Facklog, !elle stime per il Pro!uct Facklog, un grafico!el Furn!o#n, si " in gra!o !i conoscere la velocit !el proprio team emolte altre pratiche esseniali per uno Scrum altamente funionale.Se !oveste imbattervi in un test Kokia !i conformit a Scrum, l2impegnosarebbe valso la pena$Se voi foste una startup, potreste anche ricevere fon!i !a un gruppo !iCventure capitalD. Potreste essere il futuro !ello sviluppo !el soft#are e

artefici !ei principali pro!otti in questo settore.

Jeff Sutherland, Ph.3.

Co-Creatore di Scrum



.re/a-ione di 1i+e 2onSia in Scrum sia nella cosi!!etta CProgrammaione stremaD (xtremeProgramming - P) si richie!e ai team !i completare qualcosa !irilasciabile alla fine !i ogni iteraione.

Jali iteraioni sono fatte per essere brevi e Ctimeboxe!D. >uestaattenione nel rilasciare co!ice funionante in un breve intervallo !itempo significa che i team Scrum e P non !anno spaio alle teorie. Konsi per!ono nel progettare un perfetto mo!ello %8@ in un case-tool , nelloscrivere !ei perfetti !ocumenti !ei requisiti, o co!ice in gra!o !iassecon!are ogni immaginabile cambiamento futuro. 5l contrario, Scrume! P si focaliano sul fare in mo!o che le cose vengano portate atermine.

>uesti team accettano che possano essere commessi !egli errori nel percorso, ma si ren!ono conto che il migliore mo!o per trovare questierrori " smettere !i pensare al soft#are a! un livello teorico !i analisi e progettaione, ma piuttosto lanciarsi, sporcarsi le mani, e iniiare acostruire il pro!otto.

Puntare a fare piE che a teoriare " ciA che contra!!istingue questo libro.1he Ienrik Tniberg lo capisca " chiaro fin !all2iniio. gli non ci offre

una lunga !escriione !i cosa sia Scrum: per questo ci riman!a a semplicisiti #eb. 3nvece Ienrik va !irettamente al punto, e! imme!iatamenteiniia !escriven!o come il suo team si organia e lavora con il suo pro!uct backlog. +a l4 fa una una rassegna !i tutti gli altri elementi e pratiche !i un progetto agile bene avviato. Kon ci sono elaboraioniteoriche, riferimenti o note a pi" pagina. Kon sono necessari. 3l libro !iIenrik non " una spiegaione filosofica !el perch7 Scrum funioni o !el perch7 potreste voler provare questo e quello. una !escriione !i comefuniona un team agile ben collau!ato.

questo il motivo per cui il sottotitolo, C1ome facciamo ScrumD, " cos4calante.Potrebbe non essere il mo!o in cui voi facciate Scrum, ma " il mo!o incui il team !i Ienrik lo fa. Mi chie!erete perch7 !ovrebbe interessarvi il



iv R Scrum P +5@@ J*3K1

mo!o !i fare Scrum !i un altro team. +ovrebbe perch7 tutti noi possiamoimparare come migliorare il nostro mo!o !i fare Scrum ascoltan!o leesperiene !i come viene fatto !a altri e, in particolare, !a coloro che lostanno facen!o bene. Kon c2", e mai ci sar, una lista !i Cbest practicesD !i

Scrum perch7 il team e il contesto !i un progetto prevalgono su ogni altraconsi!eraione. Kon sono le Cbest practicesD che abbiamo bisogno !iconoscere, ma le Cgoo! practicesD e i contesti in cui sono state applicatesuccesso. @eggete abbastana storie !i team !i successo e !i come hannolavorato e sarete preparati a superare gli ostacoli che si insi!ieranno travoi e il vostro usare Scrum e! P.

Ienrik mette a !isposiione una moltitu!ine !i Cgoo! practicesD insiemeal contesto necessario per aiutarci a! imparare meglio come fare Scrum e!

P nelle trincee !ei nostri progetti.

Mike Cohn

4utore di Agile Estimating and Planning and User Stories Applied for

Agile Software Development.



Introdu-ione 3 *ei4 )crum a /un-ionato5Scrum ha funionato$ Per noi almeno (mi riferisco al mio cliente attuale aStoccolma, !i cui non voglio rivelare il nome qui). Spero che possafunionare anche per voi$ 8agari questo libro potr !arvi una mano inquesto percorso.

Per la prima volta ho visto una meto!ologia !i sviluppo (scusa Ten, un framework ) funionare come !a manuale. Plug 2n pla. Ke siamo tutticontenti - sviluppatori, tester, manager. 1i ha aiutato a! uscire !a unasituaione ostica, ci ha consentito !i mantenere l2attenione e lo slanciononostante severe turbolene !el mercato e ri!uioni !ello staff.

Kon !ovei !ire che sono rimasto sorpreso ma, be2, " cos4. +opo avereiniialmente !igerito alcuni libri sull2argomento, Scrum sembrava buono,ma quasi troppo buono per essere vero (tutti conosciamo il !etto Ctroppo bello per essere vero...D).ra comprensibile quin!i che all2iniio mi sentissi un po2 scettico. 8a!opo aver eseguito Scrum per un anno sono rimasto sufficientementecolpito (e cos4 anche molte persone !el mio team) cosicch7 probabilmentecontinuerA !i !efault a! usare Scrum in nuovi progetti, ogni volta che non

vi sar qualche forte motivaione per non farlo.



6Intro

State quasi per a!ottare Scrum nella vostra organiaione. N forse stateusan!o Scrum gi !a qualche mese. 5vete gi le basi, avete letto !ei libri,magari avete anche preso la vostra certificaione !i Scrum 8aster.1ongratulaioni$

Juttavia vi sentite ancora confusi.

Per !irla con le parole !i Ten Sch#aber, Scrum non " una meto!ologia, "un framework. 1iA significa che scrum non vi !ice esattamente cosa fare.

5cci!enti.

@a buona notiia " che vi !irA esattamente come io faccio Scrum, inestenuante !ettaglio. @a cattiva notiia " che, be2, si tratta semplicemente!i come io faccio Scrum. >uesto non significa che " esattamente cos4 che!ovreste farlo anche voi. 3nfatti io stesso potrei farlo !iversamente se mitrovassi in un contesto !iverso.

3l punto !i fora, e la !ifficolt, !i Scrum " che si " forati a! a!attarlo

alla propria specifica situaione.

3l mio approccio attuale a Scrum " il risultato !i un anno !isperimentaione in un team !i sviluppo !i circa B persone. @2aien!a sitrovava in una situaione !ifficile: ricorso agli straor!inari, seri problemi!i qualit, una costante emergena, sca!ene non rispettate, etc.@2aien!a aveva !eciso !i provare Scrum ma sena averne effettivamentecompletato l2implementaione, compito che " toccato a me. Per lamaggior parte !elle persone nel team !i sviluppo all2epoca, CScrumD era

solo una !elle tante strane buzzword !i cui potevano aver sentito l2eco incorri!oio !i tanto in tanto, sena effettive implicaioni sul loro lavoroquoti!iano.

+opo un anno abbiamo implementato Scrum a tutti i livelli in aien!a,



6 R S1*%8 P +5@@ J*3K1

provato !iverse !imensioni per i team (< - &; persone), sprint !i !iversa!urata (; - = settimane), !ifferenti mo!i per !efinire CfinitoD, !ifferentiformati per pro!uct backlog e sprint backlog (xcel, ira, cartoncini),!iverse strategie !i testing, !iversi mo!i !i fare le !emo, e !iversi altri

mo!i !i sincroniare piE teams Scrum, etc. 5bbiamo anche sperimentato pratiche P H !iversi mo!i !i fare continuous buid , pair programmig, test!riven !evelopment, etc, e come combinare tutto ciA con Scrum.

un processo !i appren!imento costante e quin!i la storia non finisce qui.Sono convinto che in questa aien!a si continuer a! imparare (se sicontinueranno a fare le retrospettive !egli sprint) e si avranno nuoveintuiioni su come implementare al meglio Scrum nel suo contestospecifico.

A77erten-e

>uesto !ocumento non ha la pretesa !i rappresentare il CcorrettoD mo!o !ifare Scrum$ *appresenta solamente un mo!o !i fare Scrum, il risultato !iun costante raffinamento avvenuto nel corso !i un anno. Potreste anchestabilire che lo abbiamo interpretato in un mo!o completamente errato.

Jutto ciA che " scritto in questo !ocumento rappresenta la mia personaleopinione soggettiva e non " una !ichiaraione ufficiale !a parte !i 1risp o!el mio attuale cliente. Per questo motivo ho intenionalmente evitato !imenionare qualsiasi specifico pro!otto o persona.

.erc8 l9o scritto Kell2appren!ere Scrum ho letto i testi piE rilevanti su Scrum e sull2agile,ho seguito !iversi siti e forum su Scrum, ho preso la certificaione !a Ten

Sch#aber, l2ho subissato !i !oman!e, e! ho speso molto tempo a !iscuterecon i miei colleghi. %na !elle piE vali!e fonti !i informaione,comunque, " stata quello che " acca!uto realmente in battaglia. @e guerretrasformano Princ4pi e Pratiche in... be2... >uello 1he *ealmente Oai.>uesto mi ha anche aiutato a i!entificare (e qualche volta evitare) i tipicierrori !a noviio !i Scrum. +unque, " giunta per me l2occasione !i !are qualcosa in cambio. cco lamia storia !i guerra.

Spero che questo scritto possa spronare quelli !i voi che si trovino nellastessa situaione a !armi qualche fee!back. Per piacere, illuminatemi$



1N8 O511358N 3 P*N+%1J F51T@NQ R

1a cosa : )crum;Nh, scusate, siete completamente a !igiuno !i Scrum o P9 3n tal caso potreste voler !are un2occhiata ai seguenti link:

U http://agilemanifesto.org/U http://###.mountaingoatsoft#are.com/scrumU http://###.xprogramming.com/xpmag/#hatisxp.htm

Se siete impaienti !i farlo, an!ate pure avanti in questa lettura. Qran

parte !el gergo !i Scrum verr spiegato man mano e quin!i potretesempre trovarla interessante.



& R S1*%8 P +5@@ J*3K1

#2ome /acciamo i product bac+log

3l pro!uct backlog " il cuore !i Scrum. !ove tutto ha iniio. 3l pro!uct backlog " essenialmente una lista !i requisiti, o storie, o feature, e cos4via. 3nsomma sono le cose che il cliente vuole, scritte con parole sue.

Koi le chiamiamo storie o semplicemente backlog items.

@e nostre storie inclu!ono i seguenti campi:

•

I3 - un i!entificatore univoco, ovvero un semplice numero progressivo. >uesto ci evita il rischio !i per!ere traccia !ellestorie quan!o le rinominiamo.

• 5ome - un nome sintetico che !escrive la storia. Per esempioCMerifica lo storico !elle transaioniD. +eve esseresufficientemente chiaro perch7 gli sviluppatori e! il pro!ucto#ner capiscano a gran!i linee !i che cosa si sta parlan!o, e perch7 sia !istinguibile !alle altre storie. +i solito ; - & parole.

• Im#ortanza 6 un valore che misura quanto " importante la storia

per il pro!uct o#ner. Per esempio &. N &'. 5lto V piEimportante.

• 3o ten!o a! evitare il termine CprioritD !ato che la priorit& " tipicamente consi!erata la piE elevata, e questaconvenione !eterminerebbe situaioni biarre. Peresempio, se poi si !eci!e che c2" qualcos2altro !i ancora più importante, che priorit gli !iamo9 Priorit 9 Priorit-&9

• Stima iniziale - la valutaione iniiale !a parte !el team !iquanto lavoro sia necessario per implementare questa storiarispetto alle altre. @2unit " lo stor point e !i solito corrispon!egrosso mo!o a Cgiorni-uomo i!ealiD.



1N8 O511358N 3 P*N+%1J F51T@NQ R &&

• 1hie!i al team Cse poteste formare un numero ottimale !i persone per questa storia (n7 troppe n7 troppo poche,tipicamente ;), e rinchiu!ervi in una stana con tantocibo e la possibilit !i lavorare completamente

in!isturbati, !opo quanti giorni tirereste fuori unaimplementaione finita, !imostrabile, testata erilasciabile9D. Se la risposta " Ccon tre persone rinchiusein una stana ci vorrebbero approssimativamente quattrogiorniD allora la stima iniiale " !i &; punti.

• @a cosa importante non " avere stime assolutamentecorrette (cio" una storia !a !ue punti richie!er !uegiorni), la cosa importante " avere !elle stime relativecorrette (cio" una storia !a !ue punti !ovrebbe richie!ere

circa met lavoro rispetto a! una storia !a quattro punti).• Come dimostrare - una !escriione a! alto livello !i come

questa storia sar !imostrata !urante la sprint-!emo. Si trattaessenialmente !i un semplice test !elle specifiche. COai questo, poi quello, quin!i acca!r quest2altroD.

• Per chi fa J++ (test !riven !evelopment) questa!escriione puA essere usata come pseu!o-co!ice per itest !i accettaione.

•

5ote - ogni altra informaione, chiarimento, riferimenti a! altrefonti !i informaioni, etc. 8olto breve., !i solito.

P7O38C9 :4C;0O< =esem#io>

I3 5ome Im# 1st Come dimostrare 5ote

& +eposito < ' Oa2 login, apri la pagina !ei !epositi,versa W&, va2 alla pagina !el bilancio,ve!i che " cresciuto

!i W&.

Serve un!iagramma !isequena %[email protected] ora non ci preoccupiamo

!i cifratura !ei!ati e !ellacomunicaione.

; Me!ere lastoria !elletransaioni

& 6 5cce!i, clicca suCtransaioniD. Oa2 un!eposito. Jorna alletransaioni, ve!rai ilnuovo !eposito.

%sa la paginaione perevitare pesantiquer su +F.3l!esign siasimile alla pagina !ellavista !egliutenti.



&; R S1*%8 P +5@@ J*3K1

5bbiamo sperimentato molti altri campi, ma alla fine i sei campi !i cuisopra erano i soli che effettivamente usavamo sprint !opo sprint.

Kormalmente le mettiamo in un !ocumento xcel aperto in con!ivisione

(cio" molti utenti possono e!itarlo contemporaneamente). %fficialmente il pro!uct o#ner ne " il proprietario, ma l2accesso non " precluso agli altriutenti. 1apita che uno sviluppatore voglia aggiornare il !ocumento perchiarire qualcosa o cambiare una stima.

Per lo stesso motivo non teniamo questo !ocumento sotto il sistema !iversionamento !el co!iceX lo piaiamo in un volume !i rete con!iviso. Si" rivelato il mo!o piE semplice per permettere piE accessi simultanei inscrittura sena causare problemi !i lock, o conflitti nei merge.

>uasi tutti gli altri artefatti, comunque, sono gestiti attraverso il sistema !iversionamento !el co!ice.

Ulteriori campi per le storie

>ualche volta usiamo campi aggiuntivi nel pro!uct backlog, il piE !ellevolte per consentire al pro!uct o#ner !i fare or!inamenti per priorit.

•9rack H una classificaione approssimativa !ella storia, peresempio Cback officeD oppure CottimiaioneD, per consentire al pro!uct o#ner !i filtrare gli item per tipo, per esempioCottimiaioneD, e fissare la loro priorit a CbassaD etc.

• com#onenti - Kormalmente sono realiati tramite CcheckboxDnel !ocumento xcel, per esempio abbiamo C!atabase, server,clientD. 1os4 il team o il pro!uct o#ner possono i!entificare qualicomponenti tecniche sono impattate nell2implementaione !iquesta storia. 1iA " utile quan!o hai piE team Scrum, per esempio

un team per il back office e un team per la parte client, e vuoiren!ere piE facile per ogni team !eci!ere quali storie pren!ere incarico.

• 7ichiedente - il Pro!uct N#ner potrebbe voler tenere traccia !elcliente o stakeholder che ha in origine richiesto l2item, al fine !i potergli !are un feedeback sullo stato !i avanamento.

• :ug tracking I3 - se vi " un sistema separato !i tracciamento !ei bug, a! esempio ira, !a noi usato, " utile tenere traccia !i ogni

!iretta corrispon!ena tra la storia e! uno o piE bug segnalati.



1N8 O511358N 3 P*N+%1J F51T@NQ R &<

2ome teniamo il product bac+log in unlinguaggio 7icino al business

PuA succe!ere che il pro!uct o#ner, aven!o un backgroun! tecnico,

inserisca storie come C5ggiungere gli in!ici nella tabella !egli eventiD. perch7 vuole questo9 3l vero scopo alla base probabilmente "Cvelociare la form !i ricerca !ella parte !i back officeD.

8agari non " una questione !i in!ici il collo !i bottiglia che ren!e la formlenta, ma qualcosa !i completamente !iverso. +i norma " il team il piEin!icato a capire come risolvere qualcosa, mentre il Pro!uct N#ner!ovrebbe restare focaliato sugli obiettivi !el business.

>uan!o ve!o storie un po2 troppo tecniche come questa, normalmente pongo al pro!uct o#ner una serie !i !oman!e Cma perché” finch7 nonviene fuori il vero obiettivo !ella storia. >uin!i riformuliamo la storia neitermini !ell2obiettivo che ne " alla base (Cvelociare la ricerca nel form!el back officeD). @a !escriione tecnica originale finisce in una nota(C3n!iciare la tabella !egli eventi potrebbe essere una soluioneD).



<2ome ci prepariamo per lo sprint

planning

Fene, il giorno !ello sprint planning " quasi arrivato. %na leione che nonsi smette mai !i imparare " la seguente:

0ezione? assicurati che il pro!uct backlog sia a posto prima !ell2iniio!ello sprint planning meeting.

cosa significa questo? 1he tutte le storie siano ben !efinite9 1he tuttele stime siano corrette9 1he tutte le priorit !ebbano essere fissate9 Kienteaffatto$ 3l significato ":

• 3l pro!uct backlog !ovrebbe esistere$ (ve lo immaginavate9)

• +ovrebbe esserci un pro!uct backlog e un pro!uct o#ner (per pro!otto)

• 5 tutti gli item importanti !ovrebbe essere stato assegnato undiverso gra!o !i importana.

• 3n realt " NT se gli item meno importanti hanno tutti lostesso valore, !ato che probabilmente non saranno portatiallo sprint planning meeting in ogni mo!o.

• Ngni storia che, secon!o il pro!uct o#ner, ha una qualche possibilit !i essere inclusa nel prossimo sprint, !ovrebbeavere un gra!o !i importana unico.

• 3 gra!i !i importana sono usati solo per or!inare gli item per importana. >uin!i se l23tem 5 vale ; e l23tem F vale&, questo significa semplicemente che F " piEimportante !i 5. Non significa che F " cinque volte piE

importante !i 5. Se F avesse importana ;& il significatosarebbe esattamente lo stesso$• utile lasciare !egli spai in questa sequena !i numeri

nel caso subentrasse un item 1 piE importante !i 5 mameno importante !i F. Katuralmente " possibile usare un



1N8 13 P*P5*358N P* @N SP*3KJ P@5KK3KQ R &'

gra!o !2importana tipo tipo ;,' per 1, ma " un po2 brutto, quin!i lasciamo !egli spai piuttosto$

• 3l pro!uct o#ner !ovrebbe capire ogni storia (!i solito ne " luil2autore, ma in alcuni casi sono anche altri a! aggiungererichieste, che il pro!uct o#ner puA prioritiare). gli non ha bisogno !i sapere esattamente cosa c2" !a implementare, ma!ovrebbe sapere perch7 la storia " l4.

5ota? altri, oltre al pro!uct o#ner, potrebbero aggiungere storie al pro!uct backlog. Juttavia a costoro non " consentito !eci!erne i gra!i !iimportana, cosa che " !iritto esclusivo !el pro!uct o#ner. Kon possononemmeno aggiungere le stime, che " !iritto esclusivo !el team.

5ltri approcci che abbiamo provato o valutato:

• %sare ira (il nostro sistema !i bug tracking) per il pro!uct backlog. 8olti !ei nostri pro!uct o#ner lo trovavano troppo click

intensive. xcel " gra!evole e facile per una manipolaione!iretta. Puoi facilmente colorare, rior!inare gli items, aggiungere

nuove colonne per esigene a!-hoc, aggiungere note, importaree! esportare !ati, etc.• %sare un tool !i supporto ai processi agili come MersionNne,

ScrumLorks, Planner, etc. Kon abbiamo provato nessuno !iquesti ma probabilmente lo faremo.



=2ome /acciamo lo sprint planning

@o Sprint planning " un meeting critico, probabilmente il piE importanteevento in Scrum (secon!o la mia personale opinione naturalmente). %nosprint planning meeting fatto male puA compromettere l2intero sprint.

@o scopo !ello sprint planning meeting " !are al team sufficientiinformaioni per poter lavorare in in!isturbata pace per poche settimane, e!are al pro!uct o#ner abbastana fi!ucia !a lasciarglielo fare.

NT, forse era un po2 vago. 3l risultato concreto !ello sprint planningmeeting ":

•

%n obiettivo !ello sprint• %na lista !ei membri !el team (e il loro commitment level , se

inferiore al &)• %no sprint backlog (V una lista !i storie incluse nello sprint).• %na !ata per la sprint-!emo.• %n orario e! un luogo per il !ail scrum.

.erc8 il product o>ner de7e partecipare>ualche volta i pro!uct o#ner sono riluttanti a spen!ere !elle ore con ilteam a fare sprint planning. C*agai, vi ho gi !ato la lista !i ciA chevoglio. Kon ho tempo !i pren!ere parte al vostro planning meetingD.>uesto " un problema piuttosto serio.

3l motivo per cui " necessario che l2intero team e il pro!uct o#ner siano presenti allo sprint planning meeting " che ogni storia contiene trevariabili altamente !ipen!enti tra loro.



1N8 O511358N @N SP*3KJ P@5KK3KQ R &G

@o scope e l2importana sono fissati !al pro!uct o#ner. @a stima " fissata!al team. +urante lo sprint planning meeting, queste tre variabili vengonosottoposte a! un continuo raffinamento graie a! un !ialogo faccia afaccia tra il team e! il pro!uct o#ner.

Kormalmente il pro!uct o#ner iniia il meeting riassumen!o il suoobiettivo per lo sprint, e le storie piE importanti.+opo!ich7, il team esamina tutte le storie e ne stima i tempi, comincian!o!alla piE importante. 8entre questo avviene, !al team possono sorgereimportanti !oman!e relative allo scope - Cquesta storia 2cancella utente2inclu!e il fatto !i recuperare ogni transaione pen!ente !ell2utente e!annullarla9D 3n alcuni casi le risposte sorpren!eranno il team, in!ucen!oloa cambiare !elle stime.

3n alcuni casi la stima !i una storia non " quella che il pro!uct o#ner siaspettava. 1iA potrebbe fargli cambiare l2importana !a !are alla storia,oppure cambiare il suo scope, cosa che !eterminer una nuova stima, etc.etc.

>uesto tipo !i collaboraione " fon!amentale in Scrum e, !i fatto, in tutto

lo sviluppo agile.1osa si fa se il pro!uct o#ner continua a! insistere !i non avere il tempo per partecipare allo sprint planning meeting9 3o normalmente uso,nell2or!ine, una !elle seguenti strategie:

• 1erco !i aiutare il pro!uct o#ner a capire perch7 la sua !iretta partecipaione " cruciale, speran!o che cambi i!ea.

• 1erco nel team qualche volontario che faccia !a CproxD !el pro!uct o#ner !urante il meeting. +ico al pro!uct o#ner C+al

momento che non puoi esserci al nostro meeting, lasceremo chesia eff a rappresentarti. 5vr piena facolt !i cambiare le priorite lo scope !elle storie al posto tuo !urane i meeting. Jisuggerisco !i sincroniarti con lui il piE possibile prima !elmeeting. Se non vuoi che sia lui a fare !a prox, ti chie!iamo !i

Scope

Importan+aStima



&6 R S1*%8 P +5@@ J*3K1

in!icarci qualcun altro, basta che questi possa partecipare con noi per l2intera !urata !el meeting.D

• 1erco !i convincere chi !i competena a! incaricare un altro

pro!uct o#ner.• *iman!o l2iniio !ello sprint finch7 il pro!uct o#ner non riesce a

trovare il tempo !i partecipare al meeting. Kel frattempo, rifiutoogni commitment su qualunque rilascio. @ascio che il teamspen!a ogni giorno facen!o quello che riterr piE importante farequel giorno.

.erc8 la qualit? non : nego-iabile

Kel triangolo prece!ente ho intenionalmente omesso una quartavariabile: la qualit.

1erco !i !istinguere tra qualit interna e qualit esterna.

• !ualit esterna " quello che viene percepito !all2utente !elsistema. %na lenta e non intuitiva interfaccia utente " un esempio!i scarsa qualit esterna.

• !ualit interna si riferisce a questioni che !i solito non sonovisibili all2utente, ma hanno un profon!o effetto sullamanutenibilit !el sistema: la consistena !el !esign, il gra!o !icopertura !ei test, la leggibilit !el co!ice, il refactoring, etc.

3n generale, un sistema con una alta qualit interna puA sempre avere una bassa qualit esterna, ma un sistema con una bassa qualit internararamente raggiunger una alta qualit esterna. !ifficile costruirequalcosa !i buono su !elle fon!amenta marce.

3o tratto qualit esterna come parte !ello scope. 3n alcuni casi puA avere perfettamente senso per il business rilasciare una versione !el sistema!otata !i una interfaccia utente poco agevole e lenta, e rilasciarne unamigliorata successivamente. una valutaione che lascio al pro!ucto#ner, poich7 " lui responsabile !i !eterminare lo scope.Juttavia la qualit interna non si puA mettere in !iscussione. responsabilit !el team preservare la qualit !el sistema in ognicircostana, e questo semplicemente non " negoiabile. 8ai.



1N8 O511358N @N SP*3KJ P@5KK3KQ R &

(Fe2, NT, quasi mai)

>uin!i come !istinguiamo questioni !i qualit interna e questioni !iqualit esterna9

Supponiamo che il pro!uct o#ner !ica CNT ragai, rispetto la vostrastima !i = stor points, ma sono sicuro che per questa cosa potrete trovareun qualche tipo !i quick-fi" nella met !el tempo, se vi mettete!2impegno$D

5ha$ Sta cercan!o !i usare la qualit interna come una variabile. 1ome

faccio a saperlo9 Perch7 vuole che ri!uciamo la stima !ella storia senaCpagare il preoD !i ri!urne lo scope. @a parola Cquick-fi"” !ovrebbe farscattare un allarme in testa...

perch7 non lo permettiamo9

Kella mia esperiena sacrificare la qualit interna " quasi sempre una pessima i!ea. 3l tempo risparmiato lo si ripaga caro, nel breve e nel lungo perio!o. %na volta consentito l2iniio !el !eterioramento !ella code base

!iventa molto !ifficile riuscire a recuperare la qualit successivamente.

Piuttosto tento !i orientare la !iscussione verso lo scope. CSe per te " cos4importante ottenere questa feature presto, potremmo ri!urre lo scope inmo!o !a ren!erla implementabile piE rapi!amente, o semplificare lagestione !egli errori e tenerci la 2gestione avanata !egli errori2 comestoria separata per il futuro. Nppure possiamo ri!urre la priorit !i altrestorie in mo!o !a poterci concentrare su questa9D

%na volta preso atto che la qualit interna non " negoiabile, il pro!uct!iventa abbastana bravo a manipolare le altre variabili piuttosto.

@uando gli sprint planning meeting 7annoa7anti per le lunge

@a cosa piE !ifficile !ello sprint planning meeting ":

&) @a persone non pensano che si protrarr cos4 a lungo;) ... ma " quello che poi succe!e$



; R S1*%8 P +5@@ J*3K1

Jutto in Scrum " Ctime-boxe!D. 8i piace questa regola, semplice,consistente. Koi cerchiamo !i seguirla sempre.

5llora cosa fare quan!o il Ctime boxD !ello sprint planning meeting sta per sca!ere e non vi " alcuna traccia n7 !i obiettivo per lo sprint, n7 !i unosprint backlog9 1i !iamo un taglio999 5llunghiamo !i un2ora9 Nterminiamo il meeting e continuiamo il giorno !opo9

Succe!e piE volte, soprattutto con i nuovi team. 1osa fareste9 >uesto non posso saperlo. 1osa facciamo noi9 +i solito ci !o un taglio brutale. 3lmeeting finisce qui. 1he lo sprint ne risenta. PiE specificamente, !ico alteam e al pro!uct o#ner Callora, il meeting finir tra !ieci minuti, e!

effettivamente non abbiamo un granch7 come sprint plan. 1i basiamo suquello che abbiamo o vogliamo farci altre quattro ore !i meeting !omanimattina alle 69D. 3n!ovinate la loro risposta... :o)

1i ho provato a lasciar proseguire i meeting. +i solito non porta a niente, perch7 si " tutti stanchi. Se non si " pro!otto uno sprint plan !ecente in ; -6 ore (o quale che sia la !urata !el Ctime-boxD), un2altra ora non baster !icerto. @2altra opione, !i pianificare un nuovo meeting per il giornosuccessivo, " in realt abbastana vali!a, se non per il fatto che le persone

normalmente sono impaienti e vogliono partire con lo sprint, nonspen!ere altre ore a pianificare.

>uin!i taglio corto. s4, lo sprint ne risente. @2aspetto positivo,comunque, " che il team impara una leione molto vali!a, e! il prossimosprint planning meeting sar molto piE efficiente. 3noltre, le personesaranno meno restie a! accettare la proposta !i un meeting !i una !uratache prima avrebbero consi!erato eccessiva.

3mparare a salvaguar!are i propri time-box, imparare a fissare !elle !uraterealistiche per i time-box. >uesto si applica sia alla !urata !ei meeting siaa quella !egli sprint.

L9agenda dello sprint planning meeting

5vere un qualche tipo !i programma per il prossimo sprint planningmeeting ri!urr il rischio !i violare il timebox.

>uesto " un esempio !i nostra agen!a.

S#rint #lanning meeting? &<: - &G: (& minuti !i pausa ogni ora)



1N8 O511358N @N SP*3KJ P@5KK3KQ R ;&

• %/?&& - %/?/&. Panoramica !ell2obiettivo !ello sprint !a parte !el pro!uct o#ner. +efiniione !i luogo e !ata !ella !emo.

• %/?/& - %*?&&. Stime !ei tempi !a parte !el team. Se necessario,

su!!ivisione !egli item !el backlog in item piE !ettagliati eaggiornamento !ei loro gra!i !2importana. 1hiarifica !egli item.1ompilaione !ei campi C1ome !imostrareD per tutti gli item !iimportana alta.

• %*?&& - %(?&&. Seleione !a parte !el team !elle storie !ainclu!ere nello sprint. Merifica !el calcolo !ella velocit.

• %(?&& - %"?&&. +ecisione su orario e luogo !el !ail scrum (se!iverso !all2ultimo sprint). %lteriore su!!ivisione !i storie in task.

>uesto programma non " affatto strettamente rigoroso. @o Scrum master puA allungare o accorciare i sottointervalli !i tempo se necessario nelcorso !el meeting.

De/inire la durata dello sprint%no !egli output !ello sprint planning meeting " una !ata precisa per la

!emo !ello sprint. >uin!i si !eve !eci!ere anche la !urata !ello sprint.

8a quale " una !urata a!eguata per uno sprint9

+unque, gli sprint brevi vanno bene. Permettono all2aien!a !i essereCagileD, ovvero !i poter cambiare rotta !i frequente. Sprint brevi V breveciclo !i fee!back V rilasci piE frequenti V fee!back !el cliente piEfrequenti V meno tempo speso an!an!o nella !ireione sbagliata Vappren!imento e miglioramento piE rapi!i, etc.

Juttavia anche gli sprint lunghi hanno i loro lati positivi. 3l team ha iltempo !i CcarburareD, c2" un piE ampio margine !i manovra per risolvereeventuali problemi e raggiungere comunque l2obiettivo !ello sprint, cisono meno tempi aggiuntivi in termini !i sprint planning meeting, !emo,etc.

3n generale i pro!uct o#ner preferiscono sprint brevi e gli sviluppatori preferiscono sprint !i !urata maggiore. >uin!i la !urata !ello sprint " un

compromesso. 5bbiamo sperimentato molto e siamo giunti alla nostra!urata preferita: < settimane. 8olti !ei nostri team (ma non tutti) seguonoquesta scelta. Frevi abbastana !a poter garantire una a!eguata agilitaien!ale, ma anche abbastana lunghi perch7 il team possa trovare il suo



;; R S1*%8 P +5@@ J*3K1

slancio, e! avere il tempo !i rime!iare agli eventuali problemi che possono emergere !urante gli sprint.

%na conclusione a cui siamo giunti ": sperimentare !iverse !urateiniialmente. Kon sprecare troppo tempo analizzando# ma piuttostoseleionare una !urata !ecente e provare per uno sprint o !ue, poicambiare !urata.

$omunque# una volta stabilita la !urata preferita, tenerla fissa per un perio!o !i tempo esteso. Koi !opo !iversi mesi !i sperimentaioneabbiamo realiato che tre settimane an!avano bene. +a allora i nostrisprint sono sempre !i tre settimane. >ualche volta sembrano troppe, altre

volte troppo poche. Juttavia mantenen!o sempre la stessa !urata questa!iventa una sorta !i una pulsaione che caratteria uno spirito aien!alein cui ognuno si sente a suo agio. Kon ci sono !iscussioni riguar!anti le!ate !i rilascio perch7 tutti sanno che ogni < settimane c2" un rilascio, punto.

De/inire l9obietti7o dello sprint

Succe!e quasi sempre. 5! un certo punto !urante lo sprint planningmeeting chie!o Callora quale " l2obiettivo !ello sprint9D e tutti miguar!ano perplessi e! il pro!uct o#ner inarca le sopracciglia e si tocca ilmento.

Per qualche motivo " difficile farsi venire un2i!ea !i obiettivo !ello sprint,ma ho realiato che riuscire a strapparne uno paga. %n obiettivo un po2vago " meglio !i niente. @2obiettivo puA essere per esempio Cfare piEsol!iD o Ccompletare le tre storie !i piE alta prioritD o Cimpressionare il1ND oppure Cfare in mo!o che il sistema possa an!are in pro!uione e!essere usabile !a parte !i un gruppo beta testerD oppure Caggiungere ilsupporto !i base !el back officeD, e cose simili. @2importante " che sia!efinito in termini !i business, non in termini tecnici. 1iA significa che!eve essere comprensibile a chi non faccia parte !el team.

@2obiettivo !ovrebbe essere una risposta alla questione fon!amentale

C %erché facciamo questo sprint9 Perch7 invece non ce ne an!iamo invacana9D.3nfatti, un mo!o sua!ente per strappare al pro!uct o#ner un obiettivo !a!are allo sprint " porgli questa !oman!a, letteralmente.



1N8 O511358N @N SP*3KJ P@5KK3KQ R ;<

@2obiettivo non !ovrebbe essere qualcosa !i gi raggiunto. C3mpressionareil 1ND potrebbe essere un obiettivo vali!o, ma non se questi avesse giavuto una buona impressione !el sistema nello stato attuale. 3n questo

caso potremmo starcene tutti a casa, e l2obiettivo !ello sprint rimarrebbecomunque raggiunto.

@2obiettivo !ello sprint potrebbe sembrare un po2 stupi!o o un po2 forato,ma spesso a met sprint torna utile, quan!o le persone iniiano a sentirsiconfuse rispetto alle cose !a fare. Se ci sono piE team Scrum (come nelnostro caso) a lavorare su !ifferenti pro!otti " molto utile con!ivi!ere lalista !egli obiettivi !egli sprint !i tutti i team su una singola pagina #iki(o qualcosa !el genere) e metterla in evi!ena cosicch7 tutti in aien!a (e

non solo il management !i alto livello) sappiano cosa l2aien!a stafacen!o - e perch7$

Decidere quali storie includere nello sprint%na !elle principali attivit !ello sprint planning meeting " !eci!ere qualistorie inclu!ere nello sprint. PiE specificamente, quali storie ricopiare !al pro!uct backlog allo sprint backlog.

+iamo un occhiata alla prece!ente figura. Ngni rettangolo rappresenta unastoria, in or!ine !i importana. @a storia piE importante " in cima allalista. @2altea !i ogni rettangolo rappresenta la !imensione !ella storia(cio" il tempo stimato in termini !i stor points). @2ampiea !ella graffa



;B R S1*%8 P +5@@ J*3K1

in blu rappresenta la velocit stimata, ovvero quanti stor point il teamritiene !i essere in gra!o !i completare !urante il prossimo sprint.

@o sprint backlog a !estra " una istantanea su alcune storie !el pro!uct backlog. *appresenta la lista !elle storie !i cui il team si far carico!urante questo sprint.

3l team !eci!e quante storie inclu!ere nello sprint, non il pro!uct o#ner,n7 nessun altro.

1iA fa sorgere !ue !oman!e: &. 1on quale criterio il team !eci!e le storie inclu!ere nello sprint9

;. 1ome puA il pro!uct o#ner influire sulla !ecisione !el team9

3niiamo !alla secon!a !oman!a.

2ome puB il product o>ner in/luire sulladecisione delle storie da includere nello

sprint;

Supponiamo !i avere la seguente situaione !urante uno sprint planningmeeting.

3l pro!uct o#ner " !eluso perch7 la storia + non sar inclusa nello sprint.1he opioni ha !urante lo sprint planning meeting9

&

?

"

*

(

'roduct baclog

AelocitB stimata



1N8 O511358N @N SP*3KJ P@5KK3KQ R ;'

%na opione " quella !i mo!ificare le priorit. 5ttribuen!o all2item + ilgra!o !i importana piE alto si obbligher il team a! aggiungerlo al primosprint (in questo caso taglian!o fuori la storia 1).

@a secon!a opione " quella !i mo!ificare lo scope - ri!urre lo scope !ella

storia 5 abbastana !a far entrare nello sprint, a giu!iio !el team, anchela storia +.

@a tera opione " quella !i speare una storia. 3l pro!uct o#ner potrebbe !eci!ere che alcuni aspetti !ella storia 5 non siano !avvero cos4importanti, e quin!i speare la storia 5 in !ue storie 5& e 5; con !iversigra!i !i importana.

&

?

"

*

(

8p+ione 0

AelocitB stimata

?

"

*

(

&

8p+ione 2

AelocitB stimata



;= R S1*%8 P +5@@ J*3K1

1ome si ve!e, anche se il pro!uct o#ner !i solito non puA controllare lavelocit stimata, ci sono !iversi mo!i per influire sulla scelta !elle storie!a fare nello sprint.

2ome /a il team a decidere quali storieincludere nello sprint;

Per questo usiamo !ue tecniche:&. 3l gut feel & ;. 3l calcolo !ella velocit

Stimare usando il gut feel

•Scrum master? C*agai, ce la facciamo a finire la storia 5 inquesto sprint9D (in!ican!o l2item piE importante !el pro!uct backlog)

• 0isa? CFe2. 1erto. 5bbiamo tre settimane, e! " una funionalit piuttosto banaleD

• Scrum master? CNT, e se aggiungessimo anche la storia F9D(in!ican!o il secon!o item piE importante)

• 9om @ lisa all+unisono: C1hiaro che s4D

•Scrum master? CNT, e cosa ne !ite se inclu!essimo 5, F e anche19D

& moione-intuiione K!J

&2

?

"

*

(

&0

AelocitB stimata



1N8 O511358N @N SP*3KJ P@5KK3KQ R ;G

• Sam =ri!olto al #roduct oAner>? Cla storia 1 inclu!e la gestioneavanata !egli errori9D

• Product oAner: CKo, per il momento potete sorvolare su questo

aspetto, basta implementare una gestione minimale !egli errori.D• Sam? Callora ce la facciamo anche con 1D

• Scrum master? CNT, e se aggiungessimo anche la storia +9D

• 0isa? CImm...D

• 9om? CPenso che potremmo farcela.D

• Scrum master? COi!iciosi al... 9 '9D

• 0isa @ 9om? C>uasi al D

•Scrum master? CNT, per +. se aggiungessimo anche la storia9D

• Sam? COorse.D

• Scrum master? Y9 '9Y

• Sam? C+irei piE verso il 'D.

• 0isa? C5vrei qualche !ubbio.D

• Scrum master? CFene, teniamola fuori. Possiamo pren!ercicarico !i 5, F, 1 e +. 8agari riusciamo anche a finire , ma

nessuno ci conti quin!i la teniamo fuori !allo sprint plan. 1he ne!ite9D

• 9utti? CNT$D

3l gut feel funiona piuttosto bene per team piccoli e sprint brevi.

Stimare facendo calcoli sulla !elocitB

>uesta tecnica " basata su !ue passi:

&. +eci!ere la velocit stimata;. 1alcolare quante storie si possono aggiungere sena superare lavelocit stimata

@a velocit " una misura !ella Cquantit !i lavoro fattoD, !ove ogni itemviene pesato rispetto alla sua stima iniiale.

@a figura che segue mostra un esempio !i velocit stimata all2iniio !ellosprint e !i velocit effettiva alla fine !ello sprint. Ngni rettangolo " unastoria, e il numero al suo interno " sua la stima iniiale.



;6 R S1*%8 P +5@@ J*3K1

Kotare che la velocit effettiva " basata sulle stime iniziali !i ogni storia.

ventuali aggiornamenti !elle stime fatti !urante lo sprint vengonoignorati.

8i pare gi !i sentire le vostre obieioni: C1he utilit ha9 %na velocitalta o bassa puA !ipen!ere !a una tale serie !i fattori$ Programmatoriincapaci, stime iniiali sbagliate, scope creep, elementi !i !isturbo non pianificati !urante lo sprint, etc$D

+2accor!o, " un numero greo. Juttavia " sempre utile, soprattutto sel2alternativa " non avere niente. 1i fornisce fatti nu!i e cru!i. C>uali chesiano i motivi, questa " la !ifferena approssimativa tra quanto pensavamo !i fare e quanto abbiamo effettivamente fattoD.

1osa !ire a riguar!o !i una storia quasi finita !urante uno sprint9 Perch7non contano i punti pariali !i queste storie nella nostra velocit effettiva9Fe2 questo " per puntualiare il fatto che Scrum (cos4 come lo sviluppo

agile e il lean manufacturing in generale) " tutto incentrato sulle cosecomplete, rilasciabili, finite$ 3l valore !elle cose fatte a met " ero (ani!i fatto " negativo). +ate un2occhiata a Y8anaging the +esign OactorY !i+onal! *enersten o ai vari libri !i Poppen!ieck per approfon!imenti suquesto.

>uin!i attraverso quale arcano magico stimiamo la velocit9

%n mo!o molto semplice per stimare la velocit " quello !i guar!are allastoria !el team. >uale era la velocit negli ultimi sprint9 >uin!i assumereche la velocit sar grosso mo!o la stessa nel prossimo sprint.



1N8 O511358N @N SP*3KJ P@5KK3KQ R ;

>uesta tecnica " nota come il tempo di ieri. praticabile solo quan!o unteam ha gi qualche sprint alle spalle (quin!i con !elle statistiche

!isponibili) e si appresta a! affrontare il prossimo sprint piE o meno nellostesso mo!o, con lo stesso numero !i persone, le stesse con!iioni !ilavoro etc. Katuralmente non sempre " cos4.

%na variante piE sofisticata " !i fare un semplice calcolo !elle risorse.Supponiamo !i pianificare uno sprint !i tre settimane (&' giornilavorativi) con un team !i quattro persone. @isa sar in vacana per !uegiorni, +ave " !isponibile solo al ' e sar in vacana per un giorno.8etten!o tutto questo insieme...

... abbiamo ' giorni uomo a !isposiione per questo sprint.

questa la nostra velocit stimata9 Ko$ Perch7 la nostra unit !i stima "lo stor& point che, nel nostro caso, corrispon!e a gran!i linee al Cgiorno-uomo i!ealeD. %n giorno-uomo i!eale " un giorno in!isturbato e perfettamente efficace, cosa rara.3noltre, !obbiamo tenere conto !i fattori come il lavoro non pianificato

aggiunto allo sprint, persone che si ammalano, etc.>uin!i la nostra velocit stimata sar certamente minore !i '. 8a quantominore9 Koi usiamo il termine Cfocus factorD per questo.

3l focus factor " una stima !ella concentraione !el team. %n focus factor basso puA significare che il team preve!e molti fattori !i !isturbo oassume !i aver fatto !elle stime iniiali troppo ottimistiche.

TomLisaSamDave

1513157

50 Giorni uomo disponibili

GGiorni disponibili

Velocità stimata di questo sprint :Giorni!uomo disponibili" # $ocus $actor" % velocità stimata"



< R S1*%8 P +5@@ J*3K1

3l miglior mo!o per !eterminare un focus factor ragionevole " quello !i!are una occhiata all2ultimo sprint (o anche meglio, alla me!ia !egli sprint

piE recenti).

@a velocit effettiva " la somma !elle stime iniiali !i tutte le storiecompletate nell2ultimo sprint.

Supponiamo che nell2ultimo sprint siano stati completati &6 stor pointsusan!o un team !i tre persone, Jom, @isa e Sam, e che questi abbianolavorato tre settimane per un totale !i B' giorni-uomo. Nra cerchiamo !itrovare una stima per la velocit !ello sprint a venire. Qiusto percomplicare le cose, !iciamo che un2altra persona, +ave, si sia unito alteam per questo sprint. Jenuto conto !i vacane e tutto abbiamo ' giorni

uomo per il prossimo sprint.

>uin!i la nostra velocit stimata per il prossimo sprint sarebbe !i ; stor points. >uesto significa che il team !ovrebbe aggiungere storie allo sprintfinch7 la somma non arriva piE o meno a ;.

&ocus $actor dell'ultimo sprint:

$ocus $actor" %Giorni uomo disponibili"

Velocità e$$ettiva"

Velocità stimata per questo sprint :

50 (iorni!uomo # )0* % +0 stor, points

&ocus $actor dell'ultimo sprint:

)0* %)5 (iorni!uomo1- stor, points



1N8 O511358N @N SP*3KJ P@5KK3KQ R <&

3n questo caso il team potrebbe scegliere le prime quattro storie per untotale !i & stor points, o le prime cinque storie per un totale !i ;B stor points. +iciamo che ne sceglie quattro, che " la cosa che avvicina !i piE a; stor point. Kel !ubbio, scegliere meno storie.

+ato che queste quattro storie raggiungono i & stor point, la velocitstimata finale !i questo sprint " &.

>uella !el tempo !i ieri " una tecnica como!a ma va usata con po2 !i buonsenso. Se l2ultimo sprint !ovesse essere an!ato insolitamente male perch7la maggior parte !elle persone !el team team erano a casa malate per unasettimana, allora si potr tranquillamente assumere che la stessa sfortunanon si ripeter, e quin!i stimare un focus factor maggiore per il prossimosprint.5llo stesso mo!o, se il team ha recentemente installato un nuovo sistema!i buil! che va come un rao probabilmente si potr incrementare il

focus factor. Se una nuova persona si aggiunger al team in questo sprint,magari ci sar bisogno !i !iminuire il focus factor per tener conto !el suotraining, etc.

>uan!o " possibile, esaminare !iversi sprint prece!enti e fare una me!ia per ottenere stime piE affi!abili.

se il team fosse completamente nuovo e quin!i non ci sono statistiche93n tal caso ve!ere il focus factor !i altri team in simili circostane.

se non ci fossero altri team a cui rivolgersi9 Oare una supposiione. @a buona notiia " che questa supposiione riguar!er solo il primo sprint.+opo!ich7 si avranno !elle statistiche e si potr misurare e migliorarecostantemente il focus factor e la velocit stimata.

1

C

@

C

Ini+io di questo sprint

04 stor points

inclusi nello sprint

@

on ci

stanno nello

sprint@



<; R S1*%8 P +5@@ J*3K1

3l focus factor che !i !efault uso per i nuovi team " !el G, !almomento che " quello su cui finivano per convergere la maggior parte

!egli altri team che abbiamo.

@uale tecnica usiamo per le stime;Io menionato !iverse tecniche H il gut feeling , il calcolo !ella velocit basata sul tempo !i ieri, il calcolo !ella velocit basato sui giorni uomo!isponibili e il focus factor stimato.

>uin!i quale " quella che usiamo noi9

+i solito combiniamo un po2 tutte queste tecniche. Kon ci vuole molto.

+iamo un2occhiata al focus factor e alla velocit effettiva !ell2ultimosprint. Jeniamo conto !el numero totale !i risorse !isponibili per questosprint e stimiamo un focus factor. +iscutiamo le !ifferene tra questi !uefocus factor e facciamo i necessari a!attamenti.

%na volta che abbiamo una lista preliminare !i storie !a inclu!ere nellosprint, verifico usan!o il gut feel . 1hie!o al team !i ignorare i numeri perun attimo e !i limitarsi a pensare se, a sensazione, ce la possiamo fare. Sesembra troppo, eliminiamo una storia o !ue. viceversa.

5lla fine lo scopo " semplicemente !eci!ere quali storie inclu!ere in unosprint. 3l focus factor, la !isponibilit !i risorse, e la velocit stimata sonosolo !ei mei per raggiungerlo.

.erc8 usiamo le carte#

8olta parte !ello sprint planning meeting viene spesa sulle storie !el pro!uct backlog. Stimarle, mo!ificarne le priorit, chiarirle, !ivi!erle, etc.

1ome facciamo questo in pratica9

+unque, quello che facevamo prima era che veniva acceso il proiettore,

mostrato il foglio xcel !el backlog, poi uno (normalmente il pro!ucto#ner o lo Scrum master) an!ava alla tastiera, pren!en!o in rassegna ognistoria invitan!o alla !iscussione. >uan!o il pro!uct o#ner finiva !i

; Cin!ex car!D K!J



1N8 O511358N @N SP*3KJ P@5KK3KQ R <<

!iscutere le priorit e i !ettagli, colui che stava alla tastiera aggiornava lastoria !irettamente sull2xcel.

Sembrerebbe buono9 Fe2... no$ >uesta cosa !i solito " una porcheria e lacosa peggiore " che il team non si accorge che " una porcheria finch7 nonsi arriva alla fine !el meeting realian!o che non ci si " ancora ancoraa!operati a! an!are !avvero fino in fon!o con le storie$

%na soluione che funiona molto meglio consiste nell2usare !elle carte eapplicarle alla parete (o a un tabellone).

>uesta interfaccia utente " superiore rispetto al computer e al proiettore perch7:

• @e persone stanno in pie!i e si muovono VZ sono sveglie e vigili piE a lungo.

• Jutti si sentono personalmente piE coinvolti (e non solo chi staalla tastiera)

• Si possono e!itare simultaneamente piE storie.• 3l cambiamento !i priorit " banale - basta spostare le carte.

• +opo il meeting, le carte possono essere trasportate nell2area !elteam e! applicate alla task board su parete (ve!ere pg. '& C1omefacciamo gli sprint backlogD).

possibile scriverle a mano o (come !i solito facciamo noi) generarle!irettamente !al pro!uct backlog tramite un semplice script.

.i(ration

tool

Deposit /aco$$iceLo(in

/ac 0o$$i ce

1s er a dmin

2er$ test3it4dra5 6t4er

stu$$

6t4erstu$$

7ncr,pted

pass5d

2i8 importanti .eno importanti



<B R S1*%8 P +5@@ J*3K1

P.S. - lo script " !isponibile sul mio blog all2in!iriohttp://blog.crisp.se/henrikkniberg

Im#ortante? !opo lo sprint planning meeting, il nostro Scrum masteraggiorna manualmente il pro!uct backlog su xcel in base ai cambiamenti!elle carte fisiche !elle storie. Sar pure una scocciatura !a gestire ma per

noi " perfettamente accettabile consi!eran!o quanto lo sprint planningmeeting sia piE efficiente usan!o le carte fisiche.

%na nota a proposito !el campo C3mportanaD. Si tratta !ell2importanacome specificata nel pro!uct backlog su xcel al momento !ella stampa.3l fatto !i riportarlo sulle carte ren!e semplice or!inarle fisicamente perimportana (normalmente noi piaiamo gli item piE importanti a sinistra,e quelli meno importanti a !estra). 1omunque, una volta che le carte sonoalla parete si puA ignorare il gra!o !i importana e piuttosto usarel2or!inamento fisico alla parete per in!icarlo in senso relativo. Se il pro!uct o#ner scambia !ue item, non per!iamo tempo a! aggiornare ilgra!o !i importana sulla carta. Fasta essere sicuri !i aggiornarlo sul pro!uct backlog in xcel alla fine !el meeting.

@e stime !ei tempi sono !i solito piE facili !a fare (e anche piE accurate)quan!o le storie sono su!!ivise in task . Kormalmente usiamo il termineCattivitD perch7 la parola CtaskD ha un significato completamente !iversoin sve!ese :o)>uesto " anche piacevole e facile !a fare con le carte. 3l team puA essere!iviso in coppie, che si occuperanno !i su!!ivi!ere le storie, in parallelo.

ote

"Dè bisogno di un diagramma di seguen+a3$6. on serve preoccuparsi dellacifratura dei dati, per adesso.

*eposito

"ome dimostrare la fun+ionalitB

"ollegarsi, aprire una pagina di deposito,depositare E0, &ndare sulla pagina del

bilancio personale e verificare che questo siè incrementato di E0.

?aclog item FCC

@

Importan+a

Stima



1N8 O511358N @N SP*3KJ P@5KK3KQ R <'

Oisicamente per noi consiste nell2aggiungere una piccola nota su post-it, al!i sotto ogni storia, !ove ogni post-it in!ica un task contestuale alla storia.

Kon aggiorniamo il foglio xcel !el pro!uct backlog rispetto allasu!!ivisione in CtaskD per !ue ragioni:

• @a su!!ivisione in task " !i norma abbastana effimera, cio"questi vengono frequentemente mo!ificati o ri!efiniti !urante losprint, per cui stare a! aggiornare anche il pro!uct backlogrisulterebbe un po2 pesante.

• 3l pro!uct o#ner non ha comunque bisogno !i essere coinvolto aquesto livello !i !ettaglio.

1os4 come le carte relative alle storie, anche i post-it relativi allasu!!ivisione in task possono essere riutiliati !irettamente negli sprint backlog (ve!ere pg. '& C1ome facciamo gli sprint backlogD)

De/ini-ione di C/inito importante che il pro!uct o#ner e! il team siano !2accor!o su unachiara !efiniione !i CfinitoD. %na storia " completa quan!o " stato fatto ilcheck in !i tutto il co!ice9 N " completa solo quan!o " stata rilasciata in

.i(ration

tool

Deposit /aco$$iceLo(in

/ac 0o$$i ce

1s er a dmin

2er$ test3it4dra5 6t4er

stu$$

6t4erstu$$

7nc r,pted

pass5d

2i8 importanti .eno importanti

Code

clea n u p

1d

Integrtest

2d

DB design

1d

Writefailingtest2d

GUIspec

2d

Writefailingtest

2 d

ImplGUI

1d

Integr.with

JBoss 2 d

Writefailing

test3d

ImplGUI

d

Clarif!re"uire#ments

2d

Writefailingtest

2 d

D$%

3d

&apestr!spi'e

2d

Impl.migration

(d

GU Idesign)C**+

1d

,d 1-d .d 12d 1.d 12d



<= R S1*%8 P +5@@ J*3K1

un ambiente !i test e verificata !a un team !e!icato ai test !iintegraione9 Ngni volta che ci " possibile, per CfinitoD inten!iamoCpronto per entrare in pro!uioneD ma qualche altra volta Crilasciato nel

server !i test e pronto per i test !i accettaioneD.

5ll2iniio avevamo !elle checklist !ettagliate per questo. Nra spesso!iciamo semplicemente Cuna storia " finita quan!o lo !ice il tester !elteam ScrumD. 5 quel punto sta al tester assicurarsi che l2intento !el pro!uct o#ner sia stato capito !al team, e che l2item sia CfinitoDabbastana !a so!!isfare la !efiniione !i CfinitoD concor!ata.

Siamo giunti alla conclusione che non tutte le storie possono essere

trattate allo stesso mo!o. %na storia chiamata Cform !i interrogaioneutentiD verr trattata in mo!o molto !iverso !a una storia chiamataC8anuale !i installaioneD. 3n questo secon!o caso, la !efiniione !iCfinitoD puA semplicemente essere Caccettato !ei sistemistiD. >uesto " ilmotivo per cui il buon senso " meglio !i una checklist formale.

Se ci si !ovesse confon!ere spesso sulla !efiniione !i finito (cosa che cicapitava all2iniio) bisogna probabilmente aggiungere una C!efiniione !i finito”# come campo specifico, in ogni singola storia.

)timare i tempi usando il planning po+er

Oare le stime " una attivit !el team - ogni suo membro " normalmentecoinvolto nello stimare ogni storia. Perch79

• +urante la pianificaione, normalmente non sappiamoesattamente chi implementer quali parti !i quali storie.

• @e storie normalmente coinvolgono !iverse persone e !iverse

competene (!isegno !ell2interfaccia utente, co!ice, test, etc.).• Per !are una stima, i componenti !el team hanno bisogno !i

sapere a gran!i linee la storia !i che cosa tratta. 1hie!en!o a!ognuno !i stimare ogni item, possiamo verificare che ognimembro !el team capisca !i che cosa si sta parlan!o. >uestoaumenta la probabilit che i membri !el team si aiutino a vicen!a!urante lo sprint. 3noltre ren!e piE probabile che le questioni piEimportanti relative alla storia emergano prima.

• Kel chie!ere a tutti !i stimare una storia spesso si scoprono

!iscrepane tali che !ue !iversi membri !el team !anno stime profon!amente !iverse per la stessa storia. >uesto tipo !i cose "meglio scoprirle e !iscuterle prima che !opo.



1N8 O511358N @N SP*3KJ P@5KK3KQ R <G

Se si chie!e al team !i fornire una stima, normalmente la persona checapisce meglio la storia sar la prima a tirarne fuori una. Sfortunatamente,

ciA influena fortemente le stime !i tutti gli altri.

siste una tecnica eccellente per evitarlo - e! " chiamata planning poker (termine coniato !a 8ike 1ohn, cre!o).

Ngni membro !el team pren!e un mao !i &< carte come quelle mostratein alto. Ngni volta che si stima una storia, ognuno seleiona una carta cherappresenta questa stima (in stor point) e la mette sul tavolo, coperta.>uan!o tutti hanno finito, le carte vengono scoperte simultaneamente. 3nquesto mo!o ognuno " forato a pensare !a solo anich7 a rimettersi allastima !i qualcun altro.

Se c2" una ampia !iscrepana tra !ue stime, il team !iscute le !ifferene ecerca !i farsi un qua!ro generale !el lavoro implicato nella storia. >uesto potrebbe portare a! una qualche su!!ivisione in task. Poi il team ripete lastima. 3l ciclo viene ripetuto finch7 le stime non convergono, cio" fino ache le stime !ella storia in questione non risultino approssimativamente

uguali.

importante ricor!are ai membri !el team che stanno facen!o la stima !i

tutto il lavoro che la storia comporta, non semplicemente !ella CpropriaD parte !i lavoro. 3l tester non !eve quin!i limitarsi a stimare solo laquantit !i lavoro !i test.



<6 R S1*%8 P +5@@ J*3K1

Si noti che la sequena numerica non " lineare. Per esempio non c2" nientetra B e &. 1ome mai9

>uesto " per evitare un falso senso !i accuratea per le stime gran!i. Seuna storia ha una stima approssimativa !i ; punti, non " rilevante!iscutere tra ;, &6 o ;&. Jutto ciA che sappiamo " che si tratta !i unastoria gran!e e che quin!i " !ifficile stimarla. >uin!i ; " solo una nostra prima stima approssimativa.

Muoi stime piE !ettagliate9 +ivi!i la storia in storie piE piccole e stima lestorie piccole piuttosto$

no, non si puA barare combinan!o un ' e un ; per ottenere un G.Fisogna scegliere ' oppure 6. Kon esiste il G.

5lcune speciali carte !a segnalare:• V C" una storia gi fattaD oppure Cquesta storia " quasi un

niente, bastano pochi minuti !i lavoroD.• 9 V Cnon ne ho la piE palli!a i!ea. Kel mo!o piE assoluto.D• Jaa !i caff" V CSono troppo stanco per pensare. Pren!iamoci

una breve pausa.D

2iarire le storie

@a cosa peggiore per un team " quan!o !imostra con orgoglio una nuovafeature alla !emo !ello sprint e poi si ve!e un pro!uct o#ner aggrottare lafronte e !ire Cah, niente male, ma non " quello che avevo chiesto$D 1ome si fa a! essere sicuri che il pro!uct o#ner interpreti una storia allo

stesso mo!o !el team9 N che i membri !el team interpretino le storie tuttiallo stesso mo!o9 Fe2, non si puA. 8a ci sono !elle semplici tecniche peri!entificare le incomprensioni piE eclatanti. @a tecnica piE semplice "quella !i assicurarsi semplicemente che tutti i campi siano riempiti perogni storia (o piE specificamente, per ogni storia abbastana importante !a poter essere presa in consi!eraione in questo sprint),

1sem#io %?

3l team e! il pro!uct o#ner sono contenti !ello sprint plan e pronti per

terminare il meeting. @o Scrum master !ice Caspettate un secon!o, questastoria chiamata 2a!! user2, non ha nessuna stima. Stimiamola$D +opo un paio !i giri !i planning poker i membri !el team concor!ano su ; stor points, e a quel punto il pro!uct o#ner si ala esclaman!o Ccooosa9$D.+opo pochi minuti !i accanita !iscussione, si scopre che il team aveva



1N8 O511358N @N SP*3KJ P@5KK3KQ R <

frainteso lo scope !i 2aggiungere utente2. @oro pensavano significasse 2unaQ%3 carina per aggiungere, rimuovere, cancellare, cercare gli utenti2,mentre il pro!uct o#ner semplicemente inten!eva 2aggiungere utenti a

mano attraverso S>@ su +F2. Stimano !i nuovo e si allineano su ' stor& point.

1sem#io 2?

3l team e! il pro!uct o#ner sono contenti !ello sprint plan e pronti perterminare il meeting. @o Scrum master !ice Caspettate un secon!o, questastoria chiamata 2a!! user2, come !ovrebbe essere !imostrata9D Ke seguequalche brusio e !opo un minuto qualcuno si ala e !ice Cbe2, prima si falog in nel sito #eb, e poi...D al che il pro!uct o#ner lo interrompe: C log in

nel sito #eb9$ Ko, no, no, questa funionalit non !ovrebbe essere parte!el sito #eb, !ovrebbe essere semplicemente un banale script S>@ a!isposiione !egli amministratori !el sistemaD.

@a !escriione !el Ccome !imostrareD !i ogni storia puA (e! ani!ovrebbe) essere molto breve$ 5ltrimenti non si riesce a finire lo sprint planning meeting in tempo. Si tratta fon!amentalmente !i una !escriionea! alto livello in semplice linguaggio naturale !i come eseguire i piE tipiciscenari !i test manualmente. COai questo, poi quello, e poi verifica

quest2altroD.

Io realiato che questa semplice !escriione spesso mette in luceimportanti incomprensioni relative allo scope !i una storia. Fenescoprirle prima, giusto9

)pe--are le storie in storie pi piccole

@e storie non !ovrebbero essere n7 troppo piccole n7 troppo gran!i (intermini !i stima). Se ci sono un bel po2 !i storie !a ,' stor& point si sta per !ivenire probabili vittime !el micromanagement . +2altra parte, unastoria !i B punti significa un alto rischio !i finire per completarla solo parzialmente, cosa che non pro!urr alcun valore per l2aien!a e!aggiunger solo nuove cose !a gestire. 3noltre, se la velocit stimata " Ge le !ue storie !i piE alta priorit pesano B stor& point ognuna, allora la pianificaione !iviene in qualche mo!o !ifficile. Fisogner scegliere tra il!arsi un obiettivo mo!esto (cio" solo un item) oppure un obiettivo forse

troppo ambiioso (cio" sceglierli entrambi).Io riscontrato che " quasi sempre possibile !ivi!ere storie gran!i in storie piE piccole. Fasta assicurarsi che le storie piE piccole rappresentinosempre qualcosa !i rilasciabile e !i valore per il business.



B R S1*%8 P +5@@ J*3K1

Kormalmente ci imbattiamo in storie con un peso tra i ; e gli 6 giorniuomo. @a nostra velocit !i solito " all2incirca B-= per un team tipico,

quin!i abbiamo qualcosa come & storie per sprint. >ualche voltascen!iamo a ' e altre volte siamo a &'. un numero !i carte perfettamente gestibile.

)uddi7idere le storie in tas+

%n attimo$ >ual " la !ifferena tra CtaskD e CstorieD9 %na !oman!a moltovali!a.

@a !istinione " abbastana semplice. @e storie sono cose rilasciabili cheal pro!uct o#ner interessano. 3 task sono cose non rilasciabili, o che noninteressano al pro!uct o#ner.

sempio !i su!!ivisione !i una storia in storie piE piccole:

sempio !i su!!ivisione !i una storia in task:

9d d:edit

user

Gestione

utenti

;uer,

users



1N8 O511358N @N SP*3KJ P@5KK3KQ R B&

cco alcune interessanti osservaioni:

• 3 nuovi team Scrum non sono inclini a voler spen!ere tempo asu!!ivi!ere un mucchio !i storie in anticipo in questo mo!o.

Sembra un po2 una cosa !a waterfall .• Per le storie comprese con chiarea, fare questa su!!ivisione

prima " semplice tanto quanto farla !opo.• >uesto tipo !i su!!ivisione spesso evi!enia la necessit !i

lavoro aggiuntivo che aumenta la stima. 1iA ren!e piE realisticolo sprint plan.

• >uesto tipo !i su!!ivisione aumenta in mo!o percettibilel2efficiena !ei !ail scrum meeting (ve!ere pg. =G C1omefacciamo i !ail scrumD).

• 5nche se la su!!ivisione fosse inaccurata e !ovesse cambiare unavolta iniiato il lavoro, su!!etti vantaggi valgono comunque.

>uin!i tentiamo !i far rientrare lo sprint planning in un time bo" !i !uratasufficiente a farci rientrare queste attivit, ma se la cosa va per le lunghele lasciamo fuori (ve!ere C+ove fissiamo !ei palettiD piE avanti).

Kota - noi pratichiamo il J++ (test !riven !evelopment - sviluppo

gui!ato !ai test) che in effetti significa che la prima operaione per quasitutte le storie " Cscrivi un test automatico che fallisceD e l2ultima "CrifattoriaD (V migliora la leggibilit !el co!ice e rimuovi le!uplicaioni).

;uer,

u sers

Implementareform di

interroga/ione

&ro0areun tool direport efare una

spi'e

Chiarire i

re"uisiti DesignGUI

Implementarela lista degli

utenti

&est diIntegratione deugrefactor

*cri0ere

casi di

test



B; R S1*%8 P +5@@ J*3K1

De/inire orario e luogo del dailF scrum

%no !egli output, spesso !imenticato, che ci si aspetterebbe !allo sprint planning meeting, " C!efiniione !i orario e luogo !el !ail scrumD. Sena!i questo lo sprint gi parte con il pie!e sbagliato. 3l primo !ail scrum "essenialmente il calcio !2iniio, quan!o tutti !eci!ono su cosa iniiare alavorare.

3o li preferisco !i mattina. 8a !evo ammettere che in effetti non abbiamo provato a fare i !ail scrum nel pomeriggio o a met giornata.

S!antaggi del fare gli scrum al #omeriggio? quan!o arrivi al lavoro lamattina, !evi ricor!arti cosa hai !etto ieri che avresti fatto oggi.

S!antaggi degli scrum alla mattina? quan!o arrivi al lavoro la mattina,!evi ricor!arti cosa hai fatto ieri per riferirlo.

@a mia opinione " che il primo svantaggio " peggiore, !al momento che lacosa piE importante " quello che si sta per fare# non quello che ' stato

fatto.

@a nostra prassi " !i seleionare il primo momento !isponibile che nonfaccia scontento nessuno. +i solito :, :<, o &:. @a cosa piEimportante " che sia un orario che tutti nel team possano accettare conentusiasmo.

Do7e /issiamo dei paletti

NT, il tempo sta per finire. +i tutte le cose che vogliamo fare !urante losprint planning, cosa possiamo tenere fuori se siamo quasi fuori tempomassimo9

+unque, io uso la seguente lista !i priorit:

PrioritB %: un obiettivo per lo sprint e una !ata per la !emo. il minimoche serve per iniiare uno sprint. 3l team ha un obiettivo, e una !ata finale,e potrebbe anche lavorare basan!osi sul pro!uct backlog. Kon " un gran

che, e si !ovrebbe seriamente consi!erare la possibilit !i fissare unnuovo sprint planning meeting per il giorno successivo, ma se si haveramente bisogno !i iniiare lo sprint, cos4 sia. 5 !ire il vero, comunque,in realt non ho mai iniiato uno sprint sena queste piccole informaioni.



1N8 O511358N @N SP*3KJ P@5KK3KQ R B<

PrioritB 2? lista !elle storie accettate !al team per questo sprint.

PrioritB /? stime !i tutte le storie !ello sprint.

PrioritB '? C1ome !imostrareD compilato per ogni storia.

PrioritB *? calcolo !i velocit e risorse, come verifica per il proprio sprint plan. 1iA inclu!e la lista !ei membri !el team e il loro commitment level

(altrimenti la velocit non si potr calcolare).

PrioritB (? specificare orario e luogo !el !ail scrum. 1i vuole un attimo

per !eci!erli, ma se non c2" tempo lo Scrum master puA semplicemente!eci!erlo !opo il meeting e comunicarlo via email a tutti.

PrioritB "? su!!ivi!ere le storie in task. >uesta su!!ivisione potrebbeanche essere fatta ogni giorno al !ail scrum, ma ciA puA essere !iintralcio al flusso !ello sprint.

)torie tecnice

cco una questione complicata: le storie tecniche. N item non funionali ocome li si vuol chiamare.

8i riferisco a cose che vanno fatte ma che non sono funionalitrilasciabili, non sono !irettamente correlate a storie specifiche, e nonhanno valore !iretto per il pro!uct o#ner.

Koi le chiamiamo Cstorie tecnicheD.

Per esempio:Installare un ser!er di continuous buld

• Perch7 serve: perch7 fa risparmiare una gran!e quantit !itempo agli sviluppatori e ri!uce il rischio !i grossi problemi !i integraione alla fine !i un2iteraione.

• are un diagramma del sistema

• Perch7 serve: perch7 gli sviluppatori si !imenticanosempre il !esign completo, e quin!i scrivono co!ice

inconsistente. 12" bisogno !i un !ocumento sul Cqua!rocompletoD per mantenere tutti sincroniati sullo stesso!esign.

• 7ifattorizzare lo strato 34O



BB R S1*%8 P +5@@ J*3K1

• Perch7 serve: perch7 lo strato +5N " an!ato!eterioran!osi e la cosa sta costan!o molto tempo a tuttia causa !i una certa confusione e bug inutili. *ipulire il

co!ice far risparmiare tempo a tutti e migliorare larobustea !el sistema.

• 4ggiornare Jira (sistema !i tracciamento !ei bug)• Perch7 serve: la versione corrente " troppo bacata e lenta.

%n aggiornamento far risparmiare tempo a tutti.

Jutte queste sono storie nel senso or!inario !el termine9 Nppure sonoattivit non connesse a! alcuna storia specifica9 1hi ne stabilisce la

priorit9 3l pro!uct o#ner !eve essere coinvolto in queste cose9

5bbiamo sperimentato molti mo!i !iversi !i gestire le storie tecniche.5bbiamo provato a trattarle come storie a tutti gli effetti, al pari !ellealtre. Kon " stata una gran scelta. Per il pro!uct o#ner, quan!o !eci!evale priorit, era come confrontare le mele con le arance. 3nfatti, per ovvimotivi, alle storie tecniche viene spesso !ata una bassa priorit conmotivaioni !el tipo C1erto ragai, sono sicuro che che un server !i

continuous build sia importante e tutto, ma vogliamo pensare prima a fareun Cbuild” !i qualche funionalit che ci generi !ell2utile prima, o no9 Poi potrete anche occuparvi !elle vostre !eliie tecnologiche. Ma bene9D

3n alcuni casi il pro!uct o#ner ha ragione, ma spesso no. 5bbiamo trattola conclusione che il pro!uct o#ner non sempre " qualificato per valutarei costi e i benefici !i questo tipo !i !ecisioni.

>uin!i " cos4 che facciamo:

&) 1erchiamo !i evitare le storie tecniche. 1i sforiamo !itrasformare una storia tecnica in una storia normale con unvalore !i business misurabile. 3n questo mo!o il pro!ucto#ner avr piE probabilit !i fare corrette valutaionicosti/benefici.

;) Se non possiamo trasformare una storia tecnica in una storianormale, verifichiamo se puA essere trasformata in un task !i

un2altra storia. Per esempio Cfare il refactoring !ello strato+5ND potrebbe essere un task !ella storia Cmo!ifica i !ati!ell2utenteD, !ato che questa impatta sul +5N.



1N8 O511358N @N SP*3KJ P@5KK3KQ R B'

<) Se entrambi i tentativi falliscono, !efiniamo una storiatecnica, e teniamo una lista separata !i queste storie. 3l pro!uct o#ner le puA ve!ere ma non puA e!itarle. %siamo i

parametri come Cfocus factorD e Cvelocit stimataD pernegoiare con il pro!uct o#ner e cerchiamo !i ritagliare cos4un po2 !i tempo !ello sprint per implementare le storietecniche.

sempio (un !ialogo molto simile a questo " acca!uto !urante uno !einostri sprint planning meeting).

• 9eam? C12" bisogno !i sbrigare alcune attivit tecniche.

Pensiamo !i allocare un & !el nostro tempo per questo, cio" !iri!urre il focus factor !al G' al ='. Ma bene9D

• Product oAner? Ch no, !iamine$ Kon abbiam tempo$D

• 9eam? CFe2, !a2 un occhiata all2ultimo sprint (e tutte le teste sivoltano verso !egli schii sulla lavagna). @a nostra velocitstimata era 6, e la nostra velocit effettiva " stata <, giusto9D

• PO: Csattamente$ >uin!i non abbiamo tempo per fare cosetecniche interne$ 1i vogliono piE feature$D

• 9eam? C5llora, il motivo per cui la nostra velocit " stata cos4negativa " che abbiamo speso un sacco !i tempo a cercare !imettere insieme !ei rilasci consistenti !a man!are in testD.

• PO: C allora9D

• 9eam: C+unque, la nostra velocit probabilmente continuer a!essere cos4 scarsa se non facciamo qualcosa per risolvere lasituaione.D

• PO: C>uin!i9D

• 9eam? C>uin!i la nostra proposta " !i sottrarre circa il & !ivelocit a questo sprint per installare un sistema !i continuous

build e altre cose !i questo tipo in mo!o !a liberarci !ai casini!ell2integraione. >uesto probabilmente far aumentare la nostravelocit quanto meno !el ; per ogni altro sprint a seguire,quin!i per sempre$D

• PO? C5h !avvero9 Perch7 non lo abbiamo fatto nell2ultimosprint9$D

•

9eam: Chm... perch7 tu non volevi che noi...D• PO? CNh, uhm, be2 s4, mi sembra una buona i!ea quella !i

occuparcene a!esso$D

Katuralmente, l2altra opione " tenere il pro!uct o#ner fuori !al giro e



B= R S1*%8 P +5@@ J*3K1

presentargli a priori un focus factor non negoiabile. 8a non vi sonoscuse per non tentare prima la via !el consenso.

Se il pro!uct o#ner " uno alla mano, competente e ragionevole (e quisiamo fortunati) suggerisco !i tenerlo informato il piE possibile e !iconsentirgli !i !eci!ere tutte le priorit. @a trasparena !ovrebbe essereuno !ei valori fon!amentali !i Scrum, giusto9

ug trac+ing sFstem 7s$ product bac+logcco una questione !elicata. xcel " un formato eccellente per il pro!uct

backlog, ma c2" sempre bisogno !i un sistema per tracciare i bug, e!xcel probabilmente non " a!atto. Koi usiamo ira.

>uin!i come facciamo a far rientrare nello sprint planning meetingquestioni relative a ciA che tracciamo su ira9 3nten!o !ire che non possiamo semplicemente ignorarle e focaliarci sulle storie.

5bbiamo tentato !iverse strategie:&) 3l pro!uct o#ner stampa gli item piE prioritari !i ira, li

porta con s" allo sprint planning meeting, e li attacca alla parete insieme a tutte le altre storie (quin!i specifican!oimplicitamente la priorit !i questi item rispetto alle altrestorie)

;) 3l pro!uct o#ner compila storie che fanno riferimento aitems !i ira. Per esempio C1orreggere il bug piE critici!el back office: ira-&;B, ira-&;= e ira-&6D.

<) 3l bug fixing viene consi!erato una attivit fuori !allosprint, cio" il team mantiene un focus factor abbastana

basso (per esempio !el ') per assicurarsi !i avere iltempo !i correggere i bug. Si assume semplicemente cheil team spen!er un po2 !i tempo !i ogni sprint acorreggere i bug riportati su ira.

B) Si usa ira come strumento per gestire il Pro!uct Facklog(cio" ci si sbaraa !el foglio xcel). 3 bug vengonotrattati semplicemente come tutte le altre storie.

Kon abbiamo in realt stabilito quale strategia sia la migliore per noiXinfatti questa varia !a team a team e !a sprint a sprint. 3o propen!o per la prima. semplice e! efficace.



1N8 O511358N @N SP*3KJ P@5KK3KQ R BG

Lo sprint planning meeting : /inalmenteterminato5

Lo#, non avrei mai pensato !i portare questo capitolo sullo sprint planning meeting cos4 per le lunghe$ Penso che questo rifletta la miaopinione che lo sprint planning meeting " la cosa piE importate in Scrum.Fasta impegnarsi a farlo bene, e il resto sar molto piE facile.

@o sprint planning meeting ha successo se tutti (i membri !el team e il pro!uct o#ner) ne escono con un sorriso, si risvegliano il giorno !opo conun sorriso, e iniiano il loro primo !ail scrum con un sorriso.

Poi, naturalmente, chiss quante cose possono an!are terribilmente malelungo la stra!a, ma almeno non si potr !are la colpa allo sprint plan :o)



&2ome comuniciamo gli sprint

importante tenere l2intera aien!a informata su cosa sta succe!en!o,altrimenti le persone si lamentano o, peggio, fanno !elle supposiionierrate su quanto acca!e.

Koi usiamo una Cpagina informativa !ello sprintD per questo.



1N8 1N8%K31I358N Q@3 SP*3KJ R B

>ualche volta inclu!iamo anche informaioni su come ogni storia verr

!imostrata.

3l prima possibile, !opo lo sprint planning meeting, lo Scrum master creaquesta pagina, la mette su #iki e man!a uno CspamD all2intera aien!a.

5bbiamo anche una pagina stile CcruscottoD sul nostro #iki, con i link atutti gli sprint in corso.

3noltre, lo Scrum master stampa la pagina informativa !ello sprint el2appen!e alla parete esterna all2area !el team, 1os4 che chiunque si trovi a passare possa !arvi un2occhiata e sapere cosa sta facen!o il team. +almomento che sono riportati anche orario e luogo !el !ail scrum e !ella!emo !ello sprint, sa anche !ove an!are per saperne !i piE.

>uan!o lo sprint si avvicina al termine, lo Scrum master ricor!a a tutti

che ci sar la !emo.



' R S1*%8 5K+ P O*N8 JI J*K1IS

con questo nessuno avr alcuna scusa vali!a per non sapere cosa c2" in

ballo.



H2ome /acciamo gli sprint bac+log

Qi fatto tutto questo9 Oiuu, ottimo lavoro.

Nra che abbiamo completato lo sprint planning meeting e informato tuttoil mon!o !el nostro nuovo e scintillante sprint, per lo Scrum master " ilmomento !i fare uno sprint backlog. +ovrebbe farlo dopo lo sprint planning meeting, e prima !el primo !ail Scrum.

Il /ormato dello sprint bac+log

5bbiamo sperimentato !iversi formati per lo sprint backlog, inclusi ira,xcel, e una taskboar! fisica alla parete. 5ll2iniio abbiamo usato per lo piE xcel. 1i sono molti template xcel pubblici per gli sprint backlog,con grafici burn-!o#n e cose !el genere. Potrei parlare a lungo a proposito !i come abbiamo raffinato i nostri backlog in xcel, ma non lofarA. Kon inclu!erA nemmeno un esempio.

3nvece an!rA a !escrivere in !ettaglio il formato piE efficace che abbiamotrovato per lo sprint backlog - una taskboar! alla parete$

Fisogna trovare una parete gran!e inutiliata o piena !i cose inutili comeil logo !ell2aien!a, !iagrammi vecchi o brutti !ipinti, ripulirla (chie!en!oil permesso solo se necessario), attaccare con !el nastro a!esivo un fogliomolto gran!e (almeno ;x; metri, o <x; metri per un team numeroso), poifare questo:



'; R S1*%8 5K+ P O*N8 JI J*K1IS

Katuralmente si puA sempre usare una lavagna. 8a sarebbe un po2sprecata. Se possibile, risparmiare le lavagne per farci !egli schii e

usare altre pareti per le taskboar!. KNJ5 - se si !eci!e !i usare !ei post-it per i task, non !imenticare !iattaccarli con !el nastro a!esivo, altrimenti puA capitare un giorno !itrovarli ammucchiati sul pavimento.

/urndon

<on piani$icati

<otc4eced out &inito= :o"

. i( ra t io n

to o l

De p os it

/ac0o$$ice

Lo(in

/ac0o$$ice

1ser admin

Write failingtest

3d

ImplGUI

d

Clarif!

re"uire#ments

2 d

GU Idesign)C**+

1d

6biettivo: /eta!read, release=

2rossimi

3it4dra 5 2 er $ t es t3it4dra5

c4eced out

Code

c le a nu p

1 d

Integrtest

2d

Writefailingtest

2 d

DBd esign

1d

D$%

3d

Impl. migration

(d

& a p e s tr ! s p i' e

2d

Writefailing

test2d

GUIspec

2d

Writefailingtest

2 dImplGUI

1d

Integr.

with JBoss

2 d



1N8 O511358N Q@3 SP*3KJ F51T@NQ R '<

2ome /un-iona la tas+board

Si possono naturalmente aggiungere colonne a piacere. C3n attesa !el test!i integraioneD per esempio. Nppure C5nnullatoD. 1omunque, prima !icomplicare le cose, " bene pensarci attentamente. >uesta aggiunta "davvero necessaria9

Io realiato che la semplicit " estremamente preiosa per questo tipo !i

cose, quin!i aggiungo complicaioni solo quan!o costa troppo il nonfarlo.

d 2 d 1d

/urndon

<on piani$icati


. i( r at io n

t oo l

D ep o si t

/a c0o$$ice

Lo(in

/ac0o$$ice

1ser admin

Writefailingtest

3d

ImplGUI

d

Clarif!re"uire#ments

2 d

GU Idesign ) C**+

1d

6biettivo: /eta!read, release=

2rossimi

3it4d ra5 2er $ tes t3it4dra5

c4eced out

Code

c lea n up

1 d

Integr

test 2d

Writefailing

test 2 d

DBdesign

1d

D$%

3d

Impl.migration

(d

& a p e st r ! sp i ' e

2d

Writefailingtest2d

GUI

spec

2d

Write

failingtest

2 dImplGUI

1d Integr.

withJBoss

2 d

'rima tutte le attivitB dei post >it si muovono

'oi gli item bianchi saltano a inito

"ose su cui

nessuno sta

lavorando oggi

Se tutti i baclog

items vengono

completati prima

che lo sprint sia

finito, aggiungerne

di nuovi da qui.

"ose su cui

qualcuno sta

lavorando oggi

"ose su cui

nessuno lavorerB

piH

%racciare manualmente un

nuovo punto nel burndo)n

ogni giorno dopo il dail

scrum.



'B R S1*%8 5K+ P O*N8 JI J*K1IS

Esempio 6 dopo il primo dailF scrum

+opo il primo !ail scrum, la taskboar! puA apparire come segue:

1ome si puA ve!ere, tre task sono in Cchecke! outD, cio" il team oggi cista lavoran!o.

5lcune volte, per !ei team piE numerosi, un task rimane fisso su Cchecke!outD perch7 nessuno si ricor!a chi ci starebbe lavoran!o. Se in un teamsucce!e spesso, allora si a!ottano politiche come contrassegnare ogni task

che " nello stato Ychecke! outY con il nome !ella persona che l2ha spostatosu Cchecke! outD.

/urndon

nplanned items


. i( ra t io n

to o l

De p os it

/ac0o$$ice

Lo(in

/ac0o$$ice

1ser admin

*cri0itest chefallisce

3d

Impl

GUI

d

Chiarisci

re"uire#ments

2 d

GU Idesign)C**+

1d

6/>TT>V6: /eta!read, release=

<e#t


c4eced out

3i p ul ire

il codice

1 d

&est di

inteegra/ione 2d

*cri0eretest chefallisce

2 dDB

de sign

1dD$%

3d

Impl. migra/ione

(d


2d

*cri0eretest che

fallisce2d

GUIspec

2d

*cri0ere test che

fallisce 2 d

ImplGUI

1d Integra#

/ione

conJ2oss 2 d



1N8 O511358N Q@3 SP*3KJ F51T@NQ R ''

Esempio # dopo qualce giorno+opo qualche giorno la taskboar! puA assomigliare a qualcosa !el genere:

1ome si ve!e la storia C!epositD " stata completata (cio" " stato fatto ilcheck -in !el co!ice nel sistema !i versionamento, " stata testata,rifattorizzata, etc). 3l tool !i migraione " parialmente completato, la parte !i login !el back office " cominciata, e la parte !i gestione !egliutenti !el back office non " cominciata.

1i sono tre attivit non pianificate, come si puA ve!ere in basso a !estra.

utile ricor!arlo quan!o si fa la retrospettiva !ello sprint.

/urndon

<on piani$icati


Wr itefailingtest

D$%

DBd esig n

Integr

test

. i( ra t io n

to o l

Writefailingtest

GUIspec


Impl.migration

2 d

C ode

c le an u p

De p os it

2d 1 d 4 .d 1d

2d

(d

1 d 2d

2d

/ac0o$$ice

Lo(in

/ac0o$$ice

1ser admin

Writefailing

test

3 d

2 d

1d2d

ImplGUI

1 d Integr.

with

JBoss 2 d

Write failingtest

3d

Impl

GUI

d

Clarif!

re"uire#ments

2 d

GU Idesig n)C* *+

1d

5 i6 m e m o r !le a ' ) J I 3 $ 1 2 . + 2 d

*ales support

3d W ritewhitepaper

-d

6/>TT>V6: /eta!read, release=

<e#t


c4eced out

Writefailingtest



'= R S1*%8 5K+ P O*N8 JI J*K1IS

cco un esempio !i come si presenta un vero sprint backlog verso la fine!ello sprint. +iventa piuttosto caotico al progre!ire !ello sprint, ma va

bene, visto che ha vita breve. 5! ogni nuovo sprint abbiamo uno sprint backlog nuovo !i ecca.



1N8 O511358N Q@3 SP*3KJ F51T@NQ R 'G

2ome /un-iona il burndo>nQuar!iamo nel !ettaglio il grafico !el burn!o#n:

>uesto grafico mostra che:

• 3l primo giorno !ello sprint, il primo !i agosto, il team ha stimatocirca G stor point su cui ancora lavorare. >uesto numerocorrispon!e alla velocit stimata !ell2intero sprint.

•

3l &= agosto il team stima che ci sono approssimativamente &' stor& point !i lavoro ancora !a fare. @2an!amento ten!enialemostra che siamo linea con le previsioni fatte, cio" !i questo passo sar completato tutto entro la fine !ello sprint.

Kon inclu!iamo i fine settimana nell2asse perch7 raramente si lavora nei#eeken!. Prima li inclu!evamo ma questo ren!eva il burn!o#nleggermente confuso, !al momento che l2an!amento piatto !urante i#eeken! avrebbe potuto essere interpretato come un segnale !2allarme.

/urndon

10+030)050?070

1 + 3 ) 5 - @ 10 11 1+ 15 1? 17 1- 1@9(osto

Stima del lavoro rimanente >n

stor, points"

Date



'6 R S1*%8 5K+ P O*N8 JI J*K1IS

)egnali d9allarme della tas+board%n2occhiata veloce alla taskboar! !ovrebbe essere sufficiente a chiunque per avere una in!icaione !i come sta an!an!o lo sprint. @o Scrum masterha la responsabilit !i assicurarsi che il team agisca sulla base !ei segnali!i allarme !alla taskboar!, quali a! esempio:

/urndon

&IJ *obbiamo

togliere qualchebaclog item dallo

sprint

/urndon ?isogna aggiungerequalche baclog

item allo sprint.



= R S1*%8 5K+ P O*N8 JI J*K1IS

*ei4 e la tracciabilit?;5@a migliore tracciabilit che posso offrire attraverso questo mo!ello " fareuna foto !igitale !ella taskboar! ogni giorno. Se proprio ti !icono !i farlo.>ualche volta lo faccio ma non sento mai la necessit !i !over sfogliaretutte quelle foto.

Se per voi la tracciabilit " molto importante, allora forse la soluione!ella taskboar! non fa per voi.

Juttavia suggerisco !i fare una vera valutaione !el valore !i un tracciato!ettagliato !ello sprint. %na volta completato lo sprint, rilasciato !elco!ice che funiona, e fatta la !ocumentaione, a chi interessa !avverosapere quante storie siano state completate nel giorno ' !ello sprint9 5 chiinteressa veramente sapere quanto tempo fosse stato stimato per Cscrivereun test che fallisce per la storia +epositoD9

)timare in giorni 7s$ stimare in ore Kella maggior parte !ei libri e !egli articoli su Scrum si trova che i taskvengono stimate in ore, e non in giorni. 5nche noi facevamo cos4. @anostra formula generale era: un giorno-uomo effettivo V sei ore-uomoeffettive.

5bbiamo smesso !i fare cos4, almeno per la maggior parte !ei nostri team, per le seguenti ragioni:

• @a stima ore-uomo era troppo granulare, ten!eva a incoraggiaretroppe attivit !i una-!ue ore e !unque il micromanagement.

•

Si finiva per pensare tutti in termini !i giorni-uomo,moltiplican!o per = prima !i scrivere le ore-uomo: CImmmm, per questa attivit ci vorr circa un giorno. Nh !evo mettere giE leore, e allora scrivo =D

• +ue unit !i misura !iverse causano confusione. C una stima ingiorni-uomo o ore-uomo9D

>uin!i ora usiamo giorni-uomo come base per tutte le stime !ei tempi(anche se li chiamiamo stor point). 3l nostro valore piE piccolo " .', cio"ogni attivit stimabile in meno !i mea giornata puA venire rimossa,combinata con un altro task, oppure lasciata a .' (l2eventuale !anno !asovrastima sar comunque contenuto). Semplice e! elegante.



J2ome organi--iamo l9area del team

L9angolo del design

Io notato che molte !elle piE interessanti e vali!e !iscussioni sul !esignavvengono spontaneamente !i fronte alla taskboar!.

Per questo motivo, cerchiamo !i organiare quest2area come l2Cangolo!el !esignD.

!avvero utile. Kon c2" miglior mo!o !i avere una visione generale !el

sistema che mettersi nell2angolo !el !esign, gettare uno sguar!o a!entrambe le pareti, poi mettersi al computer e provare l2ultimo build !elsistema (se si " abbastana fortunati !a avere un sistema !i continuous

build , ve!i pg. C1ome combiniamo Scrum con PD).

'arete del design :6avagna grande =

' ann el l o

d el l o s pr i n t : 6 a

gr an d e

t a

s , b o ar d =

'osta+ionepubblica p .c.

Sedie e<tra

3n poD dispa+io per

stare in piedi ,

muoversi ingiro, indicare le

cose, egesticolare



=; R S1*%8 P +5@@ J*3K1

@a Cparete !el !esignD " semplicemente una gran!e lavagna con qualcheschio !i !esign e le stampe !ei relativi !ocumenti piE importanti

(!iagrammi !i sequena, prototipi !ella Q%3, mo!elli !i !ominio, etc.).

la foto in alto: un !ail scrum che si svolge nell2angolo menionato.

Immmm.... pare che il born!o#n si presenti bene, fin troppo bene, e questo " un po2sospetto. 8a il team insiste che " reale :o)



1N8 N*Q5K3[[358N @25*5 +@ J58 R =<

I membri del team de7ono stare insieme5>uan!o si arriva al !iscorso !ella !isposiione !elle scrivanie c2" unacosa che vale sempre la pena continuare a riba!ire piE e piE volte.

3 membri !el team !evono stare insieme$

Per chiarire un po2 meglio il concetto, quello che voglio !ire "

I mem$ri del team de!onostare insieme

@a gente " riluttante a spostarsi, per lo meno nei posti in cui ho lavoratoio. Kon vogliono pren!ere le loro cose, sconnettere il computer, spostaretutto in un2altra scrivania, rimontare e riconnettere tutto !a capo. 8inore "la !istana, maggiore " la riluttana. Chi 1apo, sono solo ' metri. 1he!ifferena vuoi che faccia9D

Per costruire un team Scrum efficace, comunque, non c2" alternativa.Fisogna che i membri !el team stiano nello stesso posto. 5nche se questosignifica !over minacciare personalmente ogni persona, a!operarsi aspostare le loro cose e rimuovere le loro vecchie macchie !i caff". Se nonc2" spaio per il team, bisogna crearlo !a qualche parte, anche nelseminterrato. *i!isponi le scrivanie, metti a tacere l2office manager, fa2quello che serve. Fasta che i membri !el team stiano insieme.

%na volta riusciti a mettere tutto il team in un unico posto, si vieneimme!iatamente ripagati. +opo un solo sprint il team concor!er che "stata una buona i!ea (almeno per esperiena personale. 8agari ci sonoteam talmente ostinati che non vorranno ammetterlo). Nra cosa significa CinsiemeD9 1ome !ovrebbero essere !isposte lescrivanie9 Fe2, io non ho un2i!ea ben precisa su quale !ebba essere la!isposiione ottimale. 5nche se ce l2avessi, cre!o che molti team non

possano permettersi il lusso !i !eci!ere esattamente come !isporre le proprie scrivanie. +i solito ci sono vincoli fisici - altri team vicini, le porte !el bagno, il !istributore automatico in meo alla stana, cose !iquesto tipo.



=B R S1*%8 P +5@@ J*3K1

C3nsiemeD significa:

• 8di$ilitB? tutti nel team possono parlare con chiunque altro sena!over alare la voce o lasciare la propria scrivania.

• Visi$ilitB? tutti nel team possono ve!ere gli altri. Jutti possonove!ere la taskboar!, Kon che arrivino leggerla# ma almeno avederla.

• Isolamento? se l2intero team !ovesse improvvisamente alarsi e!ingaggiare una spontanea e viva !iscussione riguar!ante il !esign,non !ovrebbe esserci nessuno al !i fuori !el team cos4 vicino !a

esserne !isturbato, e viceversa.

C3solamentoD non significa che il team !eve essere completamente isolato.3n un ambiente a cubicoli al team puA bastare l2avere un cubicolo con!elle pareti !ivisorie sufficienti a filtrare molto !el rumore proveniente!all2esterno !el team stesso.

se il team " !istribuito9 Fe2 questa " sfortuna. %sare il piE possibilestrumenti tecnici per minimiare il !anno - vi!eo conferene, #ebcam,tool !i con!ivisione !el !esktop, etc.

Tenere il product o>ner alla larga

3l pro!uct o#ner !ovrebbe essere abbastana vicino !a poter esserefacilmente raggiunto !a chiunque !el team per rispon!ere a! eventuali

!oman!e, e !a poter lui stesso raggiungere la taskboar!, ma non !ovrebbestare insieme al team. Perch79 Perch7 c2" la possibilit che non riesca atrattenersi !all2intromettersi nei !ettagli, impe!en!o al team team !ientrare in CsintoniaD (cio" raggiungere uno stato !i compattea, auto-organiaione, iperpro!uttitivit).

5! essere sincero, questa " speculaione. 3n realt non ho ancora visto uncaso in cui il pro!uct o#ner fosse locato con il team, e quin!i non honessuna vera ragione empirica per affermare che si tratti una cattiva i!ea.

solo una mia sensaione, e un sentito !ire !a altri Scrum master.



1N8 N*Q5K3[[358N @25*5 +@ J58 R ='

Tenere i manager e i coac alla larga

un po2 !ura per me scrivere questo, !al momento che sono sia unmanager, sia un coach...

ra mio compito stare con i team il piE possibile. @i ho tirati sE, passavo!all2uno all2altro, ci ho fatto pair programming, ho fatto coaching agliScrum master, ho organiato gli sprint planning meeting, etc. +alleretrospettive " emerso che per molte persone " stata una 1osa Fuona, !almomento che avevo qualche esperiena con lo sviluppo agile !elsoft#are.

Juttavia, ero anche (e qui entra la musica !i +arth Ma!er) il capo !ellosviluppo, con ruolo !i manager funionale. 1iA significa che quan!oentravo in un team questo !iventava automaticamente meno autonomo.C1aspita, il 1apo " qui, probabilmente ne avr !i opinioni su cosa!ovremmo fare, su chi !ovrebbe fare cosa. Sentiamo quello che ha !a!ire.D

3l punto che voglio sottolineare " questo. Se sei uno Scrum coach (e amaggior ragione un manager) sii coinvolto e vicino il piE possibile, ma

solo per un perio!o limitato. Poi stanne fuori e lasca che il team inii a!amalgamarsi e a gestirsi !a s7. Oa2 una verifica sul team una volta ognitanto (non troppo spesso) assisten!o alle !emo !egli sprint, tenen!o!2occhio la taskboar! e! ascoltan!o gli scrum meeting !ella mattina. Se cisono spai !i miglioramento, pren!i lo Scrum master !a parte e !agli !eiconsigli. Non !2avanti al team. %n2altra buona i!ea " partecipare alleretrospettive (ve!ere pg GG C1ome facciamo le retrospettiveD) se con imembri !el team c2" un rapporto !i fi!ucia tale che questo non liintimi!isca.

*iguar!o ai team Scrum che gi funionano bene, assicurati che abbianotutto ciA che gli serve, ma poi... stanne ben lontano (eccetto quan!o cisono le sprint-!emo).



K2ome /acciamo i dailF scrum

3 nostri !ail scrum sono piuttosto !a manuale. 3niiano esattamenteall2orario previsto, ogni giorno nello stesso posto. 5ll2iniio pensavamo !iusare un2area separata per gli sprint planning (erano i giorni in cuiusavamo gli sprint backlog in formato elettronico), comunque orafacciamo i !ail scrum nell2area !el team proprio !avanti alla taskboar!. Kon c2" niente !i meglio.

Kormalmente facciamo i meeting in pie!i, !ato che questo ri!uce ilrischio !i superare i &' minuti previsti.

2ome aggiorniamo la tas+board Kormalmente aggiorniamo la taskboar! !urante il !ail scrum. Ngnuno,quan!o !escrive cosa ha fatto ieri e cosa far oggi, ri!ispone i vari post-itsulla taskboar!. Se !escrive una attivit non pianificata applica un nuovo post-it. Se aggiorna le sue stime, scrive la nuova stima sul post-it e barraquella vecchia. >ualche volta " lo Scrum master a fare queste cose mentregli altri parlano.

5lcuni team a!ottano la politica !i far aggiornare a tutti la taskboar! prima !i ogni meeting. 5nche questo funiona bene. Fasta !eci!ere una

politica e poi mantenerla.>ualunque sia il formato !el proprio sprint backlog, cercare !i ren!eretutto il team partecipe nel mantenere lo sprint backlog aggiornato.5bbiamo tentato !i fare !egli sprint in cui fosse lo Scrum master l2unico a

*cri0eretest chefallisce

1 g3g2g

*cri0eretest chefallisce3g2g

*cri0ere&est chefallisce2g



=6 R S1*%8 5K+ P O*N8 JI J*K1IS

tenere lo sprint backlog aggiornato, an!an!o in giro ogni giorno in giro achie!ere circa le stime !ei tempi rimanenti. Qli svantaggi !i ciA erano:

• @o Scrum master spen!e troppo tempo in cose amministrative,

invece !i supportare il team e rimuovere gli impe!imenti.• 3 membri !el team non sono consapevoli !ello stato !ello sprint,

!al momento che lo sprint backlog non " qualcosa !i cui !evonooccuparsi. >uesto mancato fee!back nel complesso ri!ucel2agilit e la concentraione !el team.

Se uno sprint backlog " ben fatto !ovrebbe essere semplice per ognimembro !el team aggiornarlo !a s7.

3mme!iatamente !opo il !ail scrum meeting, qualcuno fa la somma !ellestime !ei tempi (ignoran!o quelle !ella colonna C!oneD ovviamente) etraccia un nuovo punto nel burn!o#n !ello sprint.

@uando qualcuno : in ritardo5lcuni team hanno un contenitore !i monete e scontrini. Se sei in ritar!o,anche !i un solo minuto, aggiungi una cifra fissa nel contenitore. Kon sifanno !oman!e. Se chiami prima !el meeting e !ici che arriverai inritar!o !evi comunque pagare.

Puoi farla franca solo se hai una buona scusa, come un appuntamento !alme!ico o il tuo matrimonio o qualcosa !el genere.

3 sol!i !el contenitore li usiamo per eventi sociali. Per !egli hamburger!urante le nostre serate per esempio :o)

Ouniona bene. 8a " necessario solo nei team !ove le persone arrivanospesso tar!i. 5lcuni team non hanno bisogno !i questo sistema.

@uando qualcuno dice CNon so cosa /arBoggi

Kon " raro per qualcuno !ire Y3eri ho avuto questo e quello !a fare, maoggi non riesco a immaginare !i cosa mi !ovrA occupareY (ehi fa ancherima). ora9

8ettiamo che quelli che non sanno cosa fare oggi sono oe e @isa.

Se sono io lo Scrum master passo avanti con un altro, ma pren!o nota !ichi non aveva niente !a fare. +opo che tutti hanno !etto la loro, ripasso la



1N8 O511358N 3 +53@\ S1*%8 R =

taskboar! insieme al team, !all2alto verso il basso, e verifico che tutto siasincroniato, che ognuno sappia il significato !i ogni item, etc. 3nvito le persone a! aggiungere altri post-it. >uin!i ripren!o il !iscorso con coloro

che non sapevano cosa fare Cora che abbiamo ripassato la taskboar!, aveteuna qualche i!ea su cosa potreste fare oggi9D Se tutto va bene, cel2avranno.

Se no, consi!ero il pair programming. 8ettiamo che Kiklas implementerla logica !ella Q%3 per la parte !i back office. 3n quel caso possogarbatamente suggerire che forse oe o @isa potrebbe fare pair programming con Kiklas su questa attivit. +i solito funiona.

Se non funiona, ecco il prossimo trucco.

Scrum master? CFene, chi vuole fare una !emo !el rilascio !ellaversione beta-read&9D (che " l2obiettivo !ello sprint)9eam? silenio confusoScrum master? YKon " pronta9Y9eam? Cuhm... noDScrum master? CNh cavolo$ 1ome mai9 1osa manca9D9eam? CFe2, non abbiamo nemmeno un server !i test !ove eseguirla, e lo

script !i buil! " rotto.DScrum master?C5ha.D (aggiungen!o !ue post-it). Coe e @isa, potreste!arci una mano oggi9DJoe? C%m... cre!o che cercherA !i trovare un server !i test !a qualche parteD.0isa? C...e io cercherA !i mettere a posto lo script !i buil!D.

1on un po2 !i fortuna, qualcuno far !avvero la !emo !ella beta richiesta.Nttimo$ @2obiettivo !ello sprint " stato raggiunto. 8a se siamo a met

sprint9Oacile. 1ongratularsi con il team per il buon lavoro fatto, pren!ere una o!ue storie !alla seione CnextD in basso a !estra !ella taskboar!, espostarle nella colonna Cnot checke! outD a sinistra. >uin!i rifare il !ailscrum. 3nformare il pro!uct o#ner che sono state aggiunte alcune attivitallo sprint.

8a cosa fare se il team non ha ancora raggiunto l2obiettivo !ello sprint eoe e @isa comunque si rifiutano !i trovare qualcosa !i utile !a fare. 3o !i

solito consi!ero una !elle seguenti strategie (nessuna !i queste " moltogentile, ma !2altron!e siamo all2ultima spiaggia):

• Vergogna: CFe2 se non avete i!ea !i come poter aiutare il team,vi suggerisco !i an!are a casa, o !i leggere un libro o altro.



G R S1*%8 5K+ P O*N8 JI J*K1IS

Nppure state qua in ona finch7 qualcuno non venga a chie!erviun aiuto.D.

• Vecchia scuola? assegno loro semplicemente un task.

• Peer pressure? !ico Cpren!etevela como!a oe e @isa, noistaremo tutti qui a! aspettare che vi venga in mente qualcosa !afare e che ci aiuti a raggiungere l2obiettivo.D

• Ser!itD: !ico CFene, potreste aiutare il team in!irettamentefacen!o i maggior!omi oggi. Oate il caff", un po2 !i massaggi, le puliie, ci cucinate qualcosa per prano, e qualunque altra cosa!ovessimo richie!ere !urante la giornata.D 12" !a sorpren!ersi !icome oe e @isa si a!opereranno per trovare qualche attivittecnica utile :o)

Se si arriva spesso a questo punto con la stessa persona, bisogna probabilmente pren!erla !a parte e farle un po2 !i serio coaching. Se il problema persiste, bisogna valutare se questa persona " importante per ilteam o no.

Se non " troppo importante, provare a farla rimuovere !al team.

Se ' importante, provare metterla in coppia con qualcun altro che le faccia!a CmentoreD. oe magari " un gran!e sviluppatore o architect, ma!avvero preferisce che siano altre persone a !irgli cosa fare. +2accor!o.+a2 a Kicklas il compito !i essere sempre il curatore !i oe. N fallo tustesso. Se oe " importante abbastana per il team ne vale la pena.5bbiamo avuto casi come questo e piE o meno hanno funionato.



%2ome /acciamo le sprint demo

@a sprint !emo (o sprint revie#, come qualcuno la chiama) " una parteimportante !i Scrum che si ten!e a sottovalutare.CNh ma !avvero dobbiamo fare una !emo9 Kon c2" niente !i sfiioso !amostrare$DCKon abbiamo tempo !i preparare questa ]^_ !i !emo$DCKon ho il tempo !i partecipare alle !emo !egli altri team$D

.erc8 insistiamo a//inc8 tutti gli sprint/iniscano con una demo

%na !emo ben fatta, anche se magari puA apparire un2esibiione scenica,ha un profon!o effetto.

• 3l team gua!agna cre!ito per quello che ha fatto. 1i si sente bene.• Qli altri capiscono cosa sta facen!o il tuo team.

• Oacen!o la !emo si ottiene un fee!back vitale !a parte !egli altri stakeholder .

• @e !emo sono (o !ovrebbero essere) un evento sociale che permette ai !iversi team !i interagire e confrontare i propri lavori.>uesto " !i gran!e valore.

• Oacen!o una !emo, il team " forato a finire per davvero le cose ea rilasciarle (anche se solo in un ambiente !i test). Sena le !emo,si continuer a! avere una lunga lista !i cose finite al . 1on le!emo magari si faranno meno cose, ma queste sarannoeffettivamente portate a termine, il che (nel nostro caso) " moltomeglio che avere tutta una pila !i cose più o meno finite cheinquineranno lo sprint successivo.

Se un team " piE o meno forato a fare una sprint !emo, e magari non hacos4 tante cose pronte !avvero funionanti, la !emo sar imbaraante. 3lteam balbetter, esiter e l2applauso finale sar tiepi!o. >ualcuno potr un



G; R S1*%8 5K+ P O*N8 JI J*K1IS

po2 compatire il team, e qualcun altro si sentir anche irritato per aver perso tempo assisten!o a! una !emo obbrobriosa.

Oa male. 8a l2effetto " un po2 quello !i una me!icina amara. 5l prossimo sprint , il team cercher !avvero !i fare in mo!o che le cose siano finite$ 3l pensiero sar: C5llora, magari possiamo !imostrare solo !ue cose al prossimo sprint anich7 cinque, ma !annaione stavoltaO%K[3NK*5KKN$D. 3l team sa che ci sar !a fare una !emo,qualunque cosa acca!a, e questo accresce significativamente la possibilitche qualcosa !i utile !a !imostrare ci sar. Io visto questo capitare!iverse volte.

2ec+list per le sprint demo• 5ssicurati !i illustrare chiaramente l2obiettivo !ello sprint. Se alla

!emo c2" qualcuno che non sa niente !el pro!otto, !e!ica pochiminuti a !escriverlo.

• Kon per!ere troppo tempo a preparare la !emo. 3n particolareevita presentaioni appariscenti. 8etti !a parte queste amenit efocaliati solo sul !imostrare vero co!ice funionante.

• Jieni un passo spe!ito, cio" prepararti a ren!ere la !emo celere

piuttosto che bella.• 8antieniti a! un livello orientato al business, e lascia fuori i

!ettagli tecnici. Oocaliati sul Ccosa abbiamo fattoD piuttosto chesul Ccome l2abbiamo fattoD.

• Se possibile, consenti ai presenti !i provare !a soli le funionalit!el pro!otto.

• Kon !imostrare una massa !i correioni !i piccoli errori, ofunionalit banali. 8enionale ma non !imostrarle, !ato che !isolito questo finisce per richie!ere troppo tempo !istoglien!o laconcentraione !alle storie piE importanti.

)ulle /un-ionalit? Cnon dimostrabili

Mem$ro del team? CKon !imostrerA questa parte, perch7 non puA essere!imostrata. @a storia " 28igliorare la scalabilit !el sistema in mo!o !agestire &. utenti simultanei2. 1ome caspita li invito &. utenti

simultanei alla !emo9DScrum master: C8a la funionalit " terminata9DMem$ro del team? C8a s4, certoD.Scrum master? C1ome fai a saperlo9D



1N8 O511358N @ SP*3KJ +8N R G<

Mem$ro del team? CIo installato il sistema in un ambiente !i performance test, fatto partire 6 load server , e bombar!ato il sistema !irichieste simultaneeD.

Scrum master? C8a hai una qualche in!icaione !el fatto che il sistemaregga &. utentiD.Com#onente del team? CS4. @e macchine !i test, per quanto scarse, gireggono '. richieste simultanee !urante il mio testD.Scrum master? C come lo sai9DCom#onente del team (frustrato): C5llora. Io questo report$ Puoiguar!arlo !a te, mostra come " stato impostato il test e quante richiestevenivano lanciate$DScrum master? CNh perfetto$ cco quin!i la tua C!emoD. Fasta mostrare

il report e farlo girare tra i partecipanti. 8eglio che niente, giusto9D.Com#onente del team? CNh, solo questo9 1omunque " un po2incomprensibile, c2" !a !argli una sistemata.D.Scrum master: C+2accor!o, ma non per!erci troppo tempo. Kon !eveessere accattivante, solo informativo.D



62ome /acciamo le retrospetti7e

.erc8 insistiamo a//inc8 tutti i team /accianole retrospetti7e

@a cosa piE importante !elle retrospettive " assicurarsi che abbiano

luogo.

Per qualche motivo, i team non sempre sembrano propensi a fare leretrospettive. Se non venissero gentilmente incoraggiati molti !ei nostri

team le salterebbero spesso passan!o subito allo sprint successivo. PuA!arsi che si tratti solo !i una cosa culturale sve!ese, non saprei.

Oinora, tutti sembrano essere !2accor!o sul fatto che le retrospettive sonoestremamente utili. 3nfatti !irei che la retrospettiva " il secon!o evento piEimportante in Scrum (il primo " lo sprint planning meeting) perch7 " la

migliore occasione per migliorare$

Katuralmente, non c2" bisogno !i una retrospettiva per farsi venire !elle

buone i!ee, !ato che queste possono venir fuori mentre si " in casa magari!istesi sulla vasca$ 8a il team accetter la tua i!ea9 PuA !arsi, ma le possibilit !i accettaione !a parte !el team sono maggiori quan!o le i!eevengono C!al teamD, cio" se le proposte avvengono !urante laretrospettiva, !ove tutto possono contribuire e !iscutere le i!ee.

Sena le retrospettive si noter che il team continua a ripetere ogni voltagli stessi errori.



1N8 O511358N @ *J*NSPJJ3M R G'

2ome organi--iamo le retrospetti7e

3l formato generale puA variare un po2, ma in generale facciamo qualcosa!el genere:

• 5llochiamo & - < ore a secon!a !ella quantit !i cose che preve!iamo !i !iscutere.

• Partecipanti: il pro!uct o#ner, l2intero team, e! io.• 1i spostiamo in una sala chiusa, un confortevole angolo-sof, una

terraa sul tetto, o un posto simile. @2importante " poter avereuna !iscussione in!isturbata.

• +i solito non facciamo le retrospettive nell2area !el team, !almomento che altrimenti l2attenione !elle persone ten!erebbe a

vagare.• >ualcuno viene incaricato come segretario.

• @o Scrum master mostra lo sprint backlog e, con l2aiuto !el team,fa un sommario !ello sprint. venti importanti, !ecisioni, etc.

• Oacciamo un CgiroD. Ngni persona ha la possibilit !i !ire, senaessere interrotto, cosa pensa sia an!ato bene, e cosa pensa che poteva an!are meglio, e cosa farebbe in mo!o !iverso al prossimosprint.

• +iamo una occhiata alla !ifferena tra la velocit stimata e la

velocit effettiva. Se c2" una grossa !ifferena si cerca !ianaliarne le cause.

• >uan!o il tempo " quasi finito lo Scrum master tenta !iriassumere i suggerimenti concreti su cosa si potrebbe fare meglioal prossimo sprint.

@e nostre retrospettive sono in generale non troppo strutturate.@2argomento alla base " sempre lo stesso: Ccosa possiamo fare meglio al prossimo sprintD.

cco un esempio !i lavagna !a una recente retrospettiva:



G= R S1*%8 P +5@@ J*3K1

@e colonne sono tre:

• :ene? se potessimo rifare !i nuovo lo stesso sprint, queste cose lefaremmo allo stesso mo!o.

• Pote!amo fare meglio? se potessimo rifare un2altra volta lostesso sprint, queste cose le faremmo in mo!o !iverso.

• Miglioramenti? i!ee concrete su come potremmo migliorare infuturo.

>uin!i le colonne & e ; sono rivolte al passato, mentre la colonna < "rivolta al futuro.

+opo aver riflettuto su tutti questi post-it, il team vota assegnan!o !ei punti per !eterminare a quali miglioramenti puntare nel prossimo sprint.Ngni membro !el team ha a !isposiione tre magneti e viene invitato avotare qualsiasi miglioramento consi!eri prioritario per il prossimo sprint.3l membro !el team puA !istribuire i magneti a piacere, anche piaan!olitutti e tre su una singola proposta.

Su questa base vengono seleionati cinque miglioramenti !i processo sucui focaliarsi, e questo impegno rester vali!o fino alla prossimaretrospettiva.

importante non essere troppo ambiiosi su questo punto. Puntare solo a

pochi miglioramenti per sprint.



1N8 O511358N @ *J*NSPJJ3M R GG

2ondi7idere con gli altri team le le-ioniimparate

@e informaioni che emergono !urante la retrospettiva !i uno sprint sono!i solito estremamente preiose. 3l team sta aven!o !ifficolt aconcentrarsi perch7 il manager !el reparto ven!ite continua letteralmentea tenere i programmatori sotto sequestro per farli partecipare comeCesperti tecniciD alle riunioni !e!icate alle ven!ite9 >uesta " unainformaione importante. Oorse altri team staranno aven!o lo stesso problema9 +ovremmo fare maggiore formaione rivolta all2area gestione pro!otti, in mo!o !a ren!erli piE autonomi nel supporto alle ven!ite9

@a retrospettiva non " solo relativa a come il team potr fare meglio al prossimo sprint, ma ha implicaioni piE ampie.

Per questo la nostra strategia " molto semplice. %na persona (in questocaso io) partecipa a tutte le retrospettive e fa !a CponteD !elle conoscene.Piuttosto informale.

%n2alternativa sarebbe far pubblicare a! ogni team Scrum un resoconto!ella propria retrospettiva. 1i abbiamo provato ma poi non molti li

leggevano, e! erano ancor meno quelli che ne traevano spunto per !elleaioni. >uin!i piuttosto lo facciamo in mo!o semplice.

*egole importanti per chi fa !a CponteD:• Saper ascoltare.• Se la retrospettiva " troppo sileniosa, essere gi preparato a fare

!elle !oman!e semplici e ben centrate atte a stimolare il !ialogonel gruppo. Per esempio Cse potessi tornare in!ietro nel tempo erifare lo stesso sprint !al giorno &, cosa avresti fatto !i !iverso9D

• 5vere il tempo che serve per visitare tutte le retrospettive !i tuttii team.

• 5vere una certa posiione !i responsabilit, per poter agire in base ai suggerimenti relativi a miglioramenti fuori !el controllo!el team stesso.

>uesto funiona abbastana bene ma potrebbero esserci altri approcci chemagari funionano molto meglio. 3n questo caso, vi prego !i illuminarmi.



G6 R S1*%8 P +5@@ J*3K1

2ambiare o non cambiare

Supponiamo che il team conclu!a che Cc2" stata poca comunicaioneinterna al team, e quin!i abbiamo continuato a pestarci i pie!i a vicen!a,scompiglian!o ognuno il !esign !ell2altroD.

1osa si puA fare per questo9 3ntro!urre !ei meeting quoti!iani !e!icati al!esign9 3ntro!urre nuovi tool per favorire la comunicaione9 5ggiungere piE pagine sul #iki9 Fe2, forse s4, ma... forse anche no$

5bbiamo realiato che, in molti casi, i!entificare chiaramente un problema " gi abbastana perch7 si risolva automaticamente al prossimosprint, specialmente se il report !ella retrospettiva viene attaccato alla parete !ell2area !el team (cosa che ci !imentichiamo sempre !i fare, chevergogna$). Ngni cambiamento intro!otto ha sempre un qualche costo,quin!i, prima !i intro!urre !ei cambiamenti, consi!erare il non fare proprio niente speran!o che il problema rientri (o si ri!imensioni)automaticamente.

>uello !i cui sopra (Ccomunichiamo troppo poco tra !i noi...D) " un tipicoesempio !i qualcosa che si risolve meglio non facen!o alcunch7.

Se intro!uci un nuovo cambiamento a! ogni lamentela, le persone magari!iventano riluttanti a! evi!eniare aree problematiche minori, e questosarebbe terribile.

Esempi di cose ce possono emergeredurante le retrospetti7ecco alcuni esempi !i cose che tipicamente vengono fuori !urante leretrospettive, e le tipiche aioni.

CA7remmo do7uto dedicare pi tempo a suddi7idere lestorie in item pi piccoli e tas+ una cosa piuttosto comune. Ngni giorno al !ail scrum, alcuni membri!el team si trovano a !ire: CKon so proprio cosa fare oggiD. 1os4 !opo



1N8 O511358N @ *J*NSPJJ3M R G

ogni !ail scrum c2" !a spen!ere un po2 !i tempo per trovare !elle attivitconcrete. +i solito " meglio farlo prima.

4zioni ti#iche? nessuna. 3l team probabilmente sistemer la cosa !a s7!urante il prossimo sprint planning meeting. Se invece la cosa si ripete,aumentare il time-box !ello sprint planning meeting.

CTroppe inter/eren-e esterne4zioni ti#iche?

• chie!ere al team !i !iminuire il focus factor al prossimo sprint, in

mo!o che il suo piano sar piE realistico• chie!ere al team !i pren!ere meglio nota !elle interferene al

prossimo sprint. 1hi ha interferito e quanto a lungo. >uestoren!er piE facile risolvere il problema in seguito.

• chie!ere al team !i ribaltare tutte le interferene allo scrummaster o al pro!uct o#ner.

• chie!ere al team !i nominare un CportiereD, tutte le interruionivengono girate a lui, in mo!o che il resto !el team possa restareconcentrato. Potrebbe essere lo Scrum master o una persona a

rotaione.

CAbbiamo preso in carico troppe cose e ne abbiamo/inito solo la met?

4zioni ti#iche? nessuna. 3l team probabilmente eviter un commitment

cos4 elevato al prossimo sprint, o quantomeno non cos4 esageratamenteelevato.

CLa nostra area di la7oro : troppo rumorosa e caotica4zioni ti#iche?

• cercare !i creare un ambiente migliore, o spostare il team altrove,5ffittare una stana in un hotel, o cose simili. Me!i pg. =& Ccomeorganiiamo l2area !el teamD.

• Se non " possibile, !ire al team !i !iminuire il focus factor al

prossimo sprint, e sottolineare con chiarea che questo " !ovutoa! un ambiente rumoroso e caotico. Si spera che cos4 il pro!ucto#ner scali la questione ai livelli piE alti !el management.



6 R S1*%8 P +5@@ J*3K1

Oortunatamente non ho mai !ovuto minacciare !i spostare il team !aqualche altra parte. 8a se fosse necessario, non ci penserei !ue volte :o)



66)tacci tra uno sprint e l9altro

Kella vita reale, non si puA an!are sempre !i CvolataD. necessario tirareil fiato tra uno sprint e l2altro. Se vai sempre !i volata, in realt staifacen!o `ogging.

@a stessa cosa vale anche in Scrum e in generale nello sviluppo soft#are.Qli sprint sono piuttosto sostenuti. 1ome sviluppatore non hai mai unavera occasione per rilassarti. Ngni giorno !evi prostrarti a questo meetinge !ire a tutti cosa hai fatto il giorno prima. Pochi saranno inclini a !ireCSono stato tutto il tempo con i pie!i appoggiati sul tavolo, leggen!o bloge sorseggian!o cappucciniD.

Nltre a quella !el riposo stesso, c2" un2altra buona ragione per tirare il fiatotra uno sprint e l2altro. +opo la sprint !emo e la retrospettiva, il team e il pro!uct o#ner saranno entrambi carichi !i informaioni e !i i!ee !a!igerire. Se !ovessero subito gettarsi a pianificare il prossimo sprint, probabilmente nessuno avr la possibilit !i metaboliare le informaionie le leioni imparate, il pro!uct o#ner non avr il tempo !i mo!ificare lesue priorit !opo la sprint !emo, etc.

Male?

LunedM

4>09 Sprint 0 demo

0>009 Sprint 0 retrospettiva

0@>059 Sprint 2 planning



1erchiamo !i intro!urre una sorta !i stacco prima !i iniiare un nuovosprint (piE specificamente nel perio!o che c2" !opo la retrospettiva e

prima !el prossimo sprint planning meeting). 8agari non sempre ciriusciamo.

1ome minimo, cerchiamo !i essere sicuri che la retrospettiva !ello sprinte il successivo sprint planning meeting non occorrano allo stesso giorno.Jutti !ovrebbero quanto meno farsi una bella !ormita sapen!o che unosprint " finito, e l2altro !eve ancora cominciare.

Meglio?

4ncora meglio?

%n mo!o per consentire questo " istituire i Clab da&D (o chiamateli comevi pare). Si tratta !i giorni in cui agli sviluppatori " permesso fareessenialmente tutto ciA che vogliono (NT, ammetto !i essermi ispirato aQoogle), per esempio stu!iare gli ultimi tool e 5P3, prepararsi per unacertificaione, !iscutere questioni tecniche !a CsmanettoniD con i colleghi,o portare avanti un progetto per hobb, etc.

3l nostro obiettivo " quello !i avere un Clab !aD tra uno sprint e l2altro. 3n

questo mo!o si avr un riposo naturale tra gli sprint, e si potr avere unteam !i sviluppo realisticamente in gra!o !i tenere aggiornate le proprieconoscene. 3n piE si tratta !i un benefit lavorativo piuttosto attraente.

'enerdM

4>09 Sprint 0 demo0>009 Sprint 0 retrospettiva

)abato Domenica LunedM

4>0@9 Sprint 2 planning

LunedM

4>09 Sprint 0 demo

0>009 Sprint 0 retrospettiva

1artedM




Il miglioreE

5ttualmente i nostri Clab !aD ca!ono una volta al mese. 3l primo vener!4!i ogni mese per l2esattea. Perch7 non tra gli sprint invece9 Fe2, per meera importante che l2intera aien!a pren!esse il suo lab !a nello stessomomento. 5ltrimenti avrebbe potuto essere preso non troppo sul serio. ,!al momento che non abbiamo (ancora) allineato gli sprint !i tutti i

pro!otti, ho !ovuto invece scegliere un lab !a in!ipen!ente !allaca!ena !egli sprint.

%n giorno potremmo provare a sincroniare gli sprint !i tutti i pro!otti(cio" le stesse !ate !i iniio e fine per tutti i pro!otti e team). 3n quel caso piaeremo sen2altro il Clab !aD tra la fine !i uno sprint e l2iniio !elsuccessivo.

'enerdM

6&? *&K

)abato Domenica LunedM


Gio7eM

4>09 Sprint 0 demo0>009 Sprint 0 retrospettiva



6#2ome /acciamo i piani di rilascio per i

contratti a pre--o /isso<

5 volte abbiamo bisogno !i pianificare in anticipo piE !i uno sprint allavolta. Jipicamente questo avviene quan!o c2" un contratto a preo fisso, per cui dobbiamo pianificare in anticipo, altrimenti corriamo il rischio !ifirmare qualcosa che non riusciremo a rilasciare in tempo.

Jipicamente il piano !i rilascio per noi " un tentativo !i rispon!ere alla!oman!a Cquando " che # al più tardi, saremo in gra!o !i rilasciare laversione &. !i questo nuovo sistemaD.

Se volete davvero imparare qualcosa sui piani !i rilascio suggerisco !isaltare questo capitolo e acquistare invece il libro !i 8ike 1ohn C5gilestimating an! PlanningD. 5vrei voluto !avvero leggerlo prima (l2ho fattosolo dopo aver realiato queste cose sul campo...). @a mia versione !ella pianificaione per un rilascio " un po2 semplicistica ma !ovrebbe servirecome un buon punto !i partena.

)tabilire la soglia di accetta-ione3n aggiunta al consueto backlog, il pro!uct o#ner !efinisce una lista !i soglie di accettazione che sono una semplice classificaione !i cosa igra!i !i importana nel pro!uct backlog significhino veramente rispetto alcontratto.

cco un esempio !i regole relative alle soglie !i accettaione:• Jutti gli item !i importana ZV & devono essere inclusi nella

versione &., altrimenti saremo con!annati a morte.• Jutti gli item !i importana '- dovrebbero essere inclusi nella

versione &., ma potremmo cavarcela realian!oli in un rapi!orilascio successivo.

<anche !etti Ca corpoD K!J



1N8 O511358N %K P35KN +3 *3@5S13N P* 3 1NKJ*5JJ3 5 P*[[N O3SSN R6'

• Qli item !i importana ;' - B sono richiesti, ma possono essereanche fatti rientrare nella successiva release &.&

• Qli item !i importana ;' sono speculativi e potrebbero non

servire mai.

cco un esempio !i pro!uct backlog, co!ificato per colori in base alleregole appena !escritte.

(osso V deve essere incluso nella versione &. (banana H pera))iallo V dovrebbe essere incluso nella versione &. (uva H cipolla)*erde V potrebbe essere fatto anche piE in l (pompelmo H pesca)

>uin!i se rilasciamo tutto !alla banana alla cipolla siamo salvi. Se il

tempo !ovesse scarseggiare, potremmo tralasciare uva, arachi!i, ciambellae cipolla. Jutto quello che c2" !opo la cipolla " un plus.

)timare i tempi degli item pi importanti

Per preparare un piano !i rilascio, al pro!uct o#ner servono !elle stime,almeno rispetto a tutte le storie incluse nel contratto. sattamente comequan!o si fa lo sprint planning, si tratta !i un lavoro collegiale tra pro!ucto#ner e team - il team stima, il pro!uct o#ner !escrive gli item e rispon!e

alle !oman!e.

%na stima !ei tempi " valida se si rivela quasi corretta, meno vali!a sefinisce per !eviare, !iciamo, !i un <, e completamente inutile se nonha alcuna attinena attinena con la realt.

Importan-a Nome

0@ banana

02 mela

00C arancia00 guava

0 pera

4C uva

1 arachidi

! ciambella

5 cipolla

# pompelmo

@C papaa

0 mirtilli

0 pesca



6= R S1*%8 P +5@@ J*3K1

>uesta " la mia visione !el valore !elle stime !ei tempi rispetto a chi lecalcola e a quanto tempo ci mette a farlo.

>uesta spatafiata era solo per !ire:

• @ascia al team il compito !i fare le stime• Kon spen!ere troppo tempo a fare le stime

• 5ssicurarti !i far capire che le stime !ei tempi sono stime crude#non !elle Cimpegnative”.

+i solito il pro!uct o#ner ra!una tutto il team in una stana, provve!e aqualche rinfresco, e lo informa che lo scopo !el meeting " !i stimare le ;(o quante sono) storie principali !el pro!uct backlog. Sviscera tutte lestorie una sola volta, e poi lascia che il team si metta al lavoro. 3l pro!ucto#ner resta nella stana per rispon!ere alle !oman!e e per chiarire,

quanto serve, lo scope !i ogni item. Proprio come quan!o si fa lo sprint planning, il campo Ccome !imostrareD risulta molto utile per ri!urre ilrischio !i equivoci.

>uesto meeting " tassativamente time-boxe!, altrimenti i team ten!ono aspen!ere troppo tempo a stimare troppe poche storie.Se il pro!uct o#ner vuole che vi si !e!ichi piE tempo, basta pianificare unnuovo meeting. 3l team !eve assicurarsi che l2impatto !i questi meetingsullo sprint in corso sia ben visibile al pro!uct o#ner, in mo!o che gli sia

chiaro che fare le stime non " un2attivit a costo ero.

cco un esempio !i come le stime !ei tempi possono presentarsi (intermini !i stor points):

%empo impiegato per fare le timedei tempi

AaliditBdellastima

Quando la stima la fa il team

Quando la stima la fa il product o)ner



1N8 O511358N %K P35KN +3 *3@5S13N P* 3 1NKJ*5JJ3 5 P*[[N O3SSN R6G

)timare la 7elocit?

Fene, ora abbiamo una qualche stima cru!a per le storie piE importanti.

3l prossimo passo " stimare la velocit me!ia per sprint.>uesto significa che bisogna !i fissare il focus factor. Me!ere pg. ;=C1ome fa il team a !eci!ere quali storie inclu!ere nello sprintD.

3l focus factor " fon!amentalmente Cquanto tempo !el team vieneeffettivamente impiegato concentran!osi sulle storie in corsoD. Kon " mai al & !al momento che i team spen!ono tempo a fareattivit non pianificate, a passare !a un contesto all2altro, a !are una mano

agli altri team, a rispon!ere alle email, a mettere a posto i propricomputer, a !iscutere !i politica nell2area ristoro, etc.

Supponiamo !i !eterminare un focus factor per il team pari al '(piuttosto basso, noi normalmente siamo sul G). Poniamo inoltre che la!urata !egli sprint sia !i tre settimane (&' giorni) e che il team siacomposto !a sei persone.

3n ogni sprint ci starebbero quin!i giorni uomo, ma ci si aspetta !i

pro!urre storie per l2equivalente !i B' giorni uomo (per via !el focusfactor al ').

Imp Nome )tima

0@ banana 02

02 mela 4

00C arancia 2

00 guava 1

0 pera 2

4C uva 02

1 arachidi 0

! ciambella 1

5 cipolla 0

# pompelmo 0#@C papaa #

0 mirtilli

0 pesca



1N8 O511358N %K P35KN +3 *3@5S13N P* 3 1NKJ*5JJ3 5 P*[[N O3SSN R6

solitamente aggiungiamo un buffer significativo per salvaguar!arci !astime !ei tempi sbagliate, problemi inattesi, feature inattese, etc. >uin!i inquesto caso potremmo accor!arci su una !ata !i consegna !i tre mesi

!an!oci quin!i un mese !i CriservaD.

@a cosa piacevole " che possiamo !imostrare al cliente qualcosa !i usabileogni tre settimane e! invitarlo a mo!ificare le sue esigene via via che proce!iamo (ma !ipen!e sempre !al contratto, ovviamente)

Adattare il piano di rilascio@a realt non si a!atter !a sola a! un piano, quin!i !eve essere unqualcosa nella !ireione opposta, all2incirca.

+opo ogni sprint !iamo un2occhiata alla velocit effettiva !i questo sprint.Se la velocit effettiva " stata molto !iversa !a quella stimata, rive!iamola velocit stimata per gli sprint futuri e aggiorniamo il piano !i rilascio.Se questo aggiornamento ci creasse problemi, il pro!uct o#ner potrebbeiniiare a negoiare con il cliente oppure a verificare come ri!urre lo

scope sena violare il contratto. N magari lui e! il team potrebberoscoprire un mo!o per aumentare il focus factor rimuoven!o qualche serioimpe!imento i!entificato !urante lo sprint.

3l pro!uct o#ner potrebbe chiamare il cliente e !irgli Csalve, siamoleggermente in ritar!o ma cre!o che sarebbe possibile rispettare lasca!ena se semplicemente rimuovessimo la feature Cpac-man integratoDche richie!e un po2 !i tempo per essere portata a termine. Potremmoaggiungerla nella release successiva tre settimane !opo la prima release se

@e va beneD.

Kon si tratta !i una buona notiia per il cliente forse, ma almeno siamostati corretti e gli stiamo offren!o la chance !i una scelta tempestiva -rilasciare le cose piE importanti in tempo o tutto quanto in ritar!o. +isolito non " una scelta !ifficile :o)



6<2ome combiniamo )crum con .

1he Scrum e! P (etreme Programming) si possano combinare proficuamente non " !avvero una affermaione controversa. 8olte !ellecose che ho letto in rete supportano questa assunione, e quin!i nonspen!erA tempo a sostenerne le ragioni.

Fe2, accennerA a! una cosa. Scrum si focalia sul management e sulle pratiche organiative mentre P si focalia per lo piE sulle praticheconcrete !ella programmaione. questo il motivo per cui funionano bene insieme - affrontano ambiti !ifferenti e si completano a vicen!a.

1on questo aggiungo la mia a riguar!o !ella !imostraione empirica cheScrum e! P possono essere combinati proficuamente$

5n!rA a! evi!eniare alcune !elle piE preiose pratiche P e come sonoentrate a far parte al nostro lavoro quoti!iano. Kon tutti i team sonoriusciti a! a!ottare tutte le pratiche, ma nel complesso abbiamosperimentato la maggior parte !egli aspetti !ella combinaione P/Scrum.5lcune pratiche P sono gi insite in Scrum e ciA puA essere visto comeuna sovrapposiione, per esempio C+hole teamD, CJeam co-locatoD,

CStorieY, e CPlanning gameD. 3n questi casi semplicemente restiamoall2acceione Scrum.

Il pair programming%ltimamente abbiamo cominciato a farlo in uno !ei nostri team. Ouniona piuttosto bene. @a maggior parte !ei nostri team non fa ancora molto pair programming ma, aven!olo a!esso effettivamente provato in un team per

alcuni sprint, mi ispira l2i!ea !i farvi cimentare anche gli altri.

5lcune conclusioni, a! oggi, riguar!o il pair programming:• 3l pair programming effettivamente migliora la qualit !el co!ice.



1N8 1N8F3K358N S1*%8 1NK P R &

• 3l pair programming effettivamente aumenta la concentraione!el team (per esempio quan!o il compagno !i pair !ice Chi$ 8aquella cosa l4 ci serve !avvero in questo sprint9D).

• 1on somma sorpresa, viene fuori che molti sviluppatoriiniialmente contrari a fare pair programming, ma che in realtnon l2avevano mai provato, imparano rapi!amente a! apprearlouna volta provato.

• 3l pair programming " faticoso e non !ovrebbe essere fatto tutto ilgiorno.

• bene cambiare le coppie !i frequente.• 3l pair programming aumenta la !iffusione !elle conoscene nel

gruppo. 1iA che sorpren!e " che questo processo " anche rapi!o.• 5lcuni non si sentono a proprio agio facen!o pair programming.

Kon rinunciare a! un eccellente programmatore solo perch7 il pair programming lo mette a !isagio.

• 3l co!e revie# " una alternativa accettabile al pair programming.

• 3l CnavigatoreD (quello che non " alla tastiera) !ovrebbe averesotto mano anche lui un computer, non per lo sviluppo, ma perfare alcune spike se necessario, o per !are una occhiata alla!ocumentaione quan!o il Cgui!atoreD (quello che sta alla

tastiera) resta bloccato, etc.• Kon CimporreD alle persone il pair programming. 3ncoraggiale e

fornisci loro gli strumenti a!atti allo scopo, ma lascia che losperimentino secon!o il proprio ritmo.

Test3dri7en de7elopment (TDD

5men$ >uesto, per me, " piE importante !i Scrum e P messi insieme.Pren!ete la mia casa, la mia JM e il mio cane, ma non impe!itemi !icontinuare a fare J++$ Se non vi piace il J++ allora non fatemi neancheentrare nell2e!ificio, perch7 proverei a! intro!urlo furtivamente, in unmo!o o nell2altro :o)

cco un riassunto in & secon!i !i cosa " il J++:

,est driven development significa che scrivi untest automatizzato# poi scrivi il codice

indispensabile per far passare quel test# poi

rifattorizzi il codice principalmente per



; R S1*%8 P +5@@ J*3K1

migliorare la leggibilit e rimuovere

le duplicazioni. (isciacqui e ripeti.

>ualche riflessione sul test-!riven !evelopment.

• 3l J++ " difficile. %n programmatore ci mette un po2 a!assimilarlo. 3nfatti, in molti casi, per quanto tu possa insegnarlo, pre!icarlo e !imostrarlo - in molti casi l2unico mo!o che un programmatore ha per assimilarlo " quello fare pair con qualcunaltro che sia bravo con il J++. %na volta che un programmatorelo avr assimilato, comunque, ne sar gravemente infettato e nonvorr mai lavorare in nessun altro mo!o.

• 3l J++ ha un effetto profon!amente positivo sul !esign !elsistema.

• 1i vuole tempo per intro!urre a pieno regime il J++ in un nuovo pro!otto, specialmente quan!o si parla !i test !i integraioneCblack-boxD, ma il ritorno !ell2investimento " rapido.

• 5ssicurati !i investire il tempo necessario a ren!ere facile lascrittura !ei test. >uesto significa a!ottare strumenti a!eguati, preparare le persone, fornire corrette classi !i utilit o classi !i

base, etc.

Koi usiamo i seguenti strumenti per il test-!riven !evelopment:

• `%nit / http%nit / `Leb%nit. Stiamo valutan!o !i a!ottare JestKQe Selenium.

• IS>@+F come +ataFase integrato in memoria per facilitarel2esecuione !ei test.

• ett come #eb container integrato in memoria, per scopi !i test.

• 1obertura per le metriche !i co!e coverage.• 3l frame#ork Spring per collegare con facilit !iversi tipi !i test

fi"ture (con mock obects o sena, usan!o !atabase esterni o!atabase in memoria, etc.)

Kei nostri pro!otti piE sofisticati (!al punto !i vista !el J++) abbiamo !eitest !i accettaione automatiati Cblack boxD. >uesti test fanno partire ilsistema tutto in memoria, compresi i !atabase e i #eb server, e l2accesso al

sistema avviene solo utilian!o le sue interfacce pubbliche (per esempiol2IJJP).

Jutto questo paga, perch7 consente un ciclo estremamente rapi!o !isviluppo-buil!-test. 3noltre la cosa funiona come rete !i sicurea,



1N8 1N8F3K358N S1*%8 1NK P R <

ren!en!o agli sviluppatori sufficientemente sicuri nel fare spessorefactoring, il che significa poter mantenere pulito e semplice il !esignanche anche al crescere !el sistema.

TDD sul codice nuo7o

%siamo J++ per tutti i nuovi sviluppi, anche se questo significa spen!ere piE tempo per il setup iniiale (!al momento che ci servono piE tool esupporto per l2infrastruttura !ei test). Kon " niente !i trascen!entale, e i benefici sono talmente ampi che in questo caso non ci sono scuse per nonfare J++.

TDD sul codice 7eccio

3l J++ " !ifficile, ma cercare !i fare J++ su !el co!ice che non sia statoscritto utilian!o il J++ !all2iniio... quello " veramente difficile$Perch79 Fe2, in realt potrei scrivere tantissime pagine su questoargomento e allora penso !i fermarmi qui. @o terrA !a parte per il mio prossimo lavoro CJ++ !alle trinceeD :o)

5bbiamo speso un bel po2 !i tempo per tentare !i automatiare i test !i

integraione in uno o piE sistemi complessi, una code base che era l4 !aun po2 in uno stato fortemente caotico e completamente priva !i test.

Per ogni release !el sistema avevamo un team !i tester !e!icati a!eseguire una intera serie !i complicati test !i regressione e !i carico. 3 test!i regressione erano al piE un lavoro manuale. >uesto rallentavasignificativamente il ciclo !i sviluppo e rilascio. 1i eravamo !atil2obiettivo !i automatiare quei test. +opo aver sbattuto la testa contro ilmuro per un po2 !i mesi, comunque, non ci eravamo avvicinati piE !i

tanto.+opo!ich7 abbiamo cambiato approccio. 5bbiamo riconosciuto !i essereancora legati ai test !i regressione manuale, e! abbiamo piuttosto iniiatoa chie!erci C1ome facciamo a ren!ere piE rapi!i i test manuali9D.5vevamo a che fare con un sistema !i giochi, e! abbiamo capito che buona parte !el tempo !el team veniva speso a! eseguire !elle attivit piuttosto banali !i iniialiaione, come il trafficare con il back office per iniialiare i tornei allo scopo !i eseguire i test, o lo stare a! aspettarel2iniio !i un torneo programmato. >uin!i abbiamo messo a punto !elle proce!ure a! hoc. Piccoli shortcut facilmente accessibili e qualche scriptche facesse il lavoro !i bassa manovalana lascian!o i tester !avveroconcentrati a fare i test.

>uesto sforo ha pagato !avvero$ 3nfatti, " quello che probabilmente



B R S1*%8 P +5@@ J*3K1

avremmo !ovuto fare fin !all2iniio. ravamo cos4 impaienti !iautomatiare i test che abbiamo !imenticato !i farlo un passo per volta,!ove il primo passo era fare quanto necessario per ren!ere innanitutto i

test manuali piE efficienti.0ezione im#arata? se resti bloccato sui test !i regressione manuali, evorresti passare !i colpo a! automatiarli, non farlo (a meno che questonon sia veramente semplice). Piuttosto, fa2 quello che serve per ren!ere piE facili i test !i regressione manuali. uccessivamente pren!i inconsi!eraione il voler automatiare !el tutto l2attivit !i test.

Design incrementale>uesto significa mantenere il !esign semplice !all2iniio e migliorarlocontinuamente, anich7 cercare !a subito !i fare tutto CgiustoD e poiconsoli!arlo.

+a questo punto !i vista !irei che stiamo proce!en!o piuttosto bene, cio"spen!iamo una quantit !i tempo ragionevole a fare refactoring e amigliorare il !esign esistente, e raramente ne spen!iamo a fare big up- front design. Nvviamente a volte ci costa qualche errore, come il

permettere a scelte !i !esign traballanti !i restare l4 troppo a lungo, tantoche il refactoring stesso finisce per !iventare un gran!e progetto a s7stante. 8a tutto sommato siamo piuttosto so!!isfatti.

1ontinuare a migliorare il !esign " il piE !elle volte un effetto collateraleautomatico !el fare J++.

2ontinuous integration

3l setup !i molti !ei nostri pro!otti " gestito attraverso sistemi !icontinuous integration piuttosto sofisticati, basati su 8aven e >uickFuil!.@a cosa " !i estremo valore e fa risparmiare tempo. la soluione!efinitiva alla vecchia storia !el Chi ma sul mio P1 funionaD. 3 nostriserver !i continuous build fungono !a Cgiu!iceD, o punto !i riferimento, per !eterminare lo stato !i salute !i tutto il nostro co!ice.Ngni volta che qualcuno fa un check in, il server !i continuous build sirisveglia, compila tutto !a ero su un server con!iviso e! esegue tutti itest. Se qualcosa va storto viene spe!ita una email che notifica a tutto ilteam che il buil! " an!ato in errore, inclu!en!o tutte le informaioni suquale cambiamento !i co!ice ha rotto il buil!, un link ai report !ei test, ecos4 via.

Ngni notte il server !i continuous build riesegue il buil! !el pro!otto !a



1N8 1N8F3K358N S1*%8 1NK P R '

capo e pubblica i files binari (ear, #ar, etc.), la !ocumentaione, i reportsull2esito !ei test e sul loro gra!o !i copertura, sulle !ipen!ene, etc, tuttoverso il nostro portale !i !ocumentaione interno. 5lcuni pro!otti

vengono anche automaticamente deplo&ati su un ambiente !i test. 8etteresE tutto questo ha richiesto molto lavoro, ma ne " valsa la pena finoall2ultimo minuto.

.ropriet? colletti7a del codice

3ncoraggiamo la propriet collettiva !el co!ice ma non tutti i team l2hannoancora a!ottata. 5bbiamo realiato che il pair programming con unafrequente rotaione !elle coppie porta automaticamente a! un alto livello!i propriet collettiva !el co!ice. 3 team con un alto livello !i propriet

collettiva !el co!ice si sono !imostrati molto robusti. +a loro non ci sonosprint che muoiono perch7 qualche persona chiave " malata.

or+space in/ormati7oJutti i team hanno accesso a lavagne e spai vuoti su !elle pareti e nefanno un buon uso. 3n molte aree si possono trovare pareti tappeate !itutti i tipi !i informaioni sul pro!otto e sul progetto. 3l maggiore problema sono le cose vecchie che vi si accumulano, !ovremmo

intro!urre il ruolo !i CripulitoreD in ogni team.3ncoraggiamo l2uso !ella taskboar!, ma non tutti i team l2hanno ancoraa!ottata. Me!i pg. =& C1ome organiiamo l2area !el teamD.

2oding standard%ltimamente abbiamo iniiato a !efinire uno stan!ar! per lo stile !elco!ice. 8olto utile, magari l2avessimo fatto prima. Kon richie!e affattotempo, basta una prima semplice stesura, e poi cresce !a s7. 12" solo !a

scrivere un po2 !i cose che non sono ovvie a tutti e mettere !ei link almateriale esistente quan!o " possibile.

8olti programmatori hanno un proprio !iverso stile nella scrittura !elco!ice. Piccoli !ettagli come il mo!o !i gestire le ecceioni, il mo!o !icommentare il co!ice, quan!o restituire un valore null, etc. 3n alcuni casila !ifferena non ha importana, mentre in altri puA portare a! un !esigngravemente inconsistente e a co!ice !ifficile !a leggere. %no stan!ar! perla scrittura !el co!ice " molto utile in questo caso, purch7 ci si continui a

focaliare sulle cose che contano.

cco alcun esempi !al nostro code standard :



= R S1*%8 P +5@@ J*3K1

• Puoi violare ognuna !i queste regole, ma sii sicuro !i avere unvali!o motivo per farlo, e !ocumentalo.

• %sa !i !efault le convenioni raccoman!ate !a Sun:

http://`ava.sun.com/!ocs/co!econv/html/1o!e1onvJN1.!oc.html• Kon intercettare mai, nella maniera piE assoluta, le ecceioni

sena scrivere sul log lo stack trace, o rilancian!ole. %nlog.!ebug() va bene, basta non per!ere lo stack trace.

• 3nietta le !ipen!ene !a altre classi attraverso i setter per ren!erele classi meno !ipen!enti l2una !all2altra (a meno che,ovviamente, questa !ipen!ena non sia !esi!erabile).

• vita le abbreviaioni. %na abbreviaione nota, come +5N, va bene.

• 3 meto!i che restituiscono colleioni o arra non !evono restituirenull. 3n tal caso restituire invece colleioni e! arra vuoti.

.ace sostenibilePla7oro energi--ato3n molti !ei libri sullo sviluppo agile si sostiene che lavorare oltre l2orariosia contropro!ucente nello sviluppo !el soft#are.

+opo aver malvolentieri sperimentato su questo aspetto non posso farealtro che con!ivi!ere nella maniera piE assoluta$

1irca un anno fa uno !ei nostri team (quello piE gran!e) stava facen!ouna quantit folle !i straor!inari. @a qualit !ella code base era!eprimente e la maggior parte !el tempo veniva spesa a rincorrere leurgene. 3l team !i test (che a sua volta si tratteneva oltre il normale orario!i lavoro) non riusciva a !are una seria garania !i qualit. 3 nostri utentierano arrabbiati la stampa ci stava mangian!o vivi.

+opo pochi mesi abbiamo fatto in mo!o !a abbassare le ore !i lavoro a!un livello !ecente. Si lavorava il giusto numero !i ore (salvo quan!o nel progetto, qualche volta, c2erano !elle !ifficolt). @a sorpresa " stata che la pro!uttivit e la qualit sono aumentate notevolmente.

Katuralmente, ri!urre le ore !i lavoro extra non " stato affatto l2unicoaspetto alla base !i questi miglioramenti, ma siamo convinti che abbia in buona parte contribuito.



1N8 1N8F3K358N S1*%8 1NK P R G

6=2ome /acciamo i test

>uesta " la parte piE ostica. Kon sono sicuro se sia la parte piE ostica !iScrum, o semplicemente !ello sviluppo soft#are in generale.

3l testing " quella parte che probabilmente varia !i piE tra le !ifferentiorganiaioni. +ipen!e !a quanti tester ci sono, !a quanto "automatiata la parte !i test, !al tipo !i sistema (hai solo un server conuna applicaione #eb9 Nppure ven!i un soft#are a scatola chiusa9), !alla!urata !ei cicli !i rilascio, !alla criticit !el soft#are (gestione !i blogoppure un sistema !i controllo !i volo), etc.

5bbiamo sperimentato a lungo su come fare i test in Scrum. 1ercherA !i!escrivere cosa abbiamo fatto e cosa abbiamo imparato fin2ora.

.robabilmente non si puB /are a meno della/ase dei test di accetta-ione

Kel mon!o i!eale !i Scrum, il risultato !i uno sprint " una versione che si puA potenialmente mettere in pro!uione. >uin!i basta fare un deplo&,

giusto9

Scrum team

release

3tenti finali

0..



6 R S1*%8 P +5@@ J*3K1

Sbagliato.

Secon!o la nostra esperiena, questo !i solito non funiona. 3 bug sonosempre in agguato. Se vuoi !are valore alla qualit, una qualche fase !itest !i accettaione manuali " necessaria. Significa che !ei tester !e!icatiche non fanno parte !el team bombar!ano il sistema con quei tipi !i test acui il team Scrum team non avrebbe potuto pensare, o non ne ha avuto iltempo, o non c2era l2har!#are necessario. 3 tester acce!ono al sistemaesattamente come vi acce!ono gli utenti finali, il che significa che questitest !evono essere fatti manualmente (se stiamo parlan!o !i un sistema

in!iriato a! utenti umani).

3l team !ei tester trover !ei bug, il team Scrum !ovr fare !elle bug-fi"

release, e prima o poi (si spera prima) sar in gra!o !i rilasciare unaversione comprensiva !el bug-fixing &..& agli utenti finali, a sostituione!ella instabile versione &...

>uan!o !ico Cfase !i test !i accettaioneD mi riferisco all2intero perio!o !itest, !ebugging, e ulteriore rilascio fino a! avere una versione

sufficientemente buona per la messa in pro!uione.

1inimi--are la /ase di test di accetta-ione@a fase !ei test !i accettaione " !olente. chiaramente percepita comenon-agile. 5nche se non possiamo farne a meno, possiamo (e lofacciamo) cercare !i minimiarla. PiE specificamente, minimiiamo laquantit !i tempo necessario per questa fase. Kel seguente mo!o:

• massimian!o la qualit !el co!ice rilasciato !al team Scrum

•

massimian!o l2efficiena !ei test manuali (cio7 cerchiamo itester migliori, forniamo loro gli strumenti migliori, verifichiamoche ci abbiano in!icato tutte le attivit che portano via tempo eche potrebbero essere automatiate)

%est teamScrum team

release

3tenti finali0..

release

release

0..0

0..0



1N8 1N8F3K358N S1*%8 1NK P R

>uin!i come massimiiamo la qualit !el co!ice rilasciato !ai teamScrum9 Fe2, ci sono !iversi mo!i. ccone !ue che abbiamo scopertofunionare molto bene:

• Oar entrare i tester nel team Scrum• Oare meno cose in ogni sprint

Aumentare la qualit? /acendo entrare dei testernel team )crum

gi sento le vostre obieioni:• C8a questo " ovvio$ Si presuppone che i

team Scrum siano cross functional $D

• CKei team Scrum non ci sono ruoli$ Kon possiamo avere uno che fa solo il tester$D

Per chiarire. >uello che inten!o per CtesterD in questo caso " Cuna personaspecialiata innanitutto nel fare i testD, e non Cuno il cui compito " faresolo testD.

Qli sviluppatori sono spesso scarsi come tester, soprattutto quan!o testanoil loro co!ice.

Il tester : il Csignor no=

Nltre a! essere un semplice membro !el team, il tester ha un compitoimportante. quello che !eci!e per ultimo. Kiente viene consi!erato

CfinitoD nello sprint finch7 non lo !ice lui. Io notato che spesso glisviluppatori !icono che una cosa " finita quan!o in realt non lo ". Puressen!oci una chiara !efiniione !i CfinitoD (che effettivamente !ovrebbeesserci, ve!i pg. <' C!efiniione !i 2finito2D), gli sviluppatori spesso se ne!imenticano. Koi programmatori siamo persone impaienti e vogliamo pren!ere in carico al piE presto possibile le restanti attivit.

8a allora come fa il Signor J. (il nostro tester) a sapere che una cosa "CfinitaD9 Fe2, prima !i tutto !ovrebbe (sopresa$) testarla. 3n molti casi

viene fuori che una cosa consi!erata CfinitaD !allo sviluppatore, non si puA nemmeno testare$ Perch7 non ne " stato fatto il check-in, o non " statarilasciata sul server !i test, o non si riesce a farla partire, e via!iscorren!o. >uan!o il Signor J. testa la funionalit, !ovrebbe ripassare

B Csign off guD in originale K!J



& R S1*%8 P +5@@ J*3K1

la checklist associata a CfinitoD (se esiste) con lo sviluppatore. Peresempio, se la !efiniione !i CfinitoD preve!e una nota !i rilascio, allora ilSignor J. verifica che esista una nota !i rilascio. Se c2" un qualche tipo !i

specifica formale per una certa funionalit (cosa rara, nel nostro caso)allora il Signor J. verifica anche questo, e cos4 via.

%n gra!ito effetto collaterale !i ciA " che il team ora ha una persona perfettamente in!icata per organiare la sprint !emo.

2osa /a il tester quando non c9: niente da testare;

>uesta !oman!a continua a saltar fuori. Signor J: Chi Scrum master,

non c2" niente !a testare al momento, quin!i cosa " che !ovrei fare io9D.Potrebbe passare una settimana prima che il team completi la prima storia,e allora cosa !ovrebbe fare il tester nel frattempo9

Fene, prima !i tutto, !ovrebbe prepararsi per i test . Nvvero scriverne lespecifiche, preparare un ambiente !i test, etc. 1os4 quan!o unosviluppatore avr qualcosa !i pronto !a testare, non ci sar !a aspettare.8r.J potr subito lanciarsi con i test.

Se il team lavora in J++ allora si comincia a scrivere i test fin !al primogiorno. 3l tester !ovrebbe fare pair programming con gli sviluppatori chescrivono i test. Se il tester non sa affatto programmare !ovrebbecomunque fare pair programming con gli sviluppatori, salvo il fatto che ilsuo ruolo in questo caso si limiter a quello !i navigatore, mentre losviluppatore " alla tastiera.5! un buon tester normalmente vengono in mente !iversi tipi !i test,rispetto a! un buon programmatore, quin!i si completano a vicen!a.Se il team non fa J++, o non vi sono casi !i test a sufficiena !a poterriempire il tempo a !isposiione !el tester, allora !ovrebbe semplicementefare qualunque cosa gli sia possibile fare per raggiungere l2obiettivo !ellosprint, esattamente come ogni altro membro !el team. Se il tester " ingra!o !i programmare allora " ottimo. Se no, il team !ovr riuscire a!i!entificare tutte le attivit non !i programmaione necessarie allo sprint.

Kel su!!ivi!ere le storie in task !urante lo sprint planning meeting, ilteam ten!e a focaliarsi su attivit di programmazione. 1omunque !isolito ci sono molte attivit non di programmazione !a fare !urante losprint. Se viene !e!icato un po2 !i tempo a cercare !i identificare attivit

non di programmazione !urante la fase !i sprint planning, c2" la possibilit per il Sig. J !i !are un buon contributo, pur non essen!o ingra!o !i programmare e non essen!oci test !a fare nell2imme!iato.



1N8 1N8F3K358N S1*%8 1NK P R &&

sempi !i attivit non !i programmaione che spesso c2" bisogno !i fare!urante uno sprint:

•

3nstallare un ambiente !i test.• 1hiarire i requisiti.

• +iscutere con il reparto sistemistico i !ettagli relativi alla messain pro!uione.

• Scrivere i !ocumenti !i rilascio (note !i rilascio, *O1, cose !elgenere previste !all2aien!a).

• Jenere contatti con risorse esterne (!isegnatori !i Q%3 peresempio).

•

8igliorare gli script !i buil!.• Oare ulteriori su!!ivisioni !i storie in task.

• 3!entificare le questioni chiave che giungono !agli sviluppatori e!are loro una risposta.

5ll2estremo opposto, cosa si fa se il Sig. J. !iventa lui il collo !i bottiglia9Poniamo !i trovarci all2ultimo giorno !ello sprint. 3mprovvisamente molte!elle attivit risultano terminate e il Sig. J. non puA testarle tutte. 1osafacciamo9 3nnanitutto si potrebbe convertire tutto il team in un gruppo !iassistenti !el Sig. J. @ui !eci!e cosa fare, e !elega la parte !i test piE !iroutine al resto !el team. 3n fon!o " questo ciA che si inten!e per teamcross functional $

>uin!i s4, il Sig. J. ha un ruolo speciale nel team, ma puA sempreoccuparsi !i altro, e! allo stesso tempo tutti gli altri membri !el team possono fare il suo lavoro.

Aumentare la qualit? /acendo meno nellosprint

>uesto ci riman!a allo sprint planning meeting. Per !irla in breve, noninfilare troppe storie nello sprint$ Se ci sono problemi !i qualit o cicli !itest !i accettaione molto lunghi, fare meno in ogni sprint$ >uesto porterautomaticamente a! una maggiore qualit, a cicli piE brevi !i test !iaccettaione, meno bug sugli utenti finali, e maggiore pro!uttivit nellungo perio!o, !al momento che il team potr focaliarsi sulle nuove

cose tutto il tempo anich7 !over aggiustare cose vecchie che continuanoa rompersi.

quasi sempre meno costoso fare un po2 !i meno, ma che sia stabile,



&; R S1*%8 P +5@@ J*3K1

anich7 implementare un sacco !i cose e poi !over fare !egli hot-fix inemergena.

La /ase dei test di accetta-ione do7rebbe /arparte dello sprint;

Su questo un po2 tentenniamo. 5lcuni !ei nostri team inclu!ono i test !iaccettaione nello sprint. 8olti !ei nostri team invece no, per !ue motivi:

• Qli sprint hanno una !urata prefissata. @a fase !ei test !iaccettaione (che seco!o la mia !efiniione inclu!ono lacorreione !ei bug e l2ulteriore rilascio) sono molto !ifficili !a farrientrare in un time-box. 1osa si fa se si sfora coi tempi e ci sonoancora !ei bug critici9 Si rilascia in pro!uione con un bugcritico9 Si aspetta il prossimo sprint9 3n molti casi entrambe lesoluioni sono inaccettabili. >uin!i lasciamo la fase !ei test !iaccettaione manuali fuori !allo sprint.

• Se a lavorare sullo stesso pro!otto ci sono piE team Scrum, lafase !ei test !i accettaione manuali !eve essere fatta sul risultato!el lavoro combinato !i tutti questi team. 5nche se ogni team ha

fatto i test !i accettaione manuali nel suo sprint, c2" comunque bisogno !i un team che testi la versione finale, che "l2integraione !i quanto pro!otto !a tutti i team.

Kon " certo una soluione perfetta ma per noi " abbastana buona in molticasi.



1N8 1N8F3K358N S1*%8 1NK P R &<

2icli di sprint 7s$ cicli di test di accetta-ione

Kel perfetto mon!o 8cScrum non c2" bisogno !i fasi !i test !iaccettaione, !ato che ogni team Scrum rilascia una nuova versione !elsistema pronta per la pro!uione alla fine !i ogni sprint.

Fe2, ecco un qua!ro piE realistico:

+opo lo sprint &, una versione bacata &.. viene rilasciata. +urante losprint ;, i bug report iniiano a! arrivare e il team passa la maggior parte

Sprint 0

%imeline

0..

Sprint 2

? 3 G J

? 3 G J

0..0 0.0.

3tenti finali

Sprint 0

%imeline

0..

Sprint 2

0.0.

3tenti finali



&B R S1*%8 P +5@@ J*3K1

!el tempo a !ebuggare e si ritrova a !over rilasciare una versione &..& priva !i bug a met sprint. >uin!i alla fine !ello sprint ; viene rilasciatauna nuova versione &.&., che naturalmente sar ancora piE bacata !al

momento che il team avr avuto ancora meno tempo !i farla per bene, !atitutti i fattori !i !isturbo ere!itati !ella release prece!ente. tc. etc.

@e linee rosse !iagonali nello sprint ; simboliano il caos.

Kon " molto simpatico eh9 Fe2, la cosa triste " che il problema permaneanche aven!o team per i test !i accettaione. l2unica !ifferena " che molti!ei bug report arrivano !al team !i test anich7 !a utenti finali arrabbiati.12" una immensa !ifferena !al punto !i vista !el business, ma per gli

sviluppatori cambia poco. ccetto il fatto che i tester !i solito sono menoaggressivi !egli utenti finali. +i solito.

Kon abbiamo trovato alcuna soluione semplice a questo problema.5bbiamo sperimentato molto con !iversi mo!elli.

Prima !i tutto, ancora, massimian!o la qualit !el co!ice che il teamScrum rilascia. 3l costo !el trovare e correggere i bachi prima, !urante losprint, " !avvero molto piE basso rispetto a quello !i scoprirli ecorreggerli !opo.

8a la questione resta. 5nche se possiamo minimiare il numero !i bug,arriveranno sempre bug report !opo la fine !ello sprint. 1ome farvifronte9

Sprint 0

%imeline

0..

Sprint 2

? 3 G J

? 3 G J

0..0 0.0.

0. &cceptance test

3tenti finali

0..0

0.0 &cceptance test



1N8 1N8F3K358N S1*%8 1NK P R &'

Approccio 6! CNon /are cose nuo7e /inc8 quelle7eccie non sono entrate in produ-ione

Suona bene, no9 1i si sente un filo !i piE a proprio agio cos49

Siamo an!ati vicini a! a!ottare questo approccio !iverse volte, e abbiamo!isegnato !egli splen!i!i !iagrammi su come lo avremmo fatto.1omunque cambiavamo sempre i!ea quan!o ci ren!evamo conto !eglisvantaggi. 5vremmo voluto aggiungere !ei perio!i !i tempo non Ctime- boxe!D tra uno sprint e l2altro, in cui avremmo fatto solo test e !ebuggingfinch7 non si riuscisse a realiare una versione pronta per an!are in pro!uione.

Kon ci piaceva perA l2i!ea !i avere perio!i non time-boxe! tra gli sprint, principalmente perch7 questo avrebbe speato il battito regolare !eglisprint. Kon avremmo potuto piE !ire Cogni tre settimane iniiamo unnuovo sprintD. 3noltre, questo non avrebbe risolto il problema. 5nche

aven!o un perio!o !i rilascio, i bug report urgenti arrivano comunque !itanto in tanto, e bisogna essere preparati a! affrontare questa eveniena.

Approccio #! C'a bene ini-iare nuo7i s7iluppi4 ma lapriorit? : quella di mettere in produ-ione le cose

7eccie

>uesto " il nostro approccio preferito, almeno per a!esso.

ssenialmente, quan!o finiamo uno sprint siamo subito operativi suquello successivo, ma ci aspettiamo !i !over spen!ere un po2 !i tempo !elnuovo sprint per correggere i bug !i quello prece!ente. Se questo nuovosprint risultasse seriamente compromesso perch7 abbiamo !ovutospen!ere troppo tempo per queste correioni, valutiamo perch7 siasuccesso questo e come possiamo migliorare la qualit. 1i assicuriamoche la !urata !egli sprint sia sufficiente a farci rientrare abbastana bugfixing !ello sprint prece!ente.

Qra!ualmente, su un perio!o !i !iversi mesi, il tempo totale speso acorreggere i bug !ello sprint prece!ente !iminuiva. 3noltre siamo arrivatia poter coinvolgere sempre meno persone quan!o questi bug venivano



&= R S1*%8 P +5@@ J*3K1

fuori, e quin!i non " stato piE necessario interrompere ogni volta tutto ilteam. Nra siamo a! un livello piE accettabile.

+urante gli sprint planning meeting fissiamo un focus factor abbastana

basso !a tener conto !el tempo che ci aspettiamo !i spen!ere persistemare i bug !ello sprint prece!ente. Kel corso !el tempo, i team sono!iventati bravi a fare questa stima. @e metriche per la misuraione !ellavelocit aiutano molto (ve!i pag. ;< C+eci!ere quali storie inclu!ere nellosprintD).

Un approccio sbagliato 3 C/ocali--arsi sulle cosenuo7e

>uesto in pratica significa Cpuntare a fare cose nuove anziché mettere le

cose vecchie in produzione”. 1hi mai potrebbe volere questo9 5bbiamogi fatto questo sbaglio, molte volte, all2iniio, e sono sicuro che moltealtre aien!e lo facciano. una patologia correlata allo stress. 8oltimanager !avvero non capiscono che, quan!o tutto il co!ice " terminato,normalmente siamo ancora lontani !a una versione !i pro!uione, almenoquan!o si tratta !i sistemi complessi. >uin!i il manager (o il pro!ucto#ner) chie!e al team !i continuare a! aggiungere nuove cose finch7 lamassa !i tutto il co!ice quasi-pronto-per-la-pro!uione non !iventa cos4 pesante !a rallentare tutto il resto.

Non andare pi 7eloce dell9anello pi lentodella catena

Supponiamo che la fase !ei test !i accettaione sia l2anello piE lento !itutta la catena. 3 tester sono troppo pochi, o il perio!o per i test !iaccettaione si allunga a causa !i un co!ice !i infima qualit.

Supponiamo anche che il nostro team !e!icato ai test !i accettaione siain gra!o !i testare al piE tre funionalit alla settimana (no, non usiamouna metrica chiamata Cfunionalit per settimanaDX la sto solo usan!o



1N8 1N8F3K358N S1*%8 1NK P R &G

come esempio). 5ssumiamo, infine, che gli sviluppatori siano in gra!o !irilasciare sei nuove funionalit alla settimana.

Sarebbe allettante per i manager o i pro!uct o#ner (o anche per l2interoteam) l2i!ea !i pianificare lo sviluppo !i sei nuove funionalit allasettimana. Kon fatelo$ 3n un mo!o o nell2altro ci si scontrer comunque con la realt,e far male.

Piuttosto, pianificare tre nuove funionalit alla settimana e impiegare ilresto !el tempo a ri!urre il collo !i bottiglia rappresentato !ai test. Peresempio:

• +e!icare piuttosto alcuni sviluppatori a fare i test (ah s4, via!oreranno per questo...)

• 3mplementare strumenti e script che ren!ano piE facile fare i test.• 5ggiungere piE co!ice per l2automaione !ei test.• 5umentare la !urata !egli sprint e! inclu!ervi la fase !ei test !i

accettaione.

• +efinire alcuni sprint come Ctest sprintD nei quali l2intero teamlavori come un acceptance test team.

•

5ssumere altri tester (anche se questo !ovesse significarerimuovere !egli sviluppatori)

5bbiamo provato tutte queste soluioni (eccetto l2ultima). @a miglioresoluione sul lungo perio!o " naturalmente quella !ata !ai punti ; e <,cio" migliori strumenti e script, e automatiaione !ei test.

@e retrospettive sono un buon forum !i !iscussione per i!entificare

l2anello piE lento !ella catena.

Ritorno alla realt?

Probabilmente ho !ato l2impressione che abbiamo !ei tester in tutti i nostriteam, che abbiamo un gran!e team per i test !i accettaione per ogni pro!otto, che facciamo un rilascio alla fine !i ogni sprint, etc, etc.

Fe2, in realt no.

,alvolta ci siamo organiati in questo mo!o, e ne abbiamo riscontratoeffetti positivi, ma siamo ancora lontani !a un processo accettabile !iqualit& assurance, e su questo abbiamo ancora molto !a imparare.



&6 R S1*%8 P +5@@ J*3K1



6&2ome organi--iamo team )crum multipli

8olte cose sono piE !ifficili quan!o piE team Scrum lavorano sullo stesso pro!otto. 3l problema " universale e non ha assolutamente niente a cheve!ere con Scrum. PiE sviluppatori V piE complicaioni.

5bbiamo (come sempre) sperimentato anche su questo. 5l massimoabbiamo avuto un team !i circa quaranta persone sullo stesso pro!otto.

@e questioni chiave sono:• >uanti team mettere in pie!i• 1ome allocare le persone nei team

@uanti team mettere in piedi

Se avere a che fare con piE team " cos4 !ifficile, perch7 scomo!arsi9Perch7 non mettere semplicemente tutti nello stesso team9

3l piE numeroso team Scrum che abbiamo avuto era uno !i circa un!ici

persone. Ia funionato, ma non cos4 bene: !ail scrum che ten!evano atrascinarsi per piE !i quin!ici minuti, membri !el team che non sapevanocosa stessero facen!o gli altri, insomma un po2 !i confusione. ra !ifficile per lo Scrum master tenere tutti allineati su un obiettivo, e! era !ifficiletrovare il tempo !i risolvere tutti gli ostacoli segnalati.

@2alternativa sarebbe stata quella !i !ivi!ere il team in !ue. 8a in questomo!o si migliora9 Kon " !etto.

Se il team ha esperiena e si trova a suo agio con Scrum, e c2" un mo!oraionale !i !ivi!ere la roadmap su !ue binari che non va!ano a!impattare la stessa code base, !irei che " una buona i!ea !ivi!ere il team.5ltrimenti consi!ererei il restare su un team unico, nonostante glisvantaggi !ei team numerosi.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &&&

@a mia esperiena " che " meglio avere meno team magari un po2numerosi piuttosto che molti team piE piccoli che si ostacolano tra loro.

Fisogna fare !ei team piccoli solo quan!o il lavoro !ell2uno noninterferisce con quello !ell2altro$

Team 7irtuali

1ome si fa a sapere !i aver preso la !ecisione corretta o quella sbagliatatra Cun solo team numerosoD e CpiE team, ma meno numerosiD9

5pren!o bene gli occhi e le orecchie, si puA notare la formaione !i YteamvirtualiY.

1sem#io %? viene scelta la formula !i un unico gran!e team, ma quan!o sive!e chi parla con chi !urante lo sprint, ci si puA ren!ere conto che il teamsi " in realt !iviso in !ue sub-team.

1sem#io 2? si sceglie !i avere tre team piE piccoli. Poi si osserva un po2meglio chi parla con chi !urante lo sprint, e viene fuori che il primo e il

secon!o team si parlano spesso, mentre il tero team lavora in mo!o piEisolato.



&&; R S1*%8 P +5@@ J*3K1

1osa significa9 1he la strategia !i !ivi!erli " stata sbagliata9 S4, se questaconfiguraione in team virtuali sembra essere in qualche mo!o permanente. Ko, se i team virtuali, a quanto pare, sono solo temporanei.

Jorniamo all2esempio &. Se i !ue sub-team ten!ono a cambiare una voltaogni tanto (cio" le persone si spostano tra i sub-team virtuali) allora probabilmente la !ecisione !i avere un singolo team Scrum " statacorretta. Se i !ue sub-team virtuali rimangono gli stessi !urante l2interosprint, sar probabilmente piE appropriato su!!ivi!erli in !ue team Scrumveri e propri al prossimo sprint.

Nra guar!iamo !i nuovo l2esempio ;. Se il team & e il team ; si parlano tra

loro (ma non con il team <) !urante l2intero sprint, probabilmente sar ilcaso !i combinare i team & e ; in un unico team Scrum al prossimo sprint.Se il team & e il team ; si parlano molto !urante la prima met !ellosprint, poi il team & e il team < si parlano !urante la secon!a met !ellosprint, allora bisogna consi!erare il combinare tutti e tre i team in uno, olasciarli come sono !ivisi in tre team. Sollevare la questione !urante laretrospettiva !ello sprint e lasciare la !ecisione ai team stessi.

@a !ivisione in team " una !elle parti veramente !ifficili !i Scrum. 8eglio

non stare a pensarci cos4 nel !ettaglio o a! ottimiare troppo. 12" !asperimentare, !are un occhio ai team virtuali, e! essere sicuri !i aver!e!icato abbastana tempo a questo tipo !i cose !urante le retrospettive.Prima o poi si trover la soluione giusta per la propria situaione particolare. @a cosa importante " che i team si sentano a proprio agio enon si intralcino troppo spesso l2un l2altro.

La dimensione ottimale di un team

3n molti !ei libri che ho letto si !ice che la !imensione CottimaleD !i unteam " qualcosa tra le ' e le persone.

+a quello che ho visto fin2ora non posso che essere !2accor!o, anche se ioavrei !etto < - 6 persone. 3nfatti, cre!o che valga la pena fare anche scelte!ifficili pur !i mantenere !imensioni !i questo tipo.

5ven!o un singolo team Scrum !i & persone consi!erare anche l2i!ea !isbaraarsi !ei !ue componenti piE scarsi. Nps, ho proprio !etto questo9

Supponiamo !i avere !ue pro!otti !ifferenti, con team !i tre persone per pro!otto, che stanno an!an!o troppo lentamente. %otrebbe essere una buona i!ea quella !i combinarli insieme in un unico team !i = personeresponsabile !i entrambi i pro!otti. 3n tal caso bisogna tener fuori uno !ei



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &&<

!ue pro!uct o#ner (oppure !argli un ruolo !i consulente o qualcosa !elgenere).

Supponiamo !i avere un singolo team !i &; persone, e che il co!ice siamesso cos4 male che non ci sia mo!o !i farci lavorare !ue team !iversi

in!ipen!entemente. Fisogna !e!icarsi seriamente a mettere a posto lacode base (anich7 implementare nuove funionalit) finch7 non si arrivial punto !i poter !ivi!ere il team. probabile che l2investimento verrripagato abbastana rapi!amente.

)print sincroni--ati o no;

Supponiamo !i avere tre team scrum sullo stesso pro!otto. 3 loro sprint

!ovrebbero essere sincroniati, cio" iniiare e finire insieme9 N!ovrebbero accavallarsi9

3l nostro primo approccio " stato l2avere sprint accavallati (rispetto altempo).



&&B R S1*%8 P +5@@ J*3K1

Suonava bene. 3n qualunque momento ci sarebbero stati uno sprint incorso quasi al termine e! un altro pronto per partire. 3l carico !i lavoro peril pro!uct o#ner si sarebbe equamente !istribuito nel tempo. 1i sarebbe

stato un flusso continuo !i rilasci !a parte !el sistema. +emo ognisettimana. 5lleluia.

h s4, mi sembrava davvero convincente al momento$

5vevamo appena iniiato a fare in questo mo!o finch7 un giorno non ebbil2opportunit !i parlarne con Ten Sch#aber (in occasione !ella miacertificaione Scrum). 8i fece notare che era una cattiva i!ea, chesarebbe stato molto meglio sincroniare gli sprint. Kon ricor!o la sua

precisa motivaione ma !opo qualche !iscussione mi convinsi.

>uesta " la soluione che !a allora continuiamo a! utiliare, e non me nesono mai pentito. Kon potrA mai sapere se la strategia !i accavallare glisprint sarebbe fallita, ma penso !i s4. 3l vantaggio !ell2avere !egli sprintsincroniati ":

• 12" un momento che ca!e in mo!o naturale per riorganiare iteam - tra gli sprint$ 1on sprint accavallati, invece, non c2" mo!o!i riorganiare i team sena !isturbare almeno un team a metsprint.

• Jutti i team hanno la possibilit !i lavorare per lo stesso

obiettivo in uno sprint e !i fare gli sprint planning meetinginsieme, il che porta a! una migliore collaboraione tra i team.• 8eno overhead amministrativo, cio" meno sprint planning

meeting, sprint !emo e rilasci.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &&'

.erc8 abbiamo introdotto il ruolo del Cteamlead

Supponiamo !i avere un singolo pro!otto con tre team.

@a persona in rosso etichettata 2P2 " il Pro!uct N#ner. >uelli in nero conl2etichetta 2S2 sono gli Scrum 8aster. 3 restanti sono reclute... ehm... !eirispettabili membri !ei team.

+ata questa costellaione, chi !eci!e chi fa parte !i quale team9 3 tre

Scrum master insieme9 Nppure ogni persona sceglie il proprio team9 8aallora che succe!e se tutti vogliono stare nel team & (magari perch7 loScrum 8aster " una persona cos4 attraente)9

Potrebbe venir fuori che non " proprio possibile far lavorare piE !i !ueteam in parallelo sulla stessa code base, e che quin!i ci sia bisogno !imo!ificare la configuraione in !ue team !a persone anich7 tre team !a= persone. >uesto significa !ue Scrum master. 5llora a quale !ei treScrum master sar tolto il suo ruolo9

3n molte aien!e queste cose possono essere abbastana !elicate.

@a tentaione " !i lasciare che sia il pro!uct o#ner a! occuparsi!ell2allocaione e !ello spostamento !elle persone. Juttavia questa non "esattamente una cosa !a pro!uct o#ner, giusto9 3l pro!uct o#ner "l2esperto !i !omino che !ice al team che !ireione pren!ere. Kon!ovrebbe essere affatto coinvolto nei !ettagli particolari, soprattutto !almomento che " un CchickenD (avrete gi sentito parlare !ella metafora !ei

polli e !ei maiali, altrimenti cercate su google Cchickens an! pigsD).

Koi questo lo abbiamo risolto intro!ucen!o il ruolo !el Cteam lea!D. 3lcorrispon!ente !i quello che si potrebbe chiamare CScrum 8aster !eglialtri ScrumD o Cil bossD o lo CScrum master superioreD etc. Kon !eve fare



&&= R S1*%8 P +5@@ J*3K1

!a gui!a a nessun singolo team, ma " responsabile !elle questioni cross-team come: chi saranno gli Scrum master !ei team, come le personesaranno !ivise in team, etc.

stata un po2 !ura farci venire in mente un nome vali!o per questo ruolo.CJeam lea!D " stato il meno peggio che siamo riusciti a trovare.

>uesta soluione ha funionato bene per noi e la raccoman!erei (a parte ilnome).

2ome distribuiamo le persone tra i team1i sono !ue strategie generali per !istribuire le persone tra i team, quan!o piE team sono sullo stesso pro!otto.

• %na persona viene incaricata !ell2allocaione, per esempio ilCteam lea!D appena menionato, il pro!uct o#ner, o il functionalmanager (se " coinvolto abbastana !a poter fare !elle buonescelte su questo)

• @asciare che i team facciano in qualche mo!o !a soli.

@e abbiamo sperimentate tutte e tre. Jre9 Qi. @a Strategia &, la Strategia; e! una combinaione !i entrambe.

Per noi la combinaione !i entrambe " quella che funiona meglio.

Prima !ello sprint planning meeting, il team lea! si occupa !i organiareun meeting, a cui partecipano il pro!uct o#ner e tutti gli Scrum master,che ha come argomento l2allocaione.

+iscutiamo !ell2ultimo sprint e verifichiamo se c2" la garania !i poterfare qualche riallocaione tra i team. 8agari vogliamo unire !ue team, ospostare alcune persone !a un team all2altro. +eci!iamo qualcosa e buttiamo giE una nota !i proposta di allocazione dei team, che portiamocon noi allo sprint planning meeting.

@a prima cosa che facciamo !urante lo sprint planning meeting " una!isamina !egli item !i massima priorit !el pro!uct backlog. >uin!i ilteam lea! !ice qualcosa come CSalve a tutti. Koi proponiamo !i allocarele persone nei team come segue al prossimo sprint.D



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &&G

C1ome potete ve!ere, questo significherebbe una ri!uione !a quattro atre team. 5bbiamo fatto una lista !ei membri !i ogni team. Per favoreraggruppatevi e ciascun gruppo si scelga una seione !i una parete.D

(il team lea! atten!e mentre le persone igagano fino a formare tregruppi, posiionati ognuno accanto a! una seione vuota !i parete).

C+unque, questa !ivisione in team " preliminare$ %n punto !i partena,giusto per portarci avanti. 5l proseguire !ello sprint planning meeting,

sarete liberi !i allontanarvi verso un altro team, o magari !ivi!ere un teamin !ue, combinare un team con un altro, e cos4 via. %sate il buon senso, basan!ovi sulle priorit !el pro!uct o#ner.D

quello che per noi ha funionato meglio. %n certo livello !i controllocentrale all2iniio, seguito !a un certo livello !i ottimiaione!ecentraliata.

Team speciali--ati o no;Supponiamo !i avere una tecnologia basata sulle seguenti tre componenti principali:

&lloca+ione preliminaredei team

%eam 0> tom> Lerr> donald

> mice

%eam 2> goof> daff> humpt> dumpt

%eam @> minnie> scrooge> )innie> roo



&&6 R S1*%8 P +5@@ J*3K1

Supponiamo inoltre !i avere &' persone su questo pro!otto, allora !i certonon si vuole metterli in un singolo team Scrum. 1he tipo !i team metterein pie!i9

Approccio 6! team speciali--ati per componenti

%n approccio " !i organiare !ei team specialiati per componenti, tipoun Cteam per il lato clientD, un Cteam per il lato serverD, e un Cteam per il!atabaseD.

come siamo partiti. Kon funiona molto bene, almeno non quan!omolte storie impattano su piE componenti.

Per esempio supponiamo !i avere una storia come Cpannello notifiche per

lo scambio messaggi tra gli utentiD. >uesta funionalit implical2aggiornamento !ell2interfaccia utente lato client, l2aggiunta !ella logicasul server, e l2aggiunta !i alcune tabelle nel !atabase.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &&

>uesto significa che tutti e tre i team - il client team, il server team, e! il!b team - !evono collaborare per realiare questa storia. Kon " il

massimo.

Approccio #! team cross3component%n secon!o approccio " organiare team cross-component, per esempio!ei team non !e!icati a nessun componente in particolare.



&; R S1*%8 P +5@@ J*3K1

Se molte storie impattano piE componenti, questo tipo !i strategia !isu!!ivisione !ei team funioner meglio. Ngni team puA implementareun2intera storia che impatta la parte client, la parte server e la parte +F. 3team possono !unque lavorare in mo!o piE in!ipen!ente l2uno !all2altro, ilche " una Qran 1osa.

%na !elle prime cose che abbiamo fatto nell2intro!urre Scrum " stataquella !i speare i team specialiati per componenti che gi esistevano(approccio &) e costituire al loro posto !ei team cross-component

(approccio ;). >uesto ha !iminuito il numero !ei casi !el tipo Cnon possiamo completare questo item perch7 stiamo aspettan!o che i ragai!ella parte server finiscano la loro parteD.

5! ogni mo!o, quan!o ve n2" forte necessit, capita che mettiamo

insieme, temporaneamente, team specialiati per componenti.

Riorgani--are i team ad ogni sprint o no;

Qli sprint !i solito sono abbastana !iversi l2uno !all2altro, a secon!a !ellestorie !i maggiore priorit in quel momento particolare. 1ome risultato, lacomposiione ottimale !ei team puA !ifferire a! ogni sprint.

3nfatti, quasi a! ogni sprint ci troviamo a !ire cose tipo Cquesto sprint non" per niente uno sprint normale perch7 (bla bla bla)...D +opo un po2abbiamo proprio rimosso il concetto !i sprint CnormaliD. Kon esistonosprint normali. Proprio come non esistono famiglie CnormaliD o personeCnormaliD.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &;&

3n uno sprint potrebbe essere una buona i!ea avere un team solo per la parte client, composto !a tutti coloro che conoscono bene la code-base

!ella parte client. 5l prossimo sprint potrebbe essere una buona i!ea avere!ue team cross-component e re!istribuire le persone !ella parte client trai !ue team.

%no !egli aspetti chiave !i Scrum " il Cteam gelD, cio" se in un team silavora assieme per !iversi sprint !i solito si crea un forte legame. 3membri !el team imparano a raggiungere un flusso ottimale di gruppo/ eun incre!ibile livello !i pro!uttivit. Juttavia ci vogliono un po2 !i sprint per arrivarci. Se si continuano a cambiare i vari team, non si raggiunger

mai un forte Cteam gelD.

>uin!i se si vuole riorganiare i team, bisogna essere sicuri !i averneconsi!erato le conseguene. un cambiamento !i breve o !i lungo perio!o9 Se " !i breve perio!o, forse non ne vale la pena, mentre se " !ilungo perio!o allora magari s4.

%na ecceione " quan!o si iniia a fare Scrum con un team numeroso perla prima volta.

3n tal caso probabilmente conviene sperimentare un po2 re!istribuen!o iteam finch7 non si riesce a far sentire tutti a proprio agio. Fisogna esseresicuri che tutti capiscano che " NT sbagliare nei primi perio!i, purch7 sicontinui a migliorare.

1embri part3timePosso solo confermare quello che !icono i libri su Scrum - avere membri

a tempo pariale in un team Scrum in generale non " una buona i!ea.

Supponiamo !i essere sul punto !i pren!ere oe come membro part-timenel nostro team Scrum. Fisogna pensarci attentamente prima. Siamosicuri che c2" bisogno !i oe nel team9 Siamo sicuri !i non poterlo avere atempo pieno9 >uali sono i suoi altri impegni9 >ualcun altro potrebbe farsicarico !elle attuali attivit !i oe lascian!ogli un ruolo piE passivo, !isupporto, in questo9 PuA oe entrare nel team a tempo pieno a partire !al prossimo sprint, e nel frattempo trasferire a qualcun altro le altre sue

responsabilit9

5lcune volte non c2" mo!o !i uscirne. 12" un !isperato bisogno !i oe

' Cgroup flo#D K!J



&;; R S1*%8 P +5@@ J*3K1

perch7 " l2unico +F5 nell2e!ificio, ma gli altri team hanno allo stessomo!o bisogno !i lui cosicch7 non verr mai allocato a tempo pieno nelnostro team, e l2aien!a non puA assumere altri +F5. Fene. >uesto " un

caso vali!o in cui effettivamente lo si puA avere solo part-time (che " tral2altro " proprio quello che " capitato a noi). 5! ogni mo!o bisogna esseresicuri !i fare !avvero queste valutaioni tutte le volte.

3n generale preferisco un team !i tre persone full time anich7 !i otto persone part-time.

Se c2" una persona che !ivi!er il suo tempo tra molti team, come il +F5!i cui sopra, " una buona i!ea assegnargli comunque un team !i

riferimento. Fisogna cercare !i capire quale team probabilmente avr piE bisogno !i lui, e fare in mo!o che questo sia il suo team C!i casaD.>uan!o non c2" bisogno !i lui !a qualche altra parte, lui partecipa ai !ailscrum !i quel team, agli sprint planning meeting, alle retrospettive, etc.

2ome /acciamo lo )crum degli )crum@o crum-of-scrum " in pratica un meeting che viene fatto regolarmente e

che fornisce agli Scrum master l2occasione !i parlarsi.5! un certo punto avevamo quattro pro!otti, e per ognuno !i questi pro!otti avevamo un team Scrum !e!icato, mentre per l2ultimo pro!otto vierano ;' persone !ivise in !iversi team Scrum. %na situaione comequesta:



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &;<

>uesto significa che c2erano !ue livelli !i Scrum !egli Scrum. 5vevamouno Scrum !egli Scrum C!i pro!ottoD che consisteva in tutti i team !elPro!otto +, e uno Scrum !egli Scrum Caien!aleD che consisteva in tutti i

pro!otti.

Lo )crum degli )crum di prodotto

>uesto meeting " stato molto importante. @o tenevamo una volta allasettimana, a volte un po2 piE spesso. Mi !iscutevamo questioni !iintegraione, !i bilanciamento !ei team, !i preparaione per il prossimosprint planning meeting, e cos4 via. Mi allocavamo < minuti ma spessosforavamo. %n2alternativa poteva essere tenere lo Scrum !egli scrum ogni

giorno ma poi non l2abbiamo mai provata.

3l programma !ello Scrum !egli scrum era&) %n CgiroD. 5 turno ognuno !escrive cosa ha fatto il proprio team lasettimana prece!ente, cosa pensa !i fare questa settimana, e qualiimpe!imenti ci sono.;) Ngni questione che riguar!a tutti i team e che serve riportare, peresempio le questioni relative all2integraione.

Per me comunque non " l2or!ine !el giorno a! essere importante.@2importante " che lo Scrum !egli Scrum abbia luogo.

Lo )crum degli )crum a-iendale

>uesto meeting lo abbiamo !enominato C3l FattitoD. 5bbiamo tenuto

questo meeting in una variet !i formati, e con una variet !i partecipanti.%ltimamente abbiamo abban!onato l2intero concetto e lo abbiamorimpiaato con un incontro settimanale aperto a tutti (o meglio, tutte le persone coinvolte nello sviluppo). +i &' minuti.

1ome9 &' minuti9 Plenario9 Jutti i membri !i tutti i team !i tutti i pro!otti9 8a funiona9

S4, funiona se tu, o chiunque sia a con!urlo, resti inflessibile nel

mantenerlo breve.

3l formato !el meeting "&) Kovit e aggiornamenti !alla !ireione !ello sviluppo. 3nformaioni su prossimi eventi per esempio.



&;B R S1*%8 P +5@@ J*3K1

;) *oun!-robin. %na persona per ogni gruppo !e!icato a! un pro!ottoriporta cosa " stato fatto !al suo gruppo l2ultima settimana, che cosa pensano !i fare questa settimana, e quali problemi ci sono. 5nche altre

persone fanno !ei resoconti (i coor!inatori !i 18, >5, etc).<) 1hiunque altro " libero !i aggiungere informaioni o fare !oman!e.

Si tratta !i un forum per informaioni riassuntive, non !iscussioni oriflessioni. Se si rimane su questa linea, &' minuti !i solito vanno bene.>ualche volta an!iamo oltre, ma raramente arriviamo a piE !i < minutiin tutto. Se sorgono !iscussioni interessanti le interrompo e! invito le persone interessate a fermarsi !opo il meeting per continuarle.

Perch7 facciamo un incontro generale9 Perch7 abbiamo notato che loScrum !egli Scrum aien!ale era principalmente finaliato a fare !eiresoconti. *aramente abbiamo avuto vere !iscussioni in questo gruppo.3noltre, molte altre persone al !i fuori !el gruppo erano !esi!erose !iconoscere questo tipo !i informaioni. 3n essena, i team vogliono saperecosa stanno facen!o gli altri team. 5llora ci siamo chiesti, !al momentoche abbiamo !eciso !i incontrarci e !e!icare !el tempo per informarci l2unl2altro su cosa fanno gli altri team, perch7 non permettere semplicemente atutti !i partecipare.

Inter7allare i dailF scrumSe ci sono molti team Scrum per un singolo pro!otto, e si !ovesse fare il!ail scrum tutti nello stesso momento, sarebbe un problema. 3l pro!ucto#ner (e i ficcanaso come me) potrebbero partecipare a! un solo !ailscrum al giorno.

>uin!i chie!iamo ai team !i evitare !i tenere i !ail scrum tutti nellostesso momento.

@a sche!a !2esempio sopra viene !a un perio!o in cui facevamo i !ailscrum is aree separate, invece che nell2area !el team. Qli incontri !uranosolitamente &' minuti ma ogni team prenota uno spaio !i < minuti, casomai !ovesse sforare un po2.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &;'

>uesto " estremamente utile per !ue motivi.

&. Persone come il pro!uct o#ner e! io stesso possono partecipare atutti i !ail scrum in una singola mattinata. Kon c2" mo!omigliore per ottenere un qua!ro accurato sulle !ireioni chestanno pren!en!o gli sprint, e sulle loro criticit.

;. Ngni team puA assistere ai !ail scrum !egli altri team. Konsucce!e molto spesso, ma una volta ogni tanto !ue team!ovranno lavorare su ambiti che si sovrappongono, in tal casoalcuni membri si calano nei !ail scrum !i altri team per restaresincroniati.

3l rovescio !ella me!aglia " meno libert per il team. perch7 non gli " possibile scegliere l2orario preferito per il !ail Scrum. 1omunque questonon " mai stato veramente un problema per noi.

Il team dei pompieri5bbiamo avuto una situaione in cui per un gran!e pro!otto non

riuscivamo a! a!ottare Scrum perch7 si spen!eva troppo tempo arincorrere le emergene, per esempio !oven!o correggere bug !a panicosu sistemi rilasciati prematuramente. ra un vero circolo viioso, si eracos4 impegnati a spegnere incen!i che non c2era il tempo !i lavorare proattivamente in mo!o !a prevenire gli incen!i (cio" migliorare il!esign, automatiare i test, creare sistemi !i monitoring, !i allarme etc).

3l nostro approccio per affrontare questo problema " stato quello !i!esignare !ue team: il team !ei pompieri, e il team Scrum.

3l compito !el team Scrum era (con la bene!iione !el pro!uct o#ner) !icercare !i stabiliare il sistema e prevenire, in mo!o efficace, gli incen!i.3 pompieri (a !ire il vero li abbiamo chiamati CsupportoD) avevano !uecompiti.&) Spegnere gli incen!i;) Proteggere il team Scrum !a tutti i tipi !i !isturbo, incluse cose come ba!are a tutte le richieste !i funionalit Ca!-hocD provenienti !a non si sa!ove.

3l team !ei pompieri era piaato vicino alla portaX il team Scrum in fon!oalla stana. >uin!i i pompieri potevano proprio proteggere fisicamente ilteam Scrum !a fattori !i !isturbo come commerciali incontenibili oclienti a!irati.



&;= R S1*%8 P +5@@ J*3K1

Sviluppatori senior venivano piaati in entrambi i team, in mo!o chenessun team sarebbe stato troppo !ipen!ente !alle competene !ell2altro.

Si trattava fon!amentalmente !i un tentativo per risolvere un problema !iCavviamentoD !i Scrum. 1ome si fa a far partire Scum se i team nonhanno la possibilit !i pianificare il proprio lavoro per piE !i un giorno9@a nostra strategia era, come gi !etto, !ivi!ere il gruppo.

1iA ha funionato abbastana bene. +ato che il team Scrum avuto spaio per lavorare in mo!o proattivo, " stato finalmente in gra!o !i stabiliareil sistema. Kel frattempo la squa!ra !ei pompieri aveva completamente

rinunciato al concetto !i seguire un piano prestabilito. >uesta lavorava inmo!o completamente reattivo, semplicemente metten!o a posto tutte leurgene che si presentassero !i volta in volta.

Katuralmente il team Scrum non " rimasto completamente in!isturbato.Spesso la squa!ra !ei pompieri !oveva ricorrere all2aiuto !i alcune persone chiave !el team Scrum, oppure, nel caso peggiore, !i tutto ilteam.

1omunque sia, !opo un paio !i mesi il sistema era stabile abbastana !a poter !ismettere il team !ei pompieri e organiare invece !ei nuovi teamScrum. 3 pompieri sembravano piuttosto contenti !i !eporre i loro elmettiammaccati e! entrare a far parte !ei team Scrum.

Di7idere il product bac+log o no;Supponiamo !i avere un pro!otto e !ue team Scrum. >uanti pro!uct

backlog bisognerebbe avere9 >uanti pro!uct o#ner9 5bbiamo valutato tremo!elli. @a scelta ha un effetto notevole sullo svolgimento !egli sprint planning meeting.

)trategia 6! un product o>ner4 un bac+log

>uesto " il nostro mo!ello CKe *ester Soltanto %noD. quello che preferiamo.

>uello che c2" !i buono in questo mo!ello " che i team possono esserelasciati abbastana autonomi, e basarsi sulle maggiori priorit che il pro!uct o#ner ha al momento. 3l pro!uct o#ner si focalia su quello di



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &;G

cui ha bisogno, mentre ai team viene lasciato !eci!ere come !ivi!ersi illavoro.

Per essere piE concreti, ecco come funiona lo sprint planning meeting perquesto team:

@o sprint planning meeting viene tenuto in un centro conferene esterno.

5ppena prima !el meeting, il pro!uct o#ner in!ica quella che sar laCparete !el pro!uct backlogD e ci attacca le storie (carte), or!inate per priorit. 1ontinua a! aggiungerne finch7 la parete non sia piena, il che, !isolito, " piE che abbastana per uno sprint.



&;6 R S1*%8 P +5@@ J*3K1

Ngni team Scrum seleiona uno spaio vuoto !a una parete e ci mette ilsuo nome. >uello spaio sar il suo. Ngni team quin!i pren!e !elle storie!alla parete !el pro!uct backlog, a partire !alle storie !i maggiore priorit,e applica le carte sul proprio spaio.

@a cosa " illustrata nella figura seguente, !ove le frecce gialle mostrano il

flusso !elle carte relative alle varie storie !alla parete !ello sprint, alle pareti !ei team.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &;

5l proseguire !el meeting, tra il pro!uct o#ner e! i team si avvia unatrattativa riguar!ante le carte, che vengono scambiate tra i team, spostatesu e giE per cambiarne la priorit, speate in carte piE piccoli, etc. +opo

circa un2ora, ogni team pro!uce una prima candidate release !i sprint backlog sul proprio spaio. +opo!ich7 i team lavorano in mo!oin!ipen!ente, facen!o le stime e le su!!ivisioni !elle storie in task

incasinato, caotico, faticoso, ma anche efficace, !ivertente e sociale.Sca!uto il tempo, !i solito tutti i team hanno sufficienti informaioni periniiare il proprio sprint.

)trategia #! un product o>ner4 pi bac+log

3n questa strategia, il pro!uct o#ner gestisce più pro!uct backlog, uno perteam. 3n realt non abbiamo provato questo approccio, ma ci siamo an!ativicino. 3n sostana si tratta !el nostro piano alternativo in caso !ifallimento !el primo approccio.

3l punto !ebole !i questa strategia " che il pro!uct o#ner assegna le storieai team, un compito che probabilmente i team sanno fare meglio !a soli.



&< R S1*%8 P +5@@ J*3K1

)trategia <! .i product o>ner4un bac+log per o>ner

>uesta " simile alla secon!a strategia, un pro!uct backlog per team, macon anche un pro!uct o#ner per team$

Kon lo abbiamo sperimentato, n7 probabilmente lo faremo.

Se !ue pro!uct backlog impattano la stessa code base, questo probabilmente provocher forti conflitti !i interesse tra i !ue pro!ucto#ner.

Se invece i !ue pro!uct backlog impattano code-base !istinte, " in praticacome separare l2intero pro!otto in !ue sotto pro!otti, e portarli avanti in



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &<&

mo!o in!ipen!ente. 1iA significa che abbiamo !i nuovo una situaioneun-team-per-pro!otto, il che " molto semplice e! elegante.

2ode brancing1on team multipli, lavorare sulla stessa co!e base ci porta inevitabilmentea! aver a che fare con il fare !ei co!e branch nel sistema !i versionamento!el co!ice sorgente. 1i sono molti libri e articoli su come gestiresituaioni in cui sono in molti a lavorare sulla stessa co!e base, !unquenon mi !ilungherA qui nei !ettagli. Kon ho nulla !i nuovo o !irivoluionario !a aggiungere. Morrei, comunque, riassumere alcune !elleleioni piE importanti imparate fin2ora !ai nostri team.

• ssere rigorosi nel mantenere la mainline (o trunk) in uno statoconsistente. >uesto significa, come minimo minimo, che tutto!ovrebbe compilare e che tutti i test unitari !ovrebbero passare.+ovrebbe essere possibile creare una release funionante inqualsiasi momento. Preferibilmente il sistema !i continuous build

!ovrebbe creare un buil! e fare automaticamente deplo& su unambiente !i test ogni notte.

• 8ettere un CtagD a! ogni release. Ngni volta che viene fatto unrilascio pronto per i test !i accettaione o per la pro!uione, bisogna essere sicuri che ci sia un tag !i versione nel ramo principale che i!entifichi esattamente quello che " stato rilasciato.>uesto significa che sar possibile, a! ogni momento nel futuro,tornare in!ietro e creare un branch !i manutenione a partire !aquel punto.

• 1reare nuovi branch solo quan!o " necessario. %na buona regola per !eci!ere se creare o no un nuovo branch " farlo solo quan!onon " possibile usare l2attuale codeline sena violare una qualche politica stabilita per la codeline stessa. 3nsomma, nel !ubbio, non

creare un branch. Perch79 Perch7 ogni branch attivo costa ingestione e complessit.

• %sare branch principalmente per separare cicli di vita differenti.Si potr !eci!ere o meno che ogni team Scrum metta il co!ice suuna propria codeline. Juttavia se si !eci!esse !i mettere insieme fi" !i breve perio!o e cambiamenti !i lungo perio!o sullo stesso

ramo, si troveranno notevoli !ifficolt a rilasciare i fi" !i breve perio!o$

• Sincroniare spesso. Se si lavora su un branch, sincroniare conla mainline ogni volta che si ha qualcosa che Cbuil!aD. Ngnigiorno quan!o si iniia a lavorare, sincroniare la propria copia



&<; R S1*%8 P +5@@ J*3K1

!i lavoro, in mo!o !a essere sempre aggiornati rispetto aicambiamenti fatti !agli altri team, o !agli altri membri !el team.Se questo !ovesse comportare un merge !rammatico, basta

pensare a quanto sarebbe peggio aspettare.

Retrospetti7e multi3team1ome facciamo le retrospettive quan!o sono piE team a lavorare sullostesso pro!otto9

5lla fine !ella sprint !emo, !opo l2applauso e le chiacchierate tra i vari

gruppetti, ogni team raggiunge un2area !iversa !alla propria, o qualcheconfortevole luogo esterno agli uffici.Oaranno le loro retrospettive un po2 come !escritto a pg. GB C1omefacciamo le retrospettiveD. +urante lo sprint planning meeting (cui partecipano tutti i team, !almomento che !a noi gli sprint sono sincroniati), la prima cosa chefacciamo " lasciare che per ogni team un portavoce pren!a la parola eriassuma i punti chiave emersi !ella sua retrospettiva. 1i vogliono circa

cinque minuti per team. >uin!i abbiamo una !iscussione aperta per circa&-; minuti. Poi ci pren!iamo una pausa. 5 quel punto iniiamo il verosprint planning.

Kon abbiamo provato nessun altro mo!o per le retrospettive tra piE team,ma comunque questo formato funiona abbastana bene. 3l maggioresvantaggio " che in questo mo!o non sono previsti stacchi tra la parte!ello sprint meeting !e!icata alla retrospettiva e quella !e!icata alla pianificaione vera e propria. (Me!i pag. 6& CStacchi tra uno sprint el2altroD)

Per pro!otti !e!icati ai singoli team, non facciamo nessun riassunto !ellaretrospettiva !urante lo sprint planning meeting. Kon ve n2" necessit !almomento che tutti erano presenti alla retrospettiva vera e propria.



1N8 N*Q5K3[[358N J58 S1*%8 8%@J3P@3 R &<<



6H2ome gestiamo i team distribuiti

geogra/icamente

1osa succe!e quan!o i membri !el gruppo sono geograficamente!istribuiti9 8olta !ella CmagiaD !i Scrum e P " basata sull2avere teamco-locati che collaborano intensamente, fanno pair programming e siincontrano faccia a faccia ogni giorno.

5bbiamo qualche team separato, ovvero geograficamente !istaccato, e!abbiamo anche persone !el team che ogni tanto lavorano !a casa.

@a nostra strategia per questo " piuttosto semplice. %siamo ogni possibile

trucco per massimiare la ban!a !i comunicaione con i membrifisicamente lontani. Kon inten!o ban!a !i comunicaione in termini !i8bit/sec (pur essen!o ovviamente anch2essa importante). 3nten!o ban!a!i comunicaione in senso lato:

• Possibilit !i fare pair programming.• Possibilit !i incontrarsi faccia a faccia al !ail scrum.• Possibilit !i !iscutere personalmente in ogni momento.• Possibilit !i incontrarsi fisicamente e socialiare.• Possibilit !i avere !ei meeting spontanei con il team intero.• Possibilit !i avere la stessa visibilit !ello sprint backlog, !el

burn!o#n, !el pro!uct backlog, e altri irra!iatori !i informaioni.

5lcune !elle misure che abbiamo attuato (o stiamo attuan!o, non leabbiamo ancora messe in pratica tutte) sono:

• Lebcam con microfoni e cuffiette per ogni #orkstation.

• C1onference roomD abilitate alla vi!eo conferena, con tuttol2occorrente tra #ebcam, microfoni, computer sempre pronti eaccesi, soft#are !i con!ivisione !el !esktop, etc.

• COinestre remoteD. Qran!i schermi in ogni location, che mostrinouna visione costante !elle altre location. %na sorta !i finestra



1N8 QSJ358N 3 J58 +3SJ*3F%3J3 QNQ*5O3158KJ R &<'

virtuale tra i !ue !ipartimenti. 1i si puA mettere !2avanti e fare !eicenni. Si puA ve!ere chi " alla propria postaione e chi sta parlan!o con chi. >uesto crea il senso !ello stare inisieme.

•

Programmi !i scambio, con regolarit persone !i una location sispostano verso l2altra.

%san!o queste tecniche e! altro abbiamo pian piano iniiato a! affrontarela questione !i come fare sprint planning meeting, !emo, retrospettive,!ail scrum etc, con membri !el team geograficamente !istribuiti.

1ome sempre " tutta una questione !i sperimentare. 3nspect VZa!apt VZ

inspect VZ a!apt VZ inspect VZ a!apt VZ inspect VZ a!apt VZ inspect VZ a!apt

O//soring

5bbiamo !iversi team offshore e abbiamo sperimentato su come gestirequesto in mo!o efficiente usan!o Scrum.

Mi sono !ue principali strategie qui: team separati o membri !ei team

separati.



&<= R S1*%8 P +5@@ J*3K1

Scrum team 0

'aese &

'aese ?

Scrum team 2

Scrum team 0

'aese &

'aese ?

%eam separati

$embri dei team separati



1N8 QSJ358N 3 J58 +3SJ*3F%3J3 QNQ*5O3158KJ R &<G

@a prima strategia, !ei team separati, " una scelta allettante. Kon!imeno,

siamo partiti con la secon!a strategia, !i separare i membri !el team. 1isono !iverse motivaioni per questa scelta.

&. Mogliamo che i membri !i un team arrivino a conoscersi bene tra!i loro.

;. Mogliamo !elle eccellenti infrastrutture !i comunicaione tra le!ue postaioni, e incentivare i team a metterle in atto.

<. 5ll2iniio, il team offshore era troppo poco numeroso per formareun team Scrum autonomo vero e proprio.

B. Mogliamo un perio!o !i intenso scambio !i conoscene primache l2opione !ei team offshore in!ipen!enti !iventi attuabile.

Sul lungo perio!o potremmo benissimo spostarci sulla strategia !ei CteamseparatiD

1embri del team ce la7orano da casa

@avorare !a casa ogni tanto puA essere una buona cosa. 5 volte riesci afare molta piE programmaione in un giorno !a casa che in un2interasettimana al lavoro. 5lmeno se non hai !ei bambini :o)

1omunque il fatto che il team !ebba essere co-locato " sempre uno !eifon!amenti !i Scrum. >uin!i che facciamo9

Oon!amentalmente lasciamo !eci!ere al team quan!o e quanto spesso va bene lavorare !a casa. 5lcuni membri !el team lavorano !a casaregolarmente per evitare un lungo tragitto casa-lavoro. 1omunqueincoraggiamo il team a! essere fisicamente co-locato per la maggior parte!el tempo.

>uan!o i membri !i un team lavorano !a casa, questi partecipano al !ailscrum attraverso una chiamata Skpe (a volte anche vi!eo). Sono

raggiungibili tutto il giorno tramite instant messaging. Kon " come starein una stessa stana, ma " abbastana buono.

%na volta abbiamo provato a stabilire un focus da&# il mercole!4. 3n pratica l2i!ea era: Cse vuoi lavorare !a casa, va bene, ma fallo !i



&<6 R S1*%8 P +5@@ J*3K1

mercole!4, e comunque verifica con il tuo teamD. Ia funionato

abbastana bene nel team in cui lo abbiamo provato. +i solito buona parte!el team stava a casa !i mercole!4, e riusciva a portare a termine moltecose, e allo stesso momento si manteneva una buona collaboraione. +atoche si tratta solo !i un giorno, i membri !el team non restano troppo fuorisincronia tra loro. Juttavia per qualche motivo questa cosa non " mai statamolto recepita !agli altri team.

Kel complesso avere qualcuno che lavorasse !a casa non " mai stato un problema per noi.



6JLa cec+list dello )crum master

3n questo capitolo finale vorrei mostrare quella che per noi " la CchecklistD!ello scrum master, elencan!o le piE comuni operaioni !i routine !einostri Scrum master. 1ose che magari si !imenticano facilmente.Saltiamo pure le cose ovvie come Crimuovere gli impe!imenti !al teamD.

Ini-io dello sprint

+opo lo Sprint planning meeting, creare una pagina informativa!ello Sprint.o 5ggiungere un link al #iki sulla pagina cruscotto.o Stampare la pagina e appen!erla alla parete piE visibile a

quelli che passano. 3nformare tutti via mail !ell2iniio !ello sprint. 3nclu!ere

l2obiettivo !ello sprint e un link alla sua pagina informativa. 5ggiornare il !ocumento !elle statistiche !ello sprint.

5ggiungere la propria velocit stimata, la !imensione !el team, la

!urata !ello sprint, etc.

Ogni giorno

Merificare che il +ail Scrum sia cominciato e finito in tempo. 5ssicurarsi che !elle storie vengano aggiunte/rimosse !allo

Sprint backlog se questo fosse necessario per riallineare lo sprint

rispetto ai tempi.o 5ssicurarsi che il Pro!uct o#ner sia consapevole !i

questi cambiamenti. 5ssicurarsi che lo sprint backlog e il burn!o#n siano tenuti

aggiornati !al team.



&B R S1*%8 5K+ P O*N8 JI J*K1IS

5ssicurarsi che i problemi/impe!imenti vangano risolti osegnalati al Pro!uct o#ner e/o al responsabile !egli sviluppisoft#are.

Qine dello sprint

Oare una Sprint !emo aperta a tutti. 5vvisare tutti !ella !emo uno o !ue giorni prima. Oare una retrospettiva !ello Sprint con l2intero team e! il Pro!uct

N#ner. 3nvitare anche il responsabile !egli sviluppi soft#are, inmo!o che possa !are una mano a con!ivi!ere le leioni

imparate. 5ggiornare il !ocumento !elle statistiche !ello sprint.

5ggiungere la velocit effettiva e i punti chiave emersi !alleretrospettive.



6KEpilogo

1aspita$ Kon avrei mai pensato !i an!are cos4 per le lunghe.

Spero che il testo vi abbia !ato qualche utile i!ea, novii o veterani chevoi siate !ello Scrum.

+ato che Scrum va cucito specificamente su misura in ogni ambiente "!ifficile !iscutere costruttivamente !i sue best practice sul piano generale. Kon!imeno sono interessato a sentire i vostri fee!back. *accontatemicome il vostro approccio !ifferisce !al mio. +atemi qualche i!ea su comemigliorare$

1ontattatemi pure all2in!irio henrik.kni$ergFcris#.se.Jenete !2occhio anche scrumde!elo#mentFahoogrou#s.com.

Se questo libro vi " piaciuto potreste voler visitare !i tanto in tanto il mio blog. Spero !i aggiungere qualche post su ava e sullo sviluppo agile !elsoft#are. htt#?GG$log.cris#.seGhenrikkni$ergG

5h, e non !imenticate...

solo un lavoro, giusto9

mailto:[email protected]





Letture consigliate

>uesti sono alcuni !ei libri che mi hanno !ato molte ispiraioni e! i!ee.5ltamente raccoman!ati$



L9autore

Ienrik Tniberg (henrik.knibergcrips.se) " un consulente in 1risp, aStoccolma (###.crisp.se), specialiato in ava e nell25gile soft#are!evelopment.

Oin !all2uscita !ei primi libri su P e !el manifesto agile, Ienrik haaccolto i principi !ell2agile e! ha cercato !i imparare come applicarli inmo!o efficiente in !iversi tipi !i organiaioni. 1ome co-fon!atore e1JN !i Qoa!a &6-;< ha avuto ampia opportunit !i sperimentare iltest-!riven !evelopment e altre pratiche agili aven!o costruito e gestitouna piattaforma tecnica e un team !i sviluppo !i trenta persone.

Kel tar!o ;' Ienrik veniva messo a capo !egli sviluppi in una aien!asve!ese operante nel business !ei giochi. @2aien!a era re!uce !a unasituaione !i crisi con urgenti problemi organiativi e tecnici. %san!oScrum e P come strumenti, Ienrik ha aiutato l2aien!a a! uscire !allacrisi implementan!o principi agili e lean a tutti i livelli !ell2aien!a.

%n vener!4 !el novembre ;= Ienrik resta a casa a letto con la febbre e!eci!e !i buttare giE alcune note per s7 sulle cose imparate l2ultimo anno.%na volta iniiato a scrivere, non riesce a smettere e !opo tre giornifrenetici tra scrivere e !isegnare, queste note si allungano fino atrasformarsi in un articolo !i ottanta pagine intitolato CScrum an! Pfrom the JrenchesD, che poi !iventer questo libro.

Ienrik a!otta un approccio olistico e si !iverte a! assumere vari ruolicome il manager, lo sviluppatore, lo scrummaster, il !ocente e! il coach. un appassionato nel !are una mano alle aien!e che costruisconosoft#are eccellente e team eccellenti, assumen!o qualunque ruolo !i cui

ci sia bisogno.

Ienrik " cresciuto a Joko e! ora vive a Stoccolma con sua moglie Sofiae !ue bambini. Kel tempo libero " un musicista attivo, compone musica esuona il basso e le tastiere in ban! locali.Per maggiori informaioni an!ate su: http://###.crisp.se/henrik.kniberg


http://www.crisp.se/

http://www.crisp.se/henrik.kniberg


http://www.crisp.se/

http://www.crisp.se/henrik.kniberg

Scrum and Xp From the Trenches Italian

Documents

Transcript of Scrum and Xp From the Trenches Italian