Service Oriented Agility @ Italian Agile Day - Bologna 2008

Buzzword  Deathmatch: Si può fare agile in una  SOA?

About me • 10 di esperienza come consulente nel mondo IT. • Ho partecipato a mol> “grossi proge@” – Pubblica amministrazione – Bancario – Assicura>vo – ... • Un po’ architeIura, un po’ processo, un po’  management... • Il mio blog: hIp://ziobrando.blogspot.com  • Trainer (Italia e UK) • Ar>coli, etc. • My e‐mail:  alberto.brandolini@gmail.com

Lo scenario Agile

Perchè Agile? Tradurre

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta>

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a 

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a  • cos> eleva> 

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a  • cos> eleva>  • tempi di sviluppo lunghi

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a  • cos> eleva>  • tempi di sviluppo lunghi • Impredicibilità dei risulta> e bassa percentuale di  successo

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a  • cos> eleva>  • tempi di sviluppo lunghi • Impredicibilità dei risulta> e bassa percentuale di  successo • Diﬃcoltà nella ges>one del cambiamento

Perchè Agile? Tradurre • Lo sviluppo Waterfall si è dimostrato  ineﬃciente e insoddisfacente come risulta> – Waterfall è “tradizionalmente” associato a  • cos> eleva>  • tempi di sviluppo lunghi • Impredicibilità dei risulta> e bassa percentuale di  successo • Diﬃcoltà nella ges>one del cambiamento • Se chiedete in giro, nessuno sta più facendo il  waterfall (…o almeno così dicono)

Uniﬁed Process

Unified Process • Lo unified process ha cambiato radicalmente  lo scenario – Iterazioni come elemento fondamentale  del processo. – Definizione fine di ruoli ed ar@fact/ responsabilità  – UML come linguaggio “ufficiale” – Una definizione esaus@va di tuFe le  aGvità chiave del processo.

Uniﬁed Process  • Unfortunately, it also set the ground for – A family of UML modelling tools – A lot of documenta@on templates 6

Il lato oscuro dello Uniﬁed Process

Il lato oscuro dello Uniﬁed Process • Gli strumen> sono  diventa> sempre più  importan>, deformando  il processo stesso.

Il lato oscuro dello Uniﬁed Process • Gli strumen> sono  diventa> sempre più  importan>, deformando  il processo stesso. • Analisi e design sono  diventate a@vità soliste

Il lato oscuro dello Uniﬁed Process • Gli strumen> sono  diventa> sempre più  importan>, deformando  il processo stesso. • Analisi e design sono  diventate a@vità soliste • Carta, carta ed ancora  carta...

Sviluppatori Gli sviluppatori erano considera>  “risorse interscambiabili” il cui unico  compito era di implementare le  speciﬁche.  Però itera@vamente. 

Occasionalmente, gli archite@ passano in  rassegna la truppa...

Ruoli e Responsabilità

Ruoli e Responsabilità • La ges>one fine dei ruoli ha finito per  tradursi in un faIore di rallentamento – Spesso si finisce per scegliere solo “i task  ada@ al mio ruolo” – (implicit waterfall) – Tempi di risposta più len> – Colli di bo@glia sigli specialis> (o presun>  tali) – Il buon caro vecchio scaricabarile – ...

... I ribelli non stanno a guardare

I tre gus@ dell’Agile • XP ha “faIo il boIo” introducendo  pra>che rivoluzionarie nello sviluppo  socware. • Scrum ha deﬁnito un framework  all’interno del quale le pra>che agili  possono essere applicate all’interno di  un organizzazione. • Il movimento Lean ha introdoIo  conce@ e principi dall’industria  manifaIuriera, nello sviluppo socware  (fornendo anche un retroterra teorico  ad entrambe)

eXtreme Programming • User Stories – Less formal than Use cases, act like placeholder for a real discussion • Frequent small releases – Itera7ons are shorter and targeted to produc7on, • Frequent planning and es4ma4on – Each itera7on is re‐planned according to the currently available informa7on • No an4cipated development – No frameworks or layered architecture • Test ﬁrst – Test suites run preserving applica7on integrity, and producing beAer interfaces • Customer availability – Real feedback is the key to make the right thing • No code ownership • Con4nuous integra4on – The whole system is frequently integrated and tested • Pair programming – Programmers work in pairs, in coding sessions • No over4me • ...

