I Modelli Organizzativi Agile Scalati: il caso Tagetik … Modelli Organizzativi Agile Scalati: il...

111
DIPARTIMENTO DI INGEGNERIA DELL’ENERGIA, DEI SISTEMI, DEL TERRITORIO E DELLE COSTRUZIONI RELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE I Modelli Organizzativi Agile Scalati: il caso Tagetik Software RELATORI IL CANDIDATO Prof. Ing. Gionata Carmignani Marco Penco Dipartimento di Ingegneria dell’Energia, [email protected] dei Sistemi, del Territorio e delle Costruzioni Sessione di Laurea del 20/07/2016 Anno Accademico 2015/2016 Consultazione consentita

Transcript of I Modelli Organizzativi Agile Scalati: il caso Tagetik … Modelli Organizzativi Agile Scalati: il...

DIPARTIMENTODIINGEGNERIADELL’ENERGIA,DEISISTEMI,DELTERRITORIOEDELLECOSTRUZIONI

RELAZIONEPERILCONSEGUIMENTODELLALAUREAMAGISTRALEININGEGNERIAGESTIONALE

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware

RELATORI ILCANDIDATO

Prof.Ing.GionataCarmignani MarcoPenco

DipartimentodiIngegneriadell’Energia,[email protected]

deiSistemi,delTerritorioedelleCostruzioni

SessionediLaureadel20/07/2016AnnoAccademico2015/2016

Consultazioneconsentita

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

2

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

3

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftwareMarcoPenco

Sommario:

Questatesidilaureaèfruttodiduetipidiattività:unaricercaedanalisidipubblicazioniaccademiche,focalizzatasuimodelliorganizzativiutilizzatidelleaziendeproduttricidisoftware;edunperiododitirociniopressoTagetikSoftwares.r.l.

L’industriadelsoftwareècaratterizzatadaunasempremaggiorerapiditàneicambiamentideirequisitidegliutenti:lavelocitàdirispostarappresentaunfattoredeterminanteperilsuccessodelleorganizzazioni,inquestadirezioneimodelliorganizzativiAgilehannodimostratodiconseguiredegliottimirisultati.ImodelliAgilenasconoesisviluppanoincontestiorganizzatividimedio-piccoledimensioni,maèsempremaggioreilnumerodiorganizzazionidigrandidimensionichecercadiadattarlialpropriocontestoperottenerneibenefici.Scopodellatesièstudiarel’applicazione,attraversol’utilizzodimodellispecifici,dellemetodologieAgileinorganizzazionidigrandidimensioni,determinandoleattivitànecessarieperlatransizioneaquestimodelli.

IlcasodistudiopressoTagetikSoftware,multinazionaleoperantenelsegmentodeisoftwareCPM,analizzaleattivitàdiunatransizionedaunmodellotradizionaleditipoWaterfalladunoAgilescalato,cambiamentodigrossaentità,riguardanteillavorodiottantaprogrammatorielacreazionedinuoviruolimanageriali.

Abstract:

Thisthesisistheresultoftwotypesofwork:anactivityofresearchandanalysisofacademicpapers,focusedontheorganizationalmodelsusedbythesoftwarecompanies;andaperiodofapprenticeshipatTagetikSoftware.Thesoftwareindustryischaracterizedbyincreasinglyrapidchangesintheuserrequirements:thespeedofresponseisadeterminingfactorforthesuccessoforganizations,forthispurposetheAgileorganizationalmodelshavedemonstratedtoachieveexcellentresults.Agilemodelshavebeencreated,andarewellsuited,inthecontextsofsmall-mediumsizeorganizations,butitisincreasingthenumberoflargeorganizationstryingtoapplytheminordertoobtainthesamebenefits.Theaimofthisthesisistostudytheapplication,throughtheuseofspecificmodels,oftheAgilemethodologiesinlargeorganizations,andtodeterminetheactivitiesnecessaryforthetransitiontothesemodels.ThecasestudyatTagetikSoftware,amultinationalcompanyoperatingintheCPMsoftwaresegment,analyzestheactivitiesofatransitionfromatraditionalWaterfallmodeltoaScaledAgileone,alargetransitioninterestingtheworkofeightyprogrammersandthecreationofspecificmanagerialroles.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

4

IndiceSommario:.................................................................................................................................3

Indicedellefigure......................................................................................................................7

Strutturadellatesi.....................................................................................................................9

1. Introduzione.....................................................................................................................10

1.1. Contestogenerale........................................................................................................10

1.2. MetodologiadisviluppoWaterfall...............................................................................11

1.2.1. LefasidelprocessoWaterfall...................................................................................12

1.2.2. ElementipositividelmodelloWaterfall...................................................................13

1.2.3. CritichealmodelloWaterfall....................................................................................14

1.3. LemetodologiedisviluppoAgile.................................................................................15

1.3.1. CaratteristichedellemetodologieAgile...................................................................15

1.3.2. LepraticheAgile.......................................................................................................18

1.3.3. IlManifestoAgile......................................................................................................19

1.4. Scrum...........................................................................................................................22

1.4.1. LosviluppodiScrum.................................................................................................22

1.4.2. IvaloriallabasediScrum.........................................................................................23

1.4.3. IruolidelteamScrum...............................................................................................24

1.4.4. IlfunzionamentodiScrum........................................................................................26

1.4.5. EventiecerimoniediScrum.....................................................................................27

1.4.6. GliArtefattidiScrum................................................................................................29

1.5. ExtremeProgramming.................................................................................................31

1.5.1. LanascitadiExtremeProgramming.........................................................................32

1.5.2. AttivitàdelprocessodisviluppoconExtremeProgramming...................................32

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

5

1.5.3. IvaloridiExtremeProgramming..............................................................................34

1.5.4. LepratichediExtremeProgramming.......................................................................35

2. LemetodologieAgileinorganizzazionidigrossedimensioni..........................................41

2.1.1. IlimitidellemetodologieAgiletradizionalineiprogettidigrossedimensioni.........41

2.1.2. IprimitentatividiapplicazionedellemetodologieAgileinorganizzazionidigrosse

dimensioni...............................................................................................................................43

2.2. LosviluppodimodellispecializzatinelloscalarelemetodologieAgile........................44

2.3. ScaledAgileFramework(SAFe)....................................................................................47

2.3.1. IntroduzioneaSAFe..................................................................................................47

2.3.2. IlfunzionamentodiSAFe..........................................................................................49

2.3.3. IvaloriallabasediSAFe............................................................................................51

2.3.4. IlivellidiSAFe...........................................................................................................55

2.3.5. L’evoluzionedell’architetturainSAFe......................................................................60

2.3.6. LamisurazionedelleperformanceinSAFe...............................................................62

2.3.7. L’implementazionediSAFe.......................................................................................64

3. LatransizionedaWaterfalladAgileinTagetik................................................................67

3.1. L’azienda.......................................................................................................................67

3.2. Lasituazioneprecedenteallatransizione....................................................................68

3.2.1. Strutturaorganizzativa.............................................................................................68

3.2.2. IlprecedenteprocessodisviluppoWaterfall...........................................................69

3.2.3. Problematichedellasituazioneprecedente.............................................................71

3.3. Latransizione...............................................................................................................73

3.3.1. Ladecisionedipassareall’Agile................................................................................73

3.3.2. Pianificazionedellatransizione.................................................................................74

3.3.3. Progettazionedellanuovastrutturaorganizzativa...................................................77

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

6

3.3.4. IllanciodeiteamScrum...........................................................................................79

3.3.5. Laformazioneerogataaiteam.................................................................................80

3.3.6. LatransizionedellivellodiReleaseTrain.................................................................87

3.4. Primirisultatidellatransizione.....................................................................................92

3.4.1. Situazioneattuale.....................................................................................................92

3.4.2. AnalisiconSurvey.....................................................................................................93

3.5. Conclusioni:................................................................................................................107

Bibliografia:...........................................................................................................................108

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

7

Indicedellefigure

Figura1.0:Strutturadellatesi…………………………………………………………………………..……………..……9

Figura1.1:LefasidelprocessoWaterfall……………………………………………………………………....……12

Figura1.2:Losviluppoiterativo…………………………………………………………………………………..………16

Figura1.3:LepraticheAgilepiùutilizzate………………………….………………………………..………………18

Figura1.4:IlmanifestoAgileinunrepartosviluppopressoTagetikSoftware………………..……19

Figura1.5:lefasidiScrum……………………………………………………………………………………………..……27

Figura1.6:UnaTaskBoardpressoTagetikSoftware……………………………….……………………..……31

Figura1.7:CiclidiFeedbackinExtremeProgramming……………………………………….………....……36

Figura1.8:PairProgramming………………………………………………………..……………………………….……37

Figura1.9:LefasidelTestDrivenDevelopment……………………………………………………..…….……38

Figura1.10:ContinuousIntegration……………………………………………………………………….……..……39

Figura2.1:lamatriceASK………………………………………………………………………………………….…..……47

Figura2.2:IlivellidiSAFe……………………………………………………………………………………….……..……49

Figura2.3:Visioned’insiemedelmodelloSAFe………………………………………………………….…….…50

Figura2.4:IruolidellivellodiReleaseTrain…………………………………………………………………..……57

Figura2.5:L’evoluzionedell’architetturainSAFe……………………………………………………………..…62

Figura2.6:ungraficodiBurndownchartnegliufficidiTagetikSoftware………………….…..……64

Figura3.1:OrganigrammadiTagetikSoftware…………………………………..……………………………….69

Figura3.2:LeFasidelvecchioprocessodiproduzionesoftwareinTagetik…………………………70

Figura3.3:Graficoassessment……………………………………………………………………………………………75

Figura3.4:unaboarddelTransitionTeaminTagetik…………………………….……………………………76

Figura3.5:Lefasidellatransizione……………………………………………………………….………..……..……78

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

8

Figura3.6:Matriceperlacreazionedeiteam……………………………………………….…………….….….79

Figura3.7:Carteperl’assegnazionedegliStoryPoints……………………………………..…………………83

figura3.8:LaDefinitionofDonediunteamdisviluppo……………..………………….……………………85

Figura3.9:NotazionidiVelocity……………………………………………………..……………………………..……86

Figura3.10:MeetingdiReleasePlanninginTagetik…………………………………………………….………89

Figura3.11:UnaboarddiRelease………………………………………………………..………………………..……90

Figura3.12:UnaboarddiReleaseconledipendenzeliberate……………………………….……………91

Figura3.13:LaSurveysomministrataaiteam……………………………………..………………………………94

Figura3.14:RadardellaSurvey“quantitàdilavoro”………………………………………………..…………95

Figura3.15:RadardellaSurvey“Trasparenza”…………………………………….……….……………….…..96

Figura3.16:RadardellaSurvey“Cooperazione”………………………………….………………..……..……97

Figura3.17:RadardellaSurvey“ValorediBusiness”…………………….……………………………………98

Figura3.18:RadardellaSurvey“TempoSprecato”………………………………………..…………………..99

Figura3.19:RadardellaSurvey“Qualità”…………………………………………………….………………..…100

Figura3.20:RadardellaSurvey“GestionedeiRischi”……………………………………………….……..101

Figura3.21:RadardellaSurvey“Soddisfazionedelteam”……………………………………………..…102

Figura3.22:RadardellaSurvey“Adattabilità”………………………………………………..……………..…103

Figura3.23:QuestionariodiautovalutazioneperiteamdiSAFe……………………………….……..106

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

9

Strutturadellatesi

Questolavoroditesièdivisointrecapitoli:nelprimovengonodescrittiilcontesto,

l’approcciotradizionaleallosviluppodeisoftwareelostatodelleprincipalimetodologie

Agile;nelsecondocapitolovieneaffrontatoilproblemadell’applicazionedeimodelliAgilein

organizzazionidigrossedimensioniedanalizzatelesoluzionisviluppate,conparticolare

attenzionealframeworkSAFe;nelterzocapitolosipresentailcasodistudiodella

transizionedaunastrutturaorganizzativaWaterfalladunaAgilepressoTagetikSoftware.

Figura1.0:Strutturadellatesi

1)Analisidelcontesto,metodologietradizionalie

modelliAgile

2)ProblemadiapplicazionedeimodelliAgilein grandiorganizzazioni,lenuove

soluzioniemerse

3)Casodistudio:transizionedaWaterfallad

AgileinTagetik

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

10

1. Introduzione

1.1. Contestogenerale

L’industriadeisistemisoftwareècaratterizzatadaduefattoriincostantecrescita,lavelocità

divariazionedeirequisitidegliutilizzatorielacomplessitàdeisoftware,questielementi

rendonoisistemisoftwaresemprepiùfragiliedifficilidamantenere,leimpreseper

sopravviveredevonoessereingradodirispondereinmanieraflessibileaicambiamenti

richiestidalmercato(Leffinwell,2011).

Per“metodologieAgile”siintendeuninsiemedimodelliorganizzativi,basatisuprincipi,

ruoliepratiche,sviluppatinelsettoredell’InformationTechnologypergestirelaproduzione

disoftware.Lemetodologie,inizialmentechiamateLightweightMethods,sisonosviluppate

ediffuseapartiredaglianni’90comereazioneadapproccipiù“pesanti”qualiilmetodo

tradizionaleWaterfall(Weinberg,2003).

Nelfebbraio2001diciassettesviluppatori,tracuipersonedispiccoegurudell’informatica,si

riunironoperdiscuteredeilimitidegliapproccitradizionali,valutarelenuovepratichee

metodologieemerseedesploraremodipiùefficaciperprodurresoftware,ilrisultatodi

questomeetingfuilManifestoAgile,documentodiriferimentopergliapprocciLean-Agile

allaproduzionesoftware.IlManifestodefiniscedeiprincipi,deivaloriguidaedegliobiettivi

perleorganizzazioni,manonspecificaicomportamentinecessariperraggiungerli,per

questonegliannisisonosviluppatemetodologiediverseidentificabilicomeAgileinquanto

conformiaiprincipidelManifesto.

SonostaticondottinumerosistudichehannodimostratocomelemetodologieAgile

riescanoaottenereottimirisultatiinambientifortementedinamicicomequellodell’IT,

aiutandoiteamdisviluppoarispondererapidamentealcambiamentoeadaumentare

costantementeilvaloredelbusiness(SuprikaV.Shrivastava,2008;UrvashiRathod).Le

metodologieAgilehannoottenutounelevatogradodidiffusionenell’industriadeisoftware

(Deemer,2010;NishijimaandDosSantos,2013).Confrontateconimetoditradizionalidi

svilupposoftwarequestemetodologiepresentanovantaggiinterminidiminorTimeto

Market,aumentodellaproduttivitàdellepersone,maggiorallineamentodelprodottoai

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

11

requisitidelmercatoedaumentodellaflessibilità(JyothiandRai,2011;NishijimaandDos

Santos,2013;QumerandHenderson-Sellers,2006).InoltrelemetodologieAgilesisono

dimostratevalideopzioniperaumentarelaqualitàdelsoftware,allineareilsoftwarealle

strategiedibusinessedaumentareilcontrollosulbudgetdellosviluppo(DeAvezadoSantos,

2011;Glaiel,2013;Nerur,2005).

Essereagilisignificaesserecapacidiadattarsirapidamentealcambiamento,attesoo

inatteso,inunambientedinamico,mantenendounastrutturasemplice,orientataal

risultatoeconomico,applicandounastrategiabasatasuiterazionibrevi(Qumerand

Henderson-Sellers,2006).

LemetodologieAgilebendefinisconolestruttureedicomportamentiperiteamdisviluppo,

senzaoccuparsiperòdeilivelligerarchicisuperiori,lasciandoindefinitoilproblemadi

organizzareillavorocomplessivoelerelazionitraiteamnelcasodipresenzadiunnotevole

numeroditeamdisviluppo.L’evoluzioneattualedeimodelliriguardal’applicazionein

contestiorganizzatividigrandidimensioni,inrepartisviluppocompostidacentinaiadi

programmatori.Èinfattiincostanteaumentoilnumerodigrandiorganizzazionipassatead

unapproccioAgileperaumentarelaflessibilitàelavelocitàdirispostaallevariazioni

richiestedalmercato.

Unaseriedistrategieemodellisisonosviluppatiperrisolvereilproblemadiadattarele

praticheAgileingrandicontesti,traquestiSAFe,acronimoperScaledAgileFrameworkè

quelloconmaggiorgradodiffusione.Inquestolavoroneverràapprofonditoil

funzionamentoedanalizzatoilcasodiimplementazioneinun’organizzazionedigrosse

dimensionicomeTagetikSoftware,checontapiùdi80programmatori.

1.2. MetodologiadisviluppoWaterfall

LametodologiadisviluppodelsoftwareditipoWaterfall,initalianoModelloaCascata,

rappresental’approcciopiùtradizionaleallosviluppo.Essaprevedecheilprocesso

complessivodisvilupposiascompostoinfasisequenziali,cheinciascunafasesiarilasciata

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

12

delladocumentazioneechenonsipossapassareallafasesuccessivafinchénonsianostate

svoltetutteleverificheedunriesame,comprendenteilriesamedelladocumentazione,della

faseincorso.Lefasiincuivienescompostoilprocessosonolestessefasitipichedella

produzionemanifatturiera,infattiquestofuilprimomodelloutilizzatoquandosiiniziòa

concepirelosvilupposoftwarecomeattivitàindustrialeanzichéartigianale.

Sebbenevadadatoattoallametodologiaavergiocatounimportanteruolonelsuperarei

limitidell’approccioartigianaleedabbiafissatoilconcettochelosvilupposoftwaredeve

esseresoggettoadisciplinaepianificazione,sonostatemossenumerosecritichesulla

difficoltàdiapplicazionedelmodellonelcontestodellosvilupposoftware.

1.2.1. LefasidelprocessoWaterfall

LefasiincuivienetipicamentescompostoilprocessoWaterfallsono:

Figura1.1:LefasidelprocessoWaterfall

• Studiodifattibilità:sitrattadiunafasefinalizzataadecidereseintraprendereomenoil

progetto.Consisteinunaricercaedanalisidiprogettisimiligiàesistenti,unastima

approssimativadeicostiedeiricavidelprogetto,dellerisorsenecessarieperportarloa

termine,delladifficoltàtecnicaedellecompetenzerichieste.Comeoutputviene

rilasciatoildocumentodiavamprogetto.

• Analisideirequisiti:vengonoidentificatituttiirequisiticheilsoftwaredevepossedere

persoddisfarel’utente,sitrattasiadirequisitifunzionalicheprestazionali,essivengono

descrittidettagliatamenteneldocumentorilasciato.Inalcunicasiinquestafasepuò

Studio difattibilità

Analisi deirequisiti Progettazione Sviluppodel

software

Integrazioneetestdisistema

Manutenzione

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

13

esseregiàrealizzatounpianodeitestpreliminare,ilcuisuperamentofungadarequisito

delprogetto.

• Progettazione:Inquestafasevieneprimadefinital’architetturadimassima(dialto

livello)delsistema,poivengonodefinitelecaratteristichecheavrannoisingolimoduli.

• Sviluppodelsoftware:Glisviluppatoricreanoilcodiceeditestereseguonoitestdi

modulo,danotarechesolitamenteconquestoapproccioilruolodisviluppatoreetester

èseparato.

• Integrazioneetestdisistema:Sicontrollacheciascunmodulocreatofunzioniepoisi

integranocontrollandochedopol’integrazionecontinuinoafunzionare.Vengonosvolte

tutteleverifichenecessarieelavalidazionedelprodottoattraversoilcosiddettotest

Alpha.

• Manutenzione:consisteintutteleattivitàsvoltedalmomentodellaconsegnadel

sistemaalclientefinoallasuadismissione,compreseleverifichedelsoftwaredaparte

dell’utente(Betatest),larisoluzionedibug,ilrefactoringedaltriinterventi.

1.2.2. ElementipositividelmodelloWaterfall

Ilmodellofissadeglistandarddiprofessionalitànonpresentineiprecedentiapprocciditipo

artigianaleallosviluppo;richiedediimpiegaretempoinattivitàdipianificazioneinfasi

antipatedelciclo,permettendodievitaredisostenerecostielevatipervariazioniinfasi

avanzatedisviluppo,sistimacheunproblemaidentificatonellefasiinizialidelciclohain

mediauncostoridottodifattore100rispettoallaricercaesoluzionedelbuginstadi

avanzati;semplicitànelprocessodicontrollo:Ilmodellooffreunapprocciostrutturato,che

procedeattraversofasidiscrete,facilidaspiegareegestire,conmilestonefacilmente

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

14

identificabili.Ilmodellosiprestabeneaprogettiincuiirequisitinonvarianoneltempoela

tecnologiaèstabile.

1.2.3. CritichealmodelloWaterfall

Neltemposonostatemossenumerosecritichealmodello,tutteincentratesulladifficoltàdi

applicazionediunmodellomoltorigido,provenientedall’industriamanifatturiera,nel

contestodellosvilupposoftware.

Ilmodellononpermettediotteneredeifeedbackdall’utilizzatorefinchénonsonostate

svoltetuttelefasidelcicloedilsoftwareèfunzionante.Aquestopuntosesonostati

identificatimaleirequisitidelprodotto,oppuresequestisonocambiatiduranteneltempoil

softwarerisultaobsoletoebisognacominciaredacapotuttoilciclodisviluppo,sostenendo

costimoltoelevati.Inoltreiltemponecessarioapercorreretuttelefasidisviluppoèelevato,

einunambientedinamico,questoaumentalaprobabilitàcheduranteilprocessodi

sviluppocambinoirequisitidegliutilizzatori.

L’attivitàditestingvienesvoltainunafasesuccessivarispettoaquelladicodifica,da

personediverse,questoportainevitabilmenteanumerosilooptraleduefasi.

Elevataburocratizzazionedellavoroperchéilmodelloobbligaausarestandardbasatisulla

produzionediunadatadocumentazioneindeterminatimomenti.

Elevaticostidellafasedimanutenzione,sullaqualetipicamentesiripercuotonoamplificate

tutteleproblematichecreatenellefasiprecedentiedidifettidovutiadunapianificazione

