© 2013 - mondora.com

Prima Edizione

Agile e DevOpsexplained

1 Agile Software management significa passare da un modello di direzione a un modello di supporto.

Agile Software

La Situazione Nello Sviluppo Del Software

1. La Regola del 20/80

2. Il Product Owner

3. Il Product Backlog

4. Correre per un obiettivo (Team e Sprint)

5. Lo Sprint Planning Meeting

6. Il Daily Scrum

7. Il Burndown Chart

2

IntroduzioneLa velocità con la quale il mercato si sta muovendo sta cres-cendo esponenzialmente. Anche nello sviluppo del software le aspettative sono molto più alte che quelle di 10 anni fa; la pro-duttività è di conseguenza aumentata e così anche i canoni di qualità sono aumentati.

Tale spinta non si vede solo dal software. Si pensi per esempio al grattacielo in Cina che è stato costruito e finito in 360 ore. Sembra che tutto stia andando a una velocità sempre mag-giore. Quello che sta succedendo è quello che succede a dei chicchi di popcorn che intanto che cuociono si espandono e si gonfiano per colmare la pentola. Tutto è ben calibrato e l’esplo-sione è vicina.

E’ necessario porre la attenzione sta nel fatto di riuscire a man-tenere la natura delle cose e delle persone in un processo pro-duttivo così veloce. Riuscendo a star fermi con i piedi solidi alla terra e mantenendo dei pensieri nitidi, è possibile capire quali parti di processo ostacolano la velocità e fanno si che si pro-duca lentamente e nel contempo a rilasciare delle applicazioni che sia utili per il Business.

La velocità richiesta e il livello qualitativo necessario, impon-gono una grande disciplina rispetto alle poche regole di proc-esso e una grande attinenza rispetto ai ruoli e alla responsabil-

Section 1

Introduzione

3

ità individuali. Non c’è bisogno di grandi strumenti di gestione come si si volesse andare su Marte: è necessario avere solo una idea pulita di dove si vuole arrivare in termini di visione di prodotto.

C’è bisogno di gruppi di lavoro con specialisti che sappiano gen-eralizzare.

Un’attività di backcasting, infine, permette di partire dalla visi-one che può essere più offuscata e ripercorrere i passi per arri-vare a capire quali sono le azioni da intraprendere per riuscire a concretizzare il prodotto. Questo cambia le logiche di manage-ment aziendali e porta da un modello direttivo a un modello sup-portativo.

La cultura di prodotto si può fare solo condividendo gli ideali di visione e condividendo tutte le azioni necessarie a finalizzare quel prodotto stesso. La cultura di prodotto si confonde talvolta con la strategia di prodotto. Secondo Ulf Hannerz, “una cultura è una struttura di significato che viaggia su reti di comunicazi-one non localizzate in singoli territori”. La condivisione di pro-getto in questo modo permette a tutto il gruppo di lavoro di as-similare il significato dei propri sforzi e di lavorare sempre in virtù di un risultato che a divenire.

Di riflesso, l’attività di backcasting porta anche a una strategia ben definita in cui però tutti visualizzano già il risultato finale e riescono a capire e anticipare la natura dei loro sforzi. Vale lo

stesso principio per dei semi di mais che sono messi a cuocere sul fuoco e devono subire il calore della pentola.  Se loro visual-izzano già la mutazione e il piacere del palato di dei bambini che li mangiano, sanno indirizzare i propri sforzi.

Lavorando con i metodi agili e passando progressivamente a DevOps, si riesce a scaldare la pentola e a far si che le idee fac-ciano come i chicchi di mais: crescano e si sviluppino in brevi istanti. Il ritmo è quello che serve per verificare che il paradigma di DevOps possa continuare a rilasciare con la stessa fre-quenza e qualità. Nel palazzo costruito in Cina da una parte è stato il ritmo a portare e a far si che la velocità di esecuzione ri-manesse costante. Dall’altra parte anche gli strumenti devono perfezionare e facilitare lo sviluppo. Tutti gli strumenti che vi-vono sul Cloud sono gli elementi necessari per far si che la ve-locità di crociera sia mantenuta.

Il processo di DevOps è un meccanismo di perfezionamento a divenire e ad ogni iterazione ci fermiamo a ragionare sul me-todo con il quale possiamo perfezionare il processo.

4

Il 20/80L’80% dei risultati si ottiene con il 20% degli sforzi e di conse-guenza il 20% dei risultati si ottiene con l’80% degli sforzi. Da qui si possono fare delle buone deduzioni per capire quanto è importante lavorare cercando di minimizzare gli sforzi e mas-simizzare i risultati. In totale si va comunque ad attestare che il 100% dei risultati si ottiene con il 100% degli sforzi e che ci sono degli sforzi che sono spesi bene e degli sforzi che sono spesi meno bene.

Continuando a ragionare pensando al 20% emergono dei fatti che sono molto interessanti:

" 1." i risultati devono essere in qualche modo dichiarati come attesi e questa attività è una delle prime attività da fare;

" 2." una volta che si identificano i risultati è necessario identificare anche il valore che il risultato porta;

Questo modo di ragionare consequenziale porta a pensare che una volta fissati gli obiettivi, stimati i loro costi per raggiungerli e definita la loro priorità si riuscirà ad ottenere il prima possibile quell’incremento che con il minimo sforzo produce il massimo risultato.

Una ulteriore riflessione si può fare sulla qualità del risultato. Se il risultato risulta indipendente rispetto agli altri risultati questo determinerà una coesione di prodotto piuttosto alta. Quindi nel momento in cui si pensano ai risultati attesi, con questo nuovo pensiero, si deve focalizzare il pensiero a isolare il risultato stesso dagli altri risultati.

L’attività seppur teoricamente facile praticamente risulta molto complessa e richiede un lavoro di raffinamento del desiderata piuttosto elevato, complesso e completo.

Una volta ottenuti dei risultati diciamo coesi, si può ritornare ad applicare la regola di pareto. Ad ogni incremento di sforzo si pro-duce già un risultato finito. Questo vuol dire che in ogni mo-mento è possibile fermare gli sforzi e apprezzare i risultati di un prodotto che è in via di completamento.

Section 2

La regola di Pareto

5

Ora si può introdurre un nuovo fatto: dopo il 20% degli sforzi si interrompe lo sviluppo e si pianifica ancora un 80% di risultati.

E’ opportuno non avere paura del fatto che il prodotto è in via di completamento: si sa che gli sforzi devono essere 100 per pro-durre dei risultati 100. Ma aggiungendo il fatto che finiti i primi 20 di sforzi si deve discutere il prossimo 80 di risultati risulta di grande valore e di grande vantaggio.  

Innanzitutto al termine del primo blocco di funzionalità, si de-vono ripensare  tutti i risultati con la stessa tecnica attuata all’inizio. Quindi devono essere estrapolati ancora quel 20% di sforzi che produrranno per il prossimo giro un incremento di 80 e così via.

Questo elemento porta a una considerazione importante: un ap-proccio iterativo è valido se si produce un incremento di valore.

Da qui continuando a lavorare sulle conseguenze della regola di Pareto è possibile porre una serie di conclusioni interessanti.

La prima conclusione deriva dal fatto che, se ogni elemento è finito in senso di valore, ci si può limitare ad implementare quell’elemento e considerare il progetto finito.

La seconda conclusione deriva dal fatto che, se si svolge una iterazione di 20 e si considera finito, tutto il restante 80 rimane ancora da pensare e da negoziare. Quindi si può fermarsi a pensare e ridurre i requisiti in modo che davvero si condensino in un 20 di sforzo. Questo richiede una serie di passi di semplifi-cazione che continuano a ridurre le aspettative per centrare ciò che è veramente importante; di norma questo lavoro viene mascherato con quello che viene chiamato Interaction Design, ma il processo è verosimilmente un processo di semplificazi-one.

La terza conclusione sta nel fatto che il prodotto che si andrà ad implementare può differire molto da quello che si pensava all’inizio, ma che il business non ha avuto grosse perdite de-rivanti dai costi di cambiamento.

6

Il ruolo del Product OwnerSe si osservano diverse applicazioni online oppure applicazioni svilupate all’interno delle organizzazioni talvolta ci si accorge che non c’è un piano di crescita della applicazione.

L’utilizzo della applicazione dovrebbe far capire che i problemi dell’utente sono stati recepiti e che c’è del relativo valore per chi poi la userà. Questi sono i sintomi di un approccio in cui si pensa, per esempio, alla tecnologia e non al business e più in generale al problema che si sta risolvendo.

Una non analisi del problema fa pensare che principalmente ci si è focalizzati sulla delivery e la tecnologia e non invece sul business. In casi di applicazioni che coinvolgono utenti in maniera social è necessario fare lo studio del Social Object. Di-verse piattaforme dimostrano come invece ci sia la volontà di voler far funzionare un framework per un gusto prettamente tec-nologico. Generalmente questo approccio spegne e fa scom-parire il valore dell’idea.

Invece come ci insegnano Chris Messina e Joshua Porter, quando si progetta una applicazione è necessario isolare il con-cetto di social object per poi andare a definire attorno le caratter-istiche di quella applicazione.

E’ necessario capire che l’orientamento alla definizione di un problema è definito dall’isolare il problema stesso e mantenerlo sempre a fuoco durante le varie mutazioni di prodotto. Questo è un lavoro specifico ed ha un ruolo che lo deve continuamente tenere vivo.

Il lavoro del Product Owner è proprio quello di riuscire a gover-nare ciò che si vuole implementare nel prossimo futuro e mante-nere gli sforzi sempre orientati in una direzione.

Un Product Owner è in grado di lavorare con una mentalità di back-casting allo stesso modo di quanto ci insegna The Natural Step nel suo framework di sostenibilità.

Si pensi a cosa si vuole da un punto di vista di business nel me-dio periodo, si isola il social object se stiamo lavorando a cos-truire una Social Community e poi si ripropongono dei passi al contrario tornando dal futuro al presente. Durante questo lavoro andiamo a segnare dei punti o momenti che sono fondamentali per il business e che sanno specificare a specificare meglio ogni elemento identificato.

Section 3

Il Product Owner

7

Il Product Owner compie continuamente questo lavoro sul pro-prio prodotto  e riesce a focalizzare ciò che deve fare nel tempo. Man mano che mette a fuoco, riesce a definire il motivo e il relativo valore di ciò che sta scoprendo. Questo processo è un atto di Envisioning, di visualizzazione e di definizione di ciò che si vuole ottenere. Ci sono diverse tecniche di Envisioning e tutte derivano dal Brain Storming e fanno uso principalmente strumenti come le Mappe Mentali.

Facendo così, tutte le parti che partecipano nel processo produt-tivo possono capire il perchè si sta sviluppando una funzionalità e intravedere l’evolvere della funzionalità nel tempo. In questo modo tutto rimane dinamico, tutto viene incorporato dalle forze di tutti che comprendono il perchè si sta andando in quella di-rezione.

Anche da una analisi tecnologica, ci si rende conto che il pro-dotto evolve e sta andando avanti in una direzione ben precisa. In una social community, l’atteggiamento è quello di continuare a lavorare sul social object e di continuare durante le iterazioni a raffinarlo. Con ciò tutti sanno dove si sta andando e conoscono gli obiettivi e i risultati attesi della piattaforma soft-ware. Un venditore saprà raccontare alcuni scenari e proiettare le esigenze anche in scenari futuri perchè sarà sempre concen-trato sul motivo predominante della propria soluzione software. Così anche un programmatore che farà le scelte tecnologiche e

architetturali saprà argomentare il motivo di una implementazi-one piuttosto che di un’altra.

Non è facile isolare il problema e capire quali sono i propri obiet-tivi, ma piuttosto che fare analisi funzionale del sistema, è meglio fermarsi e iniziare a tracciare cosa si vuole ottenere nei prossimi 3 anni e da lì capire, facendo backcasting,  cosa avere nel prossimo mese o nelle prossime due settimane.

Una volta affinata la tecnica e compresa la mentalità, tutto vi-ene da sè. Si deve far notare che tutto però cambia in relazione alle condizioni al contorno, quindi anche la vision di prodotto può e deve cambiare man mano che si apprende dal mercato.

Un buon Product Owner continua a lavorare sul proprio Pro-dotto imparando dai feedback che riceve e rivede di conse-guenza gli obiettivi di medio e lungo termine. Tutto è dinamico e la possibilità di lavorare a iterazioni brevi - come dimostra la re-gola di Pareto -  permette di riflettere su ciò che si implementa e di continuare a raffinare il tiro.

Il lavoro frequente di un Product Owner è la ridefinizione della propria vision nel tempo. E’ una attività continua che garantisce la buona salute del prodotto e la relativa stabilità. Non mante-nere una visione di prodotto, significa non riuscire ad avere una roadmap e significa non governare il processo.