XP • Il feedback è l’elemento chiave per molte  delle pra>che proposte – dal codice – dai colleghi – dal cliente – dal progeFo – dal team  • Il team è responsabilizzato ed incoraggiato a  proporre soluzioni crea>ve • Lo stesso processo può essere modiﬁcato

Scrum • Scrum non si riferisce streIamente allo  sviluppo socware, ma oﬀre un framework  per la ges>one ada@va dei proge@. • A diﬀerenza di UP, ci sono solo 3 ruoli: – Il Team – Il Product Owner  – Lo Scrum Master

Lo scenario @pico di un team

Il team agile • Gruppi di piccole dimensioni • Cross‐func>onal • Il team è libero di prendere qualsiasi  decisione di design • In Scrum, il team riferisce solo al P.O. – Un cerimoniale deﬁnito ed un insieme di possibili  azioni garan>scono che il gruppo non prenda  direzioni indesiderate.

Mol@ stakeholders? Il Product  Owner è  l’unico  responsabile  per il gruppo  di sviluppo.

I principi dello sviluppo Lean • Eliminate waste – TuAo ciò che non fornisce alcun valore per l’utente. • Amplify learning – Lo sviluppo è un aIvità di esplorazione e di ricerca di soluzioni.  • Decide as late as possible – Evitare le decisioni irreversibili, o prenderle solo quando si disponde di  tuAe le informazioni necessarie. • Deliver as fast as possible – Cicli di sviluppo veloci aiutano il feedback. Spesso la velocità è meglio  della qualità. • Empower the team – Il team diventerà il massimo esperto sull’argomento.  • Build integrity in – Il soNware deve essere u7le, e adaAo al compito. • See the whole – In assenza di una visione complessiva avremo solo oFmi locali.

Spreco • Lo spreco (waste) può apparire in varie forme – Documentazione non necessaria – Design an7cipato – Over engineering – AIese – Comunicazioni ineﬃcien> – Dife@ – Handoﬀ – Complessità – blame (scaricabarile) – Qualità (?) – ...

L’approccio Lo‐Fi • Come conseguenza, alcuni tools sono sta>  abbandona>, in favore di un approccio più  materiale. – Carta (user stories, CRC cards, burndown chart) – Post‐it – Lavagne • Gli Informa@on radiators sfruIano la prossimità  ﬁsica per permeIere uno scambio di  informazioni più eﬃciente e completo • Alcuni Strumen> sono sta> bandi> (es.  MSProject), altri sono apparsi (es. Wikis)

The boFom‐up  revolu@on • Agile prepara il terreno per  fare emergere proposte  interessan> dal team • Il team impara and si  concentra su un  determinato spazio di  problemi, spesso diventando  il massimo esperto  disponibile sull’argomento

Col@vare la collaborazione • Raramente si lavora isola> • Molte a@vità sono svolte in  gruppo, in coppie o in  maniera visibile. • La trasparenza migliora la  ﬁducia e premeIe una  collaborazione più eﬃcace. • Gli scambi di informazione  avvengono in entrambi i  sensi

Lo scenario ideale • Non tuIe le condizioni di partenza sono o@mali  per “diventare agili”: per poter sfruIare  pienamente il potenziale dell’agile dovremmo  (idealmente) – Essere assun> in un’azienda la cui massima priorità sia  il socware. – lavorare nello stesso posto – Avere accesso agli uten> (qualsiasi cosa signiﬁchi) – Essere liberi di crescere come team ed assumersi  responsabilità. – Essere liberi di scegliere logis>ca, hardware, etc.

Lo scenario SOA

SOA Ra@onale • Organizzazioni di grandi dimensioni erano  appesan>te dal fardello di – Svaria> legacy systems – Fusioni and acquisizioni • Necessità di integrare sistemi eterogenei • Sistemi duplica@ e ridondan@ – Elevata complessità (non necessaria) • Cos@ opera@vi • Cos@ di evoluzione – Tempi di reazione estremamente len>, ...sviluppi  sostanzialmente blocca>, incapacità di produrre  valore. • ...Ricorda qualcosa?

In cerca dell’uniformità Standard, frameworks,  regole ed integrazione non  hanno garan>to la  necessaria agilità al  business. Con il risultato di  essere un ulteriore fardello  con cui fare i con> prima  ancora di di progeIare una  qualsiasi soluzione.