rigida.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

15

1.3. LemetodologiedisviluppoAgile

Neglianninovantalacrescitaesplosivadiinternetreselavelocitàdirispostaalmercatoun

fattoresemprepiùdeterminanteilsuccesso,inoltreirapidicambiamentineirequisiti

richiestidaiclientiportaronoadeiciclidivitadeiprodottipiùbrevi,spessoincompatibilicon

imetoditradizionalidisvilupposoftware.

Inquestoperiodocominciaronoasvilupparsidellemetodologiedisviluppocosiddette

“lightweight”incontrapposizioneall’approcciotradizionalewaterfall,detto“heavyweight”a

causadell’elevatogradodiformalizzazioneeburocratizzazionecherichiedeva.Queste

metodologieeranoincentratesuunaminorformalizzazionedelleattivitàeminorricorsoalla

documentazione,ponendoilfocusinvecesullaqualitàdelsoftwareelasoddisfazionedel

clienteraggiungibiliattraversoilfrequenterilasciodipiccoliaggiornamentidisoftware

funzionante.

DopolastesuradelManifestoAgilenel2001,iniziòadessereusatoiltermineAgilepertutte

lemetodologiechenerispettavanoivalori,iningleseAgileSoftwareDevelopmentspesso

abbreviatoASD.

GliobiettividellemetodologieAgilesono:ilraggiungimentodellapienasoddisfazionedel

cliente;lariduzionedeitempidirispostaallevariazionineibisognidelmercato;l’aumento

dellaqualitàdelsoftwareedilmiglioramentodell’efficaciaeddell’efficienzadelteam,

traducibileinunariduzionedeicostiedeitempidisviluppo.

Cisonodunquevariemetodologiechepossonoesserechiamateagili,inquantoconformigli

11principiedi4valoriispiratoridelManifesto:lepiùdiffusesonoScrum,Extreme

Programming,FeaturesDrivenDevelopment,Crystal,DynamicSystemsDevelopment

Method,ingeneraletuttequestesonoaccomunatedalleseguenticaratteristiche:

1.3.1. CaratteristichedellemetodologieAgile

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

16

• Sviluppoiterativo:Illavorocomplessivoevolveperiterazioni,cioèbrevitimeboxlacui

duratatipicamentevariadaduesettimaneadunmese.Questosignificacheillavorodei

teamdisviluppoèpianificato,eseguitoecontrollatosuquestointervallotemporale,al

terminedelqualevienerilasciatounpiccoloincrementodisoftwarefunzionante.

Ilprocessodiscomponimentodellavoropersviluppoiterativotentadiridurreilrischio

complessivodiunprogettoinrischidiminorentitàlegatiarilascipiùpiccoli,questo

permettediavererapidifeedbackdalmercato,edipoterattuarerapidiinterventidi

adattamentoemiglioramentosulsoftwarerealizzato.Perrilasciareunprodottopossono

essererichiestemolteiterazioni.

Figura1.2:Losviluppoiterativo

• Teamcross-funzionaliedauto-organizzati:Inciascunaiterazioneilteamdeveessere

gradodisvolgereautonomamentetutteleattivitànecessariearilasciareunincremento

delsoftware,questosignificacheilteamdeveavereall’internolecapacitàperpoter

svolgereattivitàdipianificazione,analisideirequisiti,design,codificazione,testdiunità

etestdiaccettazione.

Devequindiavereall’internoalmenocompetenzeorganizzative,diprogrammazione,di

testingedeirappresentantidellavocedelcliente.Imetodiagilipreferisconoinoltrela

comunicazioneintemporealeefacciaafacciatraimembridelteam,quindiè

fortementeconsigliatalaco-localizzazionedeimembridelteam.

• Coinvolgimentodelcliente:PuòavveniredirettamentecomeinExtremeProgramming,

doveilclientepartecipaanchealleriunionidelteam,oppureattraversorappresentanti

dellasuavocecomeinScrum.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

17

• Qualitàdelcodiceeproprietàcollettiva:Tuttelemetodologieagiliconcordano

sull’importanzadicrearecodicesempliceediqualità.Ilcodicenondeveappartenereallo

sviluppatorechelohacreato,madeverispettaredeglistandarddiqualitàche

permettanodiessereconsideratodiproprietàdituttiglisviluppatori.Èfondamentale

infatticheessosiafacilmenteleggibiledatuttiiprogrammatoriaffinchéinfasedi

manutenzioneciascunosiaingradodicomprendereilcodiceedoperarvici.

Ivantaggiperiteamdieffettuareconsegnefrequentisonodiversi:possibilitàdicominciare

l’interazioneavendogiàadisposizioneunbloccodicodicefunzionante;nelcasodiritardi

sugliobiettividelprogettocompletopossibilitàdiconsegnarecomunquequalcosaconcui

lavorarealcliente;possibilitàdiutilizzareilclientecometesterottenendoinformazionipiù

precisesuirequisiti.

Test:Lemetodologiesicaratterizzanoancheperundiversoutilizzodeitest,esistonotretipi

ditest:

• testfunzionali,finalizzatiaverificarecheilsoftwaresvolgalafunzionalitàpianificata;

• testunitari,finalizzatiaverificarecheogniunitàopartedelcodicefunzioni

correttamente;

• testindiretti,effettuatidalclientesuunanuovaversionedelsoftware.

Neimodelliwaterfalliltestingavvenivainunaspecificafasedelciclodisviluppo,successiva

aquelladiprogrammazione,ederasvoltodapersonediverserispettoalteamdi

codificazione.Inevitabilmentesigeneravaunlooptraquesteduefasiformalmenteseparate,

finoalsuperamentodeitest.Nellemetodologieagiliinvecequesteduefasivengonosvolte

diparipasso,oalmenosempreall’internodellastessaiterazione,dandolapossibilitàdi

effettuareconsegnefrequentidipiccolepartidicodicegiàtestato.Lacondizioneidealealla

qualemiranolemetodologieAgileècheogniparteinfinitesimaledelcodicesiatestata

nell’istantesuccessivoallacreazione.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

18

1.3.2. LepraticheAgile

CiascunametodologiaAgilesiappoggia,perlosvolgimentoquotidianodellavoroa

numerosepratiche,lamaggiorpartedellequalisonocomuniallediversemetodologie.

L’organizzazioneimplementantedevecapirequalisonolepratichedicuihabisognotenendo

contodellepropriecaratteristiche,deibeneficiedelleconseguenzecheciascunadiesse

comporta.

Lepratichepossonoessereraggruppateinpratichedigestione,pratichedelsoftwaree

pratichedisviluppo,vediamonealcuniesempi:

• Pratichedigestione:on-sitecustomer,dailystand-up,sprintplanning,openwork

area.

• Praticherelativealsoftware:Simpledesign,CollectiveCodeOwnership.

• Praticherelativeallosviluppo:Pairprogramming,unittesting.

Le15pratichepiùutilizzatedalleorganizzazioniAgilesecondounaricercadel2013di

VersionOne,aziendaspecializzatanellaconsulenzaAgile:

Pratica Percentualediadottanti1 Dailystand-up 85%2 Sprintplanning 75%3 Retrospettivadisprint 74%4 Testdiunità 72%5 Releaseplanning 70%6 StimadiBurndown 69%7 Velocity 60%8 ContinuousIntegration 58%9 Automatedbuilds 56%10 Codingstandards 55%11 Productownerdedicatoperteam 55%12 IntegratedDevelopment 50%13 Refactoring 47%14 Digitaltaskboard 45%15 Spaziodilavoroaperto 44%

Figura1.3:LepraticheAgilepiùutilizzate

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

19

1.3.3. IlManifestoAgile

“IlmovimentoAgilenonècontrarioall’utilizzodimetodologie,piuttostol’obiettivoèquello

didarenuovamentecredibilitàallemetodologie,inuncontestoincuilaburocratizzazione

eccessivarendequestepocoefficaciedefficientinelraggiungeregliobiettivi.

L’obiettivoèquellodirestaurareunasituazionedibilanciamento.

Vabeneutilizzaremodelli,maquestonondevesignificareaverediagrammipolverosied

inutilizzatichiusiinunufficio,vabenecrearedocumentazione,manoncentinaiadipagine

chenonpotrannoesseremantenute,echeresterannoinutilizzate.Noipianifichiamo,ma

riconosciamoilimitidipianificareinunambienteturbolento”-IlManifestoAgile-

IlManifestoAgileèilrisultatodellavorodiungruppodiprogettistisoftwaredimassima

fama,tracuiKentBeck,RobertC.Martin,MartinFowleredaltriveriepropriguru

dell’informatica,chesiriunirononelfebbraiodel2001conl’obiettivodianalizzareilimiti

degliapproccitradizionalinellosviluppodeisoftware,valutareleemergentimetodologiedi

sviluppoleggereedesploraremetodipiùefficacipersvilupparesoftware.Ipartecipanti,

sonoconvenutisull’importanzadi12principiispiratoridellosvilupposoftwaree4fontidel

valore.

Figura1.4:IlmanifestoAgileinunrepartosviluppopressoTagetikSoftware

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

20

IdodiciprincipidelManifestoAgile:

i. Lanostramassimaprioritàèsoddisfareilclienterilasciandosoftwaredivalore,finda

subitoeinmanieracontinua.

ii. Accogliamoicambiamentineirequisiti,ancheastadiavanzatidellosviluppo.Iprocessi

agilisfruttanoilcambiamentoafavoredelvantaggiocompetitivodelcliente.

iii. Consegniamofrequentementesoftwarefunzionante,concadenzavariabiledaunpaiodi

settimaneaunpaiodimesi,preferendoiperiodibrevi.

iv. Committentiesviluppatoridevonolavorareinsiemequotidianamentepertuttaladurata

delprogetto.

v. Fondiamoiprogettisuindividuimotivati.Diamolorol'ambienteeilsupportodicui

hannobisognoeconfidiamonellalorocapacitàdiportareillavoroatermine.

vi. Unaconversazionefacciaafacciaèilmodopiùefficienteepiùefficacepercomunicare

conilteamedall'internodelteam.

vii. Ilsoftwarefunzionanteèilprincipalemetrodimisuradiprogresso.

viii. Iprocessiagilipromuovonounosvilupposostenibile.Glisponsor,glisviluppatoriegli

utentidovrebberoessereingradodimantenereindefinitamenteunritmocostante.

ix. Lacontinuaattenzioneall'eccellenzatecnicaeallabuonaprogettazioneesaltanol'agilità.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

21

x. Lasemplicità-l'artedimassimizzarelaquantitàdilavorononsvolto-èessenziale.

xi. Learchitetture,irequisitielaprogettazionemiglioriemergonodateamchesiauto-

organizzano.

xii. Adintervalliregolariilteamriflettesucomediventarepiùefficace,dopodichéregolae

adattailpropriocomportamentodiconseguenza.

LequattrofontidelvalorenellaproduzionesoftwaredelManifestoAgile:

i. Gliindividuieleinterazionisonopiùimportantideiprocessiestrumenti:l’auto-

organizzazioneelamotivazionedellepersonesonoimportanti,cosìcometrovarsinello

stessoposto(co-localizzati)assiemealmomentodiprogrammare.

ii. Softwarefunzionanteèpiùimportantediaveredocumentazioneesaustiva,èpiù

importantepresentarequestoaiclientipiuttostocheunadocumentazioneesaustiva.

iii. Collaborarecolclienteèpiùimportantedinegoziareicontratti,infattiirequisitirichiesti

dalclientenonsonofacilidaindividuareall’iniziodelciclodisviluppo,quindiè

importanteuncoinvolgimentocontinuodelclienteedeglialtristakeholders.

iv. Risponderealcambiamentopiuttostocheseguireunpiano,bisognaessereprontia

rispondererapidamenteacambiamentiincorsod’opera.

NeiprossimiparagrafiverrannoapprofonditiilfunzionamentodelleduemetodologieAgile

piùdiffuse,ScrumedExtremeProgramming,metodologieallabasedelfunzionamentodi

SAFeequindinecessariepercomprendereilfunzionamentodelcasodistudioTagetik.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

22

1.4. Scrum

ScrumèadoggiilframeworkAgilepiùdiffusosecondol’aziendadiconsulenzaspecializzata

VersionOne.

L’originedelnomeèdaricercarenelmondodelrugby,Scruminfattiinitalianoètradotto

mischia,sitrattadellasituazionedigiocoincuiigiocatoridellasquadrasicompattanoe

spingonocomeun'unicaentitàcoordinataperraggiungerelapalla.Questasituazioneèuna

metaforadelcomportamentoacuiaspirailmodello,unteamaffiatatochespingeversoil

conseguimentodegliobiettivi.

KenSchwabereJeffSutherland,creatoridelframework,descrivonocosìilmetodonella

guidaufficialeaScrum:“Scrumèunframeworkdiprocessoutilizzatodaiprimianninovanta

pergestirelosviluppodiprodotticomplessi.Scrumnonèunprocessoounatecnicaper

costruireprodotti,mapiuttostounframework[ambientedilavoro]all’internodelqualeè

possibileutilizzarevariprocessietecniche.Scrumrendechiaral’efficaciarelativadelproprio

productmanagementedellepropriepratichedisviluppocosìdapoterlemigliorare”.

Scrumèprogettatopercontestiincuièdifficile,senonimpossibile,unaesauriente

pianificazioneinanticipodituttoilprogetto.Utilizzaquindiimeccanismitipicidiun

processodicontrolloempirico,basatosuciclidifeedback,inopposizioneallagestione

basatasulconcettotradizionaledicommandandcontrol.

Ilframeworkprescrivedeiruoliprecisiall’internodeiteamdisviluppointerfunzionali,dei

comportamenti,degliartefattiedellecerimonieperassicurarsichesianocondottelebest

practices.

1.4.1. LosviluppodiScrum

Nel1986TakeushieNonakadescrisseroin“NewNewProductDevelopmentGame”un

nuovoapproccioallosviluppodeiprodottiemersoneisettoridelautomotivee

dell’elettronica,chemiravaasuperareilimitidelprocessotradizionaleperfasisequenziali.

L’obiettivo,inunambientecaratterizzatodaunasempremaggiorglobalizzazionedei

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

23

mercati,unaumentodellacompetizione,piùrapidicambiamentineirequisitideiclientie

ciclidivitadeiprodottipiùbrevi,eraquellodiaumentarevelocitàeflessibilitàdelciclodi

sviluppo.EssichiamaronoquestiapprocciditipoOlisticooRugby,inquantol’intero

processodisviluppovieneeseguitodaununicoteaminterfunzionalesupiùfasichesi

sovrappongono,dovelasquadra“cercadiraggiungerel’obiettivocomeunità,passandola

pallaavantieindietro”.

Questinuoviapproccifuronosperimentatineiprimianninovantanell’industriadelsoftware

perfarfronteallarigiditàdimodellipiùstrutturaticomeilmodellowaterfall.

KenSchwabereJeffSutherlandsvilupparonoilframeworkScrum,chevennepresentato

ufficialmenteperlaprimavoltaallaconferenzaOOPSLAdel’95.Nel2001glistessiautori

pubblicaronoillibro“AgilesoftwaredevelopmentwithScrum”,diventatoiltestodi

riferimentoperilframework.

1.4.2. IvaloriallabasediScrum

§ Trasparenza:Gliaspettisignificatividelprocessodisviluppodevonoesserevisibiliai

responsabilidellavoro.Latrasparenzarichiedequindididefiniredeglistandardcomuni

inmodotalechegliosservatoricondividanounacomunecomprensionediciòcheviene

visto.

Adesempio:Deveesserecondivisounlinguaggiocomunediriferimentoalprocesso;una

definizionecomunedellaparola“fatto”,ininglese"DefinitionofDone",chepermettadi

stabilireinmanieraunivocatutteleattivitàchesonostatesvoltesulcodicedefinito

“fatto”.

§ Ispezione:ChiutilizzaScrumdeveispezionarefrequentementequantoprodottoedi

progressirealizzativersoilconseguimentodegliobiettiviprestabiliti,individuandointal

modoprecocementeeventualidifformitàrispettoaquantosiintenderealizzare.La

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

24

frequenzadelleispezioninondeveesseretaledadeterminareun'interruzionedellavoro

incorso.Leispezionidevonoessereeseguitediligentementeedaispettoriqualificati.

§ Adattamento:Sechiispezionaverificacheunoopiùaspettidelprocessodiproduzione

sonoaldifuorideilimitiaccettabili,echeilprodottofinalenonpotràessereaccettato,

deveinterveniresulprocessostessoosulmaterialeprodottodallalavorazione.

L'interventodeveessereportatoatermineilpiùrapidamentepossibileperridurreal

minimol’ulteriorescartorispettoagliobiettiviprestabiliti.Scrumprescrivequattro

occasioniformaliperl’ispezioneel’adattamento:SprintPlanningMeeting,DailyScrum,

SprintRevieweSprintRetrospective,sitrattadimeetingdetti“cerimoniediScrum”che

avvengonoregolarmenteogniSprint,garantendolapresenzadioccasioniformalidi

ispezioneedadattamento.

1.4.3. IruolidelteamScrum

UnTeamScrumèformatodalTeamdisviluppo,unProductOwneredunoScrumMaster.

• Teamdisviluppo:ècompostodalletreallenovepersoneedèresponsabiledella

consegnadegliincrementidiprodotto,hacompetenzecross-funzionalidianalisi,

progettazione,sviluppodelsoftware,testedocumentazione.InScrumnonesisteuna

distinzioneformaletrachicreailcodiceechiesegueitest.

• ProductOwner:Èlafiguracherappresentalavocedelclienteall’internodelteam,lasua

responsabilitàèquelladiassicurarechegliincrementidisoftwarerilasciatidalteam

apportinovalorealbusiness.Ilsuocompitoprincipaleconsistenelcomunicarecongli

utentiedefinireirequisitidelprodotto,sottoformadiUserStory.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

25

UnaUserStoryrappresentaunadescrizionediunbisognodell’utilizzatorefinale,oppuredi

unaltrostakeholder,fattainlinguaggiosemplice,perguidarelosviluppodeldevelopment

team.

Ècostruitaseguendounaformamoltosemplice:Inquanto<ruolo>,voglio<…>cosicché

<benefici>.Adesempio:“inquantoutilizzatorevogliopotereffettuarericerchedeiclientisul

databasesiapernomechepercognome”.

UnavoltadefiniteleUserStoriesilProductOwnergliassegnadeivaloridiprioritàele

aggiungealProductBacklog.Infinealterminedellosprintverificacomeessesianostate

implementateinunademodelrilasciodelsoftwareesiassicurachequesteaumentinoil

valoredibusiness.

IlProductBacklogèsemplicementeunalistaordinatadeirequisiticheilteamdisviluppo

deveimplementarenelprodotto.ContieneleUserStoryacuiilProductOwnerhaassegnato

leprioritàinbaseaconsiderazionidirischio,valoredibusinessedatediconsegna.IlProduct

Backlograppresentaquindicosadeveesserefattoedincheordine,èapertoemodificabile

datutti,mailProductOwnerèilresponsabileultimodellasuagestioneedellepriorità,in

quantoconosceleesigenzedeiclienti.

• ScrumMaster:Rappresentaunruolomanagerialeall’internodelteam,nonrappresenta

tuttaviailteamleader,mapiuttostocoluichefacilitaunacorrettaesecuzionedelprocesso.

Gerarchicamentenonhamaggiorpoteredecisionalerispettoaglialtrimembridelteam,nel

teamscrumnoncisonogerarchie.

TraicompitidelloScrumMastercisono:rimuoveregliostacolichepossonolimitarele

capacitàdelteamdiraggiungeregliobiettividisprint;assicurarsichesianoapplicatele

normediScrum;presiedereleriunionipiùimportantiefaredafacilitatore;diffonderela

culturaAgilenelteam;ricercarenuovepratichechemigliorinoleperformancedelteam;

teneredegliindicatoridiperformancedelteam;cercaredimigliorareleperformanceeporre

sfideaimembridelteam.

Spessovienedescrittocomeunservant-leader,inquantoèunleadergerarchicamentenon

superiorealteam,maalcontrarioalsuoserviziosvolgendounafunzionedicuscinettoche

evitiognidistrazionedallavoro.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

26

1.4.4. IlfunzionamentodiScrum

InScrumillavoroavvienepersuccessionidiiterazione,unprogettovienedivisoinfinestredi

lavoro,dettiSprint,delladuratatipicamentediduesettimane,allafinedelqualeilteam

rilasciaunpiccoloincrementodisoftwarefunzionante.Ognisprintèprecedutodauna

riunionedipianificazionedettaSprintPlanningincuisiidentificanogliobiettividisprint,cioè

siprelevanolelestorierealizzabilidalProductBacklogandandoacostruireloSprintBacklog,

cherappresentalalistadellestorieobiettivoperl’iterazione.

Inscrumnonèpermessocambiaregliobiettiviall’internodellosprint,lemodifichesono

quindisospesenell’iterazioneepossonoesserepreseinconsiderazionesolonelsuccessivo

sprint.AlterminedellosprintvienesvoltaunacerimoniadettaSprintReviewincuiilteamdi

sviluppopresental’incrementodisoftwarerealizzato,contenenteleUserStoryportatea

termine,alProductOwnerattraversounademodelsoftware.Loscopocerimoniaè

assicurarsichelestorierealizzatesoddisfinoilclientedicuiIlPOnerappresentalavoce,edil

teampossaotteneredeirapidifeedbacksuquantorealizzato.LaSprintReviewchiudeilciclo

diSprint,dopodiquestailteamsiprendeunpiccolointervalloditempodelladurata

timeboxeddidueoreprimadiaprireunnuovosprintpereseguireunaRetrospettivadi

Sprint,cioèun’analisidicomehalavoratoedeiproblemiriscontrati,finalizzataamigliorare

l’efficaciadelleiterazionisuccessive.

Figura1.5:lefasidiScrum

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

27

1.4.5. EventiecerimoniediScrum

Glieventiprescrittidalframeworksonofinalizzatiacreareregolaritàeridurrealminimola