8

Il tutto fortunatamente può andare a buon fine e portare dei ri-sultati buoni, ma nella maggior parte dei casi porta a una accoz-zaglia di decisioni sia tecnologiche che di business che ren-dono il sistema legato e non capace di evolvere.

Una situazione del genere non è un problema tecnico come spesso accade, ma è un problema di business e di processo. La colpa sarà data all’ultimo ingranaggio della catena quando invece bisognerà fare una riflessione a che cosa avrebbe do-vuto tenere assieme tutte le forze che sono state messe in gioco.

La vision, a questo punto, gioca un ruolo importante.

9

Come pianificare il lavoroIl Product Backlog è lo strumento con il quale poter pianificare l’elenco delle funzionalità minime con le quali rilasciare un pro-dotto. Attraverso il Product Backlog si va a creare un processo continuo di innovazione che, iterazione dopo iterazione, at-tribuisce valore al prodotto in maniera consistente.  General-mente il Product Owner parte a voler scrivere tutte le funzional-ità sul product backlog e poi pensa di pianificare queste funzion-alità direttamente da quel documento.  E’ corretto che a tempo zero si scriva tutto ciò che si pensa debba fare il prodotto, ma è anche vero che ci si focalizzi nell’implementare solo un set minimo di funzionalità in maniera coerente. Da qui il rimando d’obbligo alla regola di Pareto che enuncia che l’80% dei risul-tati si ottiene con il 20% degli sforzi e viceversa.

Ma come fare a capire quale è l’insieme minimo delle funzional-ità che danno il massimo risultato?

Il Product Backlog non è sufficiente per soddisfare una richiesta del genere da solo: è uno strumento con il quale poter fare dei ragionamenti e sul quale poter fare pianificazione, ma non è suf-ficiente a mantenere in linea il processo di innovazione con-tinua con il delivery minimo di valore richiesto iterazione dopo iterazione in maniera coerente con la vision. Al Product Backlog manca il concetto di vision.

E’ necessario, quindi, focalizzarsi all’idea di prodotto prima che di backlog ed è importante andare ad indirizzare il proprio in-tuito in una visione di prodotto che:

1. descriva un obiettivo di prodotto attraverso una frase o una serie di frasi (al massimo 2 o 3)

2. definisca un gruppo di target per questo prodotto

3. definisca un set di funzionalità cruciali (5 o 6 funzionalità) che rendono il prodotto unico

4. descriva quali sono i bisogni che il prodotto soddisfa (5 o 6 bisogni)

5. definisca il valore in termini di benefici e di penalità e ne de-finisca i canali di vendita partendo da un business model

Section 4

Il Product Backlog e le User Stories

10

L’obiettivo di prodotto

L’obiettivo di prodotto è rappresentato da una frase o da una se-rie di frasi (2 o 3 al massimo) che riescano ad esprimere in maniera coincisa quello che si vuole andare a implementare. Rappresenta qualcosa di importante e difficilmente muta nel breve periodo. Assieme all’obbiettivo di prodotto è di grande va-lore associare anche una metafora. La metafora aiuta a pen-sare in maniera parallela anche a tutte le funzionalità che dovranno poi andare ad essere implementate.

L’obiettivo  di prodotto è fondamentale per continuare a mante-nere il focus: è da intenderlo come la prima pietra fondante che da la direzione e verso la quale dover volgere lo sguardo nel momento in cui si stia prendendo un abbaglio. Deve essere chi-aramente definito e la sintesi non deve essere troppo generica da far perdere l’obiettivo stesso.

Il gruppo di target

Descrivendo il gruppo di target per il prodotto, si va ad incre-mentare la vision definendo una serie di potenziali utenti che vanno poi a utilizzare l’applicazione. Non è del tutto scontato pensare che questi utenti emergono in una seconda fase. Emergeranno ed è opportuno iniziare già dal primo momento a perfezionare un set di utenti verso le quali indirizzare i propri sforzi. Anche dal punto di vista motivazionale, ognuna delle per-

sone che collabora nella realizzazione del progetto saprà che il proprio lavoro è indirizzato, alla fine, a quel gruppo di target che è stato definito.

I bisogni

Il valore del prodotto è direttamente proporzionale rispetto ai bi-sogni che saprà andare ad indirizzare.  E’ pertanto importante che le funzionalità cruciali del prodotto vadano a soddisfare dei bisogni specifici del prodotto stesso. Anche qui riuscire ad identi-ficare alcuni bisogni (al massimo 5 o 6) e riuscire ad individuare le funzionalità critiche del prodotto che soddisfano tali bisogni riuscirà a pesare meglio che cosa si andrà a realizzare.

Il valore

Il soddisfare i bisogni significa lavorare direttamente sul valore dato al gruppo di target e poi farlo combaciare con gli elementi che derivano dal modello di business dell’applicazione stessa. Da qui emerge che rispetto al modello di business ci sono delle funzionalità che penalizzano molto e funzionalità che danno grande beneficio sia al business che al cliente. Anche in questo caso è importante stabilire quali sono le funzionalità che danno grande beneficio e le funzionalità che danno grande penealità elencandole e descrivendole con poche frasi.

11

Una volta chiariti questi punti e identificate un elenco di funzion-alità, un target di utenti e l’adattamento al business model, è possibile pensare di andare a stilare un Product Backlog. Il Product Backlog sarà quindi un insieme di user stories che saranno non altro che il Drill Down delle singole macro funzion-alità descritte in termine di vision. In questo modo le user sto-ries, saranno catalogate per la loro tassonomia naturale.  I punti espressi sopra sono un ottimo template da riempire per riuscire a preparare una visione di prodotto consistente e andare poi a fare drill down su ogni singola storia utente.

Anche per la priorità da attribuire alla singola user stories, si fa riferimento alla definizione della vision di prodotto e si riuscirà ad attribuire i Benefici e le Penalità associate. Applicando l’ap-proccio di Wieger è necessario andare a pesare ogni singola User Story con un indice di complessità (Complexity, Story Point) e andare a stimare quali sono le funzionalità che costano di meno, danno minor beneficio e penalizzano meno.

Tutto è guidato dalla Vision di Prodotto, che è più statica del product backlog e che mantiene il Product Owner sui binari del prodotto. Di fatto un prodotto non è solo un insieme di funzional-ità rilasciate iterazione dopo iterazione, un prodotto è anche un insieme di improvements che hanno una componente tecnica. E’ necessario, assieme al product backlog, mantenere il riferi-mento al Technical Debt o debito tecnico dove entrano difetti,

technical enhancement e più in generale tutto quanto è rile-vanza dal punto di vista tecnici.

La roadmap di prodotto sarà quindi il confluire del Product Back-log e del Backlog contenente il debito tecnico (che potranno e dovranno confluire a loro volta in un unico backlog). La comples-sità riferita alle storie utente e la velocità di implementazione delle singole storie che si impara iterazione dopo iterazione, per-metteranno al Product Owner di lavorare a identificare una Product Roadmap.

La vision è necessaria per far si che ad ogni iterazione si riesca a continuare a rilasciare sempre un set minimo di funzionalità potenzialmente esercibili e si riesca anche a consolidare il pro-dotto dal punto di vista tecnico.

Le User StoriesLe user stories sono il punto di inizio per poter descrivere un prodotto rispetto al modo con il quale un utente lo utilizzerà. Sono il punto focale che descrive le caratteristiche del prodotto e il valore che il prodotto riconosce ad ogni utente.

Le user stories sono poi elaborate, prodotte e il derivante pro-dotto è offerto agli utenti che decreteranno il successo o il falli-mento dell’offerta.

12

Si sa che una user story nella sua definizione non vuole e non può essere esaustiva. Le tre C che identificano una user story ci dicono che

• i requisiti devono essere sintetici secondo la prima C (Card)

• per via della loro natura, non sono esaustive e devono abili-tare la conversazione (Conversation)

• i requisiti devono poter essere controllati (Confirmation)

Pertanto non ci si aspetta che una user story descriva minima-mente tutti le caratteristiche e gli stati eccezionali del prodotto, ma che vada a far si che una molteplicità di teste possano ragionare su quei concetti specifici.

Ci sono però delle caratteristiche in più che è necessario consid-erare quando il Product Owner descrive un product backlog con un insieme di User Stories. Da qui ci si può rifare all’acronimo di Bill Wake: INVEST.

Nella nostra esperienza una user story non deve essere solo in linea con il principio delle 3C, ma deve avere una serie di carat-teristiche intrinseche in più. Deve essere (I) Indipendente, (N) Negoziabile, (V) Valutabile, (E) Stimabile, (S) Piccola e in fine Testabile.

(I) User stories Indipendenti

Avere un backlog fatto di user stories che hanno queste carat-teristiche, permette di avere un backlog a sua volta molto versa-tile in cui le priorità possono cambiare la sequenza di lavorazi-one delle user stories stesse senza la necessità di dover ripen-sare a tutto.

Non essendoci dipendenza tra le singole user stories permette di avere delle singole stime molto precise ed evita che la stima di una user story sia influenzata da un’altra.

Per disaccoppiare le user stories da altre si possono usare di-verse strategie. Essendo noi prevalentemente di estrazione tec-nica abbiamo notato che le tecniche di disaccoppiamento utiliz-zate nell’obiect orientation come il pattern Factory o il pattern Strategy possono venire utili e permette a user stories di poter essere, a loro volta, disaccoppiate.

(N) User stories Negoziabili

Lo Sprint Planning meeting e eventuali incontri precedenti sono i momenti in cui si scoprono le carte e si manifesta ciò che si vu-ole venga sviluppato. La necessità di abilitare la conversazione di una user story, viene proprio in questo momento. Le user sto-ries devono abilitare alla conversazione, ma è anche opportuno che durante questi incontri la conversazione che ne deriva venga in qualche modo documentata. Nella nostra esperienza,

13

durante gli Sprint Planning meeting abbiamo preso nota di quello che succedeva, modificando o creando i paper prototype oppure andando a definire già da quel momento un possibile documento di Deploy utile all’analisi del dimensionamento fisico della soluzione.

(V) User stories che siano Valutatabili

Ogni user story deve produrre valore per un utente. Questo è il mantra del Product Owner. Con questo mantra, il Product Owner, riesce a impersonificare l’utente e a capire quale è la pri-orità da attribuire poi alla singola user story.

Nella nostra esperienza abbiamo sempre cercato di capire quanto è il valore in termini di beneficio e di penalità rispetto all’avere o al non avere quella user stories implementata. Poi attraverso l’approccio di Wieger alla prioriticizzazione arriviamo a definire quali user stories entrano prima nella roadmap e quali entrano dopo.

(E) User stories che siano Stimabili

Riuscire a stimare le user story è il primo segnale per capire se la user story è scritta bene oppure no. Non riuscire a dare una stima, vuol dire che la sua definizione è troppo generica. La stima, nella nostra esperienza, l’abbiamo vista anche come un elemento time boxed. Siamo consapevoli che anche nello svi-luppo del software una determinata funzionalità può essere

sempre rifinita e tale processo può anche diventare eterno. La stima permette di identificare delle costrizioni temporali per an-dare ad implementare solo il necessario della storia e non tutto. Quando pensiamo a stimare a una storia consideriamo sempre il principio di Pareto, in cui il 20% della storia produce l’80% del valore. Questo è il punto in cui lavoriamo quando andiamo a sti-mare una storia. Secondo l’approccio di Wieger, mischiato con il principio di Pareto riusciamo ad implementare per prime solo le user stories che danno maggior beneficio, danno maggiore penalità e costano il meno possibile in termini di complessità.

(S) User stories che sono Piccole

Se le user stories son a granularità fine, è permessa una mag-giore accuratezza durante le stime. Di solito separiamo le storie in relazione anche al loro modo di gestire le informazioni. Gen-eralmente separiamo tutte le CRUD operations come singole user stories diverse.

(T) User stories che sono Testabili

La Confirmation di una user stories ci spinge a dover scrivere un acceptance test per la user story stessa. Ci sono anche de-gli altri test che devono essere passati nel frangente di una sin-

14

gola storia. I test non funzionali fanno parte dell’insieme di test che solitamente cerchiamo di isolare per ogni singola storia.

I test funzionali, nella nostra esperienza, devono essere il più possibili automatizzati. Utilizziamo tools come Fitnesse o Sele-nium per creare dei test funzionali di regressione. Separiamo genericamente la presentation in HTML e Javascript e in un server che è invocato via AJAX tramite delle API.

Attraverso piattaforme come Fitnesse cerchiamo di testare tutte le invocazioni di business fatte via API con una conseguenza di chiamata delle singole API (es. un workflow). La presentation invece la testiamo abitudinalmente con strumenti come QUnit. In questo modo riusciamo ad avere una suite di test per le user stories sulle API e una serie di test unitari sul frontend.

