La tesi che miro a sostenere è che si può aumentare il potenziale dei nostri progetti se si riesce ad amalgamare la spinta motivazionale del lato irrazionale nell’applicazione metodica del lato razionale ed in particolare dell’’utilità della metafora per sviluppare e sostenere l’emotività di progetto. L’obiettivo dovrebbe essere riuscire ad essere razionalmente emotivi.

Cercherò anche di spingermi oltre, cercando di dimostrare che più i progetti sono complessi  più la cura della parte emozionale è necessaria e non trascurabile: il metodo serve ad incrementare l’efficienza del lavoro mentre il  phatos serve a generare quella spinta motivazionale necessaria ad aumentare “senza sforzo apparente” le performance delle persone (efficacia). Per amore di coerenza cercherò di argomentare la centralità della metafora con l’uso di una metafora: l’ONDA.

Tutti noi, al di la del nostro percorso di crescita e formativo ci siamo imbattuti nel corso della nostra vita  in qualche forma d’onda.  Ad esempio dalle più comuni onde del mare  alle onde sonore, o ancora dalle più misteriose onde elettromagnetiche alle onde gravitazionali (queste ultime tanto misteriose che gli scienziati stessi devono ancora dimostrarne l’esistenza).

Vi chiedo un piccolo sforzo e fare un breve viaggio  a ritroso nel tempo sui libri di fisica per  ricordare che un’onda è caratterizzata da: un’oscillazione periodica, un trasporto di energia e da fenomeni di interferenza. Non voglio tediare nessuno approfondendo concetti  che sarebbero  comunque inutili nel proseguo della diserzione. A noi  interessa soprattutto chiarire il concetto di l’interferenza: l’interferenza è il risultato della sovrapposizione di due onde, che produce un’onda somma.

I due casi limite sono quello di onde completamente in fase, in cui c’è un’interferenza chiamata e “costruttiva”, e quello di onde completamente in contro fase, in cui c’è un’interferenza che si chiama totalmente “distruttiva”. Cerchiamo di fissare questi concetti con la una rappresentazione grafica

L’onda di color rosso rappresenta l’onda somma delle due onde di colore rispettivamente verde e blu. Come si evince abbastanza chiaramente dell’immagine se le due onde sono perfettamente in fase l’onda somma avrà un intensità superiore (esattamente pari alla somma delle intensità) alle due onde singole per cui si dice che si ha un’interferenza costruttiva. Mentre nel secondo caso le due onde non sono in fase e si ottiene un’onda somma la cui intensità è inferiore all’intensità della più intensa delle due onde singole per cui si dice che si ha un’interferenza distruttiva.

Interessante notare comunque come questi due casi estremi diano come risultato una forma d’onda con un andamento regolare. La cosa potrebbe non essere degna di interesse se non fosse che nella pratica è più facile garantire il controllo su fenomeni prevedibili e quindi regolari che nella gestione di  fenomeni con andamenti casuali.

Per i puristi, tengo a chiarire che queste due facce della stessa medaglia e  possono essere utilizzate entrambe a nostro favore. L’interferenza distruttiva non ha sempre un’accezione negativa potrebbe essere una condizione favorevole. Mi spiego meglio se volessi massimizzare un risultato cercherei di sfruttare  l’interferenza costruttiva creando le condizioni per cui le onde lavorino in fase, ma esistono anche situazioni reali in cui potremmo essere interessati a minimizzare un risultato (ad esempio una variabilità di processo) sfruttando le interferenze distruttive.  Una situazione del genere la troviamo nella ingegnerizzazione di processi logistici in cui mira a ridurre la variabilità degli eventi per favorire i processi previsionali e decisionali.

Ma torniamo a noi e caliamo la metafora dell’onda nel contesto che ci interessa.

Partiamo dal caso più semplice: un progetto di sviluppo di un software ad un team di lavoro composto da due persone. Se il lavoro delle due persone genererà due onde in contro fase il risultato sarà nullo indipendentemente dall’intensità e dalla qualità dello sforzo  garantito dai singoli soggetti  ovvero il  risultato sarà il fallimento del progetto indipendentemente dalla bontà delle risorse impiegate. Viceversa se genera due onde perfettamente in fase il risultato sarà eclatante perché l’energia totale di progetto sarà la somma delle energie delle singole persone.