necessitàdiriunionistraordinarie.Tuttiglieventisonotimeboxedinmodocheabbianouna

duratamassimastabilita,perevitarechesforinorubandotroppotempoalleattivitàdi

produzionedelsoftware.

OgnieventoinScrumfungedaoccasioneformaleperpianificare,ispezionareedadattareil

lavoro,oltrecheaumentarelatrasparenzasuquellochestaavvenendo.

§ SprintPlanningMeeting:Sitrattadiunincontrocheavvieneall’iniziodellosprintper

pianificareillavorodasvolgerenell’iterazione,vipartecipatuttoilTeamScrum.Il

meetingdurageneralmentequattroorepersprintdiduesettimane.Sitrattadiunavera

epropriaattivitàdipianificazionedellaproduzioneadattataalcontestoAgile.Ilteam

selezionadalProductBackloglestoriedasviluppare,lespacchettainsingoletask

realizzabilidauncomponentedelteaminuntempoinferiorealleottoore,elepone

nelloSprintBacklog.Quindiidentificaecreatrasparenzasullavorochesaràportatoa

terminenellosprint.

§ DailyMeeting:Sitrattadiunrapidomeetingdelladuratadi15minuticheilteamtiene

ognimattina.Ognicomponentedelteamdisviluppospiegacosahaportatoatermineil

giornoprecedenteecheimpedimentiallavorohariscontrato,cheattivitàhainmentedi

portareatermineoggiequaliimpedimentiallavoroprevede.L’attivitàpermetteai

programmatoridiaggiornarsirapidamentesullostatodiavanzamentodellavoroedi

pianificarelesuccessiveattività.Duranteilmeetingglisviluppatoriprendono

autonomamenteinconsegnaletaskdarealizzarenellagiornata,Gliimpedimenti

vengonodocumentatidalloScrumMasterpercercarediessererisolti.

Ilmeetingsvolgesemprenellostessoposto,tipicamentenell’ufficiodelteamdisviluppo,

allastessaoraediniziapuntualmenteanchesequalchecomponentedelteamèassente,

haduratadiquindiciminuti.Èanchechiamato“stand-upmeeting”perenfatizzareil

fattocheipartecipantidevonoalzarsiinpiedi,perevitarechesidistragganoallaloro

postazioneocontinuinoasviluppare,edinvecesiconcentrinoquindiciminutisuattività

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

28

dipianificazione.Possonopartecipareancheauditoriesterniperaggiornarsisullostato

d’avanzamentodelleattività.

§ BacklogRefinement:Ilteamdeveimpegnareunaquantitàditempoinferioreal10%del

tempodisponibilenellosprint,pereffettuarequestaattività.

ConsistenelguardareallestoriepresentinelProductBacklogeraffinarloaggiungendo

dettagli,stime,dividendolestorieinstoriepiùpiccole,cambiandol’ordine.Oltrea

questoglielementidelBacklogpossonoessereaggiornatiinqualsiasimomentodal

ProductOwnerasuadiscrezione.

LestoriedelProductBacklogpiùinaltosonopiùchiareedettagliaterispettoaquelle

chesitrovanoinbasso,questoperchépiùprossimeall’implementazione,quindi

caratterizzatedaunminorgradodiincertezza,lestimesonopiùpreciseesibasanosu

unamaggiorechiarezzaemaggiornumerodidettagli.Lestoriedelbacklogche

impegnerannoilteamdisviluppodurantelosprintsonorifiniteatalpuntodaessere

eseguibili,quindinonpresentanoalcunaincertezzesuirequisiti.DuranteloSprint

PlanninglestoriedelProductBacklogchepossonoesseresvoltedalteamdisviluppo

sonodichiarate“Ready”peruneventualeselezione.

IlBacklogRefinementserveproprioperassegnarequestomaggiorgradodidettaglioe

trasparenzaallestorie.

Ilteamdisviluppoèresponsabilepertuttelestime,poichésaràluiaeseguireillavoro.

§ SprintReview:Èunmeetingchesitieneafinesprintconloscopodiispezionare

l’incrementoeadattare,senecessario,ilProductBacklog.

Ladurataètipicamentedidueorepersprintdiduesettimane.IlProductOwner

ispezionacioècheèstatorealizzatoattraversounademoeverificalaconformitàrispetto

aquantopianificatonelloSprintPlanning,chesiarispettatalaDefinitionofDone,edil

valoreperilclientediquantocreato.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

29

L’obiettivoèpermetterealteamdisviluppodiottenererapidifeedbacksuquanto

rilasciatodalPO,assicurarsichel’incrementoapportivaloreaglistakeholder,ed

eventualmenteadattareilProductBacklogsealcunestorienonvengonoaccettate.

FormalmenteèilmeetingchechiudeilciclodiSprint.

§ SprintRetrospective:

Sitrattadiunmeetingdelladuratadiun’oraemezzoperSprintdiduesettimane.

AvvienedopolachiusuradiunosprintattraversolaSprintRevieweprimadelloSprint

Planningchesegnal’iniziodiunnuovosprint.

Sitrattadiunpiccolointervalloditempocheilteamsiprendeperfermarsiavalutare

comehalavoratonellosprint,cheimpedimentihatrovato,qualeèlostatodelle

relazionipersonaliecomesipotrebbemigliorareinterminidiefficaciaedefficienza.

Èquindiun’occasioneperilTeamScrumperispezionareséstessoecreareunpianodi

miglioramentodaattuarenelprossimoSprint.

LoScrumMasterassicurachel’eventoabbialuogoecheipartecipantinecomprendano

lefinalità,fainoltredafacilitatoreeguidalosvolgimentofacendoassicurandosiche

rispettiladuratamassimaprestabilita.

L’obiettivodelmeetingèquellodiesaminarecomeèandatol’ultimosprintinmeritoa

persone,relazioni,processiestrumenti;identificareeordinareglielementichesono

andatibeneelemiglioriepotenzialiecreareunpianoperattuareimiglioramenti;infine

ilteampianificaimodiperaumentarelaqualitàdelprodottoadattandolaDefinitionof

Done.

1.4.6. GliArtefattidiScrum

GliartefattidiScrumservonoarappresentareillavorooilvaloreinmodotaledafornire

trasparenzaeopportunitàdiispezioneeadattamento.GliartefattidefinitidaScrumsono

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

30

specificatamenteprogettatipermassimizzarelatrasparenzadelleinformazionichiave

necessarieadassicurareaiTeamScrumilsuccessonellarealizzazionediunIncremento.

§ ProductBacklog:Èunelencoordinatodituttociòchedovrebbeessereimplementato

nelprodotto,edèanchel’unicafontedirequisitipossibile.IlProductOwnerè

responsabiledelsuocontenutoedell’ordinedeisuoelementi.Inlineaconl’approccio

delmiglioramentocontinuodiprodottoilProductBacklognonèmaiconsiderabile

completo.

Lasuaprimastesuradefinisceirequisitiinizialmenteconosciutiomegliocompresi,

evolvepoicomeilprodottoalqualesiriferisceel’ambientenelqualeverràutilizzato,

cambiacontinuamenteperidentificarecosaservealprodottoperesserecompetitivo.

Contienerequisitisiaditipofunzionalecheprestazionale,miglioriearequisitigià

presentierisoluzionidiproblemiebug.

§ SprintBacklog:LoSprintBacklogèlalistadellavorocheilteamdisviluppodeve

effettuarenelcorsodellosprint.QuestalistavienegeneratainfasediSprintPlanning

selezionandounaquantitàdistorieapartiredallacimadelProductBackloginmodotale

daavereunaquantitàdilavorocheriempialosprint.

PergenerareloSprintBacklogsistimaprimalacomplessitàdelleprimestoriepresenti

nelProductBacklogepoisiscompongonointaskdicuièpiùsempliceunastimadare

unastimadeltemponecessariodisviluppo,infinesistimalacapacitàore/uomodei

programmatorinellosprintdiriferimento.

Letasknonvengonomaiassegnate,piuttostovengonopreseincaricodaimembridel

teamduranteilDailyscrum,inbasealleprioritàpredefiniteeallecompetenzedei

membridelteam.Questopromuovel'auto-organizzazioneelaresponsabilizzazionedegli

sviluppatori.

LoSprintBacklogèdiproprietàdelTeamdisviluppo,etuttelestimeinclusesono

effettuatedalteamstesso.

SpessovieneutilizzataunaTaskBoardpervisualizzareicambiamentidistatodelletask

nellosprintcorrente,comeadesempio“todo”,“inprogress”e“done”.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

31

Figura1.6:UnaTaskBoardpressoTagetikSoftware

1.5. ExtremeProgramming

Sitrattadiunametodologiadisviluppofocalizzatasullaqualitàdelsoftwareelavelocitàdi

rispostaallevariazionideirequisitideiclienti.

ComelealtremetodologieAgileèbasatasulrilasciofrequentedipiccoliincrementidi

softwaredapartediunteaminter-funzionale,alcunielementitipicidiExtreme

Programmingsonolaprogrammazioneincoppia,ininglesePairProgramming,l’uso

massicciodireviewdelcodiceeditestdiunità,lariduzionealminimodellavorodi

programmazioneeliminandodalprodottotuttelefeaturesnonrichiestedalcliente,la

ricercadimassimasemplicitàechiarezzanelcodice,elacomunicazionefrequentetrail

clienteediprogrammatori.

Ilnomedellametodologiaderivadall’ideadiprendereglielementicheapportanobeneficio

nellosviluppotradizionaledisoftwareeportarliadeilivellidiesecuzione“estremi”.Ad

esempiolereviewdelcodicesonoconsideratepratichecheapportanobeneficio,portatead

unlivelloestremovogliamocheilcodicesiarivistocontinuamente,dandoluogoallapratica

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

32

delPairProgramming;oppurelapraticadelTestFirstportataadunlivelloestremodaluogo

alTestDrivenDevelopment,cioèlacreazioneditestautomaticicheilcodicedovràsuperare

primaancoradiiniziarelascritturadelcodice.

1.5.1. LanascitadiExtremeProgramming

LametodologiaèstatacreatadaKentBeckduranteilsuolavorodaProjectManageralla

ChryslerComprehensiveCompensationSystem(C3).Beckcoprìilruolomanagerdela

partiredal’96,daquelmomentoiniziòaconcepireemigliorarelasuametodologiadi

sviluppo,chedescrisseinunlibropubblicatonel’99daltitolo“ExtremeProgramming

Explained”.

Beckraccontacheduranteilsuolavorochieseinizialmentealteamdisviluppodifareun

pocodiattivitàcheritenevamoltoimportanticometestereview,successivamenteiniziòa

direalteamdispingeresempredipiùsuquestielementi,notandodeirisultatipositivi,

arrivandoinfineall’ideadiportarliall’estremo.

NeiprimianniduemilaXPhageneratounsempremaggiorinteresseinunnumerodi

ambientimoltodiversodaquellodiorigine.L’elevatogradodidisciplinarichiestodalle

praticheoriginalifututtaviaspessoridottodientitàpoichéalcunediquesteeranoritenute

tropporigide,adesempiolapraticadeitestdiintegrazionedasvolgereentrolafinedella

giornatafuspessoridottadifrequenza,comeunavoltaasettimanaoppureentrodelledate

prefissate.

1.5.2. AttivitàdelprocessodisviluppoconExtremeProgramming

ExtremeProgrammingdescrivequattroattivitàbasedelprocessodisviluppo:codifica,

testing,ascoltoeprogettazione:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

33

1- Codifica:Sitrattaovviamentel’attivitàpiùimportantedelprocessodiproduzione

software,senzalaqualenonesisterebbeunprodotto.

2- Collaudo(Testing):L’approcciodiExtremeProgrammingriguardoaitestconsistenel

cercarediaumentareilpiùpossibile,esistonoiseguentitipiditest:

o Testdiunità:Determinanoselafeaturerealizzatalavoracomeprestabilito.Il

programmatoredevescriveretuttiitestautomaticichepossonogarantirecheilcodice

funzioni.Ognipartedicodicescrittadeveesseretestataprimadipassareallafeature

successiva.

o Testdiaccettazione:Verificacheirequisiticosìcomeintesidaiprogrammatori

soddisfinoirequisitidelcliente.

o Testdiintegrazionealivellodisistema:furonoinizialmenteincoraggiaticomeattivitàda

svolgereconfrequenzagiornaliera,alfinediindividuareprimapossibileleinterfacce

incompatibilidariconnettereprimachelesezioniseparatedivergesserotroppoper

coerenzadifunzionalità.Adessol’integrazionealivellodisistemaèstataridottaaduna

frequenzasettimanaleominoreasecondadellastabilitàdelleinterfaccedisistema.

3- Ascoltare:Iprogrammatoridevonoascoltareciòcheilclientevuolecheilsistemafaccia,

percapirequaleèlalogicadibusinessnecessaria.Devonocapirequestibisogni

sufficientementebenedapoterdarealclienteunfeedbacksugliaspettitecnicidicome

possaessererisoltoilproblema.

4- Progettazione:Inteorialosviluppodisistemapotrebberidursialleattivitàdicodifica,

testingeascolto.Sequesteattivitàfosserosvoltebeneilrisultatosarebbesempreun

sistemachefunziona.Nellapraticaperòquestononfunziona,losviluppopotrebbe

procederepermoltotemposenzaattivitàdidesignconilsistemaancorafunzionante,

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

34

maaduncertopuntoilsistemacomincerebbeadesseretroppocomplesso,si

bloccherebbeeledipendenzetralepartiandrebberochiarite.Questopuòessereevitato

progettandodellestrutturecheorganizzinoilsistemalogico,unbuondesignevitamolte

dipendenzedisistema,questosignificachecambiandounapartedelsistemanonsiha

effettosullealtreparti.

1.5.3. IvaloridiExtremeProgramming

NellaprimaedizionediXPdel’99furonoidentificati4valori:comunicazione,semplicità,

feedbackecoraggio.Nellasecondaedizionefuintrodottounquintovalore:Rispetto.

§ Comunicazione:Crearesistemisoftwarerichiedecheirequisitidelprodottosiano

comunicatiaglisviluppatori,questonellemetodologiedisviluppopesantiera

accompagnatodaunadocumentazionesuiRequisitidelProdotto.InXPinvecel’obiettivo

èdareatuttiglisviluppatoriunavisionecondivisadelsistemachecombaciconlavisione

chenehal’utilizzatore.AquestoscopoXPfalevasullacollaborazionetrautilizzatoree

sviluppatore,sullacomunicazioneverbaleesuifeedback.

§ Semplicità:Lasoluzionepiùsempliceèsempreincoraggiata,lefunzionalitàinpiù

possonoessereimplementateinunsecondomomento.Ladifferenzatraquesto

approccioequellotradizionaleèilfocussullosvilupparecodicedicuic’èbisognooggi

invecechetraunasettimanaounmese.Questospessoèsintetizzatoconl’approccio

“Youaren’tgonnaneedit”(YAGNI).C’èconsapevolezzacheunapprocciodelgenerepuò

portareadeimaggiorisforziincasodinecessitàdicambiareilsistemadomani,però

questisonopiùchecompensatidaivantaggidelnoninvestireinpossibilirequisitifuturi

chepotrebberocambiareprimadidivenirerilevanti.

§ Feedback:cisonodiversifeedbackutilizzati:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

35

Feedbackdalsistema:siottienescrivendotestdiunitàosvolgendodeitestdi

integrazioneperiodici,permettonoalprogrammatorediottenereunfeedbackdiretto

sullostatodelsistemadopoaverimplementatodeicambiamenti.

Feedbackdalcliente:Itestfunzionali,anchedettitestdiaccettazione,sonoscrittidal

clienteedaitester.Essidannounfeedbackconcretosullostatodelsistema.Questi

feedbacksonoottenibiliognidueotresettimane,cosicchéilclientepossaorientarelo

sviluppo.

Feedbackdalteam:Quandounclientetirafuoriunnuovorequisitonelplanninggameil

teamdaunastimadirettadeltempochesarànecessarioperimplementarlo.

§ Coraggio:DiversepratichediXPnecessitanodicoraggio,unaèquelladicrearesempreil

codiceperoggienonperdomani,oppureilfareRefactoringdicodicegiàcreatose

necessario,ilchesignificariesaminareilsistemaesistenteemodificarloaffinché

cambiamentifuturipossanoessereimplementatipiùfacilmente.Altresituazioniincuiè

richiestocoraggiosonoadesempiorimuoverecodicediventatoobsoleto,nonostantelo

sforzospesonelcrearlo;oppurecoraggiodipersisteresuunproblemachesembranon

trovaresoluzione.

• Rispetto:Siaversoglialtricheversoséstessi.Adesempiononèpermessorichiederedel

lavorochecompromettaquellochestannofacendoicolleghi;rispettoversoséstessi

mirandosempreadelevatistandarddiqualità.Nessunoall’internodelteamdevesentirsi

nonapprezzatooignoratoalfinedigarantireunaltolivellodimotivazionetratuttii

componentidelteam.

1.5.4. LepratichediExtremeProgramming

Icomportamentidell’organizzazionesonoregolatidapraticheraggruppabiliinquattro

categorie:

Ø Primacategoria:feedbackrapid

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

36

Figura1.7:CiclidiFeedbackinExtremeProgramming

PairProgramming:Ognipartedelcodiceèprodottadaduepersonechelavorano

contemporaneamentesullastessataskallastessapostazione.Unprogrammatorehail

controllodellaworkstationepensaaidettaglidelcodice,l’altroinveceèfocalizzatosulla

visioned’insieme,eriesaminacontinuamenteilcodiceprodottodalprimoprogrammatore,i

programmatorisiinvertonodiruolodopoqualcheora.

Lecoppienonsonofisse,iprogrammatoricambianopartnerfrequentementeaffinché

ognunosiaaconoscenzadicosastannofacendoglialtriprogrammatorietuttimantengano

unacertafamiliaritàconognipartedelsistema.Questohaancheladuplicefunzionedi

migliorarelecapacitàcomunicativetraiprogrammatoriepermettelaCollectiveOwnership

delcodice.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

37

Figura1.8:PairProgramming

Planninggame:Sitrattadellaprincipaleattivitàdipianificazionedellavoro,comeperlo

SprintPlanningdiScrumconsisteinunmeetingcheavvieneunavoltaaiterazione.Il

processodipianificazioneèdivisoinduefasi:

A. Pianificazionedelrilascio:Serveadeterminarequalirequisitiincludereinqualerilascio

delprogrammaabrevetermineequandofaravvenirequestirilasci.Partecipanoal

processodipianificazionesiailclientecheglisviluppatori,ècompostoasuavoltadalle

seguentifasi:

• Faseesplorativa:incuiilclientefornisceunabrevelistadeirequisitiadalto

valoredelsistemacheverrannopoitrascrittiinformadiUserStory.

• Fasedicommitment:nellaqualeglisviluppatorisiauto-committanosulle

funzionalitàchesarannoincluseedecidonoinqualidate.

• Fasediesecuzione:nellaqualeilpianopuòessereaggiustato,nuovirequisiti

possonoessereaggiuntiegliesistentipossonoesseremodificati.

B. Pianificazionedell’iterazione:sipianificanoleattivitàchedovrannosvolgeregli

sviluppatori,inquestafasenonsonopresentiiclienti,anchequestapianificazioneè

scomponibileintrefasi:

• Faseesplorativa:sitraduconoirequisitiintaskdaeseguire.

• Fasedicommitment:Letasksonoassegnateaiprogrammatorieviene

stimatoiltempodiesecuzione.

• Fasediesecuzione:Letasksonoeseguiteedilrisultatoèconfrontatoconle

UserStoryiniziali.

TestDrivenDevelopment:InExtremeProgrammingitestautomaticichedovrannosuperare

lesingolepartidicodicevengonoscrittiancoraprimadellafasedicodificazione.Questoè

fattoperstimolareilprogrammatoreapensareallecondizioniincuiilcodicefallirebbeiltest

durantelascritturadelcodice.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

38

Figura1.9:LefasidelTestDrivenDevelopment

IlTestDrivenDevelopmentèbasatosulleseguentifasi:Perprimacosavienescrittountest

diunitàchenondovrebbeesserepassatodalcodiceattualeperchélafunzionalitànonè

stataimplementata.Ilprogrammatoreverificacheilcodiceeffettivamentefallisca.

Doposiiniziaascrivereilcodice,tuttaviavienescrittasoltantounaquantitàdicodice

minimaperpassareiltest,siverificacheeffettivamenteilcodicepassiiltest,dopodiché

andiamoamigliorareilcodicequalitativamenteedeliminiamotuttiipuntididebolezzache

potrebberoportareadebitotecnico,assicurandosicheilcodicepassisempreitest

automatici.

Ø Secondacategoria:processicontinui

ContinuousIntegration:Ilteamdisviluppodovrebbesemprelavoraresull’ultimaversione

delsoftware.

Dalmomentocheciascunmembrodelteampotrebbeavereversionidifferentidel

programmasalvatelocalmenteconalcunicambiamentiemiglioramenti,essidovrebbero

caricarelaloroversionenelrepositorydelcodiceconunafrequenzadipocheore,oquando

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

39

sonostateimplementatemodificheconsiderevoli,l’integrazionecontinuaserveadevitare

deiritardipiùavantinelciclodisviluppocausatidaproblemidiintegrazione.

Figura1.10:ContinuousIntegration

DesignImprovement:PoichéXPchiedediprogrammaresoloquellonecessarioperoggiedi

implementarlonellamanierapiùsemplicepossibilealcunevoltesipotrebbearrivareaduna

situazioneincuiilsistemarestabloccato,unsintomodiquestoèilbisognodiduetipidi

manutenzione:cambiamentineirequisitifunzionalirichiedonocambiamentiinpiùcopie

dellostessocodice.Unaltrosintomoèchecambiamentiinunapartedelcodicevannoad

interessantediversealtreparti.ExtremeProgrammingprevedeinquestesituazionidifare

refactoringdelcodiceecambiarel’architettura,rendendolapiùsempliceegenerica.

Ø Terzacategoria:condivisionedelleconoscenze