Con queste nostre pratiche evidenziate, INVESTire sulle sin-gole user stories è un atto a cui il Product Owner deve dare rilievo. La completezza dei requisiti e il soddifacimento del prin-cipio delle tre C e del principio di INVEST fa si che il prodotto possa evolvere agevolmente giorno dopo giorno.

15

Lo SprintUna iterazione derivante nella regola di Pareto si definisce in Scrum con il termine Sprint. Uno sprint è un periodo di tempo nel quale il team si mette d’accordo con il Product Owner e si raggiungono degli specifici risultati. Lo Sprint è time boxed e l’esperienza ha riportato che la sua durata sia non superiore a 4 settimane continue.

Essendo time boxed uno sprint ha quindi un momento di inizio e un momento di fine.  Il momento di inizio è determinato da uno Sprint Planning meeting, mentre il momento di fine è identi-ficato da uno Sprint Review meeting in cui è consegnato un ele-mento di prodotto potenzialmente esercibile.

Uno sprint è quindi una unità di tempo in cui il team si auto-organizza e produce qualcosa per l’utente che è di valore. Du-rante lo Sprint il team che sta lavorando sulle attività si incon-trano quotidianamente durante una sessione chiamata Daily Scrum in cui ci si confronta.

Il TeamIn Scrum, il team include dalle 5 alle 9 persone ed idealmente arriva a 7. I team sono fatti da membri con capacità funzionali diverse: ci sono ingegneri del software, architetti, programma-tori, analisti, QA, testers, UI designers, etc.

Sono generalmente tutti localizzati all’interno della stessa stanza che poi prende il nome di Team Room. Il team ha gener-almente una forte identità, talvolta acquisisce anche un nome e una frase che lo identifica. Per esempio il Team Piraña che ha la mission Deliver Or Die.

Section 5

Correre per un obiettivo

16

Lo Scrum MasterLo Scrum Master è una figura che sta tra il team e il Product Owner e ha lo scopo di far funzionare il processo e di aiutare tutti a rimuovere gli impedimenti. Generalmente ha esperienza nel lavorare in progetti in cui il team si auto-organizza e il cli-ente è a supporto. Il suo lavoro principale è quello di battere il tempo, di far rispettare le regole che emergono dalle lesson learned e di far si che tutto fluisca nel modo migliore.

Ha la responsaiblità di completare tutto il lavoro negoziato all’inizio dello Sprint e ha anche la facoltà di decidere quanto la-voro ci vuole per terminare. Il Product Owner cercherà di spin-gere il team ad implementare un giusto numero di requisiti per permettere di raggiungere i propri risultati nel prossimo sprint. In relazione alla propria velocità un team potrà decidere e capire quante funzionalità portare a sviluppo durante l’iterazi-one.

Il team si auto-organizza e ha la autonomia di poter decidere il modo con il quale completare il lavoro. In teoria il team potrebbe finire il lavoro in anticipo rispetto alla delivery e poi gio-care con i videogiochi per la seconda parte. E’ importante che mantenga sempre la garanzia che ciò che sta implementando sia consegnato nel tempo concordato.

E’ importante notare che il team man mano che scopre il lavoro pianificato e accettato durante lo sprint planning meeting possa

notare dei problemi che invalidano alcuni risultati. Il processo di colloquio continuo con il Product Owner permetterà al team di rinegoziare - sfruttando il principio di Pareto - le funzionalità critiche e permettere di raggiungere gli obiettivi concordati.

17

Come iniziare uno sprintIl fine dello sprint planning meeting è quello di pianificare le attiv-ità che verranno effettivamente svolte durante il prossimo sprint.

L’input è il Product Backlog, cioè la lista degli item (sotto forma di user stories o di requirements), che bisogna implementare nel nostro prodotto.

A questo meeting prendono parte il Product Owner, lo Scrum Master e l’intero Scrum team. In rari casi potrebbero parteci-pare, su invito del team, anche degli stakeholders esterni.

Tutto il meeting è cadenzato mediante una Timebox:

• nei primi 10 minuti il Product Owner  descrive la vision del pro-dotto;

• nei successivi 30 minuti il Product Owner descrive le User Sto-ries che ha individuato e che propone al Development Team;

Una buona indicazione sarebbe che il Product Owner  spie-gasse un numero di user stories che coprano la durata di due sprint. Per fare un esempio molto semplice, supponiamo che un team finisca sempre cinque voci del product backlog in uno sprint: il Product Owner  dovrebbe partecipare al meeting par-lando delle prime dieci user stories a priorità più alta.

Seguono poi 5 minuti per il commitment, cioè per la scelta delle storie che il team crede di poter finalizzare.

In generale, l’intero timebox dovrebbe essere pari al 5% della lunghezza dello sprint, dunque se lo sprint di default è di due settimane, allora il meeting dovrebbe essere di circa 4 ore.

Nella seconda parte dello sprint planning meeting il team lavora insieme al fine di stilare un elenco di tasks e di stimare ognuno di essi. Per ogni user stories ci potrebbero essere numerosi tasks associati. La stima è sempre vista nell’ottica di ore che ri-mangono per finire quella attività e la stima non deve eccedere, a rigor di buonsenso, le 16 ore.

Il numero di attività che verranno finalizzate durante lo sprint dipenderà dalle stime che ragionevolemente il team avrà fatto.

Section 6

Lo Sprint Planning Meeting

18

Durante questa fase non è necessario che il product owner ri-manga nella stessa stanza col team, tuttavia è preferibile che rimanga comunque disponibile per qualsiasi chiarimento.

I risultati principali dello sprint planning meeting sono:

" •" lo sprint backlog

" •" lo sprint goal

Lo sprint goal è corto, una o due frasi, che riassumono breve-mente quale obiettivo il team si prefigge di raggiungere durante la durata dello sprint ed è concordato tra team e product owner.

Il goal dello sprint può essere utilizzato per spiegare agli stake-holders, a cui non interessa il dettaglio tecnico, a cosa sta lavo-rando il team.

Il successo dello sprint verrà successivamente valutato durante lo Sprint Review Meeting in base all’obiettivo che si era prefis-sato di raggiungere e in base ai singoli item selezionati per lo sprint dal product backlog.

L’altro risultato è invece lo sprint backlog, un elenco di attività necessarie per finalizzare le user stories selezionate dal prod-uct backlog. Queste sono stimate dal team in base al tempo e

al grado di confidenza che ritiene necessario a completare la singola attività.

E’ importante ribadire che è lo scrum team che decide quante user stories selezionare dal product backlog da inserire, dettagli-are e stimare nello sprint backlog. Il product owner decide quali.

Lo Sprint BacklogCome risultato di uno Sprint Planning Meeting il team produce uno sprint backlog in cui sono contenute tutte attività individu-ate durante la pianificazione dello Sprint. L’ordine di tali attività dipende molto dall’ordine dei requisiti enunciati dal Product Owner. Incorpora quindi un ordine implicito molto legato al busi-ness. Lo sprint backlog sarà la guida del team durante lo sprint e permetterà di poter governare lo sprint con l’elenco delle attiv-ità che mancano da fare.

Sullo sprint backlog il concetto è sempre quello di cosa manca per essere finito:

" 1." mancano delle attività da essere completate;

" 2." mancano delle ore per completare ogni attività.

19

Lo Sprint Backlog è suscettibile a variazioni nel futuro e le nuove attività che non erano predicibili al momento iniziale saranno poi inserite dal team in futuro con una stima iniziale pari a 0 e una stima alla giornata pari al numero di ore che si crede manchino.

E’ lo strumento di governo del team sul quale ci si confronta per il Daily Scrum e dal quale si desume il Burndown Chart.

20

Come si anima lo sprintDurante lo sprint, ogni giorno, il team partecipa al Daily Scrum.

Tutte le figure coinvolte nel processo di scrum devono essere presenti a questo incontro: il team, il product owner e certa-mente lo scrum master. Inoltre, è possibile, per tutte le altre per-sone coinvolte a vario titolo nel progetto di partecipare a questo meeting (ad esempio i venditori, i capi progetto ed altri). E' nec-essario però che queste figure non intervengano durante il Daily Scrum. La loro partecipazione è un ottimo modo per dif-fondere le informazioni sullo stato di avanzamento del progetto, ma non deve essere inteso come una possibilità di intervento esterno al lavoro quotidiano del team, non è questo il proposito del daily scrum.

Il daily scrum deve essere tenuto tutti i giorni nello stesso luogo ed alla stessa ora. Sempre per ovviare ad eventuali motivi di distrazione, tutte le persone presenti devono parteciparvi in piedi (standup meeting). Idealementente, avendo come scopo

quello di organizzare e condividere il lavoro svolto e da svol-gere, l'inizio della giornata lavorativa è il momento migliore per tenere l'incontro. Inoltre la durata dell'incontro deve essere tas-sativamente di 15 minuti. Questo intervallo di tempo permette di non disperdere energie da dedicare allo sviluppo vero e pro-prio, ma è abbastanza ampio per avere una una discussione rilevante e fruttuosa.

" Durante il Daily Scrum ogni membro del team deve rispon-dere a tre domande:

" cosa ho fatto ieri?

" cosa farò oggi?

" quali sono i problemi che ho avuto?

Queste domande sono finalizzate a rendere partecipi tutti gli ap-partenenti al team di sviluppo dell'attività che i singoli stanno svolgendo. L'obiettivo di queste domande non è di aggiornare il capo o il product owner sullo stato di avanzamento lavori. Piutto-sto servono agli appartenenti al team di sviluppo a rendere par-tecipi gli altri di cosa si è fatto il giorno precedente e di cosa si farà durante la giornata. Quanto detto durante l'incontro non è solo un momento di condivisione dei problemi, ma è anche una sorta di  promessa che ogni partecipante fa agli altri membri del team riguardo al proprio impegno nello svolgimento di una attiv-ità.    

Section 7

Il Daily Scrum

21

La terza domanda non è posta affinchè il problema venga ri-solto durante l'incontro. Il daily scrum non serve per risolvere i problemi e gli impedimenti venuti a galla durante quest'incontro. E' compito dello scrum master rimuovere gli impedimenti solle-vati. Quello che lui stesso può risolvere, problemi ad esempio di tipo organizzativo, devono essere presi in carico da lui in prima persona. Nel caso invece di impedimenti di tipo tecnico, che lui non è in grado di risolvere, deve assicurarsi che qualcuno possa occuparsene successivamente. Tipicamente, questo tipo di problemi sollevati durante il daily scrum, vengono trattati in sottogruppi subito dopo il daily scrum stesso.

Durante il daily scrum è possibile intervenire sullo sprint back-log, che come già detto non è un documento intoccabile, ma è uno strumento su cui il team può e deve intervenire quotidiana-mente. Il daily scrum è il momento della giornata in cui i membri del team rendono partecipi gli altri delle eventuali modifiche da apportare o già apportate allo sprint backlog. La regola fonda-mentale, su cui si basano le successive stime, è che sono le ore mancanti per finire la singola attività a dover essere comuni-cate e aggiornate nello sprint backlog.

22

Governare lo SprintDurante lo sprint planning meeting, il team identifica e produce delle stime per alcuni specifici task che sono obiettivo dello sprint a venire. Da qui lo Sprint Backlog. Quindi mentre lo sprint procede, le persone del team ridefiniscono i propri task, e con-tinuamente la mole di lavoro rimanente dello sprint viene ricalco-lata, con la tendenza a diminuire. Si può dire che se la quantità di lavoro rimasta nel backlog è zero alla fine dello sprint, allora lo sprint si è completato con successo.

Si è già detto che gli item presi dal product backlog ed esplosi nello sprint backlog dal team durante lo sprint planning meeting sono fissati, ma lo sprint backlog può comunque subire cambia-menti durante lo sprint a causa di diversi motivi:

• Le persone del team ottengono maggior conoscenza e chi-arezza dei task nel momento in cui iniziano a lavorarli e può nascere così l’esigenza di aggiungere ulteriori task che ap-

punto non erano stati considerati o immaginati, allo sprint backlog.

• Possono nascere bug o defects segnalati come task aggiun-tivi. Anche se questi possono essere considerati come la-voro non compiuto su task lavorati da qualcuno infatti, può essere utile o necessario tenerne traccia separatamente.

• Nel caso in cui il product owner lavori a stretto contatto col team durante lo sprint per aiutare a comprendere meglio le funzionalità obiettivo dello sprint, potrebbero venir fuori pic-coli miglioramenti che non allungano in maniera evidente lo sprint ma che danno valore al cliente.

Il burndown chart è lo strumento con la quale il team, lo scrum master e il product owner possono costantemente monitorare l’andamento dello sprint, con una curva che rappresenta la quantità di lavoro rimanente nel tempo.

Viene aggiornato quotidianamente dallo scrum master sulla base di quanto è stato modificato sullo sprint backlog dal team. Tipicamente è un grafico con una pendenza verso il basso e