Risulta abbastanza intuitivo comprendere come nel caso di un progetto complesso che coinvolge un team numeroso i rischi del mancato fasamento delle risorse sono pericolosamente alti. La maggior preoccupazione su cui dovremmo incanalare le nostre attenzioni dovrà essere garantire le condizioni affinchè le unità del team rimangano il più possibile in fase per tutta la durata del progetto.

Queste criticità diventano ancor più grandi nella gestione di grandi progetti dove collaborano più persone, appartenenti ad aziende diverse con una scarsa o nulla conoscenza reciproca e magari con l’aggravante dell’impossibilità fisica di lavorare a stretto contatto. Per cercare di mettere in fase il più possibile  tutte queste onde energetiche e massimizzare i risultati sono utili tre cose:

• L’approccio iterativo ovvero suddividere il percorso in piccole tappe con traguardi volanti molto vicini tra loro: questo approccio riduce naturalmente i possibili percorsi alternativi che le persone possono scegliere per raggiungere il traguardo (e quindi aumenta le possibilità che tutti seguano lo stesso percorso o detto  in altro modo rimangano in fase)  e permette inoltre di spostare il traguardo finale qualora durante il percorso emergesse la volontà o la necessità di farlo (che nella mia interpretazione vale a dire che non è necessario porsi dei limiti precostituiti e poter affrontare il progetto con obiettivi molto più sfidanti senza creare una stress di prestazione nei componenti del team)
• Il ruolo del facilitare, una persona dedicata, esterna al team di sviluppo, in grado di poter creare il fasamento delle varie onde;
• L’uso delle metafore: per aiutare il gruppo a scegliere lo stesso percorso anche quando prenderanno delle decisioni individuali  e per fornire un metro di giudizio coerente e non soggettivo nella fase di analisi dei risultati.

Possiamo fare a meno di tutto questo? Almeno fino a quando i risultati vengono sì. Quando non vengono più, c’è bisogno di un salto. Inventare una nuova metafora. E solo chi ha la mente abbastanza aperta può dedicarsi a questo.

La EFFE ha l’obiettivo di aiutare i componenti del gruppo a rimanere in Fase parola che guarda caso inizia proprio per F.  Per tutti è chiaro la nostra metafora è

LAVORARE IN Fase ovvero produrre un prodotto EasyFastFancyEfficient

Il team Team Ballo ha ora una lettera in cura:

la EFFE.

Una lettera che rappresenta la qualità di un proprio elaborato.

Easy, Fast, Fancy, Efficient

Con questo statement ci ricolleghiamo a delle note pervenute da un cliente e che integriamo nella nostra Definition Of Done.

Easy

Facile da utilizzare, facile da esercire e anche facile da manutenere e programmare. Il primo obiettivo è il riuscire a incorporare la facilità in ciò che viene prodotto. Un esercizio che viene fatto di continuo e che è molto legato alla semplificazione. Più una soluzione è semplice e più è facile da implementare. Sembra una asserzione scontata, ma nel quotidiano risulta una delle qualità più difficili da raggiungere.

Nello sviluppo del software Easy vale la possibilità di poter comunicare agilmente il lavoro fatto, una architettura o altro. L’identificarsi con una metafora potrebbe essere una strada per riuscire a colmare questa caratteristica.

Invece nella fruizione, Easy è molto legato al modo con il quale l’utente andrà ad utilizzare la piattaforma software. Cicli di interaction design sono necessari per riuscire a costruire un sistema che sia facile da utilizzare.

Fast

La velocità di erogazione del sistema così come la velocità nello sviluppo delle singole funzionalità sono delle caratteristiche ben apprezzate. Lavorare con il Fast in testa, significa pensare a un sistema che sia il più possibile automatico e che possa essere posto in esercizio nell’ordine dei minuti, se non dei secondi. Fast nello sviluppo del software riprende tutte le pratiche di XP che coinvolgono la Continuous Integration e lo Unit Testing. Implica una qualità del codice che migliori sempre di più e che rapidamente permetta a tutta l’infrastruttura software di adattarsi alle nuove caratteristiche.

Fancy