Standarddelcodice:Sitrattadiaccordisulleregoleacuiilteamdisviluppoaderiscenel

progetto.Specificanounostandardedunformatoperilcodice,unasceltadellinguaggiodi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

40

programmazione,edalcunipatternecostruttichedovrebberoessereevitatiperridurrela

probabilitàdierrori.

CollectiveCodeOwnership:Ogniprogrammatoreèresponsabilepertuttoilcodice,ne

conseguetuttisonoautorizzatiacambiareognipartedelcodice.Questapraticapermettedi

aumentarelavelocitàdiprogrammazione,perchéquandoqualcunoindividuaunerrorepuò

subitointervenire.Sipuòcreareilproblemacheunprogrammatorepotrebbeinseriredegli

errorinelcodice,perchénonaconoscenzedialcunedipendenze,itestdiunitàminimizzano

questorischio.

SimpleDesign:L’approcciocorrettoècheildesignpiùsempliceèsempredapreferire.Ogni

voltachevienescrittounnuovopezzodicodicel’autoresidevechiedereseesisteunavia

piùsempliceperintrodurrelastessafunzionalità,selarispostaèpositivadeveutilizzare

quellastrada.Allostessomododeveesserefattorefactoringdelcodiceperrenderlopiù

semplice.

Ø Quartacategoria:salutedeiprogrammatori

Ritmodilavorosostenibile:Iprogrammatorinondovrebberolavorareperpiùdiquaranta

oreasettimana,sesisuperaquestasogliaunasettimanaquestanonpuòesseresuperatala

successiva.

Infattiillavorovienedivisoinpiccolirilascicontinui,nonpuòessererichiestolavoro

straordinariovicinoallescadenze,perchéquestenonrappresentanoun’eccezione.

Lepersonehannodelleperformancemiglioriquandoriposate.Unachiaveperraggiungere

questoobiettivoèlaqualitàdelcodice,codicebentestato,integratocontinuamente

minimizzalafrequenzadiproblemiinaspettaticheportanoalavoroextra.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

41

2. LemetodologieAgileinorganizzazionidi

grossedimensioni

2.1.1. IlimitidellemetodologieAgiletradizionalineiprogettidi

grossedimensioni

IprincipaliframeworkAgile,comeScrumedExtremeProgramming,sisonosviluppatiin

contestiorganizzatividipiccole-mediedimensioni,repartisviluppocostituitidapochiteam

multifunzionali,ognunocompostodaunnumerolimitatodipersone.

Sebbenenonesistaunadefinizionepuntualesulledimensionidiunrepartosviluppo

software,possiamoprendereilvaloredi20-30sviluppatoricomespartiacquetraunapiccola

edunagrandeorganizzazione.ll70%deirepartisvilupponell’industriadelsoftwareha

dimensioniinferioriallediecipersone(Ambler,2005),laquotarestantearrivainveceapicchi

dicentinaiadisviluppatori.L’elevatapresenzadiorganizzazionidipiccoledimensioni

giustificaladiffusionedellemetodologieAgile,comevistonelprimocapitoloibenefici

apportatidallemetodologieAgilealleperformanceaziendaliinquestiambitisono

ampiamentedimostratidallaletteraturascientifica.LemetodologieAgileriesconoad

ottenereottimirisultatiancheincontestipiùgrandi,laloroimplementazionerichiedeperò

diapportarealcunevariazioniedadattamentideimodellialcontesto.

Alcunideilimitidell’applicarelemetodologieAgilecomuniincontestidigrossedimensioni

sono:

• Coordinamentotraiteam:lemetodologieAgileprevedonoche,perogniiterazione,i

teamautonomamentepianifichino,svolganoecontrollinoillavorodarealizzare,conuna

totaledecentralizzazionedecisionale.Questoapproccioèresopossibiledalfattoche

ciascunteamèspecializzatosuunaopiùfunzionidelprogramma,sullequalirilascia

miglioramenticontinui.L’approcciofunzionabenefinchéilnumeroditeamèlimitato,al

disottodeitreoquattro.Inquestesituazionièfacileperiteamcontrollarele

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

42

problematicherelativeaareedilavoroconfinantietrovareiltempoperpianificareuna

roadmapcomune,lenecessitàdicoordinamentosonofacilmenterisolvibilicondei

meetingnontroppoformali.

Insituazioniincuiilnumeroditeamèelevatoquestoapprocciorisultainvecemolto

difficiledagestire:diventanonecessarideglistrumentiedeimeetingpianificatifinalizzati

acoordinareillavorodeidiversiteam,evitaresovrapposizioni,risolvereledipendenze.

Adesempiosonocomunisituazioniincuiunteamhaleattivitàbloccateperchéattende

delcodiceiningressoprodottodaunaltroteam,risultanonecessarideglistrumentiper

identificarelasequenzadiattivitàedevitareilcrearsidicollidibottiglia.

• Allineamento:insituazioniampienonbastacheciascunteamidentifichidasoloil

propriobacklog,spessoèpreferibilecheilteambacklogsiaottenutocomedeployment

diunbacklogpiùgrandediprodotto;inquestesituazioniilteambacklogpuòessere

ottenutoinmanierapocodettagliatadaunproductbacklogcomplessivo,epoi

dettagliatopiùapprofonditamentedalProductOwnerdelteam.Ingrandiorganizzazioni

diventaimportantetrovaredeimeccanismiperallineareillavorodelrepartosviluppo

conquellodellealtrefunzioniaziendali.

• Evoluzionedell’architettura:IlmanifestoAgilesostienechelemiglioriarchitetture

provengonodabasso,cioèdateamAgilechesiauto-organizzano,variandolastruttura

esistenteecostituendonuovestruttureorganizzativesoloquandonecessarioper

rilasciareunnuovoincrementodelsoftware.Questoapproccioinuncontestoconun

numeromoltoelevatoditeamnonpuòbastaredasolo,portandoinevitabilmentea

crearedelleridondanzedirisorseedinefficienze,risultaimpossibilepericomponentidi

unteamaverelavisioned’insiemesull’architetturacomplessivadell’organizzazione.

• Governance:Ingrandiorganizzazionièimportantecreareunsistemadicontrollodelle

prestazionideiteam,dibudgetingedanalisideicosti;deveesserepresenteunsistemadi

comunicazionebidirezionaleconl’altadirezione.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

43

Nell’industriasonopresentiunelevatonumerodiorganizzazioniconteamdisviluppo

grandi,chevoglionoapplicaredellemetodologiedirispostarapidaall’ambienteper

perseguireunvantaggiocompetitivo.LemetodologieAgilesonoormaidiffuseanchein

questicontesti,laloroapplicazioneinizialmentevedeval’utilizzodipratichediproject

managementtradizionaliperlagestionedipiùteamAgileseparati,ottenendounapproccio

Agileneiteamdisviluppoedunotradizionaleailivelligerarchicisuperiori;successivamente

sisonosviluppatealcunepratichecomelacreazionediteamAgilecompostidaaltriteam

perscalarel’organizzazioneAgileanchealivelligerarchicisuperiori;infinesisonosviluppati

ediffusialcunimodellidedicati,comeSAFe,cheprescrivonoiruolielepratichepertuttii

livelligerarchiciaziendali,conl’obiettivodiottenereilcompletoallineamento

dell’organizzazione.

Questaèladirezioneseguitanegliultimiannidamolticolossidell’informaticacomeGoogle,

Yahoo,Spotify,Microsoft,passatiadunastrutturaorganizzativaAgile.

2.1.2. IprimitentatividiapplicazionedellemetodologieAgilein

organizzazionidigrossedimensioni

Permantenereilcontrollodeiprocessiincontestilavorativiestesil’inclinazionenaturaleè

quelladiintrodurreulterioristratimanagerialienuoviprocessidicontrollo(Trivellas&

Drimoussis,2013),perquestomotivomoltedellepraticheestrumentiintrodottipergestire

progettiAgiledigrandidimensionisonoglistessiutilizzatinellagestionetradizionaledei

progetti(Papadopoulos,2014).Adesempio,neiprimitentatividiscalarelemetodologie

Agile,èsubitoemersal’esigenzadiintrodurreunteamdiarchitettidistruttura,teamdi

integrazionedelcodiceegestionedellaqualità.

Latendenzaadintrodurreulterioristratimanagerialigerarchizzaticontrastaconlafilosofia

allabasedell’Agile,alfinedirispettareivaloridelManifestoAgilesidevecercaredi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

44

mantenerelastrutturaorganizzativalapiùpiattapossibile,conpiùteamestratigerarchici

solosestrettamentenecessario(Ambler,2006).

Neiprogettidiscalaelevataladifferenzapiùgrandetral’applicarelemetodologieAgilee

l’approccioWaterfallèchequest’ultimoprevedeunosviluppobassatosufasisequenziali,

doveciascunteamconfinalamaggiorpartedelleattivitàsvolteall’internodiun’unicafase.

Conl’Agileillavorocomplessivoèorganizzatosuiterazionicontinue,nellequalituttiiteam

lavorano.Inizialmentelemetodologiesonostateapplicateingrandicontesticonun

approcciotradizionale,ovveroiprogrammatorivenivanodivisiinteamspecializzatiedil

lavorocomplessivoscompostoedassegnatoaiteam,ognunodeiqualilavoravainmaniera

Agile. Ènatasubitol’esigenzadiunagestionedeirequisitichegarantissemaggior

trasparenzaepermettesseilcoordinamentodellavorointer-team:mentreneiprogettidi

piccoledimensioniirequisitidaimplementarepossonoesserescrittiinmanierasemplicein

backlogcartacei,conmoltiteamènecessariodigitalizzarliegestirliinmanierachesiano

riassumibilisuununicoProductBacklogcomplessivo,contenentealcunestimedibasesullo

sforzorichiestoelepriorità.L’approccioquindiconsistevaneldividereteamgrandiinsotto-

teampiùpiccoliecoordinarneillavorocontrollandolacoerenzadeibacklog.

2.2. Losviluppodimodellispecializzatinelloscalarele

metodologieAgile

Sullabasedelleesperienzeacquisitenell’implementazionedimetodologieAgileincontesti

digrandidimensioni,sisonosviluppatinegliultimiannideimodelliprogettatiadhoc,

finalizzatiagarantirel’allineamentodituttelepartiaziendali.

Iframeworkchehannoraggiuntounelevatogradodidiffusionesono:

• SAFe:ScaledAgileFramework,diDeanLeffingwell

• DAD:DisciplinedAgileDelivery,diScottAmbler

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

45

• LeSS:Large-scaleScrum,diCraigLarmaneBasVodde

AlcunicoachAgilecondecennidiesperienzasulcampoefiguredispiccoprovenientidalla

ScrumCoachAlliance,tracuiRichardDolman,StevenSpearman,DaveCornelius,BobGalen,

hannocondottounostudiosuquestimodelliconloscopodifornireunaguidacomparativa

basatailpiùpossibilesucriterioggettivi,facilmenteutilizzabiledalleorganizzazioniper

scegliereilmodellochemegliosiaddiceallapropriasituazione.

LostrumentocreatoèunamatricecomparativachiamataASK(AgileScalingKnowledge)

utilizzabiledalleorganizzazionipercapirequalemodellosiaddicedipiùalleproprie

caratteristiche.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

46

Figura2.1:lamatriceASK

LaricercahacondottoalleseguentivalutazionisuSAFeinrelazioneaglialtrimodelli:sitratta

delmodellocheharaggiuntoilpiùelevatogradodidiffusione;ècaratterizzatodaunelevato

gradodicompletezza,inquantoregolaedallineailfunzionamentodituttelelegerarchie

aziendali;garantisceunelevatocoordinamentotraiteam,adiscapitoperòdellaflessibilità

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

47

cherisultanonaltainquantositrattadiunmodellomoltoprescrittivo;icostidi

implementazionesonopiuttostoelevati;risultaadattoadimpresedidimensioni

particolarmentegrandi;sonodisponibiliopensourcetutteleinformazionisul

funzionamento,maèconsigliatopartecipareadeicorsidiformazione,rilascianti

certificazione,perimplementareilmodello.

2.3. ScaledAgileFramework(SAFe)

2.3.1. IntroduzioneaSAFe

SAFeèunacronimoperScaledAgileFramework,sitrattadiunmodellocreatodaDean

Leffingwellconl’obiettivodiapplicarelemetodologieAgileinorganizzazionidigrosse

dimensioni.Ilsuoimpiegopuòessereopportunoinaziendeconcentinaiadiprogrammatori,

chelavoranocontemporaneamentesiasuprogrammiinfunzionamentochesunuovi

programmi.

LeprincipalimetodologieAgile,comeadesempioScrum,funzionanomoltobenealivellodi

team,manondefinisconoleattivitàperilivelligerarchicisuperiori.Inprogettidigrosse

dimensioni,dovelavoranounelevatonumerodiprogrammatori(prendendocome

riferimentounnumerosuperiorea30)osituazioniincuil’organizzazionehaunportafoglio

differenziatodiprogrammi,risultanecessarioandareadefinireicomportamentiditutta

l’organizzazionesevogliamochesiagarantitol’allineamentotraidiversilivelligerarchici

evitandoilcrearsidiunasituazionecaotica.

SAFedefinisceunmodelloorganizzatosutrelivelligerarchiciaziendali:Team,Programe

ProgramPortfolio.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

48

Figura2.2:IlivellidiSAFe

IteamdisviluppoinSAFesonocompostidalletreallenovepersoneesiorganizzano

esattamentecomedeiteamAgile.Sitrattaquindiditeaminterfunzionaliedauto-

organizzati,chelavoranosuiterazionididuesettimanealterminedellequalirilascianoun

softwarefunzionante.

TipicamenteiteamdisviluppolavoranoseguendoilframeworkScrum,masonoliberidi

accrescerelelorocapacitàapplicandopraticheprovenientidaExtremeProgrammingo

Kanban.Unsingoloteamhaall’internotuttelecompetenzenecessariepercreare

incrementidisoftwareinmanieraautoma:identificazionedeirequisiti,scritturadelcodicee

esecuzionedeitest.

IllivellodeiteamAgilerappresentalabasedelmodello,soprailqualeècostruitoilsecondo

livello,dettolivellodiProgram:aquestolivellodiversiteamAgilevannoacostituireunteam

deiteam,inSAFechiamatoReleaseTrain,chelavorainmanieracontinuativasuununico

programma.IlReleaseTrainècompostodai7ai15teamedinmediadai50ai150individui.

Ilnomesirifàallametaforadeltrenoperchécorreininterrottamente,iterazionedopo

iterazione.IlterzolivelloèdettoilProgramPortfolio,edèillivellochegestisceilportafoglio

deiprogrammi-progettisucuihadiversificatol’azienda,suciascunodeiqualilavoraun

singoloReleaseTrain.Aquestolivellosihannoleresponsabilitàperlestrategieegli

investimenti,sigestisconoiflussidivaloreesisvolgonoleattivitàdigovernance.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

49

Ilmodelloèstatocreato2011daDeanLeffingwell,professionistaspecializzatodadecenni

nell’implementazionedimodelliLeaneAgile,assiemeadaltrispecialisticomeAlexYakyma,

DrewJemilo,RichardknastereInbanOren.Haottenutounarapidadiffusionenelsettore

diventandorapidamenteilmodelloAgileperorganizzazionidigrandidimensionipiù

adottato.Traleaziendecheutilizzanoilmodellosonopresenti:Intel,LegoDigitalSolution,

TomTom,AccentureTechnology,BigITShop,bmcsoftware,Telstraemoltialtri.SAFeviene

periodicamenteaggiornatoconmiglioramentiprovenientidalleesperienzediutilizzo.

2.3.2. IlfunzionamentodiSAFe

Figura2.3:Visioned’insiemedelmodelloSAFe

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

50

Analizzandolastrutturadisviluppoconunapprocciotop-downabbiamochel’insiemedi

tuttiglisviluppatori(intesiinun’otticaallargatacomprensivaditester,ScrumMastere

ProductOwner)èdivisoinReleaseTrain(trenidirilascio),ciascunodeiqualilavoraatempo

pienosuunsingoloprogrammaoprogetto.

UnReleaseTrainècompostodallecinquantaallecentocinquantapersone,suddivisealoro

voltainteamdisviluppo,ciascunteamdisviluppolavorasuunaspecificapartedel

programma,edèorganizzatotipicamentesecondoilframeworkScrum,anchesepuò

accrescerelepropriecapacitàconpraticheprovenientidaExtremeProgrammingoaltri

frameworkAgile.

PropriocomeinScrumilteamlavorasuiterazionididuesettimane,chiamateSprint,al

terminedellequalirilasciaunincrementofunzionante.

Suquestiintervallidelladuratadiduesettimaneilteampianificaillavoronecessarioper

rilasciarel’incremento,creailcodiceedesegueiltesting,esegueunriesameeduna

retrospettiva.IllavorovienepianificatoprelevandoleUserStorydaunTeamBacklog,

ottenutocomedeploymentdiunbacklogpiùgrandediprodotto.

Ilteamdeiteam,chevaacostituireilReleaseTraindelprogramma,lavorainvecesu

iterazionipiùlunghechiamateProgramIncrement,delladuratapariaseiiterazionideiteam.

Alterminedell’iterazioneilReleaseTrainpuòrilasciareunanuovaversionedelprogramma,

serilasciareeffettivamentesulmercatoilsoftwareomenoèunasceltacommerciale,mail

softwareèprontoperessererilasciato.VediamocomeilrequisitodellemetodologieAgiledi

sviluppareincrementalmenteilsoftwareattraversoiterazionivienerispettatosiadaiteam

chedalReleaseTrain,chepossiamoconsiderarecomeunveroeproprioteamAgileicui

membrisonoaltriteam.

RispettoaiteamdisviluppoilReleaseTrainlavorasuiterazionipiùlunghe,svolgendoogni

iterazioneleattivitàprevistedalciclodiDeming:Plan-Do-Check-Act,alfinedimigliorare

continuamenteleproprieperformance.Particolarmenteimportanteèilmeetingdi

pianificazionedell’iterazionediReleaseTrainchiamatoReleasePlanning,dalqualederivail

deploymentaisingoliteamAgile.IlReleasePlanningèilmomentopiùimportantediSAFe,

rappresentailcuoresucuièfondatoilframework:sitrattadiunmeetinglungotipicamente

2giorni,chehaunaduplicefunzionalità,oltreapianificarel’iterazioneserveancheacreare

unsensodiappartenenzaaltrenotraimembrideidiversiteam.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

51

Allineagliobiettivitraimembridituttiiteamecoordinaglisforziperraggiungerli,inoltre

ricordaaimembrideisingoliteam,chetipicamentelavoranoinambientiseparati,di

appartenereadununicoteampiùgrande.Duranteilmeetingtuttiimembrideiteamdel

trenosiriunisconorendendopossibilelaconversazionefacciaafaccia,descrittadal

ManifestoAgilecomeprincipalemotorepergliincrementi.

PropriocomeunteamAgileilReleaseTraincomprendeunProductManager(equivalente

adunProductOwnerdelteamScrum)chesioccupadigestireilProgramBacklog,edun

ReleaseTrainEngineer,chesvolgeunruolodiScrumMasterdeltreno.

IllivellodiProgramPortfoliosvolgeleattivitàtipichedeiverticiaziendali,ilcomportamento

diquestolivellovienetuttaviaincorporatonelmodelloperassicurarsichecisia

allineamentotralestrategieaziendaliedilivellioperativi,echesianoutilizzateletecniche

piùefficaciconunapproccioLean.

2.3.3. IvaloriallabasediSAFe

Ø Allineamento:Èimportantecheilivellidicuisicomponel’organizzazionesianoallineati

versoilraggiungimentodiobiettivicomuni.Questo,perquantopossasembrarebanale,

èunobiettivomoltodifficiledaraggiungere,specieinorganizzazionigrandiecomplesse

dovelatendenzanaturalesenzaunadeguatosistemadicontrolloèl’entropia.Conil

passaggioadunametodologiadisviluppoAgileedildecentramentodecisionaleversoi

teamAgilelatendenzaalcrearsidiunasituazionecaoticapuòcresceresenzaadeguati

sistemidiallineamento.

IlprimoobiettivodiSAFeècreareallineamentoall’internodell’azienda.Ilprocesso

consistenelcreareunastrategiaepoiallinearelepartiversoilsuoraggiungimento.

L’attivitàiniziaalivellodiPortafoglio,doveilverticeaziendale,collaborandocongli

stakeholderinteressati,creaedaggiornaleStrategieevaadalimentareunBacklogdi

Portafoglio,daquisidiscendeallivellodeisingoliprogrammiedanalizzandolaRoadmap

elaVision,sialimentailBacklogdiProgramma;perarrivareinfineaiBacklogdeiTeamdi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

52

sviluppocontenentilestoriedasviluppare.Cisonodeiruolicheattraversodeifeedback

dicontrollosiassicuranocheduranteivaripassaggisiagarantitol’allineamento,comei

ProductManagerdiprogrammaediProductOwnerdeiteam.

Ø Codicediqualità:lacapacitàdirilasciarenuovefunzionalitàintempiridottiereagire

rapidamenteaicambiamentidell’ambientedipendemoltodallaqualitàdelsoftware.

CrearesoftwarediqualitàrappresentaunvaloreportanteintuttelemetodologieAgile,

cheacquisisceancorapiùimportanzaneisistemidigrossedimensionidovel’effetto

cumulativodimoltipiccolidifettipiùdareluogoaconseguenzegravisull’affidabilitàdel

software.Inoltrelaqualitàrappresentaunrequisitofondamentaleperintegrareilcodice

adiversilivelli,l’obiettivoèquellodievitareilcostodiritardidovutiallafrequente

necessitàdirefactoringdelcodiceedirisoluzionedibug.Crearesoftwarediqualitàèun

problemacherichiedesforzoeformazione,mal’investimentoportasicuramenteadei

notevoliritorniinterminidi:

• Soddisfazionedelcliente:Unprodottoconminornumerodidifettiaumentala

soddisfazionedelcliente,congliinnumerevolibeneficicheneconseguonoperil

business.