Service Oriented Architecture • SOA ha come obie@vo di ridurre le  dipendenze fra le applicazioni: – Language coupling  XML – Protocol coupling  WS, SOAP – Network coupling  ESB – Availability coupling  messages • Standard e basso accoppiamento  concorrono a deﬁnire un’architeIura basata  su componen@ sos@tuibili

Low coupling • I servizi possono  dialogare tra loro  con il più basso  Enterprise Service Bus livello di  conoscenza  reciproca  possibile

La promessa iniziale

La promessa iniziale • SOA era uno strumento per

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso.

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010” – “Adesso non c’è tempo”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010” – “Adesso non c’è tempo” – “Possiamo farlo”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010” – “Adesso non c’è tempo” – “Possiamo farlo” – “Perchè non fare quest’altra cosa, invece?”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010” – “Adesso non c’è tempo” – “Possiamo farlo” – “Perchè non fare quest’altra cosa, invece?” – “...Abbiamo un idea...”

La promessa iniziale • SOA era uno strumento per – PermeIere le necessarie operazioni di pulizia – PermeIere all’ IT di diventare un faKore chiave  per il business, invece che un peso. – “è un casino” – “lo meAo in agenda per il 2010” – “Adesso non c’è tempo” – “Possiamo farlo” – “Perchè non fare quest’altra cosa, invece?” – “...Abbiamo un idea...” – PermeIere alle imprese di ridurre il vandor lock‐ in e di recuperare il controllo sul budget dell’IT. 

...deFa in un altro modo Alberto Brandolini 01/0 Qui ci pouò stare l'esem Amazon • SOA è uno strumento per permeIere alle  grandi aziende di raggiungere la business  agility – Cicli di rilascio dei prodo@ più brevi – OIenere il feedback direIamente dal mercato – Sperimentare nuovi modi di fare business

...deFa in un altro modo Alberto Brandolini 01/0 Qui ci pouò stare l'esem Amazon • SOA è uno strumento per permeIere alle  grandi aziende di raggiungere la business  agility – Cicli di rilascio dei prodo@ più brevi – OIenere il feedback direIamente dal mercato – Sperimentare nuovi modi di fare business • SOA non è uno strumento per ricostruire  un’architeFura esistente con una nuova  tecnologia

Il @pico scenario SOA... Lo scenario ideale Agile Lo scenario SOA • Essere assun> in un’azienda  • Generalmente la massima  la cui massima priorità sia il  priorità dell’azienda NON è il  socware. socware • lavorare nello stesso posto • consulen>, risorse a  • Avere accesso agli uten>  progeIo, etc. sono la regola. (qualsiasi cosa signiﬁchi) • Lo sviluppo spesso avviene in  • Essere liberi di crescere  più sedi, frequente il ricorso  come team ed assumersi  all’oﬀshore. responsabilità. • Pochi incen>vi alla crescita  • Essere liberi di scegliere  ed all’assunzione di  responsabilità logis>ca, hardware, etc. • Controllo molto limitato su  logis>ca, hardware, etc.

La tecnologia di SOA

Libertà!? • Basso accoppiamento e standard di  comunicazione indipenden> dal linguaggio  oﬀrono la possibilità di implementare  applicazioni nelle tecnologie più appropriate. Enterprise Service Bus

... Forse siamo ancora  accoppia@...? • L’accoppiamento tecnologico è solo uno dei  vari faIori di accoppiamento sulla scena: – Budget per le licenze – Opera>ons & Support – Standard aziendali, Regole e prescrizioni già in  essere – Strategie per la ges>one del personale – ArchiteIura – Cultura aziendale

In che lingua parliamo? • UML non è suﬃciente per le esigenze di SOA • Emerge un nuovo gergo, nuovi diagrammi,  nuove notazioni, nuovi layer ...

Mettiamo le cose  assieme

Agile and SOA

Agile and SOA “Enterprises experience more success with SOA  when they eschew big top‐down delivery  projects and instead get down in the trenches  with an evolu7onary approach. Agile processes  provide a basic structure for this kind of  incremental delivery.”   • Carey Schwaber, Forrester Research ... non mol> ar>coli invece ci dicono quanto i  processi agili possano trarre beneﬁcio da SOA

Agile come Gioco Coopera@vo • Lo sviluppo socware può essere definito  come un gioco coopera@vo, finito, direFo ad  un obieGvo(Cockburn) Compe@@ve Coopera@ve Finite, Carpet  wrestling Jazz Non‐goal‐directed Dolls Finite, SoLware  Tennis goal‐directed Development Career management Infinite Organiza>on Survival

