I Modelli Organizzativi Agile Scalati: il caso Tagetik … Modelli Organizzativi Agile Scalati: il...
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
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”