• Prevedibilitàdellosviluppo:Senzauncontrollodiattendibilitàsullaqualitàdel

softwareèimpossibilepianificarel’introduzionedinuovefunzionalitàoaveredelle

stimesullavelocitàdisviluppodeiteam,siècostrettiadimpiegareunanotevole

forza/lavorosullamanutenzionedelsoftwareeildebug,conripercussionisulla

fiduciadeglisviluppatorieabbassamentodelmorale.Crearesoftwarediqualità

aumentalafacilitàdimanutenzionedelsoftwareelacapacitàdiaggiungere

funzionalitàvelocemente.

• Scalabilità:Quandoicomponenticreatirispettanoglistandardqualitativi,esono

sempliciechiari,èpiùprobabilechesuperinotestdiintegrazioneeinfrastrutturali.

Inquestesituazioniaggiungereteamdisviluppoefunzionalitàalprodottoportaad

aggiungerevalorealbusiness.Sealcontrariononsonorispettatiglistandard

qualitativiaggiungerealtrisviluppatorispessononsolononaggiungevalore,mapuò

ancherallentarel’organizzazione.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

53

• Capacitàdiinnovare:Leinnovazioniarrivanoquandopersonemotivatelavoranoin

unambientestimolante,laqualitàcreaunterrenofertileedunambienteincuile

nuoveideepossonoesserefacilmenteprototipatetestateeprovate.

MoltedellepraticheconsigliatedaSAFepercrearesoftwarediqualitàderivanoda

ExtremeProgrammingesonoconsigliateinmoltiambientiinformatici:

• ContinuousIntegration:consistenelfonderepiùvoltealgiornoilcodiceproveniente

daciascunosviluppatoreconilcodicecomune,cosicchéognisviluppatorelavori

sempresull’ultimaversionedelcodiceeglierrorisianoidentificatiprimapossibile.

LafrequenzadiintegrazioneconsigliatadaSAFeèunavoltaalgiorno,sitratta

ovviamentediunobiettivomoltodifficiledaraggiungere,percuièconsigliatopartire

daunafrequenzadiduevolteperiterazionepercercarediaumentarelafrequenza

conl’esperienza.

L’integrazionecontinuanecessitadiparticolaristrumenticomeserverdedicati,ma

elementoancorapiùimportanteèlaculturadeglisviluppatori.

• Test-First:Unafilosofiacheincoraggiaiteamaragionaresulcomportamentodel

codiceeleripercussionichepuòaveresualtrefunzioniprimadisviluppare.Una

metodologiaottimaaquestoscopoèilTestDrivenDevelopment,descrittanella

sezionesuExtremeProgramming.

• Refactoringdelcodice:Èunadisciplinacheconsistenelristrutturareilcodice

esistente,quindinelmodificarelastrutturainternadelsoftwarelasciandoinalterato

ilcomportamentoesterno.Ilrefactoringdelcodicedeveessereeffettuatocon

frequenzaalfinedifornirealcodiceunastrutturasolidaperlosviluppofuturo.

Trascurareilrefactoringperandareacrearesempredellefunzionalitànuoveportaa

creareunsistemafragileecostosodamantenere.

• Lavoroincoppia:Esistonodiversepratichedilavoroincoppia,tralequaliilPair

Programmingèlapiùconosciuta.

IlPairProgrammingèunapraticaprovenientedaXPcheconsistenelcollocaredue

programmatoriallastessapostazione,unapersonascriveilcodicementreun’altra

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

54

osservaeseguendounareviewcontinua,ispezionando,eintervenendoconconsigli

nelprocessodiscritturacodice,iruolisonoscambiatidopointervalliregolaridi

tempo.Primadiiniziareascrivereilcodicelacoppiadiscutesuirequisitidadareal

codiceecometestarelefunzionalità.

IlPairProgrammingèunapraticapiuttostocontroversa,alcunisostengonochesia

troppoestremaedaumentimoltoicostiperchéduepersonelavoranoallostesso

codice.Altrepratichedicoppiaprevedonoinvecediusaredueprogrammatoriper

ognistoriadasviluppare,oppureilcrearsicoppieinmanieraautonomaincasodi

particritichedelcodice.

• Proprietàcollettivadelcodice:èunachiaveperincoraggiareciascunoacontribuiread

ognipartedelprogettoconnuoveidee.

SitrattadiunapraticaparticolarmenteimportanteinSAFeinquantoun

sistemadigrossedimensionihauncodicemoltoampiosotto,edèpiù

probabilecheiprogrammatoricambinoechihascrittoilcodicenonsiapiù

presenteperlamanutenzione,oppuresefossepresenteesserelegatiaduna

personapereffettuaredegliinterventièmoltosvantaggioso.

ImplementareCollectiveOwnershippercodicevastorichiededegliaccordisu

standarddiprogrammazione,abbracciarelasemplicitàdidesign,costruire

delleinterfacceresistentiacambiamentidelsistema.

Ø Trasparenza:Senzatrasparenzanonsipossonoprenderedecisionibasatesudatidi

fatto,latrasparenzanonpermettesolodiprenderedecisionimigliori,permetteanchedi

crearefiduciaall’internodell’organizzazione,lafiduciaèunelementofondamentaleper

averepersonemotivateequindiperformanceelevate.

Deveesseregarantitalatrasparenzasuiseguentielementi:

Idirigenti,imanagerdiportafoglio,eglialtristakeholdersdevonopotervedereilkanban

diportafoglio,ibacklogdiprogramma,edaverechiarigliobiettividelProgram

Increment.AllostessomodoailivellidiProgramdeveesserepermessapienavisibilitàdi

tuttiibacklogdeiteam.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

55

Alivelloditeameprogrammadeveesserepermessodivedereleepichearchitetturalie

dibusinesspercapireaqualeepicastiamoandandoincontro.Ognunodevepotervedere

gliindicatoridiprestazionedellealtrearee,cosicchélestrategiepossanoessere

allineate.

2.3.4. IlivellidiSAFe

Ø Primolivello:TeamdisviluppoAgile

IsingoliteamdisviluppolavoranocomedeiteamAgileScrum,sonocioècompostida

sviluppatorietester,ScrumMastereProductOwner,perillorofunzionamentodettagliato

rimandoallasezionesuScrum.

Iteampossonoaccrescerelelorocapacitàdirilasciaresoftwarediqualità,utilizzandodelle

praticheormaimoltodiffusenell’ambienteAgileprovenientidaExtremeProgramming,

comeilPairProgrammingeiltestDrivenDevelopment.CiascunteamAgilehala

responsabilitàdidefinire,sviluppareetestareleUserStorydalproprioTeamBacklog

attraversogliSprint.Lecadenzedeglisprintdeivariteamsonosincronizzatetraloroper

crearemomentidiintegrazionedisistema.

UnadifferenzarispettoalfunzionamentotradizionalediScrumstanellagestionedei

backlog,infattiilbacklogdeiteamvienecreatoduranteilprocessodiReleasePlanning,su

intervallitemporalidelladuratadiseiSprint,cioèladuratadell’iterazionedilivellodi

ReleaseTrain.Questoserveperassicurarel’allineamentotraleattivitàdeidiversiteam

versogliobiettividellivellodiprogramma.NelprocessodiReleasePlanningsicreailbacklog

diprogrammaecomedeploymentdiquestosiottengonoibacklogdeisingoliteam,

successivamenteilteamsvolgeillavorosuiterazionipiùbrevi,delladuratadiduesettimane,

quindivaacreareunoSprintBacklogconleUserStorydelTeamBacklogrealizzabilinello

sprint.

ITeamAgilededicanointervalliprefissatidellorosprintall’esecuzionedicerimonieper

garantirechesiaapplicatol’approcciodellaruotadiDemingallosviluppo.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

56

QuestecerimoniesonoloSprintPlanning,SprintRevieweSprintRetrospective,descritte

nellasezionesuScrum.

Ø Secondolivello:Programma

QuestoèillivellocheveramentecaratterizzaSAFe,mentreillivelloditeamoperacondelle

praticheScrumcomuni,illivellodiProgramserveperportarelepraticheAgilealivellodi

teamdeiteam,dettoReleaseTrain.

EssolavorainmanieraiterativaedincrementalepropriocomeunteamAgile,masu

iterazionipiùlunghe,pariaseiiterazionideisingoliteam,perciascunadellequalivengono

svoltedellecerimoniedipianificazionecontrolloeadattamento,cioèunaReleasePlanning,

unademodelsoftwareedunaretrospettivadelmetododilavoroutilizzato.

IlReleaseTrainètipicamenteècompostodai7ai15teamchesiauto-gestisconoe

organizzanoillavoro,tuttaviailtrenohabisognodiulterioriruoliguidaaffinchéiteamsiano

allineativersounamissioncomune.QuestiruolisonoReleaseTrainEngineer,chefungeda

ScrumMasterdeltreno,assistendoiteamnelrilasciaregliincrementi,edilProduct

Manager,cherappresentainveceilProductOwnerdeltreno,impersonificandolavocedel

clienteperilprogrammaesvolgendounruolodiriferimentoperiProductOwnerdeiteam.

Figura2.4:IruolidellivellodiReleaseTrain

ReleaseTrainEngineer:Facilital’esecuzionedeiprocessiallivellodiprogramma,rimuovegli

impedimenti,gestisceirischiedaiutaaguidareilReleaseTrainversoilmiglioramento

continuo.PropriocomeperloScrumMasterdeiteamilruoloèdescrittocomeservant

leader,cioèdiunteamleaderchenonsiponegerarchicamentesopraalteam,maal

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

57

contrariosimetteadisposizionedeicomponentiperassicurarsichelavorinonellemigliori

condizionieglistimolialmiglioramento.PerconseguirequestirisultatiilRTEsvolge

sistematicamentedelleattivitàdi:ascoltoesupportoaiteamnell’identificareiproblemie

nelprenderedecisioni;allineamentodelledecisionideiteamerisoluzionedeicontrasti;

pianificazionediattivitàvolteadincoraggiarelosviluppodellecompetenzedeimembridi

ciascunteamedalloscambiodicompetenzeintra-team.IlReleaseTrainEngineeregliScrum

Mastersiincontranoduevolteasettimanadifronteallaprogramboarddovediscutonoi

progressideltrenorispettoagliobiettivi,lostatodeirischiedelledipendenzeidentificate

nelReleasePlanning.

ProductManager:Lavoracostantementeincontattoconiclientiidentificandoibisogniedi

requisitiesplicitioimplicitidaimplementarenelsoftwareevalidandolesoluzioniproposte,

propriocomeiProductOwnerdeisingoliteamScrum,periqualirappresentaunpuntodi

riferimento,mantenendoperòunavisioned’insiemepiùalta.

Oltreaquestodeveavereancheunfocussulportafogliodiprogrammidell’impresaeduna

visionedall’alto.NellavorareincontattoconillivellodiProgramPortfoliodeverispettareil

budgetadisposizioneepermetterel’implementazionedelleEpicherelativealprogramma.

Deveprioritizzareillavoropresentenelbacklogdiprogrammaeassicurarsichesiano

presentiinognimomentounaquantitàgiustadifeaturespronteperessereimplementate.

InsedeReleasePlanninghailcompitodipresentarelavisioneleMilestonesprincipalidel

progetto.

SystemTeam:SitrattadiunteamAgileparticolarechelavoraallivellodiProgram,creato

persupportareglialtriteam,integrareilcodiceprovenientedaciascunodiessiedeseguirei

testdiprogramma.Leprincipaliresponsabilitàriguardano:eseguirel’integrazionedelcodice

manualmentedovenonèpossibileononancoraoperatival’integrazioneautomatica,

aiutareiteamadeterminareleinterfaccetraessi,crearegliscenariperitestautomatici,

faredeitestdeirequisitinonfunzionali,mostrareaglistakeholderdelledemodisistemaper

ogniiterazione.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

58

CommunityofPractice:SitrattagruppiinformalicostituitidamembrideiteamAgileedaltri

esperti,conlamissiondicondividereconoscenzapraticatraipartecipanti.Igruppisi

riunisconoconfrequenzaregoleperparlarediunospecificoargomento,discuteredelle

miglioripraticheperaffrontarloecreareallineamentotraidiversiteam.Adesempiola

communitypotrebberiguardareunospecificolinguaggiodiprogrammazioneancorapoco

utilizzato.L’obiettivodellecommunityèfavorirelacircolazionediconoscenzaall’interno

dell’organizzazione,evitandocheresticonfinataall’internodeiteamAgile.Ipartecipantialle

Communitysonoquindiimaggioriespertideiteamsullospecificocampodiapplicazione.

ReleasePlanning:OgniiterazionediprogrammainiziaconunReleasePlanningmeetingin

cuituttelepersonedeltreno,cioètuttiimembrideiteamsitrovanoperascoltarela

presentazionediVision,Roadmapedobiettividell’iterazione.Successivamenteciascunteam

pianificaautonomamenteillavorodasvolgerenell’iterazionediprogramma,partendodaun

elevatogradodiastrazioneedettagliandosempredipiùleattivitàdasvolgere,ponendole

infinenell’ambitotemporalediunosprint.Inseguitovengonoidentificateledipendenzetra

leattivitàdeidiversiteametrovataun’adeguatastrategiadigestione,adesempiosipuò

trattarediattivitàdiunteamchebloccanoillavorodiunaltro.Ilmeetingservepercreare

allineamentotraillavorodeiteamegliobiettividiprogramma,peridentificareegestirele

dipendenzecontraiteameidentificareegestireirischidelprogetto.

ReleaseRetrospective:Alterminediunareleasesisvolgeilmeetingdiretrospettiva,acui

partecipanoiruolichiavedelprogramma,ScrumMasterProductOwnererappresentantidei

teamAgileetuttiglistakeholderinteressati.Ilmeetinghal’obiettivodiindagaresucomesi

èlavoratonellaRelease,focalizzandosisullerelazioniintra-team,dipendenzenonrisolte,e

problemidicomunicazione,decidendoleazioninecessariepermigliorarelecondizioninella

prossimaiterazione.Sicercainoltredifaremergereiproblemimaggioridelprogrammaed

indagasullecausealfinedidecidereleazionicorrettive.

Ø Terzolivello:ProgramPortfolio

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

59

SitrattadellivellogerarchicamentepiùelevatoinSAFe,hailcompitodidefinireattraverso

lestrategieiflussidivaloreaziendali,gestirel’innovazioneattraversoEpichedibusinesse

architetturali,edeffettuareleattivitàdibudgetingelagovernancedegliinvestimenti.Il

modellodefiniscedueruoliparticolariperquestolivello:l’EpicOwnerel’Enterprise

Architect.

Leepiche:LeideeinnovativedigrossaportatainSAFesonochiamateepiche.Sitrattain

generalediideepernuovibusiness,differenziazionedelportafoglio,acquisizioniefusioni,

cambiamentidifunzionalitàsostanzialiaprogrammiesistenti,innovazionediprocesso,

variazionidellastrutturaorganizzativa,essepossonoproveniredirettamentedallastrategia,

oppureesseregenerateinternamenteatuttiilivelligerarchicioesternamente,

l’organizzazionedevequindiimplementareiprocessinecessariperlaraccoltadelleidee.Si

trattaquindidiunprocessodigestionedell’innovazionedall’alto,chesiaffiancainSAFe

all’innovazioneperpiccolipassiemergentedaiteam

L’EpicOwnerèlafiguraresponsabilediimplementareilprocesso,discomporreleepiche

relativeaidiversiprogrammiattraversoiflussidivalore;persvolgerequesteattivitàdeve

collaborareconiteamdisviluppo,ibusinessowner,l’architettodisistemaediproduct

manager.Leepichepassanoattraversofasidianalisidifattibilitàesviluppostage-gate,al

fineassicurarsidiselezionaresoloquelleconelevataprobabilitàdisuccesso.Vengonoinfine

inseritenelPortfolioBacklogattendendodiessereimplementate,ilbacklogserveadare

visibilitàalleepichecosicchéaivarilivellicisiaconsapevolezzadicosaèinprogrammaesia

piùfacileottenerecollaborazionedaglistakeholder,inoltreserveafornireunlimitesul

numerodiepicheworkinprogress,perassicurarechesianoimplementatesenzaeccedere

neivincolidicapacitàdiassorbimento.

UnaltroruoloimportantedellivellodiProgramPortfolioèl’Architettodiimpresa,insistemi

digrossedimensioniildesignemergentedalbasso,cosìcomepropongonolemetodologie

Agiletradizionali,nonèsufficientedasoloesicrealanecessitàdiun’architettura

intensionaleprogettatadall’alto,questoargomentoèapprofonditonelcapitoloapposito

sull’evoluzionedell’architetturainSAFe(2.3.5.)

Inorganizzazionidigrossedimensionifusioniedacquisizionivannoamodificare

costantementeletecnologie,glistandardelesfidecompetitive.L’architettodisistema

fornisceunadirezionetecnicastrategicainmanieratrasversaleaidiversiprogrammieflussi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

60

divaloreinportafoglio.Lacapacitàdiabbracciarecambiamentiorganizzativirappresentaun

vantaggiocompetitivoperleorganizzazioni,l’architettodisistemaconlasuavisioneolistica

dialtolivellodell’organizzazioneguidalastrategiaorganizzativadell’impresa.

2.3.5. L’evoluzionedell’architetturainSAFe

InSAFel’architetturaorganizzativainternaèprogettatapermodificarsiemigliorare

continuamente,alfinedipermettereall’organizzazionedirispondererapidamenteai

cambiamentinellecondizionidimercato.

IlmanifestoAgilesostieneche“lemiglioriarchitettureemergonodateamchesiauto-

organizzano”daquiderivailconcettodiDesignEmergentecheconsisteneldareilpotereai

teampermodificareoestendereildesignesistentesoloperquantonecessarioarealizzaree

validareilprossimoincrementosoftwaredarilasciare.Questoapprocciohasenzadubbiodei

fattoripositivi,mafunzionasolofinoaduncertopunto,quandoleorganizzazioniinizianoad

esseregrandiesicreanoteamditeamildesignemergenterisultaspessoinsufficienteper

rispondereallacomplessitàdelsistema,risultaimpossibileinquestesituazioniperiteam

capireilfunzionamentodelsistemanelcomplessoedevitarediprodurreridondanza.

Possononascereproblemicomebassavelocitànellagestionedelleinterfacceintra-team,

eccessivonumerodimodificheallastruttura,sviluppodidiversearchitetturenelsupportare

lestesserisorse.

PerquestimotiviSAFeaffiancaallapraticadelDesignEmergentequelladell’Architettura

Intensionale,iniziativeprovenientidall’altopermigliorarelastrutturaorganizzativa,

anticipandoleesigenzedelmercatoedottimizzandoirapportiintra-team.L’Architettura

Intensionalevieneprogettatadairuoliarchitetturalidell’organizzazione,qualiilSystem

Architectel’EnterpriseArchitect,eimplementataattraversoilsistemadideploymenttop

downdelleEpicheArchitetturali.

Inun’organizzazioneAgiledigrossedimensionidevonoesserepresentientrambigli

approcci:velocecontrollolocaledeldesignemergente,cosicchéiteampossanoreagirein

modoappropriatoaicambiamentideirequisitisenzaattendereeccessivitempiper

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

61

l’approvazionedall’alto,econtrolloglobaledell’architetturaintenzionale,perassicurareche

ilsistemanelcomplessoabbiacoerenzaedefficacia.

Figura2.5:L’evoluzionedell’architetturainSAFe

Idueapproccinonsonoperòindipendentil’unodall’altro,l’architetturaintensionalenon

deverappresentareunvincoloperildesignemergente,maunlivellodiastrazionepiùalto

cheautorizzaiteamadadattareefficacementelaparteintensionalenellorospecifico

contesto;allostessotempoildesignemergenteinfluenzaecorreggel’architettura

intensionale,alimentandolenuoveideeperilfuturo.

Unareciprocitàcosìprofondatradesignemergenteearchitetturaintensionalepuòesserci

solocomerisultatodiunacollaborazionetrateamagili,sistema,architettidell’azienda,

ProductManagementeProgramPortfolioManagement,perfarelevasull’architettura

dell’organizzazionealfinediottimizzareleperformancedibusiness.Unruolofondamentale

èsvoltodalReleaseTrain,chegiocaunruoloprimarionelfavorirelacollaborazionee

costruiresoluzioniefficaci.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

62

2.3.6. LamisurazionedelleperformanceinSAFe

LemetodologieAgilepermettonounamaggiorfacilitàdimisurazionedelleperformance

rispettoaimetoditradizionalidisviluppowaterfall,poichéillavoroèiteratoattraversola

ripetizioneditimeboxesdiduratacostante,inSAFequestoapproccioiterativosiapplica

anchealivelloditeamdeiteam,andandoamigliorareulteriormentelacondizione.

TuttelemetodologieAgileconcordanosulfattochel’indicatorepiùimportanteècheafine

iterazionesiarilasciatoomenounsoftwarefunzionante,equestoèdeterminato

empiricamentedalladimostrazionecheavvieneallafinediogniiterazionediteamnella

SprintReviewediterazionediReleaseTrainnellaSystemDemo.

Indicatoriquantitativiperiteam:Allafinediciascunaiterazioneilteamesegueuna

retrospettivadiSprintdovesianalizzanoalcuniindicatoriquantitativitipicamente

conteggiatidalloScrumMaster:differenzatravelocitypianificataedottenuta;differenzatra

numerodistoriepianificateenumerodistorieportateatermine;percentualedistorie

portateatermine;percentualeditestdiunitàcoperti;numerodibugriscontrati;tipologiadi

bugriscontrati;numerototaleditesteseguiti;percentualeditestautomatizzati;numerodi

refactordelcodice;burn-downchart.

Velocity:èilvaloredatodallasommatoriadegliStoryPointportatiaterminedalteamnello

Sprint.

Burndownchart:èunarappresentazionegraficadellavorodasvolgeresuunprogettonel

tempo,tipicamentevienepostosull’asseorizzontaleiltempoesulverticaleillavoro

rimanentequantificatodallasommatoriadegliStoryPointsrelativiallestoriedaportarea