Section 8

Il Burndown chart

23

che segue una traiettoria ideale che raggiunge il valore zero all’ultimo giorno dello sprint. Anche se questo non è sempre vero.

La cosa più importante che mostra il burndown chart al team è il loro progresso nel raggiungimento del goal, non nei termini di tempo speso, ma bensì nei termini di quanto lavoro rimane, mostrando quindi quanto separa il team dal proprio goal.

Se verso la fine dello sprint la curva non sta scendendo verso lo zero, allora il team può prendere una decisione: o aumentare il ritmo o alleggerire il carico di lavoro dello sprint.

Il burndown chart è uno strumento semplice ma che è in grado di lanciare tanti segnali.

Purtroppo molte persone tendono a pensare che il burndown chart è uno strumento così semplice che non danno un’appropri-ata attenzione a capire che cosa sta dicendo. Nonostante sia composto da pochi tratti, può descrivere molteplici situazioni.

Un grafico come quello a fianco, rappresenta una situazione ideale, con un team pienamente in grado di organizzare sè stesso, un product owner cosci-ente dell’avere uno sprint backlog chiuso a determi-nate funzionalità, e uno

scrum master in grado di aiutare propriamente il team.

1. In questo caso si può capire che il team è in grado di fornire stime corrette, e che durante lo sprint non è sovra caricato.

Infatti un metro che può essere usato leggendo un burndown chart, è quello che misura lo stress di un team: la porzione di grafico che sta tra la curva ideale e la curva reale quando questa rimane sopra, rappresenta un possibile stress che si sta

24

accumulando nel team. In questo caso, se la situazione dovesse perdurare, lo scrum master o il product owner potrebbero prendere provvedimenti cercando di alleggerire e diminuire lo stress.

Situazioni descritte da burndown chart come questi due, rive-lano che il team non è stato in grado di adattare lo sprint goal al proprio livello. Nel secondo caso, ad esempio, il team non ha completato delle user stories che sono state quindi splittate o spostate al prossimo sprint.Un grafico come quello a fianco, rap-presenta una situazione ideale, con un team pienamente in grado di organizzare sè stesso, un product owner cosciente dell’avere uno sprint backlog chiuso a determinate funzionalità, e uno scrum master in grado di aiutare propriamente il team.

In questo caso si può capire che il team è in grado di fornire stime corrette, e che durante lo sprint non è sovra caricato.

25

La fine dello sprintAlla fine dello sprint, il prodotto potentially shippable sviluppato viene mostrato attraverso una breve demo al product owner e a tutti gli stakeholder interessati, nella prima parte dello sprint re-view meeting. Questa non è una presentazione (non vengono usati power points e deve essere preparata in non più di mezz’ora), ma una vera e propria demo di che cosa è stato cos-truito, con la possibilità da parte di ognuno dei presenti di fare domande o dare suggerimenti. Rappresenta infatti un buon mo-mento per raccogliere preziosi feedback da parte degli stake-holder.

Il product owner conduce questa parte di meeting e determina lui stesso quali user stories del product backlog sono state com-pletate durante lo sprint, e decide col team e gli stakeholder pre-senti se e come modificare le priorità di quelle rimanenti. In questa fase viene anche definito il goal per il prossimo sprint.

Una demo ben eseguita, anche se può sembrare drammatica soprattutto agli occhi del team, ha dei profondi effetti:

• Il team si prende il merito per quello che hanno compiuto. Lo fa stare bene.

• Altre persone capiscono che tipo di lavoro sta portando avanti quel team.

• La demo attira e scaturisce feedback vitali per il prodotto fi-nale.

• Le demo dovrebbero essere viste anche come eventi sociali in cui anche team diversi interagiscono fra loro e discutono dei propri lavori. Questo è prezioso.

Inoltre, sostenere una demo, forza e spinge il team a finire i task e non lasciare codice sospeso. L’effetto che si può ot-tenere infatti, è quello di avere meno user stories completate in uno sprint, ma sicuramente quelle completate sono davvero tali e funzionanti in environment di test.

Section 9

Lo Sprint Review Meeting

26

È anche un effetto psicologico che si instaura nel team. Se un team viene forzato a eseguire una demo anche se non c’è molto che funziona realmente, la demo sarà piuttosto imbaraz-zante, e anche le persone presenti saranno più fredde o addirit-tura irritate per una demo inutile. Questo può far male, ma ha lo stesso effetto di una medicina amara. Nel prossimo sprint il team realizzerà veramente delle user stories complete. Magari diminuirà le cose da far vedere, ma sicuramente quelle svolte funzioneranno. Il team ha capito che deve in ogni caso svolgere una demo, e questo fa aumentare la chance di avere qualcosa di utile da mostrare.

Nella seconda parte dello sprint review meeting viene invece eseguita dal team e dallo scrum master una retrospettiva sul modo in cui il team ha lavorato durante lo sprint appena termi-nato. Nella retrospettiva condotta dallo scrum master, vengono identificati sia fattori positivi, i quali vengono spinti e incoraggiati come practice da seguire, sia fattori negativi o da migliorare. Per questi quindi vengono presi dei provvedimenti e costituis-cono le lesson learned di un team.

Un semplice modo per strutturare una retrospettiva è quello di appendere due fogli al muro nominati “working” e “not working or to improve”, e lasciare aggiungere alle persone del team de-

gli elementi in questi due fogli. Item ripetuti vengono marcati per renderli più evidenti. Fatto questo il team cercherà di indi-viduare le cause e in comune accordo le conseguenze, con l’at-tenzione nel rivedere e monitorare le decisioni prese nella pros-sima retrospettiva.

Un’altra utile pratica è quella di accompagnare gli item nei due fogli da una “C” nel caso in cui sia causato dal processo Scrum, o una “V” nel caso in cui sia reso visibile dal processo Scrum. Il team potrà così trovare tante “C” sul foglio “working” e tante “V” sul foglio “not working”.

La cosa più importante della retrospettiva è assicurarsi che venga fatta.

La retrospettiva è una pratica che i team sono portati a saltare, e ciò rappresenta un vero pericolo, visto che è uno dei meeting più importanti per fare Scrum con successo. È un’oppurtunità per il team di discutere sulle loro perplessità e di poter cambi-are in comune accordo qualcosa nel processo.

Senza la retrospettiva, sicuramente si potrà notare che il team continuerà a ripetere sempre gli stessi errori.

Lesson Learned

27

Come risultato della retrospettiva svolta all’interno dello sprint review meeting, il team ottiene delle vere e proprie lesson learned su diversi possibili aspetti, per le quali vengono adottati dei provvedimenti decisi di comune accordo. È importante in-fatti che ogni lesson learned venga associata ad un proposito da seguire negli sprint successivi.

Un’altra cosa utile è che le lesson learned che il team acqui-sisce, spaziano in aree diverse, come tipicamente la comunica-zione, la pianificazione, i requisiti, la qualità del software, la conoscenza di tecnologia, e altro ancora.

Per questo le lesson learned rappresentano una chiave impor-tante di Scrum, perché alimentano quel processo di continuous improvement che sempre di più si va cercando, e nel quale il team è in grado di crescere e maturare in un periodo di tempo breve, lo sprint.

Ed è proprio a questo processo di continuous improvement che l’Agile development ambisce, un concetto che nasce nell’es-tremo oriente e nominato 改善 (kaizen = “buon cambiamento”):

un approccio a lungo termine che sistematicamente cerca di ot-tenere piccoli cambiamenti incrementali in modo da migliorare l’efficienza e la qualità.

La lesson learned

Come risultato della retrospettiva svolta all’interno dello sprint review meeting, il team ottiene delle vere e proprie lesson learned su diversi possibili aspetti, per le quali vengono adottati dei provvedimenti decisi di comune accordo. È importante in-fatti che ogni lesson learned venga associata ad un proposito da seguire negli sprint successivi.

Un’altra cosa utile è che le lesson learned che il team acqui-sisce, spaziano in aree diverse, come tipicamente la comunica-zione, la pianificazione, i requisiti, la qualità del software, la conoscenza di tecnologia, e altro ancora.

Per questo le lesson learned rappresentano una chiave impor-tante di Scrum, perché alimentano quel processo di continuous improvement che sempre di più si va cercando, e nel quale il team è in grado di crescere e maturare in un periodo di tempo breve, lo sprint.

Ed è proprio a questo processo di continuous improvement che l’Agile development ambisce, un concetto che nasce nell’es-tremo oriente e nominato 改善 (kaizen = “buon cambiamento”):

un approccio a lungo termine che sistematicamente cerca di ot-tenere piccoli cambiamenti incrementali in modo da migliorare l’efficienza e la qualità.

28

Cosa significa TDDLo sviluppo del codice guidato dai test (Test Driven Develop-ment) è una tecnica di programmazione che prevede l’utilizzo di test per scrivere codice e disaccopiare le funzionalità dell’appli-cazione. L’obiettivo di questa metodologia è quello di costruire ed avere a disposizione una suite di test che ci garantisce il fun-zionamento dell’applicazione ad ogni stadio dello sviluppo.

Come funzionaIl principio fondamentale del TDD è quello di scrivere prima il test e poi il codice che ne implementa le funzionalità richieste. Lo sviluppo di codice si riassume in tre parole che identificano i passaggi da seguire: Red, Green, Refactor

Red: Creare un test e farlo fallire

Il primo passo è la scrittura del test, questo deve certificare una funzionalità, deve garantire la presenza di un input o di un out-put o prevedere la gestione di determinati errori. A questo punto

è necessario solo scrivere la parte per poter compilare corretta-mente il codice.

Il test ovviamente fallisce perchè il codice non fornisce le funzi-onalità richieste in quanto non ancora scritto

Green: Scrivere abbastanza codice per far passare il test

Il secondo passo è quello di scrivere il codice che garantisce il corretto passaggio del test.

Quando il test passa, il codice che implementa la nuova funzion-alità si può dire concluso. Una delle peculiarità del TDD è ap-punto quella di certificare che il codice soddisfi le richieste

Refactor: Modificare il codice in modo da garantire il disaccop-piamento delle funzionalità e controllare la riuscita di tutta la suite di test

L’ultimo passaggio è quello che si focalizza sulla rimozione dei costrutti nel codice che impediscono la separazione dei blocchi di codice che non dovrebbero dipendere l’un l’antro

questo passaggio aumenta la qualità del codice e ci permette di controllare che l’intera suite di test dia esito positivo a fronte delle modifiche apportate

Section 10

Test Driven Development

29

Benefici• In ogni momento dello sviluppo abbiamo la ragionevole

certezza che la nostra applicazione funzioni correttamente grazie al superamento della suite di test

• Lo sviluppo attraverso questa metodologia impone di scriv-ere blocchi di codice concettualmente separati tra loro e quindi sostituibili e rifattorizzabili con più facilità

• Gli sviluppatori che lavoro nel team hanno minor difficoltà ad individuare parti di codice inutili o a migliorare sezioni esis-tenti avvalendosi dei test che dimostrano il funzionamento dell’applicazione anche dopo ingenti modifiche

• La suite di test ci aiuta nel compito di non introdurre regres-sioni durante la correzione di un bug: se viene rilevato un problema occorrerà scrivere un test che provi la risoluzione del bug, modificare il codice per far si che il test passi e tes-tare l’intero codice in modo da escludere l’introduzione di re-gressioni

• I test forniscono un valido elenco di esempi su come devono essere utilizzate le varie strutture nel codice ad esempio come viene inizializzato un oggetto o chiamata un API

• Riducono significativamente il tempo che lo sviluppatore dedica al debug dell’applicazione in cerca di errori

Best PracticeLa suite di test deve avere un ampiezza tale da garantire la riso-luzione delle specifiche funzionali e impedire l’introduzione di regressioni.

• Per garantire che i test siano funzionali ed utilizzabili devono essere veloci nell’esecuzione: questo vuol dire che non ci de-vono essere test superflui e che in generale devono ri-manere semplici

• La portata dei singoli test deve essere limitata in modo da darci immediatamente un’idea di dove sia il problema se un test fallisce

• I test devono rimanere isolati dal contesto, ad esempio se non stiamo testano specifiche funzionalità del database ma solo degli oggetti ad un livello più alto, i test non devono far riferimento ad esso, in modo da poter essere eseguiti su qualunque ambiente senza impedimenti. A questo proposito sono utili i mock objects che introducono un nuovo grado as-trazione

30

Pair Programming" " "

Il pair programming è una regola di Extreme Programming per la gestione delle attività di sviluppo del codice. La caratteristica di questa modalità di programmazione consiste nello scrivere il codice in coppia utilizzando un'unica postazione lavoro.