L’occhio vuole la sua parte e non è solo una parte estetica. Adottando XP nello sviluppo del software si fa molto refactoring e si fa molta code inspection. I nomi delle classi, dei metodi e delle funzioni sono identificati proprio con un criterio auto-esplicativo. Nel verso opposto l’approccio allo sviluppo con i metodi agili adotta una strategia di back casting: parto dal punto di arrivo per capire il prossimo passo. Il punto di arrivo in questo caso è avere una interfaccia utente che sia aggraziata e sufficiente; le prime attività sono quelle quindi di lavorare già a questo criterio progettando una interfaccia utente che sia anche lei gradevole come il resto della applicazione.

Efficient

L’efficienza nel paradigma della EFFE è la capacità di saper rispondere nel tempo corretto. Dal punto di vista della infrastruttura informativa l’efficienza di lega all’esercizio dell’applicazione stessa. Si misurano i Key Performance Indicators e si garantiscono i Service Level Agreement tramite una policy di service level assurance dove quasi in maniera adattiva l’applicazione si adegua ai carichi utente.

Per quanto riguarda invece il processo l’efficienza si misura nella capacità di adattare il prodotto a un set di requisiti non stabili e rendere il processo di sviluppo sempre al livello adeguato anche quando le condizioni al contorno non sono molto chiare. Con questo si riesce ad affrontare una Change Request oppure si riesce a far si che il gruppo di lavoro aiuti nella definizione di alcune specifiche mettendoci del contributo.

Queste 4 nuove qualità entrano nella Definition Of Done (DOD) e vanno ad incrementare maggiormente la qualità del software prodotto. Alla fine di ogni attività ogni persona all’interno del Team Ballo risponderà di quanto è Easy, Fast, Fancy e Efficient. Un razionale per ognuna di queste parole è sufficiente per continuare nella strada della qualità continua.

Con il cloud computing abbiamo a disposizione un meccanismo simile e possiamo pensare di stabilire un modello simile anche nella propria offerta.

Si evitano così i costi d’avvio dell’acquisto e installazione di server e apparecchiature di rete ed i costi di manutenzione e gestione hardware e software. Ottenendo un’infrastruttura IT ad altissimo livello e senza limitazioni, pagando solo il consumo effettivo.

Tipicamente le tipologie di servizi offerti sono:

1. Applicazioni (SaaS)
2. Piattaforme (PaaS)
3. Infrastrutture (IaaS)

di cui l’utente finale può usufruire, ovunque in qualunque momento e da qualsiasi dispositivo. Tutte e tre le soluzioni sono pensate per essere strutturalmente scalabili e in grado di fornire un “servizio” misurabile di elevata qualità.

In quest’ottica l’adozione di una soluzione IaaS su una infrastruttura elastica rende reale la semplificazione del processo di sviluppo delle applicazioni senza incorrere però nei problemi di costo e complessità legati all’acquisto ed alla gestione dello strato hardware/software sottostante. I vantaggi per l’azienda dunque sono essenzialmente legati all’incremento della produttività ed alla riduzione dei costi operativi:

Il Time to Market è ridotto con conseguente possibilità di “monetizzare” l’applicazione in tempi più brevi.
Non sono richiesti investimenti iniziali, oltre a quello per la sottoscrizione del contratto di servizio, e conseguentemente sono ridotti i costi operativi.
Viene accelerato il processo di sviluppo, favorendo lo scambio di informazioni e la condivsione di know-how e mettendo a disposizione strumenti di sviluppo collaborativo: è questa una caratteristica essenziale nello sviluppo “collegiale” di un’applicazione

Inoltre la possibilità di integrazione con servizi web garantisce agli sviluppatori di non avere limiti nella customizzazione delle proprie applicazioni, così come non ci sono limiti per la fruizione delle stesse.

Il paradigma del PAAS

Il paradigma del Platform as a Service permette di poter offrire una piattaforma secondo il modello as a service. Il bacino di utenti che utilizza una piattaforma PaaS è quello delle aziende che hanno bisogno di integrare un sistema e vogliono aggredire un mercato nuovo: quello della facilità di estensione da terzi del proprio sistema.

In una visione moderna, le architetture al tendere considerano il fatto che la soluzione software sarà a sua volta erogata anche come Platform as a Service e che sarà estesa da una comunità di integratori.