terminenelloSprint.Permettedifareunconfrontoimmediatoconunasituazioneidealedi

produttivitàcostante.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

63

Figura2.6:ungraficodiBurndownchartnegliufficidiTagetikSoftware

Metrichediautovalutazioneperiteam:iteamagilivalutanocontinuamentemodiper

migliorareiloroprocessi,spessoconautovalutazionistrutturate.Questodaaiteammododi

rifletteresullepratichechiavecheaiutanoadottenererisultati.

SAFeproponeinoltredieseguireregolarmenteuntestdiselfassessmentchevalutalasalute

delteamindiversearee.

IndicatoriquantitativiperilReleaseTrain:Leiterazionidiquestolivellohannounadurata

piuttostoelevata,solitamenteditremesi,èconsigliabileutilizzaredegliindicatoriperil

monitoraggiodellostatod’avanzamentodellosviluppo:

Statod’avanzamentodellosviluppodifeatures:Perciascunafeatureprogrammataper

l’iterazioneabbiamoilrapportotranumerodistorieportateaterminesunumerodistorie

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

64

pianificateperlafeature;numerodistoriedellafeatureinritardorispettoallosprint

pianificato.

IndicatoridifineiterazioneperilProgram:Programvelocity;differenzanumerodifeatures

pianificateenumeroportatoatermine;Rapportotranumerodifeaturesportateatermine

supianificate;percentualedicoperturadeitestdiunità;percentualedeitestautomatici;

numerodibug;Burn-downchartdiRelease.

2.3.7. L’implementazionediSAFe

SAFeèunmodelloprescrittivoperquantoriguardal’architettura,iruoli,lepraticheegli

artefattidautilizzare,lastradaelefasidaseguireperimplementazionesonoinvecelasciati

all’organizzazioneenonsonodescrittiinmanieraprecisa.

Èperòemersodalleesperienzed’implementazionediunelevatonumerodiorganizzazioni

chealcunestrategiesirivelanomoltoefficaci,eadatteaquasituttiicontestiaprescindere

dalledimensioniel’ambitodell’organizzazione.

Lastrategiadiimplementazionepiùdiffusaèbasatasuunatransizioneperfasisequenziali

conlogicabottom-up,quindichevedelatransizionescompostanelletrefasirelativeaitre

livellidelmodello.Scomporrelatransizioneglobaleintransizionisequenzialidipiùpiccola

entitàpermettediscomporreilrischiocomplessivoinrischiminori,permettendoquindiun

migliormonitoraggiodellatransizione,delrischiodifallimentodelprogettoedelblocco

delleattivitàdiprogrammazione.Latransizioneattraversofasisequenzialipermetteinoltre

unascomposizionedell’attivitàdiformazionelimitandoiltempodiallontanamentodel

personaledalleattivitàordinariedisvilupposoftwareemanutenzionedeiprogrammiin

portafoglio.

Nelcasodiun’organizzazioneprovenientedaunaproduzionesoftwareconmodello

tradizionalewaterfallèmoltocomuneperilverticeaziendaleaffiancarsinellatransizionead

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

65

unaopiùorganizzazionispecializzatediconsulenzaecoachingLean-Agile,incaricatedi

diffondereiprincipiallabasedelmodelloedaiutareconleattivitàdichangemanagement.

Ilprimopassoconsistenell’organizzaremeetingperiverticiaziendali,responsabilidel

repartoproduzionesoftwareeruolichiaveperilprocessoditransizione,finalizzatia

promuovereiprincipibaseLean-Agile,ilmodelloSAFe,edacrearecommitmentperla

transizione.Seinquestafasenonvieneraggiuntounelevatogradodiconsensononsarà

possibileproseguireconlatransizione.VienepoicreatounTransitionTeaminterno

all’organizzazioneincaricatodiguidareilcambiamento,sponsorizzareilprogetto,mantenere

unelevatogradodiconsensoneiverticiaziendaliediffondereinternamenteiprincipiAgile.

Vengonoprogettatilastrutturaobiettivo,iReleaseTrain,iteamedisuoicomponenti.

Aquestopuntoèpossibileiniziareconlatransizionedellivelloditeam:

Tipicamentevienesvoltaaquestolivellounulteriorescomposizionedellatransizioneconil

lanciodipochiteamAgilepervolta,questopermettealrestodell’organizzazionedi

continuareconleattivitàdisviluppo,testedebugdelcodicementrealcuniteamvengono

creati,formatisullepraticheScrumedinfinelanciatisullavoroattraversoiterazionidiSprint.

InquestafaseiteamlavoranosudeiBacklogprovvisoricreatidalProductOwnerdelTeam

assiemealTransitionTeam,poichénonèancorafunzionantel’attivitàdideploymentdei

backlogdeiteamdaquellodiprogramma.

Solitamenteiprimiteamlanciatisonoteampilota,chesvolgonoattivitàdicaratterenon

determinanteperilsuccessodell’organizzazione,ilqualelavoroserviràpervalidareomeno

l’applicabilitàdellepraticheAgilealcontestospecificodell’organizzazione,persondareil

camporelativamenteallarispostamotivazionaledellepersonepermettendointerventi,edin

futuroapplicarelelessonlearnedaisuccessivilanciditeam.Laduratadiquestafasepuò

variaremoltoinbasealledimensionidell’organizzazioneedilnumeroditeam,solitamente

duradaseiadiciottomesi.

InfaseavanzatadilanciodeiteamsiiniziaalavorareparallelamentesullivellodiProgram:in

questafaseèimportantechesidiffondaneiprogrammatorilaconsapevolezzadel

funzionamentodeiReleaseTrain.Vengonocreatiiruolidellivelloeformatisulleloro

responsabilità,silancianoleCommunityofPracticeedinfinequandotuttiiteamAgilesono

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

66

statilanciatisiiniziaalavorareattraversoiReleaseTrain,ovverovengonoeseguitiiRelease

PlanningedillavorodituttiiteamèallineatosucadenzediseiSprint.

Unavoltacheèavvenutalatransizionedituttoilrepartosviluppoall’Agilerimaneda

guidarelatransizionedelverticeaziendale,aquestolivelloiprincipiLean-Agiledovrebbero

essereoramaibencompresi,lepraticheprevistedalmodellononsidiscostanoinrealtà

moltodalleattivitàcomunisvoltedalverticeaziendale,sivannoperòacreareiruoliele

pratichespecificheperassicurarcichecisiaallineamentoecoerenzaall’internoditutta

l’organizzazione.SitrattaquindidiformalizzareiruolidiEnterpriseArchitecteEpicOwner

cominciareconleattivitàdigestionediepicheecreazionedellestrategie.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

67

3. LatransizionedaWaterfalladAgileinTagetik

3.1. L’azienda

TagetikSoftwareèun’aziendamultinazionaleoperantenelsettoredeisoftwarediCorporate

PerformanceManagement(CPM).IlsoftwareTagetikèindirizzatoabancheedaziendedi

medio-grandidimensioni,perlagestionedelbudgetingedellapianificazione,il

consolidamento,lagestionedelleattivitàfinanziarie,lagenerazionedireportdigestione,di

analisiavanzateemoltoaltro,siaattraversosoluzionion-premisechecloud.Negliultimi

decennil’aziendahaavutoun’espansioneesplosivasulmercato,chehacomportato

inevitabilmenteunaumentodelledimensioniinterne.

TagetiknasceaLuccanel1986comesocietàdiconsulenza,nel’90iniziaasvilupparele

primeapplicazionisoftwareenel2002collaboraconUnicreditnellosviluppodiunsoftware

perilCPM,dal2005siespandealdifuorideiconfininazionali,diventandorapidamenteil

vendordisoluzioniCPMapiùrapidaespansionesulmercatointernazionale,conunacrescita

annualepariacinquevoltequellamediadelmercato.

Lasituazioneattualecontalapresenzadi31sedisparsein5continentieattivitàin53paesi,

lasedeprincipalerestacomunquequelladiLucca,dovepiùdi80programmatorilavorano

sulsoftware.

TraiclienticheutilizzanoilsoftwareTagetiksonopresentialcunedellemaggioriaziende

operantiinsvariatisettori:TIM,Unicredit,Finmeccanica,Barilla,Generali,TelecomItalia,

Enel,PosteItaliane,Sorgenia,emoltialtri.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

68

3.2. Lasituazioneprecedenteallatransizione

3.2.1. Strutturaorganizzativa

L’aziendaèorganizzatasecondounastrutturafunzionale,sottoall’altadirezioneiprincipali

ramisonoquellidellosvilupposoftware,marketing,venditeeconsulenza;noici

focalizzeremosulrepartodisvilupposoftware.

Figura3.1:OrganigrammadiTagetikSoftware

CONSULTING

INTERNAT.DIRECT

OPERATIONGENERALSERVICES MARKETING SALES ITALIA DEVELOPMENT

TAGETIKN.A.

TAGETIKFR

TAGETIK U.K.

QUALITY MANAGER

LEGAL AFFAIRS

HUMANRESOURCESSAFETY

CEO

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

69

ConilprecedentemetododilavoroilrepartoSvilupposoftwareseguivaunprocesso

tradizionaleacascata,perfasisequenziali,rilasciandoinmediatreversionidisoftware

l’annoadintervallinonregolari.Iprogrammatorieranoorganizzatiin7teamdisviluppo.

Ilcriterioconcuisieranovenutiacreareiteamerasiaperfunzionalitàdelprogrammache

perinterfacciaedelaborazione,cioèunadivisionetrachiprogrammailfront-endedilback-

enddelsoftware.Ciascunteameracompostoinmediadadieciprogrammatori.

ITeampresentierano:

• InterfacciaWeb(webclient):teamchesioccupavadirealizzarelemaschereele

applicazioni.

• ElaborazioneeCalcolo:ilteamsviluppavaciòchestadietroallemaschere,cioèil

backend.

• Framework:teamchesviluppaval’infrastrutturadifondodelsoftware.

• Reporting:teamchesioccupavadiquestafunzionalitàdelsoftware,eradivisoasua

voltainduesottogruppiunorelativoall’interfacciael’altroalbackend.

• Analitics:teamchesioccupavadell’integrazionetraTagetikestrumentiterzidi

BusinessInteligence,cioèdellacomunicazionedelsoftwareconaltrisoftware

aziendalipresentidall’utilizzatorecomeMicrosoft,SAPecc.

• Test:Teamchetestavailsoftwareadiversilivelli,testdiunitàediintegrazione.

• Documentazioneutente:Creavanoladocumentazionenecessariaagliutentiper

utilizzareilsoftware.

3.2.2. IlprecedenteprocessodisviluppoWaterfall

IdentificazioneRequisiti

Pianificazione Sviluppo delsoftware Testing Documentazione

Utente

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

70

Figura3.2:LeFasidelvecchioprocessodiproduzionesoftwareinTagetik

Lefasinecessariealrilasciodiunanuovaversionedelsoftwareeranoleseguenti:

• Identificazionedeirequisiti:Perprimacosavenivanoidentificatiirequisistida

incorporarenellanuovaversionedelsoftware,trattasiindifferentementedinuovi

requisitifunzionali,requisitiprestazionali,risoluzionedibugomiglioramentidella

versioneattualedelsoftware.

Irequisitipotevanoavereprovenienzainternaoesterna,seinterna,cioèdalreparto

sviluppo,venivanoinseritidirettamentenelPianodiSviluppo;quelliesterni,provenienti

daiclientiestakeholders,venivanocaricatidaglistessiaprendounaissuesulla

piattaformaJira,unapiattaformaonlineutilizzatasiainternamenteperlacomunicazione

elagestionedellavoro,cheperlacomunicazioneconiclientielasegnalazionedi

problemisulsoftware.

LapiattaformaJiraèancorafunzionanteedognivoltacheunclienteriscontraun

problemacolsoftwarepuòaprirviunaissue,chevieneetichettatacomeTrivial,Minor,

MajoroBlockeredinbaseaquestoprioritizzataeprocessatainmanieradiversa.

IrequisitiprovenientidaJira,sedecisodiimplementarlinelnuovorilasciovenivano

inseritinelPianodiSviluppo.LedecisionirelativeacosainserirenelPianodiSviluppo

eranomoltoconcentratenellemanidiungrupporistrettodipersone,laDirezione

Tecnicaavvalendosidelpareredialcuniprogrammatorisenior.

• Sviluppodelsoftware:Illavorodisviluppoveroepropriodelsoftwareavvenivaperfasi

sequenziali,convariciclidifeedbacktralefasiacausadiproblematichechesi

riscontravanoinfasiavanzatedelprocessodisviluppo.

PerprimilavoravanoglisviluppatoridelFramework,cherappresental’intelaiaturadi

fondo,l’architetturalogicadisupportosucuivienesuccessivamentesviluppatoil

software.Successivamentepartivanoinparalleloleattivitàditreteamdisviluppo:

Interfacciaweb,cioèlosviluppodimaschereedapplicazioni;Elaborazioneecalcolo,cioè

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

71

ilmotorechestadietroallemaschere,eReporting,sviluppodellemaschereedel

motorediquestafunzione.Poichéquestiteamcreavanopartidisoftwaremoltolegate

tralorolosviluppoinparallelopermettevadaunlatodiridurreilleadtimecomplessivo

disviluppo,dall’altrodavaluogoanumerosedifficoltàdiallineamentoeallanecessitàdi

modifichesuccessive.

• Testing:Tutteleattivitàditestingvenivanosvoltedaunteamapposito,successivamente

allacreazionedelcodice.

• DocumentazioneUtente:Ultimafasedelprocessoconsistevanellacreazionedapartedi

unteamdedicatodituttaladocumentazionenecessariaall’utente,finalizzatoall’utilizzo

siadeiclientifinalichedell’areaconsulenzadiTagetik.Vatenutopresentecheil

softwareTagetikèmoltoampioperareesupportateeprofondoperfunzionalitàofferte,

erisultapiuttostocomplessodautilizzare,ragionipercuiilManualeUtenterisultauno

strumentofondamentale.

3.2.3. Problematichedellasituazioneprecedente

PrimadellatransizioneeradiffusanellaDirezioneTecnicalaconsapevolezzadellanecessità

dimigliorarelagestionedelRepartoSviluppo,chesitrovavainunasituazionedielevata

complessitàorganizzativa.Lacrescitaveramenteesplosivasulmercato,cheavevainvestitoe

statuttoracoinvolgendol’organizzazione,avevainevitabilmenterichiestounrapido

aumentodelledimensioniinterneintuttelefunzioniaziendali,generandoinparticolarenel

repartosviluppounasituazionecaotica.

IlmodellodigestionedellosvilupposoftwareeraquindiditipoWaterfall,mapresentava

anchedelleparticolaritàdell’organizzazionediTagetik,leproblematichepresentierano

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

72

quindidaimputaresiaalmodelloWaterfalldipersé,siaallasituazioneparticolare

dell’azienda.

Lemaggioriproblematicheriscontrateerano:

• Conoscenzemoltoconcentrateinpochepersone,siasulfunzionamentodispecifiche

partidelsoftwarechedelcodicechecistadietro.Ilsoftwaresibasasuuncodicemolto

grandecreatonegliannichesiavvaledidiversistrumentiinformatici,quindicomplesso,

inoltrenellascritturadelcodicesononecessariesiacompetenzeaziendaliche

informatiche.Sudeterminatepartidelcodicesoltantoalcunepersonehannoconoscenza

ecapacitàperintervenire.

• Poteredecisionalesulladirezionedadareallosviluppomoltoconcentratoinpoche

persone,enonnecessariamenteallineatoconlavisionedelmercato.Mancanzadifigure

cherappresentanolavocedelclienteall’internodelrepartosviluppo.

• Incompletezzadelladocumentazionesiatecnicacheutente,dobbiamoricordareche

stiamoparlandodiunsoftwarechedallatoutenteèmoltoampioperareecopertee

profondocomefunzionalitàofferte,talechequasinessunoinaziendanehalavisione

completamacisonospecialistiperarea.Larealizzazionediunadocumentazioneutente

esaurienterisultaquindisignificativo,maanchedinonsemplicerealizzazione.

• Sievidenziavanospessodeiproblemisulsoftwarenellafaseditesting,problemiche

quindinecessitavanodiunritornoallafasedisviluppo,connumerosilooptraquestefasi

finoallagenerazionedelcodicecorretto.Problematipicodell’approccioWaterfall.

• Codicevecchiononsempredielevataqualità,difficoltàdimanutenzionedelcodiceda

partedichinonl’hascritto.Moltedelleoreuomodeiprogrammatorispeseperrisolvere

ibugriscontratiemanutenerel’elevatonumerodiversionidelsoftwareinuso.

• Ciclodisviluppolungoemancanzadifeedbackdagliutilizzatorifinoalrilasciosul

mercato,problematipicodellametodologiadisviluppoacascata,quindiimpossibilitàdi

conoscerelarispostadelclientefinoaquandounagrossafettadilavoroèstataormai

fatta.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

73

3.3. Latransizione

3.3.1. Ladecisionedipassareall’Agile

IlrepartosviluppoeraaconoscenzadellarapidadiffusionedellemetodologieAgile

nell’industriadell’IT.Decisequindidicontattareun’aziendadiconsulenza,ilcuinomeverrà

omesso,specializzatanell’affiancareleorganizzazioninellatransizioneversol’Agile,formare

ilpersonaleeseguireleattivitàdichangemanagement.

Dopoalcunicolloquiilmanagementsiconvinsechequelladell’Agileeralastradagiustada

percorrerepermigliorarelacondizioneorganizzativa.Comeprimacosanell’aprile2015

l’aziendadiconsulenzasvolseunassessmentsullamaturitàdell’organizzazionenella

situazioneprecedentealcambiamentoperpoterpianificarealmeglioleattivitàdella

transizione.

L’assessmenterafinalizzatoadindagarelostatoattualediquattroelementi:

• strutturaorganizzativadelrepartosviluppoeflussicomunicativitraiteam;

• governance,cioèmodalitàdipianificazioneegestionedeirilascisoftware;

• prassidisviluppoetesting;

• capacitàdell’organizzazionedigestirelaresistenzaalcambiamento.

Questavalutazioneèstatafattaprimaanalizzandoladocumentazionediprodottoe

gestionaleepoiintervistandouncampionerappresentativodellediverseareeaziendali.

Inoltresonostatiindividuatialcunigoalchepermettonoadun’organizzazionedicomportarsi

inmodoAgileedèstatovalutatoillivellodimaturitàdell’organizzazionerispettoaquesti

goal:culturadelContinuousimprovement;volontàecapacitadicambiareemigliorare;

capacitàdiavereaccessoaglistakeholderedidentificarneibisogni;capacitàdiprioritizzare

gliobiettivi;volontàdirisolvereproblemi.

L’esitodell’assessmenthaevidenziatounelevatolivellodisponsorhipedicommitment

dell’organizzazioneversoilcambiamentomamedio-bassecapacitàdigestionedelprogetto

echangemanagement,sièstimatoinoltreunimpattosullepersonedelcambiamentodi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

74

entitàmedio-alta,comportandovariazionidellastrutturaorganizzativa,deiteameinalcuni

casideiruolioperativideisingoli.

Figura3.3:Graficoassessment

Successivamenteallavalutazioneilmanagementhadecisodiintraprenderelatransizione

affiancandosiall’aziendadiconsulenzaperleattivitàdipianificazionedellatransizione,

formazionedellepersoneegestionedelcambiamento.

3.3.2. Pianificazionedellatransizione

Èstatapianificataunatransizioneditipoincrementale,menorischiosa,estesasuun

orizzontetemporalediunanno.Infattigliaspettilegatiacultura,visioneeesperienze

pregressenonpositivediChangeManagementponevanol’organizzazionearischioecon

unaelevataprobabilitàdiincontrareresistenzaalcambiamento.

Sonostatievidenziaticomeelementiimportantiperlabuonariuscitadelprogetto:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

75

• lanecessitàdidefinireecomunicarevisioneedobiettividelcambiamentoatuttigli

stakeholders;rinforzareperiodicamentelabuonasponsorshipesistenteversoil

progetto;

• effettuareattivitàdiAgileAwarenessesteseatuttal’aziendaperaumentarela

culturarispettoagliargomentidellaLeanproductioneeAgile;

• effettuaresessionidiformazionemiratasuiteamchedovrannopartire;

• svolgereattivitàdicoachingsullepersoneegruppiimpattate;

• fareunlavorosuculturadelchangemanagementaccompagnatocostantementenel

tempo;

• lavoraresulledinamichedicollaborazioneintra-team;

• definirekpivoltiamisurareproduttività,qualitàemoraledelteam.

ÈstatocreatounTransitionTeaminternoall’azienda,compostodaunpiccologruppodi

personeedincaricatodiguidarelatransizione,nefannopartefigurechericoprivanoruolidi

governancenelrepartosviluppo.

Ilteamhacomemissionquelladiincoraggiareesupportarel’organizzazionenellosforzo

versoilpassaggioaSAFe,deveinoltrecrearelepressioniinterneesponsorizzareilprogetto

atuttelegerarchieaziendalialfinediassicurarnelabuonariuscita.

Figura3.4:unaboarddelTransitionTeaminTagetik

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

76

ScrumeSAFesonostatiscelticomeambientidilavoroAgile,Scrumèunatralemetodologie

Agilepiùdiffusenelmondo,èilmetododilavorosceltopercoordinareleattivitàall’interno

deiteam.SAFeèunframeworkchesistadiffondendorapidamentetraleaziendeAgiledi

grossedimensioni,permettediscalareScrumadunasituazioneaziendalepiùampia,di

coordinareillavorodivariteamscrumoperantisullostessoprogrammaedallineareirilasci

delsoftwareconlavisiondelverticeaziendale.

Ilpianoditransizionecreatodall’aziendadiconsulenzaprevedeva,alfinediminimizzareil

rischiod’insuccesso,unatransizionesequenzialeconlogicabottom-upcheriguardassein

ordinei3livelliprescrittidaSAFe:teamScrum,AgileReleaseTraineProgramPortfolio

Management.