Inizialmente potrebbe sembrare una modalità di lavoro senza senso o uno spreco di risorse: il datore di lavoro sta pagando due persone per svolgere un'unica attività di sviluppo del co-dice. Se utilizzata correttamente, rispetto al tradizionale mod-ello di lavoro, porta ad un aumento:

- della produttività,

- della qualità del codice scritto (design più semplice, meno bugs, maggiore manutenibilità)

- della soddisfazione

- della condivisione della conoscenza

- di una migliore gestione del tempo

Il successo o meno dell'utilizzo di tale metodologia si basa sulla mentalità della coppia stessa. Per aumentare sia la produttività che la qualità del codice scritto, entrambi i membri della coppia devono avere un ruolo attivo. I ruoli previsti sono due: colui che guida (driver), cioè colui che digita sulla tastiera il cui obiettivo è completare l'attività più velocemente possibile ignorando i grossi problemi, e colui che osserva (observer o navigator), senza dettare il codice, il cui compito è quello di controllare ogni linea di codice scritta prevenendo gli errori e pensando ai possi-bili problemi che il codice scritto potrebbe incontrare nell'ottica di ottenere un codice migliore sia per quanto riguarda la manutenibilità che per la robustezza a fronte di successivi inter-venti.

Prima di cominciare a scrivere il codice è opportuno che sia il driver che l'observer debbano:

- sapere cosa devono fare per evitare di sviluppare cose non necessarie

- scegliere di iniziare un’attività che sono in grado di completare

- siano d'accordo sulla soluzione di massima: stabilire una strategia prima di scrivere il codice

Section 11

Extreme Programming alcune pratiche

31

- darsi degli obiettivi per completare delle attività in pochi mi-nuti.

Durante l’attività di scrittura del codice, colui che guida deve te-nere attivo il partner che osserva aggiornandolo su cosa si sta facendo, chiedendogli un parere per migliorare l’implementazi-one del problema da risolvere. Dall’altro canto chi osserva ha il compito di supportare il partner che in quel momento sta guidando in caso di problemi oppure suggerendo delle scelte implementative migliori.

Un’altro aspetto importante è la sincronizzazione frequente tra chi guida e che chi osserva per evitare che il partner scriva del codice non sicuro o che qualcosa non sia chiaro al partner.

Inoltre per una migliore produttività, un migliore appagamento e una migliore condivisione delle conoscenze è opportuno cambi-are frequentemente i ruoli all'interno della coppia, anche ogni mezz’ora, e cambiare i membri di ogni coppia quando si inizia una nuova attività.

Refactoring

Il refactoring, la cui migliore traduzione potrebbe essere “rifare”, è una pratica attraverso la quale viene, con coraggio, cambiato

un algoritmo o una struttura interna di dati, senza alterare però la funzionalità originaria.

Di fatto è un cambiamento della struttura “interna” di un soft-ware già funzionante, garantendo la regressione, con l’obiettivo di migliorare il codice per renderlo più comprensibile.

Potremmo pensare al refactoring come ad una “semplificazi-one” a favore della manutenibiltà di una funzione, a parità di val-ori di ingresso e di risultati.

Ovviamente è più agevole da applicare solo quando vengono rispettati i paradigmi di un software object oriented, ovvero l’in-capsulamento e l’uso per interfaccie e non per oggetti specifici. Anzi, un sistema object oriented, ha come sua caratteristica la possibilità di essere rifattorato agevolmente.

Questo introduce la necessità di avere delle “API” pubbliche che siano definite e mantenute, mentre l’implementazione può essere completamente stravolta, senza che l’utilizzatore ( sia umano che macchina ) debba accorgersene, se non per carat-teristiche non-funzionali, ad esempio perchè è diventato molto più veloce ( oppure molto più lento ).

Il refactoring promuove il fatto che la proprietà del codice, per poter fare manutenzione ed evoluzione, sia di più persone e non solo dello sviluppatore originario.

32

Vige il principio di “chi rompe paga” e chi, durante una sessione di refactoring, altera il codice di modo che quello già realizzato non funzioni più ha il dovere di sistemare di modo che la code base sia sempre funzionante allo stesso modo. Per garantire questo è necessario avere una suite di test unitari che venga eseguita periodicamente o addirittura ad ogni modifica realiz-zata sulla codebase.

Dunque una precondizione per poter effettuare il refactoring è quella di avere un sistema di test, che garantisca e dimostri in modo automatico il funzionamento dei componenti.

Come si effettua il refactoring ?

Con delle piccole e semplici modifiche. Ogni spostamento e modifica deve essere mantenuto semplice, chiaro, evidente. Come per esempio lo spostare di un metodo fra alcune classi. Ogni operazione di refactoring deve essere associata ad un test specifico, che sia in grado di dimostrare la correttezza e la bontà della modifica e rilevare eventuali regressioni.

Martin Fowler ha realizzato ed organizzato un catalogo di opera-zioni tipiche del refactoring, che alcuni IDE permettono di utiliz-zare. Il catalogo è disponibile su http://refactoring.com/catalog

I benefici delle attività di refactoring possono cadere generica-mente in due categorie, entrambe identificabili come “requisiti

non funzionali” del software, ma che sono elementi di qualità im-portanti.

" 1." Manutenibilità. E’ più facile fissare i difetti nel codice, perchè il codice stesso è più facile da comprendere e leggere e gli intenti sono visibili. Questo può essere ottenuto riducendo funzioni complesse e prolisse in un set di funzioni ben identifi-cate, con nome “parlante”, concise, con un proposito specifico e preciso.

" 2." Estensibilità. E’ più facile estendere le funzionalità e le capacità dell’applicazione.

Durante la scrittura di codice, ma sopratutto durante il refactor-ing il principio che vige è “Keep It Simple, Stupid” proprio per identificare che il codice realizzato deve essere semplice, stu-pido, ed ognuno deve poterlo leggere direttamente, senza docu-mentazione specifica.  Significa evitare di pensare alle ottimizza-zioni fin dall'inizio, ma cercare invece di mantenere uno stile di programmazione semplice e lineare, demandando le ottimizzazi-oni al compilatore, o a successive fasi dello sviluppo, attraverso una fase di refactoring.

Code Collective Ownership E’ una regola di Extreme Programming, che incoraggia ognuno a contribuire attivamente con nuove idee, nuove realizzazioni,

33

refactoring, in ognuna delle parti del progetto e non solo in quella sulla quale egli sta lavorando.

Ogni sviluppatore deve essere in grado, e sentirsi a proprio agio, nel cambiare qualsiasi linea di codice per fissare difetti, aggiungere nuove funzionalità, migliorare la leggibilità, intro-durre pattern e fare “refactoring”. Nessuno è proprietario di una porzione di codice e non esistono colli di bottiglia di cono-scenza, per effettuare cambiamenti e manutenzione.

All’inizio è arduo, in quanto ognuno è “geloso” del proprio la-voro ed è difficile da accettare che non ci sia un “capo”, un ar-chitetto che sia responsabile delle scelte architetturali e del disegno del sistema: il team stesso è responsabile, tutti allo stesso modo, dell’intera applicazione, delle scelte architetturali, del disegno, della sua implementazione e della qualità.

In pratica la “Code collective ownership” è più affidabile del fatto di avere una singola persona specialista, responsabile di sottosistemi, moduli e classi specifiche; sopratutto quando questa persona potrebbe lasciare il progetto in qualsiasi mo-mento.

I. Come si effettua la “Code collective ownership” ?

Per ogni porzione di codice prodotto, lo sviluppatore deve for-nire i test unitari. L’insieme di questi test unitari, e la loro ese-

cuzione automatica, diventano un meccanismo di verifica della qualità. Il codice è affidabile solo quando i test forniscono il 100% dei risultati positivi.

In questo modo, ognuno può sentirsi di integrare le proprie idee, effettuare qualsiasi cambiamento su qualsiasi classe, di fare refactoring sul codice, e rilasciarlo sul repository.

2 DevOps elimita il gap che passa dalla produzione allo sviluppo del software.

DevOps

35

Perchè il Cloud? Quale è l’esigenza che ha spinto il proliferare del cloud?

Se dovessimo dire che cosa è il cloud, di certo non possiamo dire che il cloud è un insieme di tecnologie. Dovremmo definirlo come un fenomeno che abbraccia la cultura di erogare servizi e modelli di business dirompenti.

E’ necessario mettere a fuoco questa proporzione:

Cloud : IT = Energia Elettrica : Industria

Il cloud è per l’IT quello che per l’industria è l’energia elettrica. Qualcosa dove l’IT diventa un elemento che si può consumare e che se lo usi paghi altrimenti no. E’ necessario sapere che an-che la corrente elettrica è erogata a consumo con dei dimen-sionamenti “illusori”.

Allo stesso modo della corrente elettrica, il Cloud offre il mirag-gio delle risorse illimitate. Per esempio Gmail offre la posta 10GB di posta elettronica gratuita. Così come il fornitore di cor-rente elettrica offre 3Kw di corrente, anche il Cloud racconta solo il potenziale e il limite superiore (Capping) che viene messo. Da un recente studio si sa che se tutte le utente elet-triche italiane consumassero simultaneamente 1Kw di corrente

Section 1

Le evoluzioni del Datacenter

36

il tutto cadrebbe e non ci sarebbe corrente a sufficienza. Così anche il Cloud, è un mare di risorse ipoteticamente disponibili.

Le device e i tablet hanno spinto a questa direzione con una crescita del fenomeno più che esponenziale.

Le devices sono innumerevoli, oggi ognuno di noi ha in tasca una device che ha la possibilità di far funzionare delle applicazi-oni.

Il concetto di applicazione negli ultimi anni sta emergendo sem-pre di più e ogni device deve avere la sua applicazione che ri-mappa tipicamente un servizio online.

Che differenza c’è tra una applicazione nativa e una applicazi-one html5?

Le applicazioni native aggiungo funzionalità contestualizzate all’utente e alla device stessa. Per esempio, la geolocalizzazi-one, l’integrazione con la fotocamera etc. Oltre alle dimensioni dello schermo ci sono delle caratteristiche che implicano lo svi-luppo nativo di applicazioni.

Il mercato delle applicazioni sta quindi proliferando e stanno nascendo da un set di API un set di applicazioni molto verticali e contestualizzate non solo al device, ma anche a quello che sta facendo l’utente. Per esempio stanno nascendo applicazioni consumer per un solo concerto di un artista o per un evento specifico.

E’ risaputo che dal punto di vista marketing una applicazione vale di più di tanta pubblicità sui giornali e il motivo è noto: in-gaggiano l’utente.

Ma a cosa portano queste applicazi-oni?Le applicazioni portano necessariamente ad avere un sistema di backend che funzioni in maniera adattiva. Lo sviluppo delle applicazioni è fuori controllo: ogni sviluppatore ha la possibilità di creare una applicazione che utilizza un sistema informativo. Chi eroga il sistema informativo non ha la possibilità di control-lare cosa sta succedendo.

Un esempio è in US, dove Visa ha rilasciato la possibilità di ac-cettare carte di credito da iPhone con una device da collegare all’iPhone. Visa non avrebbe mai pensato che il mercato più alto e i picchi più alti erano quelli fatti dalle baby sitters che in orario notturno ricevevano i pagamenti.

I carichi diventano impredicibili per via dell’uso che si fa dei servizi e delle applicazioni.

37

Come deve evolvere quindi un servizio

La SOA non è sufficiente a pensare dei servizi sul cloud. E’ nec-essario impostare e definire un livello di astrazione tramite API. Si ricorda il principio di sostituibilità di Parnas in cui un sistema deve essere nascosto a un altro sistema da una astrazione. Quindi l’applicazione deve essere estensibile e integrabile tra-mite le API. Le API sono processi di Business espressi in forma di invocazione Restful. Il protocollo JSON e la notazione Restful ha superato di gran lunga il modello dei Webservices.

Quindi la Prima Caratteristica di un servizio sul Cloud è deve po-ter essere invocato tramite API.

Come stanno offrendo i servizi nel mondo di tutti i giorni?Si pensi per esempio a una stazione di pompe di benzina. Oggi ci troviamo di fronte al fatto che ci sono pompe il cui prezzo della benzina è determinato dal modo con il quale l’utente sta chiedendo la benzina. Se un utente fa self service e paga alla colonnina ha un prezzo, se fa self service e paga alla cassa ne ha un altro e se invece su vuole far servire ne ha un altro an-cora.

Analizzando questo modello si capisce che il principio della Util-ity sta proprio entrando ovunque.

Anche nell’IT il cloud sta prepotentemente dimostrando che la virtualizzazione è il primo passo per far diventare il DataCenter una utility e quindi una commodity per il business.