In questo modo la tecnologia sottostante permetterà agevolmente di offrire il sistema a terzi con politiche diverse e con una unica capacità di gestione. La possibilità di offrire la propria infrastruttura software come un servizio permette di estendere la propria soluzione verso partner o integratori in grado di dar maggior valore ai propri servizi.

Per esempio ci possono essere dei partner che stanno studiando delle nuove forme di comunicazione tramite l’ultima device – e.g. Google Glasses – e che vogliono inserire tale soluzione nell’ecosistema applicativo.

Avere i propri servizi erogati secondo il modello PaaS permette di configurare dei nuovi scenari di business con i propri fornitori e stabilire dei nuovi modi di collaborazione (es. revenue sharing).

Questo modello di lavoro evolve l’idea che si ha dei framework dello sviluppo rispetto alle piattaorme ed è il punto cruciale in cui i nostri architetti stanno continuamente lavorando per dare maggior beneficio ai nostri clienti.

Recentemente ho avuto il piacere di ascoltare Joseph Pelrine, il quale mi ha dato modo di fermarmi a riflettere su che cosa significa realmente implementare Scrum.

Ogni tanto mi capita di parlare con persone diverse sulle tematiche Agile e di Scrum, ed è molto interessante osservare che cosa né viene fuori; qualche giorno fa mi sono anche sentito dire: “ma Scrum non è quella cosa dove una volta al giorno vai dagli sviluppatori a rompere le palle per sapere cosa hanno fatto?”.

Mi rendo conto che parlando di Scrum le cose che vengono a galla sono le practices quali il Daily Scrum, il Backlog, lo Sprint Planning Meeting, il Burndown, ecc., forse perché sono le cose più evidenti e semplici da capire, ma in realtà c’è ben altro.

Nella rappresentazione di Joseph possiamo vedere Scrum come un grande albero: le practices sono i rami dell’albero, che se è sano e rigoglioso produce dei frutti che sono i risultati, come la delivery on time e la soddisfazione del cliente. Ma i rami saranno robusti solo in caso di un tronco solido, che è rappresentato da core principles che guidano il processo. Ancora più in basso, il tronco può crescere retto e robusto solo se ci sono delle radici profonde e ben piantate, e queste sono rappresentate dai values di base propri del mindset Agile.

Commitment (inteso come impegno e responsabilità), Focus, Rispetto, Coraggio (nel cambiamento) e Trasparenza, questi sono i 5 valori fondamentali che devono essere nel cuore di un ambiente e una realtà che vuole essere Agile e implementare al meglio Scrum. Sono valori ben visibili durante l’intero processo e nelle practices originali. Senza anche uno di questi elementi l’intero processo risulta compromesso e anche l’albero non può crescere retto.

Ispirati questi valori sono una serie di principi madre che devono essere sempre presi in considerazione, e che rappresentano il motore fondamentale delle nostre azioni.

Avere feedback rapidi: quando vorresti sapere che hai problemi?

Apprendimento continuo: noi impariamo dai nostri errori, l’importante è dunque riconoscerli e agire per evitarli di nuovo.

Conoscere il proprio potenziale: quanto possiamo e riusciamo a dare?

Solo chi ha un rischio diretto può ed è in grado di prendere decisioni.

Fermarsi a ragionare sul significato delle cose: che cosa sto facendo, e perché?

Divertirsi: l’entusiasmo è il motore che ci porta avanti nella giornata lavorativa.

Da questi valori e da questi principi, nascono le note e comuni practices adottate dal framework Scrum, ma che possono e devono essere sempre contestualizzate ed editate per rispondere alle necessità di ogni realtà. Adottarle e seguirle alla lettera per come si è letto su un libro, probabilmente porta solo a disagio e frutti acerbi.

Quindi solo partendo dalle radici si può vedere la crescita dell’albero e infine comprendere cosa realmente è Scrum e cosa non lo è.

Questo è un tema molto attuale se si pensa al trend che sempre di più si può osservare sul mercato: in origine, e mano a mano che Scrum andava affermandosi, le persone lo approcciavano perché volevano apportare un cambiamento e un miglioramento al processo, mentre oggi sempre di più le persone si approcciano a Scrum perché devono, sotto indicazione del management, apportare un miglioramento.