Alivelloditeamlatransizioneèstatasotto-scompostainulteriorifasi,partendodalla

formazioneelanciodidueteampilota,epoiaseguireintrefasiillanciodeirestantiteam.

Sonostatiindividuaticomeobiettividellatransizione:

• Aumentarelareattivitàrispettoaicambiamentieallenuoverichiestedelmercato:i

miglioramentiapportatidallemetodologieAgileinquestadirezionesonoampiamente

dimostratidallaletteraturascientifica.

• Aumentarelaqualitàdelsoftware:siarispettandostandardqualitativiperilnuovo

codicecreato,cheattuandorefactoringalcodiceesistente.

• Creareunambientedilavorochefacilitilacrescita,lamotivazioneelasoddisfazione

dellepersone.

• Farcrescerelepersoneattraversoloscambiodiconoscenzetraimembriditeam

multifunzionali:iteamScrumsonocompostidamembriconconoscenzesumaschere,

elaborazioni,testingedocumentazione.Illavoroastrettocontattotramembricon

specializzazionediversahacomeobiettivoilsuperamentodelconcentramentodi

conoscenze.Inoltrelapossibilitàdicreareteamdoveaffiancaresviluppatoriseniorad

altrinuoviinaziendadovrebbeessereun’ulterioreopportunitàdiscambioe

accrescimentodellabasecomplessivadiconoscenza.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

77

• Decentrareilpoteredecisionale:creareunsistemaincuituttiiteamsianoingradodi

prenderedecisioniinmanieraautonomapermettedievitareiritardiel’effettocollodi

bottiglialegatoadunadecisioneedapprovazionecentralizzatonellaDirezioneTecnica.

• Avereunosviluppopiùlegatoallavocedelcliente:portareneiteam,attraversolafigura

deiProductOwner,imassimiespertineirapporticoniclienti,perassicurarsicheillavoro

deiteamapportisemprevalorealbusiness.

• Scomporreilprocessodirealizzazionedelladocumentazioneall’internodeiteamdi

sviluppo,evitandoilcollodibottigliafinale.

• Scomporreilprocessodirilasciocomplessivoinpiccolirilascipiùrapidi,chepermettano

diottenereprimaifeedbackdapartedelcliente.

Figura3.5:Lefasidellatransizione

3.3.3. Progettazionedellanuovastrutturaorganizzativa

1)TransizionedeiTeamAgile

•Creazionedeinuoviteam•FormazioneScrumelanciodeiteampilota•Affiancamentodelcoachaiteampilota•Formazioneelanciodeirestantiteam scompostointrefasisequenziali

2)Transizionedell'AgileReleaseTrain

•Diffusionedellaconoscenzasulfunzionamento•Lanciodellecerimoniedilivello•LanciodelleCommunityofPractice•Affiancamentodeicoachnellecerimoniedilivello

3)TransizionedelProgramPortfolioManagement

•Creazione deiruolidilivello•Formazione sullebestpractices•Affiancamentoemonitoraggionelprimoperiodo

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

78

Sonostaticreatideiteamdisviluppocompletamentenuovibasandosisullefunzionalitàdel

softwareTagetik:Consolidato,Budgeting,CashFlowPlanningeConnettori,sonostate

individuatecomefunzionalitàprincipalidelprogramma.

Perciascunadiquesteèstatocreatounappositoteamdisviluppatori,assegnandoal

consolidatodueteametrealbudgeting,inquantofunzionipiùgrandidellealtre.

Iteamtrovatinonpotevanoesserecompostidallestessepersonedeiteamprecedenti,

infattiaffinchéiteamScrumpossanorilasciareincrementidelsoftwareinmaniera

autonoma,essidevonoavereall’internotuttelecompetenzenecessarie,cioèrealizzazione

maschere,elaborazionetestingedocumentazione.Questecompetenzeinvece,

nell’organizzazioneprecedente,eranodiviseinteamspecializzati.

Perassegnarelepersoneaiteamèstatautilizzataunamatriceconivariteamsulleascissee

sulleordinatelepersonediviseingruppianalista,sviluppatoremaschere,sviluppatore

elaborazioni,testeredocumentazione.Poisonostateassegnatelepersonediciascun

gruppoaivariteamtenendocontodellecompetenzedellepersoneedellorogradodi

maturitàall’internodiTagetik,cercandodicrearegruppiequilibratichepotesseromaturare

neltempo,chefavorisseroloscambiointernoel’accrescimentodiconoscenze.

Team1 Team2 …. TeamnSviluppatoremaschere1

X

Sviluppatoremaschere2

X

X

Sviluppatoremascherem

Sviluppatoreelaborazioni1

X

Sviluppatoreelaborazioni2

X

X

Sviluppatoreelaborazionim

X

Sviluppatoretesting1

X

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

79

X

Sviluppatoretestingm

X

Figura3.6:Matriceperlacreazionedeiteam

AdessorimanevadaassegnareaiteamiProductOwner,infattiaffinchésiadecentrato

poteredecisionaleaiteamequestipossanorilasciareincrementidelsoftwareinmaniera

autonoma,essidevonoessereingradodicapirecosacreavaloreomenoperilcliente,a

questoserveilPO,cherappresentaintuttoepertuttolavocedelclienteportataall’interno

delteam.

PercrearelafiguracompletamentenuovadeiPOsonostatepresedalramoconsulenzale

personeconlamassimaconoscenzasullospecificoramodisviluppodelteam,edassegnate

alteam.Nelleareedibusinessdelconsolidatoebudgetingdovesonopresentipiùteamè

statacreatalafiguradelBusinessOwnersopradiquesti.

Ilprimopassoèstataquindilaformazionedeinuoviteamelanciodeiprimiteamscrum,

affiancatidauncoachdell’aziendadiconsulenzaneiprimisprint.Sempreperridurreil

rischiodiinsuccessoepermettereunmonitoraggiopiùefficaceiteamscrumsonopartitiin

fasidifferenti,condueteampilota.

3.3.4. IllanciodeiteamScrum

Ilprogettopilotaèservitopervalidarel’applicabilitàdellametodologiaAgilealcontesto

Tagetik,valutarnel’efficacianelrilasciarevaloreeraccoglieredelleesperienzeelessons

learneddaapplicareaisuccessivilanciditeam.

• Giugno2015:Formazionescrumelanciodeidueteampilota.“Cashandchips”e

“BananaSprint”

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

80

• Ottobre-novembre2015:Formazioneelanciodialtri4team“YesYouCons”,Three

Agnostic”,“BudgetScrummies”,“UXFiles”.

• Febbraio2016:Lanciodialtritreteam.

PrimadiesserelanciatoogniteamScrumèstatoaffiancatodadeicoachAgileeformato,i

dettaglidellaformazione,cosìcomel’adattamentodellepraticheAgileall’internodiTagetik

sonodettagliatenelcapitolosuccessivo.

3.3.5. Laformazioneerogataaiteam

LoScrumMasterinalcuniteamsvolgeildoppioruolodiprogrammatoreeSM,inaltriteam

invecesvolgeilruolodiSMatempopieno,inquesticasipuòanchenonavereun

backgrounddaprogrammatore,madeveaverecapacitàorganizzativeemotivazionali.Il

ruolodiScrumMasterèstatoricopertopercandidaturaspontaneadeimembridelteam

duranteilperiododiformazione,eccettoilcasodiScrumMasternonprogrammatore.

Primadiesserelanciatiiteamsonostatiformatisulfunzionamentodellametodologia

Scrum,iruolielepratiche.Dopoillancioc’èstatounperiododiaffiancamentodeicoach

Agilenelleprincipalicerimonieincuiessosièassicuratochevenisseroapplicatelebest

practicesefosserocapitiiprincipidelmetododilavoro.Èmoltoimportanteinfattichei

membridelteamcapiscanol’importanzadelleattivitàprescritteedacosaessesiano

finalizzate,evitandochesianopercepitecomeobblighiprividiutilità.

Labaseteoricaacuisiappoggianolecerimoniescrumèl’approccioPDCA,conosciutocome

“ruotadiDeming”:cioèilconcettochedebbanoesseresvolteinmanieraciclica4tipidi

attività,laPianificazione“Plan”,il“Do”cioèsvolgereeffettivamentel’attivitàpianificata,il

“Check”cioèilcontrollodell’attivitàsvolta,e“Act”attuazionesiadellecorrezionidiciòcheè

statorilevatonelcheck,chedeimiglioramentialprocesso.

Inquest’otticaiprocessietutteleattivitàsvoltevengonomiglioratecontinuamentesiain

efficacia,cioècapacitàdiconseguiregliobiettivi,cheinefficienza,cioèottimizzazionedegli

sforzinelladirezionedegliobiettivieminimizzazionedelleattivitànonavalore.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

81

Esisteilrischiocheiteammember,diformazioneinformatica,noncolganol’importanzadi

attivitàdicaratteregestionale,chepotrebberoesserepercepitecometemporubatoalla

programmazione,epoiquestenonsianoapplicatearegime.Èimportante,invece,che

capiscanocomepochiminutidipianificazionepossanoevitaremolteoredi

programmazione,l’importanzadellacomunicazioneintraeinter-teamalfinedellaqualitàdi

quantoprodotto,l’importanzadeitestdiunitàedintegrazione,echeleattivitàdireviewe

retrospettivaportanoadazioniconcretechemiglioranoillavorodituttiigiorni.

Lecerimoniesucuièstatafattaformazionesonoquellerelativeallosprint,incuiloScrum

Masterfadafacilitatore:

LoSprintèilnomedatoall’iterazione,dicadenzadiduesettimane,sucuilavorailteam.Si

trattadiunperiododitempofissatoincuiilteamcreaerilasciaunincrementodelsoftware

funzionante.Durantequestoperiodoilteamsvolgeautonomamentetutteleattivitàdi

pianificazione,sviluppo,testing,debug,eDemodelsoftware.

• Sprintplanning:sitrattadiunmeeting,delladuratatimeboxeddiquattroore,svolto

all’iniziodiognisprint,concuiilteampianificaautonomamenteillavorodasvolgere

durantel’iterazione.Serveadallineareimembridelteamversogliobiettivicomuni

dell’iterazioneedadeciderecosadovràesseremostratonellademodifinesprint.In

praticaimembridelteam,decidonoqualistorieprenderedalProductBacklog,cheè

statocreatonellaReleasePlanningedinserirenelloSprintBacklog.Sitrattadiunveroe

proprioadattamentodipratichediprogrammazionedellaproduzionealcontestoAgile.

ComeprimacosailteamvasulsistemainternodigestioneJira,doveèriprodottoin

formaelettronicailProductBacklogdelteam,edanalizzalestoriepresentiunaperuna

inordinedipriorità,discutendoneladimensione,lesfidetecniche,icriteridi

accettazioneedinfineassegnandoaciascunadiquesteloStoryPoint,cioèunpunteggio

chenerappresentaunindicatoredicomplessità.

IlvaloredelloStoryPointvienedecisotramiteunparticolaremetodobasatosullanciodi

cartedaciascunmembrodelteamdettoScrumPoker:

Ciascuncomponentedelteamdisviluppohainmanounmazzodicarteconpunteggi

crescentisecondolasequenzadiFibonacci,lestoriepresentinelProductBacklog

vengonounaadunapresentateediscusseriguardoagliobiettividaraggiungere,strade

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

82

chesipossonoseguire,difficoltàriscontrabili.Dopolapresentazionetuttiicomponenti

votanoloStoryPoint,rappresentativodellacomplessitàdaassegnareallastoria,girando

lecartetuttiinsieme.LoStoryPointèassegnatorispettoastoriepassatedigrandezza

standard,solitamenteilteamhaunastoriadiriferimentodicomplessitàtre,dal

confrontoconquestavotalenuovestorie.

Figura3.7:Carteperl’assegnazionedegliStoryPoints

Dopoillancio,seipunteggiassegnatidifferiscono,icomponentispieganoperchéhanno

assegnatoquelpunteggioeprocedonoripetendolavotazione,infattiallalucediquanto

emersoicomponentipossonocambiareopinionesullacomplessitàdellastoria,siripete

l’iterazionefinoaquandononsièraggiuntalaquasiunanimità,conl’obiettivodiavereuna

stimacoerente.QuestometododiassegnazionedeipunteggiderivadalMetodoDelphi,

girarelecartetuttiinsiemepermetteinfattiunavalutazioneautonomaedievitare

condizionamentiesterni,lefasisuccessiveinvecepermettonol’emergeredituttiipuntidi

vistasulledifficoltàriscontrabili.

UnavoltaassegnatigliStoryPointsilteampuòdeciderequantestoriedelProductBacklog

inserirenelloSprintBacklog,usandocomeriferimentounindicatorechiamatoVelocity,che

rappresentalasommatoriadeipunteggidellestoriecheilteamèriuscitoaportarea

termineneglisprintprecedenti.VengonocaricatenelloSprintBacklogunaquantitàdistorie

lacuisommatoriadiStoryPointèinlineaconlaVelocitymediadelteamlasciandoalcune

storieextraincasodiproduttivitàmaggioreaquellaprevista.

Adessovienesvoltaunariprovadiaverpianificatolagiustaquantitàdilavoroperlosprint:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

83

sipartecolconteggiareleoretotaliadisposizionedeimembridelteamnellosprint,infatti

questepotrebberocambiaredasprintasprintacausadiferieprogrammateedattività

collateralicomeleeCommunityofPracticesedaltrecerimonie.Ilsecondopassaggio,di

difficoltànonbanale,consistenelsuddividerelestorieinsingoletask,cioèattivitàunitarie

realizzabilidaunsingolocomponentedeldevelopmentteaminunintervalloditempo

inferiorealle8ore,comprensiveanchedeltesting.

Questopermettedieffettuareunastimadelleoredisvilupponecessarie,edinfasedi

esecuzioneunamiglioregestionedellosviluppostorieattraversol’esecuzionedisingole

attività.Adessocheabbiamoottenutounastimadeltemporichiestodaciascunastoria

possiamofareunariprovaconleoredidisponibilitàdeicomponentidelteam.

Danotarechedurantelosprintleorestimateperisingolitaskpossonoessereaggiornatee

cambiateinbaseaquantoriscontrato.

• Daily:Anchedetto“Standupmeeting”.Èunmeetingsvoltolamattinatraimembridel

teamScrum,haduratadiunquartod’oranelqualeciascunmembrodelteamspiega

cosahafattoilgiornoprecedenteecheimpedimentihatrovato,cosafaràdurantela

giornataequaliimpedimentiallavoroprevede,questomeetingèfondamentaleper

permettealteamdiorganizzarsiautonomamenteillavorogiornaliero.

Perscegliereletaskdaportareavantiicomponentidelteamfannoriferimentoallo

SprintBacklog,dovesonopresenti,scrittesupost-it,tutteletaskrelativeallestorieda

completarenellosprint.Losviluppatoreprendeinconsegnaunadiquesteelaspostada

To-doaWipedinfine,quandoportataatermine,inDone,attaccandosulpost-itilsuo

avatarperpermettereunatracciabilitàdichihasviluppatocosa.Glisviluppatori

scelgonoautonomamentequaletaskportareavanti.Solitamenteèpresenteun’altra

colonnadopoDone,dovevengonospostatiletaskquandosiaccertacheessesoddisfino

tuttiirequisitidella“DefinitionofDone”.

La“DefinitionofDone”èunelementofondamentaledelmetododilavoro,consistein

unalistacreatadalteamditutteleattivitàeditestchedevonoesseresvoltisuuna

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

84

storiaprimadipoterladefinirepronta,serveadassicurarelaqualitàdelcodiceedevitare

chealcuneattivitàimportantisianostateomesse.

figura3.8:LaDefinitionofDonediunteamdisviluppo

• SprintReview-Demo:Èunmeetingsvoltoafinesprintdelladuratamassimadidueore,in

cuiilteamricontrollal’incrementorisultantedallavorodell’iterazioneelopresentaal

ProductOwnerattraversounademodelsoftware.Lademohaloscopodiispezionareil

funzionamentodelsoftwareaggiornatodalteamdisviluppoconilrilasciodellenuove

storie.Siverificacheeffettivamentelestoriesvolganoquantostabilitoecheapportino

valoreall’esperienzadell’utente.

Ilteamdeveessereingradodidimostrareognistoria,Spike,orequisitononfunzionale

sulqualehalavorato.Preparareunademodell’incrementorichiededellosforzoalteam,

maserveperottenereunrapidofeedbackdalPOcherappresentaintuttoepertuttola

vocedelcliente,epuòdeciderediaccettareomenol’incremento.

Lademorappresentailmomentoformaledichiusuradellosprintincuiviene

concretizzatol’apportodivaloredelperiodo,dalpuntodivistamotivazionaleèun

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

85

momentochefornisceaimembridelteamdisviluppolasoddisfazionedivedere

concretamenteilfruttodellavoro.OltrealProductOwnerpossonoparteciparetuttigli

stakeholderinteressati,membridialtriteam,BusinessOwner,verticiaziendali,partner,

edaltri,alloscopodiforniredeifeedbackalteam.

Dopocheilteamhamostratotuttelestoriecompletateparladiquellechenonèriuscito

aportareatermineedellemotivazioni,chepossonoessererelativeastimesbagliate,ad

impedimenti,mancanzadicompetenzeoover-commitment;quellocheemergeviene

discussonellacerimoniasuccessivacheèlosprintretrospective.

• SprintRetrospective:Èunmeetingdiduratamassimadiun’ora,cheavvienetipicamente

dopolaSprintReview,asprintterminatoprimadicominciareilnuovosprint.

Loscopodelmeetingèquellodipermettereaimembridelteamdifermarsiperunbreve

periodotimeboxedadanalizzarecomehalavoratonellosprinteindividuarepossibili

miglioramenti.

Ilpuntodipartenzaèlapresentazionediindicatoridiperformancedellosprintche

tipicamentetieneloScrumMastercomelavelocity.

Quindiognimembroesponecosasecondoluihafunzionatobenenellosprintecosa

meno,sifaunaanalisidellecausedeiproblemiriscontratiesicercanopossibili

miglioramenti.

Sitrattadiunmeetingalqualenonhopotutoassistere,inquantononsonoammessi

ospitiperfarsicheimembridelteampossanoconfrontarsiapertamenteedanche

affrontareproblemineirapportipersonali,primachesfocinoinliti.

Lepossibiliazionidimiglioramentoemersevengonoapplicatenellosprintsuccessivo.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

86

Figura3.9:NotazionidiVelocity

• BacklogRefinement:Ilbacklogcontienealcunestorie,quellepiùprossimealla

realizzazione,chesonoinunostatoavanzatodimaturità,sonobendefiniteepronteper

essereimplementate,mentrealtresonoancorainunostatomenomaturoedhanno

bisognodiesseredefinitemeglioperpoteressereimplementate.Ilbacklogrefinement

consistenelportarelestorieadunmaggiorelivellodimaturitàecominciareadiscuterne

icriteridiaccettazionedellestoriepiùvicine.

Nell’effettuareattivitàdiformazionebisognatenerepresentecheglisviluppatoridevono

continuarealavoraresulcodice,l’attivitàdell’aziendanonpuòessereinterrotta,quindiè

importantemantenereuncertoequilibriotral’attivitàdiformazioneediltempochedeve

esserelasciatoallosviluppo.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

87

3.3.6. LatransizionedellivellodiReleaseTrain

DopocheiteamhannobenassimilatoilfunzionamentodiScrumvengonocreatedelle

communityinter-team,erelativecerimoniediincontro,finalizzateallagestionedelRelease

Train,ilsecondolivellodiSAFe.

Sitrattadigruppidipersoneappartenentiateamdiversi,chesiincontranoincommunityal

finedipermettereunoscambiotrasversalediconoscenzeel’allineamentodei

comportamentinell’organizzazione.

Silancianoinoltrelecerimoniedipianificazione,ispezioneedadattamentodellivellodi

ReleaseTrain,relativeall’iterazionediProgramIncrement.Inquestecerimoniesilavora

sullacreazionedellaconsapevolezza,traimembrideivariteam,difarpartediununico

teampiùgranderelativoatuttoilprogramma.

Il“teamdeiteam”vienechiamatoinSAFe“ReleaseTrain”esioccupaatempopienodiun

unicoprogramma,Tagetik.LacadenzaconcuilavorailReleaseTrain,dettoProgram

Incrementèdi6sprintdeiteam,quindiiciclidipianificazione,demo,rilascioeretrospettiva

avvengonosuquestacadenza.

Lecommunityerelativecerimoniechevengonolanciatesono:

• CommunityofPractices:sitrattainpraticadimeetingripetutiadintervalliregolariogni

unaoduesettimanetraespertisuunospecificocampodidiscussione,appartenentia

teamdiversi,conalmenounrappresentanteperteam.LeCommunitysonofinalizzate

alloscambiodiconoscenze,individuazionediproblemiedecisionedisoluzionicomuni;

questesonodellesedifondamentaliperfarsicheleconoscenzedell’organizzazionenon

sirinchiudanoall’internodelsingoloteam,maalcontrariofermentinotraidiversiteam,

egarantirel’allineamentodeicomportamentideiteam.

LeCommunityOfPracticecheattualmentesiriunisconoregolarmentesonoquelladegli

ScrumMaster,deiProductOwner,delframework,sullaqualitàdelcodice,esul

database.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

88

• ScrumofScrum:Sitrattadiunincontroconcadenzasettimanaleacuipartecipanogli

SMdituttiiteamperdiscutereassiemedellavorochestannosvolgendoirispettivi

team,degliimpedimentichehannotrovato,dellavorocherealizzerannonelperiodo

successivoegliimpedimentichepotrebberotrovare,ponendoparticolareattenzione

alleareedisovrapposizioneedintegrazione.ConcettualmenteèsimilealDailydeiteam,

peròavvienealivellodiprogramma.

• ReleasePlanning:Sitrattadellapianificazionedelleattivitàdisviluppocheverranno

realizzatenellaprossimareleasediprogramma,cheinTagetikècompostada6sprint

deiteam.

Èunmeetingdelladuratadiun’interagiornatacheavvienemediamenteadintervallidi