I servizi stanno evolvendo per essere consumati in self-servicing dove l’intervento umano è ridotto e dove tutto viene automatizzato il più possibile. E’ necessario fare una puntualiz-zazione per vedere il proliferare di strumenti di automazione del datacenter (HP Opsware, Puppet, Chef, Orsyp Million Dollar, etc.). Quindi l’automazione degli ambienti di produzione sta ren-dendo il possibile il Self Service di servizi su richiesta da un utente.

Il Self-Service è la seconda caratteristica di un ambiente Cloud. Si pensi per esempio che su Amazon EC2 si può fare in com-pleta autonomia il provisioning di una macchina. Su ControlMyCloud.com è possibile fare provisioning di un sistema di governance del cloud e su Salesforce.com si fa provisioning di una intera applicazione CRM.

La velocità di selfservice è un parametro che è importante no-tare. Con la tecnologia moderna, un servizio deve essere reso disponibile in maniera automatica. Vale quindi la considerazi-one che il tempo di provisioning del servizio sia ragionevol-mente attorno ai minuti/ore. Un servizio che ci mette qualche

38

giorno o qualche settimana di certo dimostra una carenza e fa pensare che debba richiedere l’intervento umano.

Sempre analizzando le pompe di benzina, devono poter funzi-onare a prescindere dall’utilizzatore. Sia uomo, donna e anche nazione possibile. Il sistema e i relativi dati deve essere condi-viso per più utenti.

La terza caratteristica di un servizio sul Cloud è il fatto che questo servizio sia Multi-tenant e che quindi le informazioni si-ano rese disponibli con tutti i limiti di protezione e di sicurezza per quel utilizzatore. Non è cloud, se non in casi estremamente particolari, un sistema che non sa condividere informazioni non è scalabile su vasta area. Quindi per natura, progettando un servizio è da tenere in considerazione il fatto che debba essere multi-tenant e che debbano valere dei requisiti non-funzionali in fase di definizione del requisito che dicono quali sono i livelli di protezione del servizio stesso. In questo modo si capirà come fare il partizionamento dei dati e anche come si dovranno identi-ficare gli script di deployment e di partizionamento fisico del servizio stesso.

Il cloud è un nuovo modello di business.

Riuscendo a declinare il fatto che il cloud è un fenomeno di Business e un modello culturale e pensando allo Utility Comput-ing si può pensare che il Cloud stia anticipando un nuovo modo di fare business.

I servizi devono poter essere venduti a consumo, allo stesso modo di come si vende l’energia elettrica. Questo vuol dire che il servizio oltre che avere una api di business, deve essere an-che in grado di notificare a una piattaforma di billing o di charg-ing il consumo che è avvenuto per quell’utente di modo poi da mandare la fattura.

La quarta caratteristica di un servizio cloud è che il servizio possa essere fatturato a consumo.

Il modello di business nuovo presuppone quindi che se un servi-zio è erogato al consumo, non sia possibile a priori conoscere quanto consumo venga richiesto da un utente o un altro. E’ quindi necessario stabilire una nuova forma oltre che di ricavi anche di costi. Quando offro un servizio al consumo, mi aspetto che anche i costi e tutta le tecnologia sotto sia disponibile a con-sumo.

In questo modo posso scalare (e fare quindi economica di scala), in maniera più agevole ed elastica. Elastico significa che i costi funzionino in relazione ai ricavi. Se i costi aumentano è perchè i ricavi diminuiscono è perchè i costi diminuiscono.

39

La curva seguente spiega come funzionano i costi rispetto ai ri-cavi sul cloud.

Avendo un modello di business “elastico” è possibile pensare che l’IT nella sua evoluzione a Cloud sia a favore di costi opera-tivi che costi in conto capitale. Da qui la grande differenza tra investimenti OPEX (Operativi) che sono contabilizzati nell’at-tuale esercizio e costi CAPEX (in conto capitale) che vanno in ammortamento. I servizi sul cloud entrano, per via della loro na-tura elastica di “business”, nei costi dell’esercizio corrente.

Ma come può essere un business elastico?

Un business può essere elastico se il servizio è in qualche modo gestibile. La gestione del servizio serve per comunicare al servizio diverse cose. Per prima cosa deve essere possibile interrogare il servizio per verificare lo stato di salute del servizio stesso. Poi è necessario poterlo amministrare.

La Quinta caratteristica di un servizio sul Cloud è che il servizio sia amministrabile via API.

E’ interessante notare come sia necessario disaccoppiare l’inter-faccia di gestione dal servizio stesso. Negli ultimi mesi stanno esplodendo sempre di più degli “application server” leggeri Esempio NodeJS, Dart, Vert.x. La caratteristica di queste tec-nologie è che hanno un footprint basso e che sono esposti rest-ful. Loro quindi sono degli ottimi candidati per essere agenti che non occupano troppe risorse. La loro migliore collocazione è proprio nell’ambito di Business API e di Managing API.

Come cambia il concetto di vendere o acquistare servizi ITI servizi IT possono variare rispetto alla loro natura. L’impor-tante è che un servizio possa essere gestito nel suo ciclo di vita tramite un set di API. E’ l’utente finale che decide come il servi-zio deve essere consumato ed è il venditore che decide che cosa è un servizio. Ogni servizio che da un valore di business e che rispetta i principi è un servizio che ad oggi è venduto sul cloud. Potrebbe essere una macchina virtuale venduta ad ora

40

ed esponendo l’hypervisor come un servizio lui stesso o potrebbe essere qualcosa di più alto in termini di business.

Aquisire servizi IT diventa qualcosa dove si può spaziare e cer-care molta innovazione proprio come business model. Si pensi per esempio ad Amazon che ha una linea di vendita di mac-chine che chiama Spot Machine. Amazon offre ad una asta con-tinua le macchine mentre gli acquirenti offrono del $ all’ora per quelle macchine cercando di stare al ribasso. La logica di Ama-zon è che da la macchina a chi offre di più togliendola a chi aveva offerto di meno e facendo pagare le giuste quote di util-izzo.

Su un modello del genere, l’azienda americana NetFlix che si occupa di fare streaming video ci ha fatto sopra un vero e pro-prio business. Hanno progettato la loro infrastruttura logica (ar-chitettura e partizionamento logico del sistemi) con in testa la continuità di business anche se un server cade. Hanno persino inventato della piattaforme opensource per far si che le istanze che stanno facendo girare la produzione in maniera imprevedi-bile vengano uccise (il sistema che crea questo chaos si chiama Monkey Chaos). In questo modo sono sollecitati con-tinuamente a progettare i loro servizi con una ottica di Fail First e si chiedono sempre: cosa succede agli occhi del business quando dietro fallisce il sistema?

Avendo creato questa cultura all’interno dell’azienda sono rius-citi a comprare tutte le macchine da Amazon in modalità Spot e

a far si che le macchine venissero allocate con una logica al ri-basso. ll loro sistema è diventato resiliente per definizione.

Non entrando tecnicamente ora in questo ambito, è interes-sante verificare il business model che si crea. Una asta al ri-alzo, una architettura resiliente e la possibilità di aggiungere ri-sorse in maniera elastica ha costruito un nuovo business model molto resiliente.

Bisogna sottolineare che il meccanismo di licenze cloud-based è un modello che spinge ad eliminare investimenti e royalti di ogni tipo. Applicazioni come Google Docs, Zoho o Office 365 di Microsoft permettono di comprare una sottoscrizione annuale per utente. Con 50$ si compra da Google un servizio profes-sionale che offre la posta elettronica su gmail (assimilata al do-minio), un editor nello stile di word online, uno spreadsheet e un sistema di presentazione. Il tutto fornito con 25GB di spazio su disco replicato e backuppato sempre.

Come si articola l’offerta sul cloudCi sono molti Cloud Service Provider (CSP) che offrono i più svariati servizi. Si va dalla condivisione di una chiavetta USB sulla rete con sistemi tipo DropBox o Google Drive a database rilasciati come servizi etc.

Il NIST (National Institutes for Standard and Technology) ha identificato 3 macro-zone nelle quali classificare servizi che hanno le caratteristiche sopra descritte. In relazione alla tipolo-

41

gia di servizio si riesce a classificare il cloud nel seguente modo:

IAAS - Infrastructure As A Service: dove i servizi che sono ero-gati sono servizi infrastrutturali come macchine virtuali, rete, cpu, storage. Tra i più grandi players in questo settore troviamo Amazon AWS (Amazon Web Services) dove è possibile com-prare a consumo dalla loro rete nei loro data centers (Avail-ablity Zones).

La sicurezza dei dati è importante ed è importante per esempio che i dati di società europee rimangano in Europa o di francesi in Francia. Ogni fornitore di infrastruttura ha aperto almeno un datacenter ridondato su un altro datacenter in ogni continente (Europa, US, Asia Pack).

PAAS - Platform As A Service: qui i servizi che sono erogati sono assimilabiil ad application servers, database, e più in gen-erale piattaforme. Nei players si identifica ancora Amazon con la sua offerta Beanstalk, Google con la sua offerta AppEngine (dove è possibile configurare applicazioni in Java e in Python), e molti altri. Per quanto riguarda i database Amazon da poco tempo sta vendendo istanze di Oracle con il modello As A Serv-ice.

SAAS - Software As A Service. Qui il terreno è molto più friabile in quanto ci sono molti ASP che si sono ricondizionati a dire che fanno Software As A Service. Nei players si identificano so-luzioni verticali come Salesforce, Sugar, Chargify, Google Docs, ZenDesk, Webex, Gotomeeting, Github, RepositoryHosting, etc.

In relazione alla tipologia di cloud esistono anche poi delle vari-anti sulla modalità di usufruire il cloud.

Ormai tutte le SME hanno migrato alla virtualizzazione, questo gli permette di gestire il datacenter come a uno spazio in cui po-tenzialmente e teoricamente tutto è infinito. Con questo modello potenzialmente possono pensare di gestire il loro datacenter come un cloud privato.

Il cloud privato o interno è un cloud che è nei limiti del datacen-ter dell’azienda stessa. Oggi, anche in Italia, in diverse realtà grosse è richiesto il fatto di gestire datacenter come un cloud privato da aziende esterne. Una specie di outsourcing dei servizi ma ancora dentro al proprrio datacenter. Hanno operato questa logica gli operatori telefonici per primi (H3G con Erics-son, Vodafone con IBM, Telecom con SSC) e poi anche le grandi aziende si stanno approcciando a questo modello. Nei casi sopracitati si sta tendendo al cloud e ci si sta muovendo dalle scelte business alle implementazioni tecnologiche.

42

Il Cloud offerto da Amazon AWS è un Cloud Pubblico. Loro of-frono un servizio pubblico e ci si accede tramite indirizzi IP pub-blici. In Italia ci sono delle implementazioni molto interessanti di cloud pubblici: CloudUP è una piattaforma molto interessante, così come Nuvola Italiana (anche se i tempi di provisioning sono ancora piuttosto elevati).

Il cloud pubblico non è per tutti i settori e talvolta è utilizzabile per gestire gli overbooking. Amazon AWS offre la possibilità di stabilire delle VPN tra il private cloud e amazon stessa. In questo caso è possibile pensare di configurare un servizio che scala in orizzontale e nel momento in cui il datacenter interno finisce trabocca su AWS per il tempo che è necessario.

Questa configurazione di Cloud si chiama Hybrid Cloud che è una via intermedia tra Public Cloud e Private Cloud.

Ci sono dei mercati che sono particolari per via delle norme e della normativa. Un esempio può essere il mercato militare e un altro può essere il mercato bancario. Molti CSP offrono la possi-bilità di ospitare sulla loro infrastruttura (tipicamente IAAS o PAAS) che rispetta le norme che regolano quel mercato. Questo tipo di usufruizione del cloud si chiama Community Cloud.

Quali sono le insidie sul cloud?Molti parlano della sicurezza dei dati e la privacy sono i punti per i quali il cloud non può essere approcciato. In realtà si può fare una analogia con una banca che sa tenere i nostri soldi e una cassaforte messa in casa. Chi sa far meglio la gestione dei soldi. E’ innato e da tutti convenuto che è la banca. Così anche per un servizio di email, chi sa far di meglio è un grande forni-tore come google che gestisce molte caselle di posta elettron-ica.

La vera insidia del cloud è il saperlo governare, saper garantire e capire se il cloud service provider sta garantendo continuità di servizio e nel momento in cui la continuità di servizio degrada saper offrire continuità di servizio con altre tecniche. Netflix ha molto da insegnare in questo caso. Loro con la loro Chaos Mon-key sanno progettare il sistema in maniera davvero affidabile. Nei loro tool sono in grado persino di simulare la caduta di una Availability Zone di Amazon e vedere cosa succede.

Un sistema di governance esterno come ControlMyCloud.com permette di attaccare le risorse e governare quello che succede nel momento in cui i loro livelli di servizio sono violati.

43