Perciò ultimamente le persone che implementano Scrum si fermano e concentrano sulle practices da adottare, dimenticando di far crescere un albero solido che porta i frutti.

Con questo voglio aprire una possibilità di mitigare Scrum con Kanban e la gestione del tempo con la tecnica del Pomodoro. Così da avere un tamburo che ritma e scandisce, così come nella canoa, anche la giornata di un team.

In questo caso il tamburo è un pomodoro timer che passa da divenire un pomodoro individuale o di coppia a un vero metronomo di gruppo.  In Scrum oltre al Daily Scrum è difficile avere una idea chiara della gestione del tempo nei termini di cosa succede durante la giornata e della concentrazione nell’ordine delle prossime ore. Tutto è lasciato alla capacità di organizzazione della coppia o del singolo e alcune tecniche come GTD o la tecnica del Pomodoro sono di grande aiuto per riuscire a rimanere focalizzati.

Nell’idea iniziale lo stream giornaliero è comandato dallo sprint backlog che è comandato dalla user story o dall’obiettivo che si vuole realizzare. I singoli task sono a loro volta della kanban card e sono stimati a pomodori rimanenti per completare il task.

Ogni mattina il team decide su cosa lavorare e seleziona quali task crede di lavorare. Ad ogni task sono associati un numero di Remaining Pomodoro e si sa quanto potersi allocare proprio dalla propria esperienza.

Nel momento in cui si parte il timer inizia a battere il ritmo di tutti. Allo stesso modo di come si fa sulle canoe con molti vogatori. Chi non ha preso il ritmo aspetta il prossimo pomodoro, non dichiarando che è partito (il tasto play del team) e chi non riesce perchè è stanco o ha ricevuto un interrupt clicca il tasto pause o stop sempre del suo team.

Abbiamo intenzione di elaborare l’idea in un prodotto con licenza Open Source per poi erogarlo come servizio e il progetto è in via di definizione; in questo momento stiamo iniziando a raccogliere gli obiettivi e definire le prime user stories. La tecnologia di riferimento sarà, fino a decisione contraria,  Meteor e ci si muoverà intensivamente sempre più verso html5.

Perchè questo post?

Cerchiamo contribuzioni e idee. Anche solo la votazione del nome e del logo per iniziare ad indossare la maglietta e sentirlo un po’ più nostro.

Se ti senti potenzialmente motivato e vuoi/puoi contribuire in questa attività, le figure professionali che ci mancano variano dall’interaction designer, al webdesigner, al programmatore software, al sistemista che conosca DevOps fino alla figura che sa ipotizzare una service offering line.

Negli step di lavoro che stiamo pensando c’è l’idea di costruire il primo prototipo, e poi di valutare di lanciarlo su una piattaforma come indiegogo o kickstarter e poi, nel frattempo iniziare a lavorarci sopra con il nostro abituale taglio professionale.

Se vuoi partecipare o essere informato in questo progetto

Subscribe to our newsletter

In una discussione con un gruppo di architetti riguardo a come si devono documentare le architetture abbiamo convenuto al fatto che la documentazione di una architettura deve essere ridotta all’essenziale. Ma i problemi delle architetture moderne sono in contraddizione con il fatto che la documentazione possa essere ridotta all’osso e arrivare all’essenziale. Ci sono tematiche nuove sulle quali è necessario spendere tempo e fare dei ragionamenti approfonditi che richiedono poi una rappresentazione anche formale su dei documenti. Per esempio progettare un sistema che sia multi tenance non è facile, è una decisione che può impattare le architetture logiche e le architetture fisiche (sempre che sul cloud si possa parlare ancora di architetture fisiche).

Delle nuove rappresentazioni si manifestano ed è importante capire come fare a far si che le decisioni prese riescano a dare con il minor numero delle informazioni la maggior conoscenza della architettura. E’ necessario per far questo lasciare perdere alcuni pregiudizi e sperimentare delle nuove forme comunicative anche in ambienti strettamente professionali.

Un po’ come quando un bambino apprende che considera tutto quello che arriva come nuovo e interessante e prova a digerire ciò che gli viene esposto in maniera sintetica e precisa. Quando apprendiamo qualcosa di nuovo, cerchiamo di sintetizzarlo e di riuscire a comprendere tutte le parti che riteniamo più importanti. Solo in un secondo momento si può andare a collegare ciò che abbiamo appreso con ciò che abbiamo già conosciuto creandone dei nessi e quindi dei pensieri nuovi.