3mesi,sitrattadiunodeglieventipiùimportantiinSAFeperchépermettedicoordinare

leattivitàdidiversiteamversoilprossimorilasciodelprogramma.Concettualmente

possiamoparagonarloadunosprintplanningdeiteam,peròallivellodiprogramma.

SitrattadiuneventoroutinizzatochecominciaconunritrovodituttigliScrumMaster

peranalizzarelaRoadmapedellaVisiondell’incremento;successivamentegliScrum

Masterraggiungonoipropriteam,edinsiemeaglialtricomponenticomincianoa

pianificareagrandilineeciòcheverràsviluppatonellareleaseperriuscirearaggiungere

gliobiettivi,andandoadefinirelestorieescendendogradualmenteadunlivellosempre

maggioredettaglio;gliScrumMasterdeidiversiteamsiritrovanoognioraper

comunicaresullostatod’avanzamentodelleattività;manoamanocheilprocesso

avanzaiteamcomincianoaspezzettareadunmaggiorlivellodidettagliolestorieche

dovrannosvilupparescrivendolesupost-itedecidendolasequenzadelleattività,

ponendoinfinelestoriesull’orizzontetemporaledeidiversisprint.

Unavoltaidentificatetuttelestorieparteunasecondaattività,checonsiste

nell’identificareledipendenzetralestorietrovatedaidiversiteam,sitrattacioèdi

attivitàdisviluppovincolateallavorodialtriteam,adesempiostoriechenecessitano

primadicodiceiningressodaaltriteamperesseresviluppate,oppurestoriechesonodi

confinetradueteam.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

89

Laterzaattivitàdeiteamconsistenell’identificaretuttiirischialraggiungimentodegli

obiettivipianificati.

Questeprimetreattivitàvengonosolitamenteterminateentrolamattinata.

NelpomeriggioavvieneunincontrodiScrumMaster,ProductOwner,SystemTeam,

TransitionTeam,teamdiReleaseTrainetuttiglistakeholderinteressati,perdiscutere

delledipendenzetrovateeottimizzareladiposizionedellestorieneltempo,perfarsi

cheattivitàsvoltedaunteambloccantiperlosvolgimentodelleattivitàdialtriteam

venganosvolteneitempigiusti.

Figura3.10:MeetingdiReleasePlanninginTagetik

Vienecreatalaboarddireleasechecomprendetuttelestoriedasvilupparedatuttiiteam

distribuiteneglisprint,poivengonoappesideifilirossidicollegamentotraalcunestorie,che

rappresentanoledipendenzetrovate.Questifiliservonoperricordareaiteamdelle

dipendenzeevengonostaccatidallaboardunavoltarisolti.Laboarddeverimanere

aggiornataincasodivariazionidelleattività.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

90

Figura3.11:UnaboarddiRelease

Figura3.12:UnaboarddiReleaseconledipendenzeliberate

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

91

Vengonoanchediscussiirischiidentificatidaiteameclassificatiinunadellequattro

categorie:

i. Risolto:siamoarrivatiallasoluzionedelproblemaetuttiiteamsonod’accordocheil

problemanonesistepiù;

ii. Owned:Ilproblemanonpuòessererisoltonelmeetingperòunapersonasiprendela

responsabilitàdirisolverlo;

iii. Accettato:accettiamoilfattochepossanoaccadere;

iv. Mitigato:Iteamidentificanounpianopermitigarel’impattodell’evento;

Unavoltaevidenziatetutteledipendenzeedirischiiteamvotanolaconfidenzanelriuscire

aportareaterminegliobiettividireleaseconunvotoda1a5.Unvotodialmenotreporta

adaccettarequantopianificato,unvotodi1o2significachedevonoesserefatteulteriori

modificheperchéc’èilrischiodiunover-commitment,lavotazionevienereiteratafinché

nonsiarrivaadunpianoconsideratofattibiledaciascunteam.

• ReleaseRetrospective:Sitrattadiunmeetingchevienesvoltopochesettimanedopola

chiusuradellaRelease,delladuratadiunpomeriggio.PartecipanotuttigliScrumMaster,

iProductOwneredunprogrammatoredelteam,ilSystemteam,ilTransitionTeam,il

TeamdiReleaseeglistakeholderinteressati.

L’obiettivo,comeintutteleretrospettive,èquellodiprendersiunperiododitempo

timeboxedperfermarsiaguardarecomeabbiamolavorato,analizzareefficaciaed

efficienzatramiteindicatoriquantitativiequalitativi,faremergeretuttiiproblemi

trovati,sceglierequellipiùgravi,indagaresullepossibilicauseecercaresoluzionidi

miglioramento.Peròinquestasede,adifferenzachenellaSprintRetrospective,ci

focalizziamosullivelloditeamdeiteam.Quellocheanalizziamoquindisonoirapportied

interfaccetraidiversiteam,lacapacitàdidividersiillavoro,iproblemipiùgrandiche

riguardanoilprogramma.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

92

Ilmeetingparteconirappresentantidiogniteamchemostranol’incrementochehanno

apportatoinquestaRelease(quindiseisprint),cosaèstatoportatoatermineecosano

rispettoaquantopianificatonelReleasePlanning,cercandolecausechepossonoessere

relativearapportiinter-teamecattivagestione.

DoposidiscutedellostatodelleCommunityepossibiliproblemi.

Oltreaquestosiindagasuulterioriproblemilasciandolalibertàaipartecipantidiscriverlisu

post-it.Siclusterizzanotuttiiproblemiemersiinclassiomogeneeesivaavotaresuqualidi

questic’èunamaggioremergenzadiintervento.

Suidueotreproblemivotaticomepiùemergentisifaunaanalisidellecauseeditutti

l’impattichepotremoavere,adesempiocrashdelsoftware,perditaclienti,dannidi

immagineecc.alfineditrovareunastrategiapergestirequestirischi.

Poisiindagasullecauseepossibilisoluzioniconalcunistrumentitipicidelproblemsolving.

3.4. Primirisultatidellatransizione

3.4.1. Situazioneattuale

Comedescrittoneicapitoliprecedentilatransizioneèdigrossaportata,edalmomento

attuale,difinetirocinio,nonèancoraterminata;andiamocomunqueadanalizzareirisultati

parzialidiquesteprimefasi:

Seguendounalogicaditransizionesequenzialeditipobottom-up,allostatoattualeèstata

portataaterminelatransizionedellivellodeiteamScrum,fasepiùimportantedella

transizione,inquantosegnaeffettivamenteilpassaggioadunametodologiadilavoroAgile.

ÈincorsoquelladiReleaseTrain,sistannodiffondendotraimembrideiteamicapisaldidi

SAFeelaconsapevolezzadifarpartetuttidiununicoteampiùgrande.Questosta

avvenendotramiteillanciodiattivitàdicoordinamentointra-team,lacreazionediruolidi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

93

Program,eleattivitàdidiffusionedeivaloridiReleasenellecerimoniedapartedeicoach

Agile.

3.4.2. AnalisiconSurvey

AndiamoaindagareconunaSurveyanonimasuirisultatidellatransizionedelprimolivello,

quellodeiteamversoilframeworkScrum.Sitrattadellafasepiùimportantedella

transizione,quellachepermetteall’organizzazionediessereeffettivamenteAgile.La

transizionesembraaveravutoesitopositivo,noncisonostatigravirallentamentidi

produttività,mentresembraelevatalarispostadalpuntodivistadelmoraleedella

soddisfazionedeiprogrammatori.

SonomostratiirisultatidellaSurvey,bisognatenerepresentecheiteamhannoundiverso

gradodimaturitàinquantosonostatilanciatiinfasisequenziali,iteampilota“Banana

Sprint”e“CashandChips”sonoattivida7mesi,irestantida3.

LaSurveyèstatasottopostaatuttiiteammemberscomprensividisviluppatori,Scrum

MastereProductOwner.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

94

Figura3.13:LaSurveysomministrataaiteam

1. ComegiudichilaquantitàdilavorosvoltodalteamlavorandoconScrumrispettoai

metoditradizionali:

0-Sensibilmentepeggiore;

1-Peggiore;

2-Invariato;

3-Migliore;

4-Sensibilmentemigliore;

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

95

Figura3.13:RadardellaSurvey“quantitàdilavoro”

Nell’analizzareirisultatidellaSurveyusiamocomeriferimentolacirconferenzadivaloredue

cherappresentaunapercezioneinvariatarispettoallasituazioneprecedente.

Laquantitàdilavorosvoltapercepitaèper4teammaggiore,perunoinvariataeperun

teamleggermenteminore.BisognaprecisarecheilteamUXFilesèunteamchesiètrovato

inunasituazioneparticolare,infatticompostodasoli4programmatoridicui2inmaternità

edhaavutoproblemidimalattianelperiodo,quindilapercezionepotrebbeessere

influenzatapiùdallasituazionespecificachedaproblemidelmodelloorganizzativo.

Inoltredobbiamoteneredicontochesitrattadiindaginisvoltedopounbreveperiododi

lanciodelmodello,èlogicoaspettarsiunaumentodellaproduttivitàdeiteamdovutoad

economiediapprendimento,allacomprensioneeroutinizzazionedeicomportamentiedelle

cerimonieScrum.

Ilmodelloèprogettatoproprioperfarsicheleperformancedeiteamaumentinoneltempo,

grazieall’applicazionesistematicadifasidiPDCAcheimplementaadogniiterazionei

miglioramentiemersinelleretrospettivedisprint.Perquestosirimandaalconcettodi

velocityeleseriestorichedivalori.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

96

2. Comegiudichilachiarezzadegliobiettividaraggiungerenellosprintrispettoaprogetti

condotticonaltrimetodidilavoro:

Figura3.14:RadardellaSurvey“Trasparenza”

C’èstatounaunanimitànelconcordarechelachiarezzadegliobiettividisprintèaumentata

notevolmente,grazieall’utilizzodelbackloglecuitaskrimangonofissedurantelosprint.

3. Comegiudichicollaborazioneecooperazionedelteamrispettoaprogetticondotticon

metoditradizionali:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

97

Figura3.15:RadardellaSurvey“Cooperazione”

Anchesullacollaborazionedeisingoliall’internodelteamèstatopercepitonettamenteun

aumentorispettoallasituazioneprecedente,cheeramoltoincentratasullavoroindividuale.

4. Quantovaloredibusinessritienisiastatoprodottointrentagiornirispettoadunmetodo

tradizionale:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

98

Figura3.16:RadardellaSurvey“ValorediBusiness”

PerquantoriguardailvalorediBusinessrilasciatoabbiamovalorimaggioriperquasituttii

teamedinvariatiperunteam.Ilvaloredibusinessgeneratoèrilevatoconunadomanda

separatadallaproduttivitàperchésebbenedipendadaquestaèinfluenzatoanche

dall’efficaciadiquantoprodottonelsoddisfareiclienti,mentrenontienecontodellavoro

svoltopermanutenzionesulcodicevecchio,lavorocheoccupaancoramoltedelleore/uomo

deiprogrammatori.

5. Quantotempoèstatosprecatoinatteseemalintesiequantolavoroèstatorifatto

rispettoadunmetodotradizionale:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

99

Figura3.17:RadardellaSurvey“TempoSprecato”

Ivaloripositiviinquestocamposonodovutialfattocheiteampossonolavoraresempre

sulletaskpresentinelpropriobacklog,senzapreoccuparsididoverattenderecodiceininput

daaltriteam,lagestionedelledipendenzeèrisolta,perquantopossibile,infasediRelease

PlanningedevidenziataconifilirossisullaboarddiRelease.Inoltrelestoriedasviluppare

neglisprintrestanoinvariate,questoriduceilrischiodisvilupparecodicenonnecessario.

6. Comegiudichiilgradodiqualitàdiquantoprodottorispettoametodipassati:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

100

Figura3.18:RadardellaSurvey“Qualità”

Vieneunanimementepercepitounincrementonellaqualitàprodotta.Ilmodelloponeenfasi

sullaqualitàdelcodice,suconcettidiownershipcomplessivadelcodiceeroutinizzarele

attivitàditestandcode.

7. Comevalutilavisibilitàegestionedeirischiedimpedimentirispettoadunmetodo

tradizionale:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

101

Figura3.19:RadardellaSurvey“GestionedeiRischi”

Ilmetodoprevededegliorariprestabilitiincuiilteampuòessereinterrottodamembridi

altriteampercolloquinonprogrammati.Scrumprevedemoltecerimonie,masonoditipo

routinizzato,eleattivitàdisprintplanningedildailypermettonodistimareleinterruzionial

lavoroemitigaregliimpedimenti.

8. Soddisfazionedelteamrispettoaprogettisviluppatinellasituazioneprecedente:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

102

Figura3.19:RadardellaSurvey“Soddisfazionedelteam”

Lasoddisfazionegeneraledeiteamèmigliorata,perunteamèrimastainvariata.

9. Possibilitàdiadattarelepratichedilavoronelteamrispettoametoditradizionali:

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

103

Figura3.20:RadardellaSurvey“Adattabilità”

• Alladomanda“Consiglierestil’Agile?”ogniintervistatoharispostoSI.

• NellasezionePlus/Deltal’intervistatopotevaspiegarecosasecondoluièmiglioratoo

peggioratorispettoallasituazioneprecedente,questoèquantoemerso:

PLUS:maggiorcollaborazionetraimembridelteam;migliororganizzazionedellavoro;

maggiorcondivisionedellecompetenze;serenitàdell’ambientedilavoro;maggior

qualitàdelcodiceprodotto;possibilitàdiottenerefeedbackrapidisullavoro;maggior

sforzonelmettersineipannidell’utente;maggiorrispettodelleideedituttiimembridel

team;obiettivipiùabrevetermine;minorrischiopercepitoperunamaggiorevicinanza

aglistakeholder;maggiorcondivisionediideenellosviluppare;maggiorstimoloa

raggiungereirisultati;scadenzevicinemantengonoaltiglistimoli.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

104

DELTA:Molteinterruzionidellavorodovuteallecerimonie;scadenzevicinepressanti;

difficoltànelcollaborareconaltriteam;difficoltànell’interagireconalcunicolleghiche

lavoranomale;difficoltàainteragireallapariconcolleghipiùanzianiinazienda;

difficoltàdicomunicazionetraProductOwnereprogrammatoriinterminidilinguaggio;

difficoltàdiprogrammatoricheorasvolgonoildoppioruolodiScrumMasterneltrovare

iltempoperprogrammare;difficoltàapassaredaunlavorostrettamenteindividuale

versounoditeam;

DiquestiPluseDeltariportatialcunifannoriferimentoaciòcheeragiàemersonellasezione

avotodellaSurvey,maemergonoaltripuntiinteressanti:

Glisviluppatoripercepisconounoscambiodicompetenze,finoadoraditipopiù

specialistico,conicolleghi;Partecipanopiùmenticontemporaneamenteallasoluzionediun

problema;

SonosoddisfattidellapossibilitàdiriceveresubitounfeedbackdalProductOwnersuquanto

realizzatonellosprintequestofapercepiremaggiormentel’incrementoapportatodaogni

storiaalvaloredibusiness.

Lescadenzevicineognisprintdaunlatodannounmaggiorestimoloaraggiungereirisultati

emantengonolaproduttivitàsemprealta,dall’altrolatoalcunipercepisconouneccessivo

stresschepotrebbeesserecausatodaover-commitment,situazionechefascattareun

campanellod’allarmeevasicuramentemonitorata.

LecerimonieScrumsononumeroseealcunisviluppatoriritengonotolganoeccessivotempo

allaprogrammazione,dall’altrolatositrattadiattivitàdipianificazionecontrolloe

miglioramentonecessarieperottenerequell’aumentodiqualitàedivaloredibusiness

apportatocheèstatorilevatodatutti.Èimportantenonsottovalutarelaquestionee

mantenereilgiustobilanciamentotrailtempocheiprogrammatoridedicanoadattivitàdi

gestioneeiltempodadedicareallosviluppo.InquestoèimportanteilruolodiScrum

Mastercomecuscinettotrailteamegliimpedimentiesterni.

Ilteam-workingèriconosciutocomeunelementopositivonelmigliorareilproblemsolvinge

scambiodiconoscenze,peròsinotanodelledifficoltàdiattuazione,arrivandodauna

situazionecheeraincentratasullavoroindividuale.Inoltrecisonoproblemidi

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

105

collaborazionetramembridelteamcheprecedentementesvolgevanoruoligerarchicamente

diversi,ocondiversilivellidianzianitàinazienda,mentreorasitrovanoallostessolivello

gerarchico.

SAFeprevedeinoltredimonitorareperiodicamentelecondizionidisalute

dell’organizzazioneconquestionaridiautovalutazione,iprimisonostatigiàsomministratiai

team.

IlquestionariodiautovalutazionecreatodaSAFesibasasull’individuazionedi

comportamenticherappresentanofattoricriticiperilsuccessodeiteamall’internodella

strutturaorganizzativa.

• ProductOwnershipHealt:capacitàdelteamdiindividuareegestireirequisitida

inserirenelbacklogedimplementarenelprogramma;

• PI/ReleaseHealt:capacitàdelteamdifarpartedelReleaseTrain,equindidi

interagireconglialtriteam;

• SprintHealt:efficaciadelleattivitàecerimoniedisprintdeiteam;

• TeamHealt:statodisalutedeirapportitraimembridelteamecapacitàdi

teamworking.

• TechicalHealt:capacitàocarenzetecnichedelteam.

Ciascunodiquestifattorièscompostoin5attivitàallaqualeilteammemberdaunvotoda0

a5sullafrequenzaconcuiquestevengonosvolte.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

106

Figura3.21:QuestionariodiautovalutazioneperiteamdiSAFe

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

107

3.5. Conclusioni:

L’elevatadinamicitàevelocitàdivariazionedeirequisitinelsettoredellaproduzionedel

softwarehannoportatomolteorganizzazioniadadottaredeimodelliorganizzativiAgile,al

finediaumentarelapropriaflessibilitàemigliorareleperformanceinterminidiproduttività

equalitàdelsoftware.

ImodelliAgilesonoormaiampiamentediffusinelsettoretraleorganizzazionidimedio-

piccoledimensioni,maabbiamovistocomeancheuncrescentediorganizzazionidigrosse

dimensionistiapassandoaquestimodelli,essiperessereimplementatiingrossicontesti

necessitanodialcuniaccorgimentiestrategiediadattamento.Inquestadirezioneimodelli

specifici,traiqualiSAFeharaggiuntoilmaggiorgradodidiffusione,sembranooffriredelle

soluzioniefficaciedinondifficileimplementazione.

IlcasodistudiodellatransizionedaWaterfalladAgileinTagetikSoftwares.r.l.hamostrato

lefasi,gliapproccieglistrumentitipiciperquestotipoditransizione.Iprimirisultatiparziali

delprogetto,analizzatinelparagrafoprecedente,sonoottimi.Tuttaviaènecessario

continuareconilmonitoraggiodellefasisuccessivedellatransizioneperpoterdareun

giudiziocomplessivosugliesitidelprogetto.

Sviluppifuturipossonocomprendereanalisidelleperformancediuncampionesignificativo

diorganizzazionipassateall’utilizzodimodelliAgileScalati,alfinediidentificareleevoluzioni

dellestrategiediimplementazioneedipoterconfrontareleperformancediquestimodelli

conapproccialternativi.

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

108

Bibliografia:

o Deanleffingwell,2011.“ScalingSoftwareAgility:BestPracticesforLargeEnterprises”

o GeraldM.Weinberg,2003.“AgileImpressions”

o SuprikaV.Shrivastava,2008.“RiskManagementinDistribuitedAgileDevelopment”

o UrvashiRathod,2008.“CategorizationofRiskFactorsforDistributedAgileProjects”

o Deemer,2010.“TheSecretSauceForOrganisationalAgile”

o NishijimaandDosSantos,2013.“ThechallengeofimplementingScrumAgile

methodologyintraditionaldevelopmentenvironment”

o JyothiandRai,2011.“AgileBusiness:Efficient,Effective&Growing”

o QumerandHenderson-Sellers,2006.“MeasuringAgilityandAdoptabilityofAgile

Methods”

o DeAvezadoSantos,2011.“AgilePractices:anAssessmentofPerceptionofValueof

ProfessionalsontheQualitycriteriainPerformanceofProjects”

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

109

o Glaiel,2013.“Agileprojectdynamics:Astrategicprojectmanagementapproachtothe

studyoflargescalesoftwaredevelopmentusingsystemdynamics”

o Nerur,2005.“TheoreticalReflectionsonAgileDevelopmentMethodologies”

o ScottAmbler,2005.“EnterpriseUnifiedProcess:ExtendingtheRationalUnifiedProcess”

o Trivellas&Drimoussis,2013.“InvestigatingLeadershipStyles,Behaviouraland

ManagerialCompetencyProfilesofSuccessfulProjectManagers”

o GeorgiosPapadopoulos,2013.“Movingfromtraditionaltoagilesoftwaredevelopment

methodologiesalsoonlarge,distributedprojects”

o KenScwaber,MikeBeedle,2001.“AgileSoftwareDevelopmentwithScrum”

o StanleyMcCrystal,2014.“TeamofTeams,NewofEngagementforaComplexWorld”

o CraigLarmar,BasVodde,2008.“ScalingLean&AgileDevelopment:Thinkingand

OrganizationalToolsforLarge-ScaleScrum”

o AlanShalloway,GuyBeaver,JamesTrott,2009.“Lean-AgileSoftwareDevelopment:

AchievingEnterpriseAgility”

o SandraMerdith,DavidFrancis,2006.“JourneytowardsAgility:theAgileWheelexplored”

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

110

o FrankK.Y.Chan,JamesThong,2008.“AcceptanceofAgileMethodologies:Acritical

reviewandconceptualframework”

o AycaTarhan,SedaGunesYilmaz,2013.“SystematicAnalysesandComparisonof

DevelopmentPerfomanceandProductQualityofIncrementalProcessandAgileProcess”

IModelliOrganizzativiAgileScalati:ilcasoTagetikSoftware MarcoPenco

111