Sistemi resilientiFinalmente si può parlare di architetture software resilienti. Fino ad ora ci sono state delle timide mosse con Jini e con altri sistemi simili per rendere una architettura resiliente. Una tale ar-chitettura è capace di durare nel tempo a prescindere dalle con-dizioni in cui si trova.

Da wikipedia, in informatica la resilienza è la capacità di un sistema di adattarsi alle condizioni d’uso e di resistere all’usura in modo da garantire la disponibilità dei servizi erogati. I con-testi di riferimento sono quelli relativi alla business continuity e al disaster recovery. Sinonimi di resilienza sono: elasticità, mo-bilità. È definibile anche come una somma di abilità, capacità di adattamento attivo e flessibilità necessaria per adottare nuovi comportamenti una volta che si è appurato che i precedenti non funzionano.

Con le infrastrutture rilocabili così agevolmente come quelle che ci sta offrendo il paradigma del cloud, anche le architetture software possono davvero incrementare la loro resilienza.

La progettazione del software sta scemando da un modo cos-tretto a pensare a pool e dimensionamenti statici a una tecnica che permette di costruire un sistema che è sempre vivo. La dice lunga la modalità con la quale Netflix sta erogando il pro-prio servizio. Bisogna osservare come, per esempio, il progetto Hystrix permetta di poter fare qualcosa di furbo implementando il pattern  Circuit Breaker in cui la resilienza del sistema è pen-sata dal primo momento in cui si implementa il servizio.

Questo richiede un maggiore sforzo durante il momento di de-finizione architetturale del sistema. Lo studio della la resilienza del sistema, cambia persino il modello di business. La consis-tenza tra l’architettura, la sua implementazione e i requisiti busi-ness è fondamentale. Domande nuove entrano in testa all’ar-chitetto Cloud. Un architetto deve pensare a cosa succede all’utente che sta accedendo a un servizio che non è disponi-bile. Per molti casi non lo potrà fare da solo, lo dovrà fare par-lando con il business che, per sua necessità, avrà bisogno di continuare e quindi capire cosa fare nel momento in cui un servizio non è disponibile.

Con strumenti come ControlMyCloud e più in generale la dis-ponibilità elastica del cloud le architetture fisiche virtualizzate

Section 2

La Resilienza Applicativa

44

diventano adattive ai carichi promuovendo nuova potenza di cal-colo in relazione alla richiesta. I Service Level Agreement stanno andando sempre più oltre alla normale definizione le-gale, stanno diventando delle policy che raccontano cosa fa il sistema in caso di sofferenza e di benessere.

A questo punto le architetture logiche devono anche loro attu-are dei nuovi paradigmi in cui dal punto di vista funzionale il processo può continuare a funzionare. Una architettura resili-ente pone il fallimento come uno dei primi problemi da indiriz-zare. Cosa succede quando il servizio fallisce? Che feedbacks si merita un utente quando non ha più il sistema o il servizio che stava utilizzando? Quali tecnologie per disaccoppiare il sistema client dalla piattaforma server.

La tecnologia ci offre tutte le potenzialità per poter rispondere e scegliere in maniera appropriata le componenti tecnologiche con le quali costruire un sistema resiliente. Sul client oggi si cos-truiscono Applicazioni a prescindere che esse siano Web o na-tive del sistema di riferimento (htm5, ios, android, etc.). Le Appli-cazioni hanno la caratteristica di essere asincrone e quindi in-corporare una logica che viene eseguita direttamente sul client.

Sul server ce ne sono davvero tante altre che permettono di costruire un sistema secondo il paradigma del Fail First. Così come è stato fatto in Netflix ogni dipendenza con piattaforme  critiche è da essere valutata come critica. Durante i tests è con-sigliabile fare un test di endurance, dove si provano a mettere

offline dei servizi a prescindere dalla loro finezza. E’ consigli-abile adottare l’Endurance come principio continuo e non come fase. Sempre in Netflix utilizzano dei bot che sono in grado di spegnere delle macchine in produzione. Sembrerebbe un auto-gol, ma questa mentalità porta a rafforzare sempre di più la pro-pria architettura software.

Così Sandy e tutti gli Outages dei Cloud Service Providers non riusciranno a fermare un sistema che è resiliente. Alla peggio l’utente finale non riceverà una singola funzionalità perchè es-tromessa dalle funzionalità attive, ma continuerà ad usare la pi-attaforma così come progettata.

Fail FirstQuando pensiamo ai Service Level Agreement di un sistema, generalmente pensiamo a quanto è il livello di uptime del sistema stesso. Generalmente sono identificati in maniera molto oggettiva da un numero. Per esempio 99.99% indica che un sistema deve essere non disponibile al massimo per poco più di 4 minuti al mese. Indicando un numero si specifica che il sistema costituito da tutte le sue parti debba essere agibile per molto tempo.

45

Nel paradigma moderno un sistema è qualcosa di molto com-plesso con molte dipendenze verso servizi interni e sistemi esterni. Per far fronte a uno specifico business è necessario an-dare ad integrare sistemi esterni, incorporare sistemi interni su tecnologie diverse etc. Sostanzialmente i colli di bottiglia che possono influire e degradare il mio SLA sono molteplici e pen-sare di garantire un livello di servizio del sistema a un certo va-lore di uptime, vuol dire pretendere che tutti gli altri sistemi inte-grati garantiscano per tale servizio la stessa qualità richiesta.

Quindi la probabilità di caduta del sistema è l’insieme delle prob-abilità di caduta di ogni singolo servizio che compone il sistema.

P(sistema) = (1 – P(sistema interno) * P(servizio1) * P(servi-zio2) * … )

Se 5 servizi esterni offrono un livello di servizio di 99.9% è da notare che la qualità di servizio ben ragionata non può essere superiore a 99.5%. Da qui bisogna fare delle giuste osservazi-oni su come poter frammentare correttamente il sistema di modo che la probabilità di fallimento sia solo quella del sistema interno e cioè sia, verosimilmente, governabile mediante scal-abilità.

Pertanto è possibile postulare il pattern della Inversione dello SLA:

• quando integriamo servizi esterni lo SLA può solo che dimi-nuire.

Ci sono due tecniche principali con le quali affrontare questo problema:

1. E’ necessario disaccoppiare il servizio integrato implemen-tando la logica del fail first e attuando il pattern Circuit Breaker

2. E’ necessario porre particolare attenzione a quando si pensa agli SLA. Da Service Level Agreement si dovrebbe passare a Service Level Assurance. Da 99.* % si dovrebbe passare all’idea di Business Continuity.

Le funzionalità che hanno dipendenze con sistemi esterni pos-sono avere solo il livello di servizio che le parti esterne riescono ad offrire. Questo è l’equivalente nell’Information Technology al secondo principio della Termodinamica dove i livelli di servizio possono solo andare peggio.

46

Nel cloud, è necessario muovere l’idea da un livello di uptime del sistema o del datacenter verso a un principio di business continuity con la qualità misurata in relazione alla percezione dell’utente. Come fa il sistema a sopravvivere nel caso in cui un servizio stia violando il proprio livello di servizio minimo. Come varia la user experience nel momento in cui un sistema o la parte di sistema va in fault?

Queste domande meritano delle risposte che devono tenere in considerazione il pattern di Inversione dello SLA.

47

Development e Operations

Rispetto alle grandi metodologie che ci sono nell’IT, rilasciare un progetto in produzione è ancora sinonimo di andare in guerra. Gli sviluppatori sono nervosi perchè hanno la pressione sulla consegna delle funzionalità al cliente il più velocemente possibile e nell’altro verso le Operations sono resistenti al cam-biamento in quanto consapevoli che i cambiamenti sono la causa dei maggiori disservizi. Quindi succede il classico atteg-giamento del Puntare il dito: “E’ un problema di Sviluppo”, “ No, è un problema di produzione!”.

Questa scena si ripete nel tempo e in molte aziende provo-cando forte frustrazione sia nel management che nel business i quali non sono capaci di predire  una roadmap consistente  e consegnare il valore di business nei modi e nei tempi concor-dati.

Il problema poi si amplifica notevolmente da due standard emer-genti:

" 1." l’agile software development;

" 2." le infrastrutture basate sul cloud

L’agile software development per sua natura incorpora i cambia-menti  e presuppone parecchi rilasci in produzione. La maggior frequenza provoca, per ovvie ragioni, maggiore pressione in produzione che diventa sempre di più il collo di bottiglia.

E’ buffo osservare come l’Agile Software Development predichi e riesca a collaborare con un team eterogeneo tra diverse fig-ure professionali e gli Stakeholders, ma non riesca a coinvol-gere le persone di Operations. La Continuous Integration e il di-partimento di test sono messi come cuscino tra i due diparti-menti.

Il secondo driver, spinto dalle infrastrutture virtualizzate e poi cloud based, sta forzando Operations a cambiare il modo con il quale si sta gestendo l’infrastruttura.

Il lavoro manuale non permette di scalare a migliaia di mac-chine per persona e i cambiamenti di rilasci frequenti rompono completamente tutti gli schemi.

Section 3

DevOps

48

La Virtualizzazione è permetto a Operations di velocizzare gli ambienti e il cloud ha rimosso l’ostacolo delle risorse limitate. La vera differenziazione viene da due concetti base: Configura-tion Management e Instrastructure as a Code.

Il Configuration Management permette di descrivere lo stato de-siderato di una infrastruttura tramite uno specifico linguaggio, permettendo di creare e di gestire una infrastruttura usando gli stessi strumenti. L’Infrastructure as a Code è il risultato dell’in-cremento di piattaforme SAAS e di APIs usate per gestire l’infra-struttura. Sono rimarcabili strumenti come ControlMyCloud per l’assicurazione dei Livelli di Servizio della infrastruttura stessa.

Abbracciando entrambi i concetti si permette a operations di automatizzare molto lavoro, non solo il privisioning iniziale delle macchine nuove, ma l’intero lifecycle. Questo offre la speranza di avere una infrastruttura Agile.

DevOps è nato come risposta a questi due drivers. Un gruppo di persone hanno iniziato questo movimento per rimuovere i confini tradizionali tra Sviluppo e Produzione. Alcuni consid-erano questo come un punto di partenza di dove si è fermato l’Agile Tradizionale.

Dopo tutto c’è da considerare che il software non porta valore fintanto che non è in Produzione.  Per ovviare a questo prob-

lema DevOps incoraggia la costante adozione della medesima collaborazione dell’Agile anche con Produzione. Non solo quando le cose non vanno bene, ma già dal primo momento.

Come in un esercizio, più si pratica il rilascio in produzione e più si migliora.

Operations diventa un attore di valore nel processo di sviluppo agile con le stesse facoltà degli altri membri del gruppo di la-voro. Sempre spesso gli SLA richiesti dallo stakeholder vanno contro alle richieste di cambiamento del cliente stesso.

Ora sia i requisiti funzionali che quelli non funzionali possono essere valutati nelle priorità di business. Questo aiuta nel identi-ficare le priorità prima che il progetto parta e aiuta ad identifi-care gli impedimenti che potrebbero esserci.

Una volta che le priorità sono state definite e il lavoro può inizi-are, gli sviluppatori assieme alle persone di produzione lavo-rano affinchè il lavoro sia finito. Questo lavoro permette di tras-ferire conoscenza e problemi all’interno di tutto il team. Prob-lemi come stabilità, monitoring e backup sono indirizzati immedi-atamente. Operations ha una migliore comprensione di come funziona l’applicazione prima che l’applicazione venga rilasciata in produzione.

49

Quando diventa complicato, fallo più spesso. Così come negli esercizi, piùi si pratica la messa in esercizio e più si diventa con-fidenti. Grazie all’automazione, le operations possono intro-durre piccoli cambiamenti e aggiungere infrastruttura. Prati-cando la messa in produzione durante lo sviluppo, il test, la quality assurance, gli ambienti di produzione risultano più replicati/replicabili e offrono risultati più predicibili.

Così ora, sia Sviluppo che Produzione sono responsabili as-sieme. I confini cominciano a sfumare e gli sviluppatori sono abilitati a mandare dei cambiamenti in produzione (dopo aver passato un ciclo intensivo di tests), e produzione dalla sua parte agiscono solo in caso di emergenza.

Operations e Sviluppo elaborano il concetto di “pipeline auto-matica di rilascio” che estende le fasi nello sviluppo del soft-ware. Tutti i cambiamenti a prescindere da sviluppo, instrastrut-tura o database seguono la stessa pipeline. La pipeline è un po’ come il sonar per i problemi: più si entra dentro la pipeline, e più i risultati diventano robusti.

I feedback sono a tutte le persone che appartengono al gruppo: le persone di operations imparano quali sono le problematiche legate alla produzione, mentre gli sviluppatori apprendono gli ambienti di produzione. Non solo il feedback è per l’utente, ma è anche per il management che impara velocemente dalle reazi-oni degli utenti.