Il valore di una metafora posiziona proprio questo pensiero dove le analogie servono per portare alla immaginazione dei concetti che risulterebbero difficili da interpretare. I componenti architetturali generalmente sono denominati con degli acronimi e nella vita mi è capitato di sentirne molti.

Discorsi come l’SDP parla con il Triplo A (AAA) per la risoluzione dell’MSISDN sono tra architetti software normali in contesti specifici.

Ma cosa succede quando si cerca di spiegare a un nuovo collega un prodotto nelle sue logiche di funzionamento basilari. Sebbene un dizionario dati con degli acronimi ben definiti, l’interlocutore capirà proprio poco di quello che gli si cerca di spiegare in quanto è tutto è per lui astratto. Oltre ai processi anche i nomi sono astratti e nella astrazione la sua fantasia non può correre e cercare di collegare dei nessi. Si può osservare il suo sguardo che seppur attento, ci comunica quanto non comprenda ciò che stiamo passando.

La curva di apprendimento è sempre elevata e solo quando lui ha già familiarità con una situazione simile succede che la sua comprensione sia davvero migliore. Ci si rendo conto dalla propositività dei suoi commenti e nel momento in cui si comunica lo sforzo più grande che faccio non è nella bocca, ma nelle orecchie e negli occhi se sto dialogando. C’è bisogno di raccogliere i feedback per capire il livello di comunicazione a adeguare continuamente alla comprensione.

Per questo una metafora gioca un ruolo essenziale e vorrei dire, quasi vitale nella progettazione di una architettura software. Si parte con identificare dei componenti, ma assieme si cerca di capire una analogia nel mondo vissuto quotidianamente per riportare a terra l’astrazione del modello.

La metafora permette di fare delle considerazioni aggiuntive. Siccome facilita il livello di comprensione di un problema, permette anche di capire come una offerta di prodotto può evolvere. Questo può includere diversi uffici tra cui il marketing che può pensare delle offerte diverse per la soluzione proprio studiando l’analogia.

Dall’altra parte, l’inabilità di trovare una metafora consistente fa pensare a dei possibili problemi in una architettura. E’ utile spezzare in piccole altre metafore le parti di componenti di un sistema che può essere pensato in maniera coesa.

L’analogia si rivela uno strumento davvero importante se adottata. L’adozione richiede certe volte coraggio nel giustificare e spendere del tempo per ritrovare la metafora.

Nella documentazione, a questo punto, ci sarà una spiegazione che narra la parte del componente specifico rispetto alla metafora.

Anche le architetture software affrontano questo percorso, ed è molto interessante andare a scovare le costanti che la comunità tiene ferme ad ogni giro di ruota.

Se si torna un po’ indietro nel tempo, agli albori del J2EE la comunità inseguiva il concetto di “componenti” java che potessero essere riutilizzabili: vennero così definite le specifiche per gli Enterprise Java Beans (EJB), ovvero dei bean accessibili sia localmente che da remoto. Il concetto alla base era quello di fornire dei mattoncini Lego che potessero comporre facilmente e rapidamente una costruzione complessa. Ma il fallimento di questo tipo di architettura basata sui componenti EJB è stato presto decretato da diversi fattori pratici, come l’ingestibilità del modello di programmazione che sta alla base, la grossa difficoltà a scalare visto l’ancoramento a dei server middleware, e infine gli insidiosi ostacoli nel deployment di queste applicazioni.

SpringSource intervenne creando un modello in cui i vari pezzi dell’applicazione diventano POJOs (Plain Old Java Objects) iniettati nell’applicazione, in modo da alleggerire e migliorare il processo di sviluppo-test-deploy. Nonostante il grosso passo avanti, questa architettura composta da componenti POJO, si è trovata di fronte a diversi limiti dovuti principalmente dalla difficoltà di isolamento dei vari pezzi, di integrazione di tecnologie o linguaggi differenti, e ancora di scalabilità ostacolata dall’ammontare di componenti che vanno ad aggiungersi uno sopra l’altro.

