Prima Edizione
Agile e DevOps explained
© 2013 - mondora.com
Agile Software
1
Agile Software management significa passare da un modello di direzione a un modello di supporto.
Section 1
Introduzione
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
Introduzione La velocità con la quale il mercato si sta muovendo sta crescendo esponenzialmente. Anche nello sviluppo del software le aspettative sono molto più alte che quelle di 10 anni fa; la produttività è 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 maggiore. 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’esplosione è vicina. E’ necessario porre la attenzione sta nel fatto di riuscire a mantenere la natura delle cose e delle persone in un processo produttivo 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 produca lentamente e nel contempo a rilasciare delle applicazioni che sia utili per il Business. La velocità richiesta e il livello qualitativo necessario, impongono una grande disciplina rispetto alle poche regole di processo e una grande attinenza rispetto ai ruoli e alla responsabil2
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.
stesso principio per dei semi di mais che sono messi a cuocere sul fuoco e devono subire il calore della pentola. Se loro visualizzano già la mutazione e il piacere del palato di dei bambini che li mangiano, sanno indirizzare i propri sforzi.
C’è bisogno di gruppi di lavoro con specialisti che sappiano generalizzare.
Lavorando con i metodi agili e passando progressivamente a DevOps, si riesce a scaldare la pentola e a far si che le idee facciano 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 frequenza e qualità. Nel palazzo costruito in Cina da una parte è stato il ritmo a portare e a far si che la velocità di esecuzione rimanesse costante. Dall’altra parte anche gli strumenti devono perfezionare e facilitare lo sviluppo. Tutti gli strumenti che vivono sul Cloud sono gli elementi necessari per far si che la velocità di crociera sia mantenuta.
Un’attività di backcasting, infine, permette di partire dalla visione che può essere più offuscata e ripercorrere i passi per arrivare a capire quali sono le azioni da intraprendere per riuscire a concretizzare il prodotto. Questo cambia le logiche di management aziendali e porta da un modello direttivo a un modello supportativo. 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 comunicazione non localizzate in singoli territori”. La condivisione di progetto in questo modo permette a tutto il gruppo di lavoro di assimilare il significato dei propri sforzi e di lavorare sempre in virtù di un risultato che a divenire.
Il processo di DevOps è un meccanismo di perfezionamento a divenire e ad ogni iterazione ci fermiamo a ragionare sul metodo con il quale possiamo perfezionare il processo.
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 3
Section 2
La regola di Pareto
Il 20/80 L’80% dei risultati si ottiene con il 20% degli sforzi e di conseguenza 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 massimizzare 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;
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 produce già un risultato finito. Questo vuol dire che in ogni momento è possibile fermare gli sforzi e apprezzare i risultati di un prodotto che è in via di completamento.
" 2." una volta che si identificano i risultati è necessario identificare anche il valore che il risultato porta;
4
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 produrre 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 devono 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 approccio iterativo è valido se si produce un incremento di valore.
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 semplificazione 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 semplificazione. 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 derivanti dai costi di cambiamento.
Da qui continuando a lavorare sulle conseguenze della regola di Pareto è possibile porre una serie di conclusioni interessanti.
5
Section 3
Il Product Owner
Il ruolo del Product Owner Se 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. Diverse piattaforme dimostrano come invece ci sia la volontà di voler far funzionare un framework per un gusto prettamente tecnologico. Generalmente questo approccio spegne e fa scomparire il valore dell’idea.
Invece come ci insegnano Chris Messina e Joshua Porter, quando si progetta una applicazione è necessario isolare il concetto di social object per poi andare a definire attorno le caratteristiche 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 governare ciò che si vuole implementare nel prossimo futuro e mantenere 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 medio periodo, si isola il social object se stiamo lavorando a costruire 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. 6
Il Product Owner compie continuamente questo lavoro sul proprio 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 produttivo 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 direzione. Anche da una analisi tecnologica, ci si rende conto che il prodotto 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 software. Un venditore saprà raccontare alcuni scenari e proiettare le esigenze anche in scenari futuri perchè sarà sempre concentrato sul motivo predominante della propria soluzione software. Così anche un programmatore che farà le scelte tecnologiche e
architetturali saprà argomentare il motivo di una implementazione piuttosto che di un’altra. Non è facile isolare il problema e capire quali sono i propri obiettivi, 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 viene 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 Prodotto imparando dai feedback che riceve e rivede di conseguenza gli obiettivi di medio e lungo termine. Tutto è dinamico e la possibilità di lavorare a iterazioni brevi - come dimostra la regola 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 mantenere una visione di prodotto, significa non riuscire ad avere una roadmap e significa non governare il processo.
7
Il tutto fortunatamente può andare a buon fine e portare dei risultati buoni, ma nella maggior parte dei casi porta a una accozzaglia di decisioni sia tecnologiche che di business che rendono 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 dovuto tenere assieme tutte le forze che sono state messe in gioco. La vision, a questo punto, gioca un ruolo importante.
8
Section 4
Il Product Backlog e le User Stories
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 è sufficiente a mantenere in linea il processo di innovazione continua con il delivery minimo di valore richiesto iterazione dopo iterazione in maniera coerente con la vision. Al Product Backlog manca il concetto di vision.
Come pianificare il lavoro Il Product Backlog è lo strumento con il quale poter pianificare l’elenco delle funzionalità minime con le quali rilasciare un prodotto. Attraverso il Product Backlog si va a creare un processo continuo di innovazione che, iterazione dopo iterazione, attribuisce valore al prodotto in maniera consistente. Generalmente il Product Owner parte a voler scrivere tutte le funzionalità sul product backlog e poi pensa di pianificare queste funzionalità 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 risultati si ottiene con il 20% degli sforzi e viceversa. Ma come fare a capire quale è l’insieme minimo delle funzionalità che danno il massimo risultato?
E’ necessario, quindi, focalizzarsi all’idea di prodotto prima che di backlog ed è importante andare ad indirizzare il proprio intuito 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 definisca i canali di vendita partendo da un business model
9
L’obiettivo di prodotto L’obiettivo di prodotto è rappresentato da una frase o da una serie 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 valore associare anche una metafora. La metafora aiuta a pensare in maniera parallela anche a tutte le funzionalità che dovranno poi andare ad essere implementate. L’obiettivo di prodotto è fondamentale per continuare a mantenere 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 chiaramente 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 incrementare 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 bisogni 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 identificare 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. 10
Una volta chiariti questi punti e identificate un elenco di funzionalità, 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 funzionalità descritte in termine di vision. In questo modo le user stories, 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’approccio 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 funzionalità rilasciate iterazione dopo iterazione, un prodotto è anche un insieme di improvements che hanno una componente tecnica. E’ necessario, assieme al product backlog, mantenere il riferimento al Technical Debt o debito tecnico dove entrano difetti,
technical enhancement e più in generale tutto quanto è rilevanza dal punto di vista tecnici. La roadmap di prodotto sarà quindi il confluire del Product Backlog e del Backlog contenente il debito tecnico (che potranno e dovranno confluire a loro volta in un unico backlog). La complessità riferita alle storie utente e la velocità di implementazione delle singole storie che si impara iterazione dopo iterazione, permetteranno 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 prodotto dal punto di vista tecnico.
Le User Stories Le 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 prodotto è offerto agli utenti che decreteranno il successo o il fallimento dell’offerta.
11
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 abilitare la conversazione (Conversation) • i requisiti devono poter essere controllati (Confirmation) Pertanto non ci si aspetta che una user story descriva minimamente 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 considerare 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 caratteristiche 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 caratteristiche, permette di avere un backlog a sua volta molto versatile in cui le priorità possono cambiare la sequenza di lavorazione delle user stories stesse senza la necessità di dover ripensare 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 diverse strategie. Essendo noi prevalentemente di estrazione tecnica abbiamo notato che le tecniche di disaccoppiamento utilizzate 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 vuole venga sviluppato. La necessità di abilitare la conversazione di una user story, viene proprio in questo momento. Le user stories devono abilitare alla conversazione, ma è anche opportuno che durante questi incontri la conversazione che ne deriva venga in qualche modo documentata. Nella nostra esperienza, 12
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 priorità 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 sviluppo 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 andare 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 stimare 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 maggiore accuratezza durante le stime. Di solito separiamo le storie in relazione anche al loro modo di gestire le informazioni. Generalmente 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 degli altri test che devono essere passati nel frangente di una sin13
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 Selenium 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 singole user stories è un atto a cui il Product Owner deve dare rilievo. La completezza dei requisiti e il soddifacimento del principio delle tre C e del principio di INVEST fa si che il prodotto possa evolvere agevolmente giorno dopo giorno.
14
Section 5
Correre per un obiettivo Lo Sprint Una 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 è identificato da uno Sprint Review meeting in cui è consegnato un elemento di prodotto potenzialmente esercibile. Uno sprint è quindi una unità di tempo in cui il team si autoorganizza e produce qualcosa per l’utente che è di valore. Durante lo Sprint il team che sta lavorando sulle attività si incontrano quotidianamente durante una sessione chiamata Daily Scrum in cui ci si confronta.
Il Team In 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, programmatori, 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 generalmente 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. 15
Lo Scrum Master Lo 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 cliente è 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.
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.
Ha la responsaiblità di completare tutto il lavoro negoziato all’inizio dello Sprint e ha anche la facoltà di decidere quanto lavoro ci vuole per terminare. Il Product Owner cercherà di spingere 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’iterazione. 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 giocare 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 16
Section 6
Lo Sprint Planning Meeting Come iniziare uno sprint Il fine dello sprint planning meeting è quello di pianificare le attività 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 partecipare, 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 prodotto; • nei successivi 30 minuti il Product Owner descrive le User Stories che ha individuato e che propone al Development Team;
Una buona indicazione sarebbe che il Product Owner spiegasse 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 parlando 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 rimangono 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.
17
Durante questa fase non è necessario che il product owner rimanga 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 brevemente 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 stakeholders, a cui non interessa il dettaglio tecnico, a cosa sta lavorando il team. Il successo dello sprint verrà successivamente valutato durante lo Sprint Review Meeting in base all’obiettivo che si era prefissato di raggiungere e in base ai singoli item selezionati per lo sprint dal product backlog.
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, dettagliare e stimare nello sprint backlog. Il product owner decide quali.
Lo Sprint Backlog Come risultato di uno Sprint Planning Meeting il team produce uno sprint backlog in cui sono contenute tutte attività individuate 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 business. Lo sprint backlog sarà la guida del team durante lo sprint e permetterà di poter governare lo sprint con l’elenco delle attività 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à.
L’altro risultato è invece lo sprint backlog, un elenco di attività necessarie per finalizzare le user stories selezionate dal product backlog. Queste sono stimate dal team in base al tempo e 18
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.
19
Section 7
Il Daily Scrum
Come si anima lo sprint Durante 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 certamente lo scrum master. Inoltre, è possibile, per tutte le altre persone coinvolte a vario titolo nel progetto di partecipare a questo meeting (ad esempio i venditori, i capi progetto ed altri). E' necessario però che queste figure non intervengano durante il Daily Scrum. La loro partecipazione è un ottimo modo per diffondere 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 svolgere, l'inizio della giornata lavorativa è il momento migliore per tenere l'incontro. Inoltre la durata dell'incontro deve essere tassativamente di 15 minuti. Questo intervallo di tempo permette di non disperdere energie da dedicare allo sviluppo vero e proprio, ma è abbastanza ampio per avere una una discussione rilevante e fruttuosa. " Durante il Daily Scrum ogni membro del team deve rispondere 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 appartenenti 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. Piuttosto servono agli appartenenti al team di sviluppo a rendere partecipi 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 attività. 20
La terza domanda non è posta affinchè il problema venga risolto 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 sollevati. 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 backlog, che come già detto non è un documento intoccabile, ma è uno strumento su cui il team può e deve intervenire quotidianamente. 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 fondamentale, su cui si basano le successive stime, è che sono le ore mancanti per finire la singola attività a dover essere comunicate e aggiornate nello sprint backlog.
21
Section 8
Il Burndown chart
Governare lo Sprint Durante 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 continuamente la mole di lavoro rimanente dello sprint viene ricalcolata, 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 cambiamenti durante lo sprint a causa di diversi motivi: • Le persone del team ottengono maggior conoscenza e chiarezza 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 aggiuntivi. Anche se questi possono essere considerati come lavoro 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 piccoli 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 22
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’appropriata 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 cosciente dell’avere uno sprint backlog chiuso a determinate 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 23
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, rivelano 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, rappresenta 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. 24
Section 9
Lo Sprint Review Meeting La fine dello sprint Alla 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 review 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 costruito, con la possibilità da parte di ognuno dei presenti di fare domande o dare suggerimenti. Rappresenta infatti un buon momento per raccogliere preziosi feedback da parte degli stakeholder. Il product owner conduce questa parte di meeting e determina lui stesso quali user stories del product backlog sono state completate durante lo sprint, e decide col team e gli stakeholder presenti 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 finale. • 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ò ottenere infatti, è quello di avere meno user stories completate in uno sprint, ma sicuramente quelle completate sono davvero tali e funzionanti in environment di test.
25
È 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 imbarazzante, e anche le persone presenti saranno più fredde o addirittura 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 terminato. 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 costituiscono le lesson learned di un team.
gli elementi in questi due fogli. Item ripetuti vengono marcati per renderli più evidenti. Fatto questo il team cercherà di individuare le cause e in comune accordo le conseguenze, con l’attenzione nel rivedere e monitorare le decisioni prese nella prossima 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 cambiare in comune accordo qualcosa nel processo. Senza la retrospettiva, sicuramente si potrà notare che il team continuerà a ripetere sempre gli stessi errori.
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-
Lesson Learned 26
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 infatti 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 acquisisce, spaziano in aree diverse, come tipicamente la comunicazione, la pianificazione, i requisiti, la qualità del software, la conoscenza di tecnologia, e altro ancora.
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 infatti 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 acquisisce, spaziano in aree diverse, come tipicamente la comunicazione, la pianificazione, i requisiti, la qualità del software, la conoscenza di tecnologia, e altro ancora.
Per questo le lesson learned rappresentano una chiave importante 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.
Per questo le lesson learned rappresentano una chiave importante 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’estremo oriente e nominato 改善 (kaizen = “buon cambiamento”):
Ed è proprio a questo processo di continuous improvement che l’Agile development ambisce, un concetto che nasce nell’estremo oriente e nominato 改善 (kaizen = “buon cambiamento”):
un approccio a lungo termine che sistematicamente cerca di ottenere piccoli cambiamenti incrementali in modo da migliorare l’efficienza e la qualità.
un approccio a lungo termine che sistematicamente cerca di ottenere piccoli cambiamenti incrementali in modo da migliorare l’efficienza e la qualità. 27
Section 10
Test Driven Development
è necessario solo scrivere la parte per poter compilare correttamente il codice. Il test ovviamente fallisce perchè il codice non fornisce le funzionalità richieste in quanto non ancora scritto Green: Scrivere abbastanza codice per far passare il test
Cosa significa TDD Lo sviluppo del codice guidato dai test (Test Driven Development) è una tecnica di programmazione che prevede l’utilizzo di test per scrivere codice e disaccopiare le funzionalità dell’applicazione. L’obiettivo di questa metodologia è quello di costruire ed avere a disposizione una suite di test che ci garantisce il funzionamento dell’applicazione ad ogni stadio dello sviluppo.
Come funziona Il 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 output o prevedere la gestione di determinati errori. A questo punto
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 funzionalità si può dire concluso. Una delle peculiarità del TDD è appunto quella di certificare che il codice soddisfi le richieste Refactor: Modificare il codice in modo da garantire il disaccoppiamento 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
28
Benefici
Best Practice
• In ogni momento dello sviluppo abbiamo la ragionevole certezza che la nostra applicazione funzioni correttamente grazie al superamento della suite di test
La suite di test deve avere un ampiezza tale da garantire la risoluzione delle specifiche funzionali e impedire l’introduzione di regressioni.
• Lo sviluppo attraverso questa metodologia impone di scrivere blocchi di codice concettualmente separati tra loro e quindi sostituibili e rifattorizzabili con più facilità
• Per garantire che i test siano funzionali ed utilizzabili devono essere veloci nell’esecuzione: questo vuol dire che non ci devono essere test superflui e che in generale devono rimanere semplici
• Gli sviluppatori che lavoro nel team hanno minor difficoltà ad individuare parti di codice inutili o a migliorare sezioni esistenti avvalendosi dei test che dimostrano il funzionamento dell’applicazione anche dopo ingenti modifiche • La suite di test ci aiuta nel compito di non introdurre regressioni 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 testare l’intero codice in modo da escludere l’introduzione di regressioni • 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
• 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 astrazione
• Riducono significativamente il tempo che lo sviluppatore dedica al debug dell’applicazione in cerca di errori 29
Section 11
Extreme Programming alcune pratiche 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 codice. Se utilizzata correttamente, rispetto al tradizionale modello 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 possibili 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 interventi. 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 30
- darsi degli obiettivi per completare delle attività in pochi minuti.
un algoritmo o una struttura interna di dati, senza alterare però la funzionalità originaria.
Durante l’attività di scrittura del codice, colui che guida deve tenere attivo il partner che osserva aggiornandolo su cosa si sta facendo, chiedendogli un parere per migliorare l’implementazione 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.
Di fatto è un cambiamento della struttura “interna” di un software già funzionante, garantendo la regressione, con l’obiettivo di migliorare il codice per renderlo più comprensibile.
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 cambiare 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
Potremmo pensare al refactoring come ad una “semplificazione” a favore della manutenibiltà di una funzione, a parità di valori di ingresso e di risultati. Ovviamente è più agevole da applicare solo quando vengono rispettati i paradigmi di un software object oriented, ovvero l’incapsulamento 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 caratteristiche 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.
31
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 realizzata 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 operazioni tipiche del refactoring, che alcuni IDE permettono di utilizzare. Il catalogo è disponibile su http://refactoring.com/catalog I benefici delle attività di refactoring possono cadere genericamente in due categorie, entrambe identificabili come “requisiti
non funzionali” del software, ma che sono elementi di qualità importanti. " 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 identificate, 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 refactoring il principio che vige è “Keep It Simple, Stupid” proprio per identificare che il codice realizzato deve essere semplice, stupido, ed ognuno deve poterlo leggere direttamente, senza documentazione specifica. Significa evitare di pensare alle ottimizzazioni fin dall'inizio, ma cercare invece di mantenere uno stile di programmazione semplice e lineare, demandando le ottimizzazioni 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, 32
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à, introdurre pattern e fare “refactoring”. Nessuno è proprietario di una porzione di codice e non esistono colli di bottiglia di conoscenza, per effettuare cambiamenti e manutenzione.
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.
All’inizio è arduo, in quanto ognuno è “geloso” del proprio lavoro ed è difficile da accettare che non ci sia un “capo”, un architetto 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 momento.
I.
Come si effettua la “Code collective ownership” ?
Per ogni porzione di codice prodotto, lo sviluppatore deve fornire i test unitari. L’insieme di questi test unitari, e la loro ese33
DevOps
2
DevOps elimita il gap che passa dalla produzione allo sviluppo del software.
Section 1
Le evoluzioni del Datacenter
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 anche la corrente elettrica è erogata a consumo con dei dimensionamenti “illusori”. Allo stesso modo della corrente elettrica, il Cloud offre il miraggio delle risorse illimitate. Per esempio Gmail offre la posta 10GB di posta elettronica gratuita. Così come il fornitore di corrente 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 elettriche italiane consumassero simultaneamente 1Kw di corrente
35
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.
E’ risaputo che dal punto di vista marketing una applicazione vale di più di tanta pubblicità sui giornali e il motivo è noto: ingaggiano l’utente.
Le devices sono innumerevoli, oggi ognuno di noi ha in tasca una device che ha la possibilità di far funzionare delle applicazioni.
Ma a cosa portano queste applicazioni?
Che differenza c’è tra una applicazione nativa e una applicazione html5?
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 controllare cosa sta succedendo.
Le applicazioni native aggiungo funzionalità contestualizzate all’utente e alla device stessa. Per esempio, la geolocalizzazione, l’integrazione con la fotocamera etc. Oltre alle dimensioni dello schermo ci sono delle caratteristiche che implicano lo sviluppo nativo di applicazioni.
Un esempio è in US, dove Visa ha rilasciato la possibilità di accettare 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.
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.
I carichi diventano impredicibili per via dell’uso che si fa dei servizi e delle applicazioni.
Il concetto di applicazione negli ultimi anni sta emergendo sempre di più e ogni device deve avere la sua applicazione che rimappa tipicamente un servizio online.
36
Come deve evolvere quindi un servizio La SOA non è sufficiente a pensare dei servizi sul cloud. E’ necessario 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 tramite 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 poter 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 ancora.
Analizzando questo modello si capisce che il principio della Utility 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 selfservicing dove l’intervento umano è ridotto e dove tutto viene automatizzato il più possibile. E’ necessario fare una puntualizzazione 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 rendendo 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 completa 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 notare. Con la tecnologia moderna, un servizio deve essere reso disponibile in maniera automatica. Vale quindi la considerazione che il tempo di provisioning del servizio sia ragionevolmente attorno ai minuti/ore. Un servizio che ci mette qualche 37
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 funzionare a prescindere dall’utilizzatore. Sia uomo, donna e anche nazione possibile. Il sistema e i relativi dati deve essere condiviso per più utenti. La terza caratteristica di un servizio sul Cloud è il fatto che questo servizio sia Multi-tenant e che quindi le informazioni siano 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 identificare 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 Computing 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 anche in grado di notificare a una piattaforma di billing o di charging 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 servizio è 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 consumo. 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.
38
La curva seguente spiega come funzionano i costi rispetto ai ricavi sul cloud.
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’interfaccia 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 tecnologie è che hanno un footprint basso e che sono esposti restful. 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.
Avendo un modello di business “elastico” è possibile pensare che l’IT nella sua evoluzione a Cloud sia a favore di costi operativi che costi in conto capitale. Da qui la grande differenza tra investimenti OPEX (Operativi) che sono contabilizzati nell’attuale esercizio e costi CAPEX (in conto capitale) che vanno in ammortamento. I servizi sul cloud entrano, per via della loro natura elastica di “business”, nei costi dell’esercizio corrente.
Ma come può essere un business elastico?
Come cambia il concetto di vendere o acquistare servizi IT I servizi IT possono variare rispetto alla loro natura. L’importante è che un servizio possa essere gestito nel suo ciclo di vita tramite un set di API. E’ l’utente finale che decide come il servizio 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 39
ed esponendo l’hypervisor come un servizio lui stesso o potrebbe essere qualcosa di più alto in termini di business.
a far si che le macchine venissero allocate con una logica al ribasso. ll loro sistema è diventato resiliente per definizione.
Aquisire servizi IT diventa qualcosa dove si può spaziare e cercare molta innovazione proprio come business model. Si pensi per esempio ad Amazon che ha una linea di vendita di macchine che chiama Spot Machine. Amazon offre ad una asta continua le macchine mentre gli acquirenti offrono del $ all’ora per quelle macchine cercando di stare al ribasso. La logica di Amazon è che da la macchina a chi offre di più togliendola a chi aveva offerto di meno e facendo pagare le giuste quote di utilizzo.
Non entrando tecnicamente ora in questo ambito, è interessante verificare il business model che si crea. Una asta al rialzo, una architettura resiliente e la possibilità di aggiungere risorse in maniera elastica ha costruito un nuovo business model molto resiliente.
Su un modello del genere, l’azienda americana NetFlix che si occupa di fare streaming video ci ha fatto sopra un vero e proprio business. Hanno progettato la loro infrastruttura logica (architettura 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 imprevedibile vengano uccise (il sistema che crea questo chaos si chiama Monkey Chaos). In questo modo sono sollecitati continuamente 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 riusciti a comprare tutte le macchine da Amazon in modalità Spot e
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 professionale che offre la posta elettronica su gmail (assimilata al dominio), 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 cloud Ci 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 tipolo40
gia di servizio si riesce a classificare il cloud nel seguente modo: IAAS - Infrastructure As A Service: dove i servizi che sono erogati 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 comprare a consumo dalla loro rete nei loro data centers (Availablity Zones).
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 soluzioni verticali come Salesforce, Sugar, Chargify, Google Docs, ZenDesk, Webex, Gotomeeting, Github, RepositoryHosting, etc.
In relazione alla tipologia di cloud esistono anche poi delle varianti sulla modalità di usufruire il cloud.
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).
Ormai tutte le SME hanno migrato alla virtualizzazione, questo gli permette di gestire il datacenter come a uno spazio in cui potenzialmente e teoricamente tutto è infinito. Con questo modello potenzialmente possono pensare di gestire il loro datacenter come un cloud privato.
PAAS - Platform As A Service: qui i servizi che sono erogati sono assimilabiil ad application servers, database, e più in generale 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 Service.
Il cloud privato o interno è un cloud che è nei limiti del datacenter 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 Ericsson, 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. 41
Il Cloud offerto da Amazon AWS è un Cloud Pubblico. Loro offrono un servizio pubblico e ci si accede tramite indirizzi IP pubblici. 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 possibilità 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 fornitore come google che gestisce molte caselle di posta elettronica. 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 Monkey 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.
42
Section 2
La Resilienza Applicativa Sistemi resilienti Finalmente 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 architettura è capace di durare nel tempo a prescindere dalle condizioni 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 contesti di riferimento sono quelli relativi alla business continuity e al disaster recovery. Sinonimi di resilienza sono: elasticità, mobilità. È 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 costretto 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 proprio 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 è pensata dal primo momento in cui si implementa il servizio. Questo richiede un maggiore sforzo durante il momento di definizione architetturale del sistema. Lo studio della la resilienza del sistema, cambia persino il modello di business. La consistenza tra l’architettura, la sua implementazione e i requisiti business è fondamentale. Domande nuove entrano in testa all’architetto Cloud. Un architetto deve pensare a cosa succede all’utente che sta accedendo a un servizio che non è disponibile. Per molti casi non lo potrà fare da solo, lo dovrà fare parlando 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 disponibilità elastica del cloud le architetture fisiche virtualizzate 43
diventano adattive ai carichi promuovendo nuova potenza di calcolo in relazione alla richiesta. I Service Level Agreement stanno andando sempre più oltre alla normale definizione legale, 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 attuare dei nuovi paradigmi in cui dal punto di vista funzionale il processo può continuare a funzionare. Una architettura resiliente pone il fallimento come uno dei primi problemi da indirizzare. 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 costruiscono Applicazioni a prescindere che esse siano Web o native del sistema di riferimento (htm5, ios, android, etc.). Le Applicazioni hanno la caratteristica di essere asincrone e quindi incorporare 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 è consigliabile fare un test di endurance, dove si provano a mettere
offline dei servizi a prescindere dalla loro finezza. E’ consigliabile 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 autogol, ma questa mentalità porta a rafforzare sempre di più la propria 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è estromessa dalle funzionalità attive, ma continuerà ad usare la piattaforma così come progettata.
Fail First Quando 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.
44
Nel paradigma moderno un sistema è qualcosa di molto complesso con molte dipendenze verso servizi interni e sistemi esterni. Per far fronte a uno specifico business è necessario andare 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 pensare di garantire un livello di servizio del sistema a un certo valore di uptime, vuol dire pretendere che tutti gli altri sistemi integrati garantiscano per tale servizio la stessa qualità richiesta. Quindi la probabilità di caduta del sistema è l’insieme delle probabilità di caduta di ogni singolo servizio che compone il sistema. P(sistema) = (1 – P(sistema interno) * P(servizio1) * P(servizio2) * … ) 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 osservazioni 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 scalabilità.
Pertanto è possibile postulare il pattern della Inversione dello SLA: • quando integriamo servizi esterni lo SLA può solo che diminuire.
Ci sono due tecniche principali con le quali affrontare questo problema:
1. E’ necessario disaccoppiare il servizio integrato implementando 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 possono 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. 45
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.
46
Section 3
DevOps
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 cambiamento in quanto consapevoli che i cambiamenti sono la causa dei maggiori disservizi. Quindi succede il classico atteggiamento del Puntare il dito: “E’ un problema di Sviluppo”, “ No, è un problema di produzione!”. Questa scena si ripete nel tempo e in molte aziende provocando 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 concordati.
Il problema poi si amplifica notevolmente da due standard emergenti: "
1."
l’agile software development;
"
2."
le infrastrutture basate sul cloud
L’agile software development per sua natura incorpora i cambiamenti 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 figure professionali e gli Stakeholders, ma non riesca a coinvolgere le persone di Operations. La Continuous Integration e il dipartimento di test sono messi come cuscino tra i due dipartimenti. 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 macchine per persona e i cambiamenti di rilasci frequenti rompono completamente tutti gli schemi. 47
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: Configuration Management e Instrastructure as a Code.
Il Configuration Management permette di descrivere lo stato desiderato 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’incremento di piattaforme SAAS e di APIs usate per gestire l’infrastruttura. 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 considerano 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 lavoro. 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 identificare le priorità prima che il progetto parta e aiuta ad identificare gli impedimenti che potrebbero esserci. Una volta che le priorità sono state definite e il lavoro può iniziare, gli sviluppatori assieme alle persone di produzione lavorano affinchè il lavoro sia finito. Questo lavoro permette di trasferire conoscenza e problemi all’interno di tutto il team. Problemi come stabilità, monitoring e backup sono indirizzati immediatamente. Operations ha una migliore comprensione di come funziona l’applicazione prima che l’applicazione venga rilasciata in produzione.
48
Quando diventa complicato, fallo più spesso. Così come negli esercizi, piùi si pratica la messa in esercizio e più si diventa confidenti. Grazie all’automazione, le operations possono introdurre piccoli cambiamenti e aggiungere infrastruttura. Praticando 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 assieme. 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 automatica di rilascio” che estende le fasi nello sviluppo del software. Tutti i cambiamenti a prescindere da sviluppo, instrastruttura 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 reazioni 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 obsolete 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?
49
In un approccio multidiciplina, si ha l’opzione sia di generalizzare che di specializzare o in fondo specializzare i generalisti. Entrambi possono funzionare, ma se si generalizzano gli specialisti 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 comprendere gli impatti ad ampio spettro (orizzontali). In una organizzazione 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 identificarsi 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 lavorando 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 aziende tradizionali.
Il termine DevOps è solo sinonimo di Collaborazione intraziendale.
DevOps può partecipare a far colloquiare anche strutture che hanno deciso di lavorare con CMMI o con ITIL v3. DevOps segue il processo di inspect and adaption e può tenere buoni anche 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 business è un aspetto importante: alcune persone si fermano a pensare 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 estendersi 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 potenziale. 50
Section 4
Continuous Delivery Automazione La “Continuous Delivery” (CD) è un processo automatizzato che permette di rilasciare in produzione nuove versioni di software diminuendo il tempo che intercorre tra la definizione di un'idea da implementare e la disponibilità di un software usabile che la realizza (minimizzazione delle interazioni). In tale processo sono considerate e gestite tutte le fasi e sequenze che garantiscono una corretta pubblicazione di software 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 - creazione, 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 conoscenza dei problemi non appena si verificano, in modo che possano essere risolti il più presto possibile, " 3." Distribuzione continuativa: attraverso un processo completamente automatizzato, è possibile distribuire e rilasciare qualsiasi versione del software in qualsiasi ambiente (Test/ Stage/Prod).
51
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 52
• gestione automatica di feedback (es. mail) dal sistema di CI verso il team
• utilizzare linguaggi di scripting conosciuti ed adeguati che possano essere modificati da tutti i membri del team
• generare il build ed eseguire i test automatici ad ogni modifica committata sul repository
• esternalizzare tutte le fonti di configurazione
• ripristinare immediatamente il corretto comportamento del software ogni qualvolta non passa i test automatici • definire script per la gestione del build indipendente dall'IDE di sviuppo
• gestire e versionare gli script di build/deploy nel repository del codice sorgente • unificare gli script di deploy e gestire l'ambiente come parametro
Database In fase di testing occorre: • automatizzare la verifica e la validazione del software includendo 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 complessità 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
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 storicizzato come tutti gli altri script/sorgenti. Un backup completo, comunque, normalmente è previsto e schedulato con cadenza periodica. 53
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.
54
Section 5
Databases
I Database sul Cloud Recentemente 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 adozione e con un concetto di gestione delle informazioni SemiRelazionale.
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 transazionalità è da demandare al database piuttosto che rimandarla allo sviluppatore inventando concetti e modelli di gestione di transazioni compensative. Effettivamente sta facendo pensare molto la loro presa di posizione, 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 problemi applicativi e sono risolti in maniera non sistematica con interventi applicativi. Una netta separazione architetturale, promuoverebbe questi elementi fondamentali come caratteristiche comuni nella gestione del dato. Quindi se sono comuni, devono allora essere delle funzionalità offerte dalla piattaforma di persistenza e non dall’applicazione 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.
55
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 sviluppo del software, ma nella maggior parte dei casi le loro scelte sono state fatte con motivazione. La motivazione principale era legata alla facilità di uso, alla loro natura di essere interrogati con un approccio restful da Apps e alla capacità di sapersi replicare su una rete geografica in maniera molto agevole. Tutto ciò a discapito di alcuni elementi caratterizzanti le piattaforme di persistenza dei dati o più generalmente chiamati Databases. La transazionalità è uno di questi, così come anche la necessità di dover mettere le informazioni in schemi ben precisi. Nei razionali che si dovrebbero adottare quando si sceglie una piattaforma di persistenza è necessario affrontare dei temi importanti. Temi che riguardano a:
1.
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 geografica (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 persistenza 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 geografica (Internet) e accedervi in maniera restful si adotterà un modello NOSQL “tradizionale” (MongoDB, Redis, etc.)
come evolverà la natura del dato nelle versioni future 56
Se invece abbiamo la necessità di avere dati che vengono trasferiti geograficamente sulla rete dei quali è necessaria la transazionalità e per i quali è anche importante mantenere uno schema, si adotterà un database NEWSQL come Spanner oppure un database NOSQL come Orient-DB. Analizzando l’evoluzione di queste due utlime piattaforme di persistenza, i dati possono sottostare a uno schema. I dati possono essere acceduti con la conoscenza SQL like (SQL per Orient-DB) e cosa molto importante sono garantite le caratteristiche ACID. Questi nuovi database sono focalizzati sulla replica delle informazioni in rete, dove le informazioni possono muoversi. Le repliche 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 ricommettere 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 rivoluzionarie perchè permettono di fare molto con poco e permettono di mantenere livelli qualitativi che solo database di grandi corporate offrono.
57
Copyright
© mondora.com Autori: Daria Vener Davide Morri Francesco Barbera Francesco Manenti Francesco Mondora Marco Rozzati Michele Mondora Roberto Giana
lviii