Questo approccio muvoe da uno sviluppo orientato al prodotto a uno sviluppo orientato al cliente e permette di provare le idee di business in quasi tempo reale.

I cambiamenti con DevOps non sono cambiamenti repentini e il processo si raffina e si scopre durante il lavoro. Un pattern comune nell’adozione di DevOps è che i cambiamenti vanno a braccetto con l’introduzione di nuovi strumenti. Un tool da solo non cambia nulla, ma il modo con il quale lo strumento si usa può fare la differenza e risultare un cambio culturale.

Tutto il focus su devops e l’automazione riduce i cicli di lavoro e amplifica la ripetibilità. Se vogliamo tante cose diventano obso-lete e rimpiazzate da strumenti.

E’ necessario diventare agili nello sviluppo e anche agili nei sistemi; prende tempo e sforzi portare avanti queste idee, ma il risultato è impressionante. Il ciclo di feedback fa la differenza nella qualità e nei risultati. Con questa collaborazione così vicina tra Sviluppator e Produzione, i confini sfumano.

Saranno Tutti Sviluppatori? Faranno Tutti Rilascio In

Produzione?

50

In un approccio multidiciplina, si ha l’opzione sia di generaliz-zare che di specializzare o in fondo specializzare i generalisti. Entrambi possono funzionare, ma se si generalizzano gli spe-cialisti si otterrà un migliore visione della loro specializzazione. Questo fenomeno si definisce “T-shaped people”: persone con profonda conoscenza (verticali) che sono in grado di compren-dere gli impatti ad ampio spettro (orizzontali). In una organizza-zione tradizionale, questo mappa una matrice o una struttura. E’ importante ruotare le persone in differenti ruoli e progetti ed è ugualmente importante per gli specialisti di continuare a vivere nei loro gruppi di specialisti per portare la loro esperienza globale.

Anche la struttura del management diventa molto più flessibile. Amazon, Netflix e altre non usano il termine Agile per identi-ficarsi ma applicano un mindset simile. Ci sono piccoli gruppi di sviluppatori e sistemisti (generalmente un gruppo per una pizza americana) rilasciano assieme. Hanno compreso che stanno la-vorando assieme verso gli obiettivi comuni che coincidono con quelli del cliente.

Date questi preconcetti, alcuni possono pensare che DevOps non può lavorare nelle loro aziende. Vedono conflitti con altri frameworks come CMMI, Scrum, XP etc. E’ però da notare come le più grandi storie di successo di DevOps arrivino da azi-ende tradizionali.

Il termine DevOps è solo sinonimo di Collaborazione intrazi-endale.

DevOps può partecipare a far colloquiare anche strutture che hanno deciso di lavorare con CMMI o con ITIL v3. DevOps se-gue il processo di inspect and adaption e può tenere buoni an-che alcune pratiche attuate già nei processi tradizionali.

Non bisogna dimenticarsi che la maggior ragione per cui c’è l’IT è il business che ne deriva. La relazione tra DevOps e il busi-ness è un aspetto importante: alcune persone si fermano a pen-sare che DevOps è solo Sviluppo e Produzione che lavorano assieme. Il ciclo di feedback che si instaura deve essere visto come una parte di un sistema complesso. Quindi DevOps, come l’Agile Software Development, pian piano deve es-tendersi all’intera azienda.

Solo producendo risultati positivi al business può permeterre all’IT di eliminare la cattiva reputazione che si crea quando non si riesce a completare una Applicazione.

I giorni del controllo che viene dall’alto sono finiti, DevOps è un modello che dal basso o meglio in maniera orizzontale cambia. Anche il ruolo del Management cambia: non più solo direttivo, ma a supporto delle persone aiutandole a scoprire il loro po-tenziale.

51

AutomazioneLa “Continuous Delivery” (CD) è un processo automatizzato che permette di rilasciare in produzione nuove versioni di soft-ware diminuendo il tempo che intercorre tra la definizione di un'idea da implementare e la disponibilità di un software us-abile che la realizza (minimizzazione delle interazioni).

In tale processo sono considerate e gestite tutte le fasi e se-quenze che garantiscono una corretta pubblicazione di soft-ware di qualità, e precisamente:

" •" la gestione della configurazione di sistema

" •" la verifica di correttezza con test automatici

" •" la gestione dell'ambiente

" •" la gestione del rilascio

Lo scopo del flusso di deployment è triplice:

" 1." Visibilità: tutti gli aspetti del sistema di deploy - creazi-one, distribuzione, testing, e rilascio in produzione - sono visibili a tutti i membri del team che promuovono la collaborazione,

" 2." Feedback: i membri del team devono essere a cono-scenza dei problemi non appena si verificano, in modo che pos-sano essere risolti il più presto possibile,

" 3." Distribuzione continuativa: attraverso un processo completamente automatizzato, è possibile distribuire e rilasci-are qualsiasi versione del software in qualsiasi ambiente (Test/Stage/Prod).

Section 4

Continuous Delivery

52

Nello schema del flusso della CD (Deployment Pipeline), sono indicati i modelli che il sistema deve gestire correttamente per assicurare un rilascio qualitativo.

Per agevolare la fase di Configuration Management (CM) è buona norma:

• utilizzare software di terze parti facilmente configurabili

• gestire un catalogo di opzioni dell'applicazione (documento compilato automanticamente)

• minimizzare e gestire branch “a vita breve” per convergere il più possibile alla “mainline”.

• proteggere le configurazioni in sistemi sicuri remoti

• versionare tutto il codice sorgente, eseguibili e configurazioni

• gestire gli ambienti con singoli e semplici comandi

Per agevolare la Continuous Integration (CI) è necessario:

• interrompere il processo di build quando una regola è violata (es. test)

• commit regolari da parte dei membri del team

53

• gestione automatica di feedback (es. mail) dal sistema di CI verso il team

• generare il build ed eseguire i test automatici ad ogni modifica committata sul repository

• ripristinare immediatamente il corretto comportamento del soft-ware ogni qualvolta non passa i test automatici

• definire script per la gestione del build indipendente dall'IDE di sviuppo

In fase di testing occorre:

• automatizzare la verifica e la validazione del software inclu-dendo test unitari, funzionali e di performance

• utilizzare database transazionali che permettano il rollback dei dati al termine del singolo test

• utilizzare codice di simulazione che possa ridurre la comples-sità del sistema e verificarne meglio il comportamento

Gestione degli script di build e deploy; ecco alcune regole:

• individuare e centralizzare tutte le librerie e dipendenze per evitare duplicati e confusione

• utilizzare linguaggi di scripting conosciuti ed adeguati che pos-sano essere modificati da tutti i membri del team

• esternalizzare tutte le fonti di configurazione

• gestire e versionare gli script di build/deploy nel repository del codice sorgente

• unificare gli script di deploy e gestire l'ambiente come parame-tro

Database

Il database è una risorsa che si evolve insieme allo sviluppo del software, ma anche con i dati che sono introdotti dall’utilizzo del sistema.

L’evoluzione strutturale di un database è costituita da script DDL (Data Definition Language) che devono anche mantenere il più possibile l’integrità dei dati.

Per ciascun passo evolutivo deve perciò essere previsto lo script di “migrazione” e di rollback, e deve anche essere storiciz-zato come tutti gli altri script/sorgenti.

Un backup completo, comunque, normalmente è previsto e schedulato con cadenza periodica.

54

Infine, nella gestione di un sistema di CD, occorre archiviare i binari di ciascuna versione, fornire un sistema di rollback per casi di insuccesso, e soprattutto gestire il rilascio in produzione e lo switch al nuovo software tenendo conto del numero di utenti connessi al sistema per minimizzare eventuali anomalie.

55

I Database sul CloudRecentemente Google ha rilasciato un paper su Spanner, il suo Database distribuito globalmente. Spanner è un database che è pensato da Google per riuscire a a distribuire informazioni su scala globale con un meccanismo di distribuzione sincrono, con la gestione delle transazioni, con SQL come linguaggio di adozi-one e con un concetto di gestione delle informazioni Semi-Relazionale.

La cosa curiosa nel loro paper è che scrivono

“We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.”

Un attacco molto forte ai database NOSQL dove la semplicità la fa da sovrano e dove temi come la gestione della transazion-alità è da demandare al database piuttosto che rimandarla allo sviluppatore inventando concetti e modelli di gestione di transa-zioni compensative.

Effettivamente sta facendo pensare molto la loro presa di posizi-one, ma anche fa pensare quale modello dobbiamo adottare in un nostro database. L’atomicità, la consistenza dell’operazione e il relativo isolamento sono dei temi che oggi come oggi non sono molto considerati nei database di “nuova generazione” come i database NOSQL. Dei trucchi di programmazione fanno si che sia la consistenza del dato e l’isolamento siano dei prob-lemi applicativi e sono risolti in maniera non sistematica con in-terventi applicativi.

Una netta separazione architetturale, promuoverebbe questi ele-menti fondamentali come caratteristiche comuni nella gestione del dato. Quindi se sono comuni, devono allora essere delle fun-zionalità offerte dalla piattaforma di persistenza e non dall’appli-cazione che ne fa uso.

Sembrerebbe quindi che c’è un salto in dietro, volendo tornare alla logica dei database relazionali in cui le caratteristiche ACID di un database sono la base della gestione del dato stesso.

Section 5

Databases

56

L’innovazione portà però a risolvere problemi vecchi e sempre più complessi con strumenti nuovi cercando di non iterare e ripetere gli errori già fatti. E’ necessario identificare, in fase di studio di una architettura quale tipo di persistenza adottare e scegliere con accortezza relativamente alle proprie necessità.

I database NOSQL fanno anche parte della moda nello svi-luppo del software, ma nella maggior parte dei casi le loro scelte sono state fatte con motivazione. La motivazione princi-pale era legata alla facilità di uso, alla loro natura di essere inter-rogati con un approccio restful da Apps e alla capacità di sa-persi replicare su una rete geografica in maniera molto agevole.

Tutto ciò a discapito di alcuni elementi caratterizzanti le piatta-forme di persistenza dei dati o più generalmente chiamati Data-bases. La transazionalità è uno di questi, così come anche la necessità di dover mettere le informazioni in schemi ben pre-cisi.

Nei razionali che si dovrebbero adottare quando si sceglie una piattaforma di persistenza è necessario affrontare dei temi im-portanti.

Temi che riguardano a:

1. come evolverà la natura del dato nelle versioni future

2. il fatto di avere uno schema ben preciso che costringa una informazione ad essere consistente

3. il come si disperderà il dato in rete geografica una volta che il dato diventa “vivo” e può andare vicino all’utente

4. il come le informazioni dovranno essere isolate in due transazioni concorrenti anche se su distribuzione geo-grafica (2 Phase Commit)

5. Una volta che si indirizza il pensiero verso temi come quelli proposti si può applicare una logica di selezione di un database, se scegliere una piattaforma di persis-tenza distribuita con delle caratteristiche oppure una logica di gestione di queste problematiche dal punto di vista applicativo.

Se per esempio sappiamo che l’informazione non evolve e che il dato dovrà essere conservato in un datacenter specifico per via della relativa confidenzialità si adotterà un modello SQL standard (MySql, Postgresql, etc. ).

Se non abbiamo la necessità di dover gestire transazioni, ma abbiamo la necessità di dover replicare i dati su una rete geo-grafica (Internet) e accedervi in maniera restful si adotterà un modello NOSQL “tradizionale” (MongoDB, Redis, etc.)

57

Se invece abbiamo la necessità di avere dati che vengono tras-feriti geograficamente sulla rete dei quali è necessaria la transa-zionalità e per i quali è anche importante mantenere uno schema, si adotterà un database NEWSQL come Spanner op-pure un database NOSQL come Orient-DB.

Analizzando l’evoluzione di queste due utlime piattaforme di per-sistenza, i dati possono sottostare a uno schema. I dati pos-sono essere acceduti con la conoscenza SQL like (SQL per Orient-DB) e cosa molto importante sono garantite le caratteris-tiche ACID.

Questi nuovi database sono focalizzati sulla replica delle infor-mazioni in rete, dove le informazioni possono muoversi. Le repli-che sono tutte Master To Master e quindi anche la probabilità di perdere informazioni si ridimensiona drasticamente.

L’evoluzione di certi database come Orient-DB sta innovando il mondo della persistenza delle informazioni cercando di non ri-commettere gli errori commessi nel passato. Lo si vede dalla loro capacità di essere scalabili, transazionali e compliant a SQL.

E’ necessario mantenere un occhio a queste piattaforme rivo-luzionarie perchè permettono di fare molto con poco e permet-tono di mantenere livelli qualitativi che solo database di grandi corporate offrono.

lviii

© mondora.com

Autori:

Daria VenerDavide MorriFrancesco BarberaFrancesco ManentiFrancesco MondoraMarco RozzatiMichele MondoraRoberto Giana

Copyright