Avvicinandoci ai giorni nostri, si può osservare la crescita vertiginosa del paradigma SOA (Service Oriented Architecture) che prevede il partizionamento di componenti che possono essere richiamati da diversi sistemi e che prendono il nome di servizi. Questo tipo di architettura ha ricevuto una forte spinta all’interno della comunità anche grazie al diffondersi dell’utilizzo di protocolli web service come SOAP e modelli di design REST. La SOA però rimane un paradigma, un mindset che per molti rimane solo concettuale e difficilmente implementabile.

Ma è da questo paradigma che nasce il modello più evoluto e seguito dalla comunità attuale, che risponde al nome di Cloud Computing, che, seguendo il concetto SOA, porta alla definizione di componenti “as a service”, in modo da comporre un’architettura rappresentabile come segue.

Ci sono diversi benefici nell’adottare un’architettura Cloud, tra i quali sicuramente la scalabilità favorita dalla natura di servizi leggeri ed indipendenti che non impattano nell’architettura generale dell’applicazione. I componenti cloud possono essere aggregati rapidamente anche grazie all’utilizzo di API RESTful che accordano anche tecnologie e linguaggi differenti. Senza contare i temi legati alla semplicità di deployment che porta il partizionamento dei componenti, il miglioramento degli aspetti di sicurezza e la malleabilità nella gestione dei costi.

Ripercorrendo questa strada evolutiva, si ritrovano facilmente quelle costanti che la comunità da sempre cerca di ottenere: la modularità dei componenti in modo da favorirne il riutilizzo, la scalabilità di questi permettendo alle applicazioni di crescere e dare sempre più valore aggiunto, e infine la semplicità di un modello di programmazione che non generi o aumenti l’entropia di un sistema.

Queste qualità si possono ritrovare nel modello che si definisce Cloud, e che rappresenta al giorno d’oggi l’ultimo gradino nella scala evolutiva delle architetture software.

Per le nostre sedi (Milano, Morbegno in Valtellina) e non, stiamo sempre cercando nuove persone che vogliano entrare a far parte del nostro team. Le nostre caratteristiche sono sempre orientate alla modernità tecnologica e alla agilità.

Qualsiasi forma geniale è apprezzata, ci piace molto la creatività e il modo con il quale  affrontare le situazioni. E’ per questo che anche la ricerca del personale la facciamo nei modi più diversi. In questo caso abbiamo predisposto solo una sandbox. L’unico vincolo è che il file non sia più grande di 3Mb.

Ti chiediamo di risolvere l’esercizio, se sei in grado e se non riesci ammettiamo valutiamo anche chi si distingua in altri modi.

Pertanto è necessaria una propria presentazione, oltre che a mettere l’eventuale soluzione dell’esercizio in un file e fare upload proprio qui sotto. Potrebbe essere un video che ti presenta, il tuo curriculum normale oppure qualsiasi altra cosa tu voglia usare per distinguerti.

Se fai l’esercizio, questo è un esercizio di virtuosismo e porta a verificare le proprie conoscenze e a capire il proprio livello di capacità di soluzione dei problemi. Se non riesci non è un problema, puoi sempre rilanciare la posta e aggiungere tu un esercizio che vuoi venga risolto.

La tecnologia è un di per cui e la nostra implementazione classica è in java. E nel file di assegnazione che si scarica ci sono delle istruzioni dentro a index.html che raccontano cosa fare.

Lo scopo è quello di far fare ad una classe java, un comportamento diverso da quello che si legge nel codice. La classe è un automobile “Carolina” che è in grado di accelerare fino al suo limite. Se vai oltre il limite, quella si resetta alla velocità zero.Il tuo compito, da Gino Pilotino è quello di mandarla oltre il limite cablato.

Non è ammesso cambiare il sorgente della classe Carolina, quello del pilotino puoi fare quel che vuoi; ho fornito solo un esempio ( non di soluzione ma di codice ).

Per fare l’upload dell’esercizio abilitare qui sotto la maschera di upload con  la parola segreta hireme e poi fare l’upload nel box che si presenta.

Per scaricare l’esercizio clicca sull’immagine.