So[ware development as a Game • Finito: un progeIo comincia e ﬁnisce (in un  modo o nell’altro)  • DireFo ad un obieGvo: es. consegnare in  tempo • Collabora@vo: s>amo giocando insieme agli  altri membri del team • … ma non s>amo facendo solo questo: – S>amo investendo sulla carriera – Giochiamo a fare i genitori – Etc. etc.

Un team di successo

Alcuni elemen@ chiave • Il Team – Migliori talen> disponibili – Obie@vi della squadra prima di quelli personali – Elevata mo>vazione • L’obieGvo – Obie@vo chiaro – esperienza limitata nel tempo – Risultato misurabile

Un team un po’ meno di successo...

Elemen@ chiave • Il team – I migliori talen>? – Obie@vi individuali (o di par>to) prima di quelli  del team, ... o del cliente... :‐( • L’obieGvo – Non così ben deﬁnito (a meno di credere ai  proclami eleIorali) – Intervallo di tempo casuale – Risultato non misurabile (ai posteri... )

Gioco a risorse limitate • Lo scenario è limitato su svaria> parametri  chiave: – Budget – Tempo – Esperienza – Talento – Quan@tà di informazioni ges@bili

Qual è il gioco di SOA? • SOA è generalmente un gioco giocato ad un  livello diﬀerente dallo sviluppo: – Gli obie@vi sono lega> ad una strategia di lungo  periodo – I risulta> di medio termine possono risultare non  osservabili o misurabili per il team. • Es. Budget • Eliminazione di un sistema esterno

The SOA Game Una cri>ca comune alle metodologie Agili, è  che si focalizzano su obie@vi a breve termine. SOA vuole vedere il quadro  complessivo, concentrandosi su  obie@vi a volte non  completamente trasparen>.

La cultura dominante • la cultura aziendale può essere molto lontana  dai principi agili • SOA può avere l’appoggio del management,  ma non è deIo che anche le metodologie  agili ce l’abbiano. • Carriere, ruoli e specializzazioni possono  risultare soIo pressione.

Dimensione del progeFo • SOA spesso implica la presenza di mol> team  di sviluppo allo stesso tempo

Più realis@camente...

Il ritorno del Top Down • Alcun strumen> reintroducono la filosofia  top‐down – Ruoli prefissa>  – Tool driven design – Sviluppo basato sulle specifiche • Un ulteriore sgradevole effeIo ... – Il feedback dal basso è scoraggiato – Idee potenzialmente buone vanno perdute

Cominciare Agile e SOA? • Benchè siano ortogonali, due rivoluzioni allo  stesso tempo sono probabilmente troppo per  un team • Ma ...agile si comporta bene in presenza di  esplorazioni ed incertezza: – processo ada@vo – spikes – approccio test driven

Prepariamo la scena • Non generiamo aspeIa>ve diﬃcili da  soddisfare • Manteniamo il management al corrente dei  possibili problemi – Le transizioni ai metodi agili meIono soIo  pressione le organizzazioni, esponendo problemi  che sono sempre sta> nascos> soIo il tappeto. – Cer> problemi sono sempre sta> lì (magari soIo il  tappeto), meIerli in evidenza può apparire  sgradito.

Scegliete un obie@vo facile • Scegliamo obie@vi raggiungibili in un  tempo ragionevole • Raggiungiamoli • Costruiamo sui risulta> • sicurezza • aﬃatamento • reputazione 

Viaggiamo leggeri

Viaggiamo leggeri • la disponibiltà di strumen> per  ges>re la complessità di SOA  non signiﬁca che dobbiamo  incoraggiare la complessità

Viaggiamo leggeri • la disponibiltà di strumen> per  ges>re la complessità di SOA  non signiﬁca che dobbiamo  incoraggiare la complessità • Il lato oscuro di SOA non è  meglio di ciò che l’ha  preceduta...

Appoggiamoci su standard • Come corollario a  “decide as late as  possible”: – Sviluppiamo su standard consolida> se possibile • Migliore documentazione • Rimpiazzabili • ... s>amo facend strategie di lungo termine. – Evitare le tentazioni di features vendor‐speciﬁc – Manteniamo soIo controllo la deviazione dagli  standard

La decisione più  irreversibile...

La decisione più  irreversibile... Non separiamoci dai  nostri soldi! Non compriamo  nulla la cui necessità  non sia provata!!!

Evi@amo l’approccio Big‐Bang • Un’approccio su larga scala introduce più  problemi lega> al coordinamento ed alla  condivisione di informazioni in evoluzione. • Piccoli guerrilla‐teams possono fare un  lavoro migliore con un uso più eﬃciente delle  risorse 59

Evi@amo l’approccio Big‐Bang • Un’approccio su larga scala introduce più  problemi lega> al coordinamento ed alla  condivisione di informazioni in evoluzione. • Piccoli guerrilla‐teams possono fare un  lavoro migliore con un uso più eﬃciente delle  risorse • Ogni frase che comincia con “ogni” è  potenzialmente pericolosa! 59

Never be blocked 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente • Non aspeFare qualcosa al di fuori del nostro  scope di progeIo. 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente • Non aspeFare qualcosa al di fuori del nostro  scope di progeIo. – Mockiamola 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente • Non aspeFare qualcosa al di fuori del nostro  scope di progeIo. – Mockiamola – implemen>amola 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente • Non aspeFare qualcosa al di fuori del nostro  scope di progeIo. – Mockiamola – implemen>amola – facciamone a meno 60

Never be blocked • Le interdipendeze tra sistemi possono  rallentarci indeﬁnitamente • Non aspeFare qualcosa al di fuori del nostro  scope di progeIo. – Mockiamola – implemen>amola – facciamone a meno • ...qualsiasi cosa facciamo, facciamolo  pubblicamente. 60

Ripensiamo agli Sprechi • Alcune forme di spreco “fare due volte la  stessa cosa” possono essere preferibili a  “documenta cos’hai faKo” • Lo sviluppo su larga scala cambia le priorità • I conﬁni aziendali e logis>ci cambiano – Cos> di comunicazione – Passaggi di consegne

Il costo di comunicare • Le informazioni non si propagano con la  documentazione, ma sapendo cosa stanno  facendo gli altri. – Mantenere più team allinea> • Scrum of Scrums • Informa>on radiators • Prossimità • End of itera>on demo • Quando è comunque meglio scrivere, i Wiki  permeIono di scrivere documentazione on‐ demand.

Condividiamo il piano • Impedire agli sviluppatori di vedere il quadro  complessivo impedisce di dare dei contribu@  signiﬁca@vi. – Sono possibili solo oGmizzazioni locali – Sono possibili errori madornali

Pianificazione di alto livello • SOA è un processo di trasformazione a lungo  A termine f • Ogni passo cambia lo scenario – Maggiore conoscenza del contesto – Pesi e priorità differen> – Differen> opportunità • E’ necessario aggiornare e ri‐pianificare di  frequente, per centrare gli obie@vi (non  necessariamente quelli originali)  – Misuriamo, non assumiamo – Ges@amo i rischi, non facciamo previsioni – Non iniziamo nulla di cui non ci sia bisogno ora

SOA Tes@ng • SOA è basata sui principi di Design by  Contract ...il paradiso del tester! – Deﬁnizione dell’interfaccia basata su standard.  – AIese ben deﬁnite sul comportamento esposto  dai servizi

Tes@ su SOA: challenges • Test suite indipendente dal linguaggio  • Mocks e Stubs che implementano i servizi  • Selezione delle aree chiave per il test  • Deﬁnizione e ges>one dell’ambiente di test  

Deﬁnizione degli ambien@ • In determina> contes>, gli ambien> di test  possono essere troppo complessi o costosi  per essere replica> – Teniamo sempre in funzione i tool di con>nuous  integra>on – Estendiamo gli ambien> di integrazione ﬁn dove  possibile – Troviamo un punto di equilibrio tra correIezza e  ges>bilità – Manteniamo sempre i test aggiorna>

In due parole...

In due parole... • Impediamo alle vecchie abitudini di farla da  padrone • Prepariamoci a compromessi (temporanei) – Teniamo traccia del prezzo da pagare – Siamo pron> a cambiare, cogliendo nuove  opportunità • Coinvolgiamo i gius> sponsor • Comunicare!!! • Prepariamoci ad un oIovolante!

... ﬁnito?

... ﬁnito? Grazie a tutti!

Service Oriented Agility @ Italian Agile Day - Bologna 2008

by Alberto Brandolini

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 11

Statistics

Service Oriented Agility @ Italian Agile Day - Bologna 2008 Presentation Transcript

http://lanyrd.com	6
http://www.slideshare.net	3
http://www.linkedin.com	2