Nella mia permanenza in azienda uno degli aspetti che piu mi interessano e da cui imparo di più sono  i vari corsi che tengo in giro per l’Italia. La scorsa settimana ad esempio ho tenuto un corso base di sviluppo di applicazioni sul sistema operativo Android; il training è durato cinque giorni ed ha coperto un’ampia serie di argomenti piu o meno complessi. Nella preparazione ho cercato di elaborare materiale su un vasto numero di argomenti in modo da coprire tutti gli argomenti di interesse. Il numero dei partecipanti era abbastanza elevato, 14 persone, la maggiorparte con una buona conoscenza di Java e, tranne in due casi, con nessuna esperienze gia maturata nello sviluppo su Android. La dimestichezza con Java era l’unico requistito che avevo richiesto ai partecipanti in quanto è il linguaggio principale con cui vengono sviluppate le applicazioni. Personalmente questo era il terzo corso che tenevo sull’argomento, i temi trattati non erano gli stessi che mi erano stati richiesti negli altri interventi, quindi ho dovuto redarre nuovo materiale per una buona metà del corso. Invece per quanto riguarda l’esperienza come sviluppatore su piattaforma Android questa si riassume nello sviluppo di  conversioni di web application direttamente su applicazioni Android. Come organizzazione generale delle tempo ho preferito iniziare la giornata con una parte teorica per continuare nel pomeriggio con una sezione pratica composta da esempi ed esercizi da svolgere insieme ai partecipante o da far svolgere in maniere autonoma. Questa suddivisione mi ha permesso di mantenere il corso interessante e mai troppo pesante e noioso per il mio pubblico. In questo senso l’omogeneità delle skills dei partecipanti e in generale il loro interesse all’argomento mi hanno permesso di dipanare senza particolari problemi tutte le sezioni che avevo preparato e di confermarne l’apprendimento grazie alle esercitazioni svolte nel pomeriggio. Sin dal primo giorno ho stabilito un buon rapporto con i partecipanti, definendo da subito qualli argomenti avrei trattato e quali argomenti fossero per loro di maggior interesse. In particolare ho definito un elenco di temi facendomeli suggerire e indirizzando le richieste concentrandole sui soggetti che avevo già preparato. I cinque giorni sono passati abbastanza velocemente: grazie alla vastità dell’argomento trattato (il sitema operativo Android e lo sviluppo di applicazioni per esso è un argomento veramente ampio) non mi sono dovuto soffermare su nessun tema in particolare riuscendo a presentare ogni sezione in modo semplice e soprattutto riuscendo a realizzare esempi ed esercizi sempre brevi e semplici nella comprensione. Se mi fossi addentrato troppo in un singolo argomento avrei corso sicuramente due rischi, il primo è un ovviamente un eccessiva perdita di tempo e il secondo è una difficoltà magiore nello spiegare concetti più complessi e meno lineari, e di conseguenza un calo nell’attenzione dei partecipanti. Al termine della settimana le reazioni del cliente sono state buone, tutti i partecipanti hanno espresso un giudizio positivo sulla metodologia utilizzata nell’esporre gli argomenti e nel complesso i concetti fondamentali che è voluto passare sono stati recepiti ed integrati. Com’è ovvio ci sono state anche delle critiche, ad esempio due argomenti che ho esposto erano più inerenti al mondo Java che all’ambiente Android, e quindi sono risultati un po’ noiosi e ripetitivi, soprattutto per un pubblico che è abitutato a lavorare quotidianamente in questi ambiti. La soluzione nel mio caso è stata quella di trattare in modo veloce queste sezioni senza soffermarmi troppo. Posso a questo punto delineare dei lati positivi e alcuni aspetti da approfondire per i futuri training: di buono c’è sicuramente la divisione della giornata in una prima parte teorica e una seconda parte pratica. In più lo svolgere esercizi sugli argomenti trattati la mattina permette di cofermare l’apprendimento e fissare i concetti chiave nella mente. Durante lo svolgimento delle esercitazioni e quindi nella messa in pratica della teoria appresa sono giustamente sorti anche dubbi e domande che hanno portato i partecipanti ad una maggior comprensione dell’argomento. Da migliorare invece c’è la conoscenza del pubblico al quale vado ad esporre i temi, con particolare riguardo alle skills individuali e una definizione ancora più precisa degli argomenti da trattare in modo da andare a coprire in maniera puntuale le richieste del cliente.

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 appunto 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 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 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.