HAPPY CONTINUOS DELIVERY

HAPPY CONTINUOS DELIVERY

PARLIAMO DI E-DEMOCRACY

PARLIAMO DI E-DEMOCRACY

Parole del secolo scorso sembrano quanto mai attuali, scriveva così Adriano Olivetti nel suo saggio del 1949 intitolato Democrazia senza partiti: “All’alba di un mondo che speravamo nuovo, in un tempo difficile e duro, molte illusioni sono cadute, molte occasioni sfuggite perché i nostri legislatori hanno guardato al passato e hanno mancato di coerenza o di coraggio. L’Italia procede ancora nel compromesso, nei vecchi sistemi del trasformismo politico, del potere burocratico, delle grandi promesse, dei grandi piani e delle modeste realizzazioni.
Riconosciamo francamente una mancanza di idee, una carenza di uomini, una crisi di partiti.”.
Continua Olivetti: ”Nel primo dopoguerra, aveva allora 18 anni, Piero Gobetti così descriveva la stessa gravissima situazione: «Gli schemi in cui si svolge la vita politica nostra (i partiti) non consentono agli uomini sufficiente vitalità. Gli uomini cercano, nella vita pratica, realtà ideali concrete che comprendano i loro bisogni e le loro esigenze. Oggi i partiti si sono limitati a formule vaste e imprecise, da cui nulla si può logicamente e chiaramente dedurre. [...] Nella vita attuale dei partiti di concreto c’è solo un circolo pernicioso per cui gli uomini rovinano i partiti, e i partiti non aiutano il progresso degli uomini. [...] Le idee, insomma, in cui le forze si inquadrano, i partiti, sono rimasti addietro di un secolo. E gli uomini ci stanno a disagio. La storia va innanzi: gli uomini con essa. Gli schemi non possono restare gli stessi. Se non si liquidano, se rimangono, vanno soggetti nella pratica realtà alla deformazione che su di essi operano i singoli, favoriscono la disorganizzazione, la confusione, essi che per organizzare e sistemare erano sorti»”.

Facebook non basta più, o forse non è mai bastato (tranne le dovute ed eclatanti eccezioni), ma come tutti gli strumenti che dischiudono una strada nuova, è un elemento ormai imprescindibile per la maggioranza dei cittadini virtuali abitatori del web.

Ritengo che molti utenti animatori di Facebook si siano resi conto dei limiti del social network per antonomasia e siano altresì frustrati e stufi di riversare fiumi di parole su bacheche sterminate, senza tuttavia vedere la propria voce aggregarsi in una proposta condivisa che abbia la forza di travalicare il mondo della realtà virtuale per produrre un risultato socialmente rilevante, proprio laddove ci siano delle resistenze al cambiamento.
Le alternative sorte negli ultimi anni, che mirano ad innovare i meccanismi di sublimazione della conoscenza a partire dalla cosiddetta intelligenza collettiva, sono molti: progetti assimilabili (a vari livelli di attinenza, diffusione e sviluppo) al calderone della E-partecipation o in altri termini al concetto di piattaforma per la costruzione collaborativa di proposte di soluzione ai problemi più disparati, sono per esempio Liquid Feedback (Germania), Nation Builder (Usa), Ocopomo (consorzio EU), Senador Virtual (Cile), Loomio (Nuova Zelanda), Parlamento elettronico, Open Dcn, Vilfredo, ARS E-democracy, Airesis (questi ultimi nati in Italia), ADI! (parlamento vasco), E-democracia (Brasile), Adhocracy (Germania), Bungeni (continente africano), Your Priorities (Islanda), Ideascale (USA), ed altri ancora.

l’implementazione dell’algoritmo di Shulze nel contesto delle votazione a soluzioni multipla, un sistema utilizzato anche da Liquid Feedback, che consente attraverso le preferenze di determinare la soluzione maggiormente gradita (o meno sgradita) dai votanti, superando i limiti di altri sistemi che pure oggi godono di maggior fama e diffusione.

Quali sono ad oggi le sfide della E-democracy ? Moltissime e ancora aperte.

Citerò un breve elenco non esaustivo, con l’itento di fornire una panoramica propedeutica a stimolare l’indagine e l’approfondimento personali:

* la certificazione delle identità dei partecipanti ed il valore legale delle votazioni online: rappresentano due fattori imprescindibili al fine di determinare un’effettiva integrazione della E-democracy nei processi istituzionali. L’attribuzione di un valore giuridicamente attendibile alle identità presenti sulle varie piattaforme, così come ai voti espressi dagli utenti medesimi, dovrà con ogni probabilità passare per l’adozione di tecnologie e strumenti già esistenti e riconosciuti dalle normative vigenti, italiane ed internazionali, andando a prevedere l’uso di certificati digitali qualificati e l’intermediazione di Certification Authorities accreditate, che svolgano pertanto la funzione di garanzia e attendibilità sufficienti a che le istituzioni possano permettersi di considerarle, accoglierle ed eventualmente svilupparle e realizzarle. Il principio guida dev’essere: “Giochiamo secondo le regole e da queste ricaviamone forza, credibilità, attendibilità”. Nessuna certificazione degli utenti o delle votazioni realizzata senza conformità agli strumenti ed alle regole previste dalle normative potrà mai andare oltre il mero accordo tra gruppi privati (che quasi certamente potrebbero disconoscere le delibere di altri gruppi con cui sono in competizione...), fatta salva la possibilità di adeguare le normative a strumenti e tecnologie per ora non contemplati.

* la facilitazione implica onestà intellettuale nell’integrare opinioni e contributi divergenti dai propri, sensibilità e capacità di ascolto di chi espone un punto di vista diverso, competenza e cultura specifiche rispetto al tema per il quale ci si è proposti in qualità di redattore, proprietà di linguaggio e di comprensione del testo tali da consentire la redazione di sintesi fedeli al pensiero di tutti i partecipanti, evitando le distorsioni generate da un’arbitraria e deleteria reinterpretazione dei contenuti altrui.

Questo punto rappresenta una criticità potenzialmente enorme in un processo di redazione di una proposta che si possa considerare attendibile ed efficace.

Se tali caratteristiche vengono a mancare, la sintesi della proposta non sarà democraticamente rappresentativa di tutti i punti di vista emersi durante la discussione e, di conseguenza, il raggiungimento di una delibera ne dovrebbe risultare compromesso, anche se ciò non è sempre vero.

Quando invece questi requisiti umani e culturali vengono soddisfatti e confluiscono nel redattore modello o in un gruppo di redattori affiatati, sensibili, rispettosi e competenti, il miracolo dell’intelligenza collettiva e della deliberazione consensuale si manifesta in tutto il suo splendore.

* il coinvolgimento degli stakeholders per il giusto ambito: questo punto implica l’ideazione di un flusso di discussione che garantisca o quantomeno attribuisca un valore ponderato, riferibile al grado di partecipazione di tutti gli stakeholders (soggetti interessati al problema o coinvolti a livello di impatto e quindi di conseguenze da esso derivanti). Entrano qui in gioco fattori piuttosto difficili da gestire come la tutela delle minoranze e la determinazione dell’insieme di cittadini da coinvolgere (il criterio dell’area geografica e dell’iscrizione anagrafica riferita al territorio di competenza giuridico-istituzionale, non è sufficiente, basti pensare alla problematica inerente l’ipotetica realizzazione di un inceneritore con annessa discarica entro il confine territoriale di competenza del comune X, ma con impatto sui comuni limitrofi o potenzialmente su territori ancora più vasti).

* L’attribuzione di un peso matematico differente ai voti espressi dagli aventi diritto (il dilemma “dell’uno vale uno”), sulla base di vari fattori quali la competenza rispetto al tema in esame, il livello d’impatto delle conseguenze sui vari stakeholders, l’area geografica di appartenenza, la presenza o meno di un livello di voto delegato ad altre persone. Anche qui risulta evidente che le sfide filosofiche, prim’ancora che matematiche, sociologiche e giuridiche, non manchino.

* La gestione della competenza e della reputazione degli utenti: tutti non possono parlare di tutto con lo stesso livello di attendibilità, la competenza rispetto a tematiche o branche della conoscenza andrebbe certificata o quantomeno collegialmente attribuita e documentata? La meritocrazia dovrebbe essere un criterio ammissibile (o auspicabile) per l’individuazione degli utenti maggiormente capaci nel redigere la sintesi delle proposte, quelli che si dimostrano capaci di rispettare e rappresentare le voci di tutti ? Come determinare algoritmi il più possibile equi ed al contempo incentivanti secondo i criteri della gamification ? E’ filosoficamente ammissibile un modello deliberativo basato sulla merito-democrazia ?

* L’interfacciamento con le istituzioni: questo è un altro punto focale che porta con sè molte sfide legate per esempio agli Open e Big Data, questioni d’interoperabilità e di sicurezza strettamente informatiche, necessità di adozione di protocolli di drafting normativo (es. akomantoso) per l’interazione con gli organi istituzionali, la necessità di porsi come soggetti superpartes, rispetto alla scena politica di riferimento, e di risultare credibili e in grado di fornire adeguati e garantiti livelli di servizio.

* Il ruolo effettivo della E-democracy nel contesto degli organi istituzionali esistenti: Può davvero la democrazia partecipativa online sostituirsi a Camere e Parlamenti ? E’ auspicabile che lo faccia ? Sarebbe un modello migliore o peggiore dell’esistente ? Può agire con potere consultivo e propositivo ma cosa fare nel caso le sue deliberazioni provenissero da una minoranza dei cittadini aventi diritto di voto in quel contesto ? La E-democracy può agire in affiancamento paritetico o in regime di subalternità rispetto agli organi istituzionali rappresentativi ?

* Il problema della tracciabilità degli esiti delle deliberazioni e delle votazioni online: occorre prevedere degli strumenti che consentano di gestire il project planning e il project management delle proposte, andando a dettagliare chi deve fare cosa, a quale prezzo, entro quali tempi, ecc. creando così uno strumento operativo e d’informazione che coinvolga i cittadini e gli enti privati così come le istituzioni, dialogando su un terreno comune costituito da normali e consolidati criteri di gestione d’impresa ma affini anche alla gestione di una semplice economia domestica.

Occorre anche rendere tracciabili le votazioni effettuate implementando un meccanismo di auditable voting e garantire poi l’autenticità (del votante rispetto al voto), la non alterabilità (dell’azione di voto rispetto alle preferenze espresse) e il non ripudio (la possibilità di disconoscere il voto dopo averlo “firmato” e autenticato). L’operazione di auditing dovrebbe essere accessibile potenzialmente a tutti gli utenti per tutti i voti riferibili ad una sessione di votazione considerata.

* Il problema della gestione dei problemi complessi: se immaginiamo di dover discutere il rinnovamento di un’area pubblica degradata, diciamo per esempio un quartiere, risulta evidente che il problema, per poter essere trattato in modo adeguato, dovrà essere scomposto in sottoproblemi (e relative sottoproposte di soluzione come per es. costruire un parco pubblico, una scuola, un’area giochi per i bambini ed una per i cani, ecc.) mentre poi, una volta approvati alcuni progetti (es. la scuola) ci si dovrebbe addentrare nei dettagli di ciascuna idea emersa con sufficiente consenso (es. come costruire il tetto, gli impianti elettrici e idraulici, gestire la conformità alle normative, arredare i locali, ecc.).

Pertanto si rende necessario ideare degli strumenti che consentano di scomporre i macro problemi in sottoinsiemi, mantenendo i legami tra i vari elementi, consentendone la tracciabilità pre e post delibera, così come la votazione e discussione indipendente ma correlata.

* Il problema del fact checking e dell’attendibilità delle informazioni: sappiamo bene come questo problema coinvolga da sempre tutti gli organi ed i media informativi. Basta citare un articolo dalla parvenza scientifica per condizionare il giudizio degli sprovveduti, si possono spacciare per certezze null’altro che ipotesi, si può insinuare senza indizi e suggerire interpretazioni intellettualmente disoneste, marcatamente di parte o fondate sul pregiudizio, le varianti qui sono molte. Per sgombrare il campo da strumentalizzazioni e deformazioni varie in questo contesto si tratterebbe di implementare quei vecchi, solidi e sani principi propri del metodo galileiano (e quindi di tutta la buona scienza), coadiuvandoli con le best practices proprie del codice deontologico dei giornalisti (attenersi ai fatti, se possibile dimostrarli, citare le fonti e tutelarne l’anonimato se richiesto, ecc.). Anche questo punto presenta diverse sfide, non c’è che dire.

* Il problema dell’autoregolamentazione democratica dei gruppi: questa problematica riguarda la possibilità di creare delle meta-policy o meta-regolamenti che consentano a ciascun gruppo presente sulla piattaforma di online deliberation, di rivedere su base democratica ruoli e autorizzazioni inizialmente decisi dagli amministratori del gruppo stesso all’atto della sua costituzione. Questo processo dalla parvenza avveneristica trova in realtà il suo predecessore filosofico nel gioco di società Nomic e nelle idee di Peter Suber (si veda il libro The Paradox of Self-Amendment) ma in realtà afferisce in qualche maniera alle teorie e paradossi orbitanti attorno ai sistemi autoreferenziali.

* La gestione dei grandi numeri a livello di partecipazione: grandi numeri implicano un volume di contributi da gestire potenzialmente enorme, con un prevedibile livello di overflow per i redattori, che dovrebbero crescere in maniera proporzionale, evitando le edit wars e riuscendo ad aggregare e canalizzare le idee maggiormente condivise all’interno di differenti e alternative proposte di soluzione.

Tutto ciò comporta anche la necessità di sviluppare una tecnologia efficace in grado di evitare la proliferazione di proposte doppie o semanticamente affini, allo scopo di evitare la dispersione dell’intelligenza collettiva in rivoli di discussione ignari l’uno dell’altro.

Infine si rende necessario ideare meccanismi in grado di filtrare sempre meglio il cosiddetto “suono” rispetto al “rumore” della conversazione, al fine di determinare rapidamente quale contenuto sia costruttivo (anche in senso critico) e quale invece rappresenti un generico commento non utile all’evoluzione della proposta, evoluzione che si immagina per definizione essere finalizzata ad una sempre crescente attendibilità, esaustività, comprensibilità e ipotetica efficacia e vicinanza rispetto allo stato dell’arte esistente sul tema considerato.

Se i software di E-democracy saranno o meno in grado di realizzare un modello di Deliberative opinion poll, perfezionato e scalabile per grandi volumi di partecipanti, superando di fatto il modello del professor James S. Fishkin della Stanford University, che lo teorizzò nel 1988), sarà una delle sfide più interessanti cui prendere parte nel prossimo futuro.

* Individuare un modello di e-democracy sostenibile: La E-democracy è sulla bocca di molti, tuttavia personalmente ritengo che il “solido della partecipazione” abbia una struttura piramidale costituita da un livello di partecipazione trasversale alla cultura, ma non all’impegno pratico (determinato in termini di tempo o denaro dedicato alla “causa”), con cui anzi trovo che esista una fortissima correlazione inversa (al crescere dell’impegno richiesto la base di utenti partecipanti si riduce). Partecipare costa fatica e per chi si dedica allo sviluppo di queste piattaforme trovare un modello economicamente sostenibile per continuare a coltivare il sogno di poter creare uno strumento utile al miglioramento della società, bilanciando garanzie per gli utenti e gratuità del servizio (fin dove ciò sarà possibile), è davvero la sfida più grande, perchè per un modello Wikipedia che riesce a sostenersi (seppur a fatica), mille altri falliscono miseramente e non sempre in seguito ad un equo processo di selezione naturale.

Tutto ciò restando ben consapevoli che nessun software, per ora e per molto tempo ancora, sarà in grado di sopperire ai limiti culturali ed evolutivi radicati nell’essere umano, rappresentando esso sempre uno strumento, aggregazione ragionata di zeri e uno, dna digitale, mezzo e non traguardo, una tavolozza di colori e pennelli con cui dipingere un mondo nuovo, più equo e sostenibile, una tavolozza quasi-senziente che richiama, e reclama, ad un uso di sè effettuato con la dovuta perizia e maestria e con la giusta dose di umiltà che consenta a ciascuno di noi di apprendere ciò che di buono hanno da insegnarci gli altri.

VT: Virtual Team e Leadership

Le caratteristiche dei VT sono:
- la distribuzione geografica dei membri ;
- l'uso esteso delle tecnologie come principale mezzo di comunicazione e di collaborazione;
- l'eterogeneita organizzativa, disciplinare, culturale e linguistica dei membri.

Come per i team tradizionali anche per i VT il ruolo del leader è cruciale per la perfomance del gruppo ma i modelli tradizionali di leadership finora considerati mostrano tutti i loro limiti quando vengono mutuati nel contesto virtuale perché le teorie sulla leadership sono state studiate specificatamente per i team co-locati che si basano su interazioni FtF ( face to face ), mentre le dinamiche dei VT sono in parte diverse e non possono essere completamente spiegate dalle teorie tradizionali.

La scelta del team science è anche motivata dal fatto che vi è una emergente esigenza di ulteriori studi su come l'esperienza, l'infrastruttura tecnologica ed il comportamento organizzativo possano migliorare le performance dei team coinvolti in collaborazioni scientifiche.

Da un lato infatti, i due progetti di ricerca percepiti come più efficaci hanno ottenuto un allineamento alto: nel primo siamo in presenza di una leadership decentralizzata e il ruolo di integrazione della conoscenza e del comportamento è demandato alle tecnologie mentre nel secondo si ha una leadership centralizzata che svolge il ruolo di integrazione, senza aver bisogno di ricorrere a molte tecnologie.

Si arricchisce anche la conoscenza sulle dinamiche sociali dei team science: i processi sociali, come le risorse relazionali e il processo di leadership, e linfrastruttura tecnologica hanno implicazioni reciproche sulla produzione scientifica, la collaborazione e il successo del team.

Lean MURI-MURA-MUDA

Come Comprendere in "Learning Time Zero" la metodologia Lean di sviluppo ? 

Ebbene vi propongo il metodo Giapponese MURI-MURA-MUDA !
Cosa Vuol dire ?
Supponete di possedere un camion con una portata di due tonnellate e di dover trasportare 6 tonnellate, cosa fareste ?
Per buonsenso distribuireste il lavoro facendo 2 portate da 3 tonnellate l'una, ecco questo è Lean.

MUDA vuol dire spreco (fisico, visibile), la sua identificazione ed eliminazione. Ma nel lean thinking, anche le altre due indicano sprechi, ma in forma diversa rispetto a sette tipi di spreco classici che si notano immediatamente, e rappresentati da muda (sovrapproduzioni, trasporti, attività non necessarie, movimentazioni, difetti, inventari e attese). Ma non vuol dire che sono meno importanti. Vediamole:

MURI è il termine che indica il sovraccarico delle persone o delle risorse. Cosa comporta il sovraccarico delle persone o delle risorse? Quello delle persone può provocare a lungo termine la possibilità di infortuni o malattie professionali, dovuti alle posture esagerate che vengono richieste in continuazione dai lavoratori. Anche a breve termine può provocare gli strappi muscolari o altre cose simili. Ciò poi causa (nel migliore dei casi…) l’assenza dal lavoro per periodi più o meno lunghi e insoddisfazione generale delle persone che si sentono sfruttate (secondo voi, quale è il motivo dell’esistenza dei sindacati dei lavoratori in Italia?…). Pensate per analogia ad un camion che viene sollecitato con il doppio del carico nominale in continuazione: la prima volta probabilmente non succederà nulla, la seconda neanche, … , alla n-esima volta invece succede che si rompe un’asse e il camion non è più utilizzabile o ha bisogno di lunghi tempi di riparazione. Questo deve farvi pensare: ma vale veramente la pena sollecitare le persone e le risorse oltre il loro limite fisico per avere un beneficio a breve termine? O volete pensare a lungo termine e usare le persone e le risorse in modo ottimale? Come fate a sapere che le persone sono sovrasollecitate? Basta chiedere a loro. Vi diranno loro che quella postura non va bene, che quel carico è troppo pesante ecc. Ma dovete anche osservare il lavoro ed accorgervi da soli che ci sono attività che potrebbero essere fatte in maniera più efficace ed anche veloce, e che tolgono il sovraccarico dalle persone. Il lean thinking insegna proprio questo: di vedere!

MURA invece indica le fluttuazioni, variazione, irregolarità del carico del lavoro (della domanda). Cosa comportano le fluttuazioni? Comportano la creazione delle fasce dove c’è un sovraccarico (spreco di muri…) e delle fasce nelle quali c’è un sottocarico ottimale (ad esempio spreco di attese – muda…). Il flusso produttivo sicuramente nè risulta disturbato. Quale è la causa delle fluttuazioni? E’ la non standardizzazione della domanda attraverso l’utilizzo dei metodi che servono per appiattire i picchi e le valli (ad esempio attraverso l’utilizzo del box heijunka). Facciamo un esempio, sempre del nostro camion: supponiamo di dover trasportare 6t di materiale e camion ne porta 3t. Uno spreco di muri vorrebbe dire portare 6t tutti in una volta. Il muda sarebbe di portare 3 volte per 2t. Mura sarebbe di portare una volta 4t e un’altra volta 2t (o 5t e 1t, indifferentemente…). L’ottimale sarebbe invece di portare 2 volte 3t (non ci sono sovraccarichi, non c’è la fluttuazione della domanda, non ci sono sottocarichi o sprechi delle risorse, un flusso equilibrato e continuo).

Che cosa sono i microservizi?

Contesto
Dagli anni ‘90 il modello multi-strato (multi-tier architecture) è stato considerato un pattern architetturale fondamentale per costruire un sistema software. Secondo tale modello le varie funzionalità software sono logicamente separate su più strati che comunicano tra di loro. Ogni strato comunica con gli strati adiacenti in modo diretto richiedendo ed offrendo servizi. In effetti in questa architettura il sistema software, sia pure se logicamente suddiviso in strati, risulta essere un unico sistema monolitico.
L’avvento e la diffusione del cloud computing, le pratiche di continuous delivery, l’approccio alla gestione della complessità del software basato sul DDD (Domain-Driven Design), l’organizzazione agile delle aziende in team di sviluppo piccoli ed autonomi (3-7 persone) sono il contesto in cui è emerso il modello dell’architettura a microservizi.
Che cosa sono i microservizi?
In breve i microservizi sono dei servizi “piccoli” ed autonomi che interagiscono tra di loro e che hanno come finalità quella di fare una cosa e di farla bene; sono a tutti gli effetti dei sistemi distribuiti. Per dare una definizione più precisa possiamo riprendere le parole di Martin Fowler che afferma:
Lo stile architetturale a microservizi è un approccio allo sviluppo di una singola applicazione come insieme di piccoli servizi, ciascuno dei quali viene eseguito da un proprio processo e comunica con un meccanismo snello, spesso una HTTP API.
Ma quanto devono essere piccoli i microservizi?
Non è facile rispondere a questa domanda. Infatti non è possibile fornire una risposta, ad esempio, in termini di numero di righe di codice che definiscono la giusta taglia: alcuni linguaggi di programmazione sono più concisi di altri, riuscendo ad esprimere molto senza essere verbosi, per non parlare poi di librerie e dipendenze o della complessità del dominio del software in oggetto.
Secondo Jon Eaves, famoso autore di testi del mondo Java, un microservizio deve essere tale da poter essere riscritto in due settimane. Ovviamente va considerato che tale risposta ha validità nel contesto lavorativo di Real Estate Australia dove Eaves lavora. In sostanza la taglia corretta deve essere identificata in accordo alla struttura organizzativa aziendale.
Teniamo sempre in mente che man mano che la dimensione di un servizio decresce, aumentano i benefici relativi all’indipendenza tra le parti, ma cresce anche la complessità di gestire un numero elevato di parti.
Autonomia
Ogni microservizio è un’entità separata che viene generalmente pubblicata su una piattaforma PaaS oppure eseguita da uno processo di sistema ad hoc.
La comunicazione tra i servizi avviene attraverso la rete al fine di garantire l’indipendenza tra i servizi ed evitare ogni forma di accoppiamento.
Ogni microservizio si propone all’esterno come una black-box, infatti espone solo un Application Programming Interface (API), astraendo rispetto al dettaglio di come le funzionalità sono implementate e dallo specifico linguaggio o tecnologia utilizzati. Ciò mira a far si che il cambiamento di ciascun microservizio non abbia impatto sugli altri.
Vantaggi
L’utilizzo dell’architettura a microservizi ha indubbiamente dei vantaggi:
• Velocizzare i tempi di rilascio del software e reagire velocemente alle esigenze del mercato
In generale, nell’architettura a microservizi, ogni singolo servizio è autonomo rispetto agli altri, di coseguenza può raggiungere l’ambiente di produzione in modo indipendente dagli altri, senza che tale attività abbia effetti drammatici sul resto del sistema. Disporre di un processo di deployment snello e veloce consente di poter aggiungere o modificare funzionalità di un sistema software in modo efficace ed efficiente, rispondendo alle necessità di mercato e utenti sempre più esigenti.
• Sperimentare più facilmente nuove tecnologie
Molto spesso, la principale barriera per adottare una nuova tecnologia risiede nel rischio associato all’utilizzo di qualcosa di nuovo e con il quale si ha poca esperienza. Confinando questo rischio ad una piccola porzione di un sistema software, che è possibile riscrivere in appena due settimane di lavoro, il rischio risulta molto contenuto e quindi è una sfida da accettare.
• Migliori performance grazie all’utilizzo di tecnologie ad hoc
L’utilizzo di linguaggi e tecnologie eterogenee consente di poter utilizzare gli stack più performanti per implementare specifiche funzionalità: ad esempio è possibile introdurre una particolare tipologia di base dati che risulta naturale per mappare un determinato dato, oppure eseguire un calcolo in un modo particolarmente efficiente.
• Resilienza
In un’architettura a microservizi, quando una componente non funziona non è automatico che tutto il sistema software smetta di funzionare. In molti casi è possibile isolare il problema ed intervenire mentre il resto del sistema continua a funzionare, cosa non possibile in un’architettura monolitica. Va però sottolineato che l’architettura a microservizi, essendo un insieme di sistemi distribuiti, espone ad una nuova fonte di problemi legati ai disservizi di rete.
• Scalabilità
In generale risulta molto più semplice ed economico scalare un microservizio rispetto ad un sistema software monolitico di grandi dimensioni. Il modello a microservizi consente di poter effettuare provisioning delle parti del sistema software in modo dinamico ed intelligente.
• Facilità di deployment
Modificare poche righe di codice su un sistema software monolitico di grandi dimensioni ed effettuarne il deploy è generalmente un’attività non banale, che espone a rischi significativi considerando anche l’impatto che tali modifiche possono avere. Questa paura generalmente porta a raccogliere un certo numero di modifiche prima di avviare un’attività così onerosa e rischiosa.
Con l’approccio a microservizi ogni singolo servizio può raggiungere l’ambiente di produzione in modo indipendente, sicché se si verifica un problema esso è facilmente isolato e possono essere intraprese azioni di rollback più velocemente.
• Componibilità
Tra le opportunità più interessanti dell’architettura a microservizi vi è la possibilità di riusare le funzionalità. Infatti è possibile che una stesso servizio venga utilizzato in modi differenti e per scopi diversi. Si pensi ad esempio ad un sistema software che deve poter dialogare non solo col mondo web ma anche con applicazioni mobile, dispositivi wearable, etc.
• Sostituibilità
Quando un sistema software è organizzato a microservizi, il costo di sostituire un servizio con un altro più efficiente e migliore è limitato a circa due settimane di sviluppo, così come banale è il costo di rimuovere un servizio inutile.
Svantaggi
Da quanto fin qui trattato, potrebbe sembrare che l’architettura a microservizi risulti essere la manna dal cielo, non è così. Infatti non possiamo dimenticare di ribadire che utilizzare tanti servizi che dialogano tra di loro attraverso la rete, vuol dire di fatto avere a che fare con un sistema distribuito, con tutti i problemi dal caso.
Si pensi, ad esempio, a cosa vuol dire autenticare un utente su un’architettura distribuita volendo garantire il single sign-on, oppure a come gestire la mutua autenticazione tra i servizi che compongono il sistema software. E ancora: cosa vuol dire testare un sistema software di questo tipo?
Infine, vengono fuori altre tematiche tipiche dei sistemi distribuiti come la gestione di situazioni in cui è necessario che il sistema software sia in grado di riconfigurarsi al volo quando una nuova istanza di un servizio viene creata e il resto della rete può automaticamente trovare essa ed iniziare a comunicare con essa. Questo processo è chiamato service discovery.

Bibliografia
• Appunti della CloudConf 2015 di Torino
• Building Microservices, Sam Newman, O’Relly
• Micro services, what even are they? Jon Eaveshttp://techblog.realestate.com.au/micro-services-what-even-are-they/
• Microservices, Martin Fowlerhttp://martinfowler.com/articles/microservices.html
• Road to Microservices, Salvatore Cordianohttp://www.slideshare.net/parallelit/road-to-microservices

Effetto Zeigarnik e Procrastinare...

[“Una persona saggia inizia ciò che uno stupido rimanda. Entrambi affrontano la stessa attività, ma in tempi diversi.” (Lord Acton).]

Cos’è l’effetto Zeigarnik
L’effetto Zeigarnik prende il nome dalla psicologa Russa Bluma Zeigarnik, che seduta in un ristorante di Vienna all’inizio del secolo scorso, notò uno strano comportamento da parte dei camerieri:

“Ogni singolo cameriere sembrava ricordare perfettamente gli ordini ancora da servire, dimenticandosene immediatamente dopo che erano stati serviti”.

Da brava studiosa, la dott.ssa Zeigarnik tornò nei suoi laboratori per testare, su un gruppo di partecipanti, una teoria che aveva in mente per spiegare lo strano comportamento dei camerieri. La psicologa russa chiese ai suoi partecipanti di svolgere una ventina di semplici compiti: risolvere dei puzzles, realizzare delle collanine, etc.

Da simpatica burlona quale era, la dott.ssa Zeigarnik interrompeva ogni tanto i suoi partecipanti, scrivendo sul taccuino i compiti che stavano svolgendo quando erano stati interrotti.

Al termine dell’esperimento, Bluma la “rompiballe” chiese ai suoi partecipanti quali, dei circa venti compiti svolti, ricordassero meglio: la stragrande maggioranza dei partecipanti dimostrarono di ricordare molto meglio i compiti nei quali erano stati interrotti, rispetto ai compiti che avevano portato a termine; esattamente come i camerieri osservati nel ristorante viennese.

Fico… ma che me frega a me?! Qual è l’utilità di questo studio, ma soprattutto come posso utilizzarlo per sconfiggere quel problemino che mi affligge e prende il nome di…  PROCRASTINAZIONE!

Un attimo di pazienza ancora: voglio darti un altro indizio nel prossimo paragrafo…

L’effetto Zeigarnik in televisione
L’effetto Zeigarnik è ampiamente utilizzato in televisione, soprattutto nelle soap opera e nelle serie tv.

Ti sei mai chiesto come faccia tua mamma ad essere invogliata a seguire la milionesima puntata di Beautiful? Sarà il fascino plastificato di Ridge?! o l’ennesimo tradimento di Brooke con lo zio della cugina della pronipote della nonna?!

Magari è successo anche a te con quella serie tv americana che ti appassiona tanto: finisci di guardare l’ultima puntata e non vedi l’ora che passi una settimana per vedere la puntata successiva.

Cos’è che ti tiene incollato allo schermo?!

Stranamente, ogni puntata viene interrotta sul più bello! lasciandoti con una sensazione di suspense, a cui l’effetto Zeigarnik è strettamente correlato. Hai presente quell’odiosa frasetta: “to be continued…”?!

Stai iniziando a capire il collegamento tra effetto Zeigarnik e procrastinazione? Ci siamo quasi…

… iniziamo ad intuire il potere dell’effetto Zeigarnik: ma come cavolo utilizzarlo a nostro vantaggio.

Utilizzare l’effetto Zeigarnik per battere la procrastinazione
Se stai leggendo questa frase, significa che ho utilizzato correttamente l’effetto Zeigarnik per invogliarti a leggere questo articolo. Come avrai notato al termine di ogni paragrafo ho utilizzato frasi come:

“Un attimo di pazienza ancora: voglio darti un altro indizio nel prossimo paragrafo…”
“Stai iniziando a capire il collegamento tra effetto Zeigarnik e procrastinazione? Ci siamo quasi…”

Tutte frasi che hanno un unico obiettivo: invogliarti ad iniziare il paragrafo successivo. Come notato dalla psicologa russa Zeigarnik e come ben risaputo dagli autori di soap opera e serie tv: quando una persona inizia una determinata attività, è molto più propensa a portarla a termine.

L’effetto Zeigarnik ci insegna dunque un’importante lezione per battere la procrastinazione:

Quando devi affrontare un progetto complesso ed importante e stai continuando a procrastinare: semplicemente.. inizia!!

SticaXi: hai inventato l’acqua calda! Lo so che devo iniziare, ma non c’ho voglia! Non ci sono le condizioni giuste, sono demotivato, sono svogliato!

Non importa che tutte le condizioni siano perfette, non importa se non sai da dove iniziare o come iniziare: semplicemente inizia. Il tuo obiettivo principale è metterti in moto ed eliminare quella che è la procrastinazione statica.

Se sarai in grado di iniziare, anche quando non ti senti motivato, anche quando sei svogliato, l’effetto Zeigarnik farà il resto per te, aiutandoti a completare ciò che hai iniziato.

Energized Work by James Shore

Energized Work

Pubblico

Allenatori

Tutta la squadra

Noi lavoriamo a un ritmo che ci permette di fare il nostro lavoro migliore, più produttivo a tempo indeterminato.

Mi piace la programmazione. Mi piace risolvere i problemi, scrivere buon codice, a guardare i test che passano, e in particolare la rimozione di codice inutile mentre faccio "refactoring". Programmo nel mio tempo libero e talvolta anche pensare al lavoro sotto la doccia.

In altre parole, io amo il mio lavoro. Eppure mi ha messo su una squadra con obiettivi poco chiari, poca responsabilità collettiva, sostenendo, e lotte di pancia, e mi sveglio temendo di andare al lavoro. Passo le mie ore in ufficio, ma sarò tentato di spendere le mie mattinate a leggere e-mail e miei pomeriggi a studiare buon codice durante la navigazione attraverso i siti web tecnici marginalmente correlati.

Siamo stati tutti in questa situazione. Perché siamo professionisti, ci sforziamo di produrre un lavoro di qualità anche quando ci sentiamo demoralizzati. Consideriamo, però, i momenti di maggiore produttività nella vostra carriera. Hai notato una grande differenza quando ti svegli e senti benedetto per andare al lavoro? Non è molto più soddisfacente quando si lascia il lavoro a fine giornata, sapendo che avete compiuto qualcosa di solido e utile?

La pratica di XP di Energized Work riconosce che, sebbene i professionisti possono fare un buon lavoro in circostanze difficili, fanno del loro meglio, il lavoro più produttivo avviene quando sono pieno di energie e motivato.

Come essere Energized

Vai a casa in tempo.

Uno dei modi più semplici per essere alimentato è quello di prendersi cura di se stessi. Vai a casa in tempo ogni giorno.Trascorri del tempo con la famiglia e gli amici e impegnati in attività che richiedono la vostra mente fuori di lavoro. Mangia cibi sani, esercizio fisico, e ottieni l'abbondanza del sonno. Mentre sei impegnato con queste altre cose, il cervello si accende sugli eventi della giornata. Spesso avrete nuove intuizioni di mattina.

Se il tempo di qualità è lo yin dell' Energized Work, rimanere concentrato a lavoro è il yang. Durante il lavoro, dare la massima attenzione. Spegnere interruzioni come la posta elettronica e messaggistica istantanea ( skype, etc...) . Tacere i vostri telefonini. Chiedete al vostro project manager di difenderti dagli incontri inutili e di politica organizzativa.

Quando lo yin e lo yang incastrano perfettamente, ti svegli la mattina, ben riposati e desiderosi di iniziare la giornata. Alla fine della giornata, sarete stanchi, ma non esausti, e soddisfatti del lavoro che avete fatto.

Questo non è facile. Energized Work richiede un sostegno ai luoghi lavorativi e alla vita domestica. E', comunque, una scelta personale; non c'è alcun modo per obbligare qualcuno a essere Energized. Tuttavia, è possibile rimuovere gli ostacoli.

Sostenere Energized Work

Stare a casa quando si è malati. Per Il rischio di infettare troppe altre persone.

Una delle mie tecniche preferite come coach è quello di ricordare a tutti di tornare a casa in tempo. Gente stanca commette errori e prende scorciatoie. Gli errori risultanti possono finire per costare più di quanto vale il lavoro speso. Questo è particolarmente vero quando qualcuno è malato; oltre a fare un lavoro scarso, avrebbe potuto infettare altre persone.

Alleato

Pair programming

Pair programming è un altro modo per incoraggiare l'Energized Work. Essa incoraggia l'attenzione come nessun altra pratica. Dopo una giornata piena di pair programming, sarete stanchi ma soddisfatti. E' particolarmente utile quando non sei al tuo meglio: l'abbinamento con qualcuno sicuramente può aiutare a rimanere concentrati.

Può sembrare sciocco, ma avere cibo sano a disposizione sul posto di lavoro è un altro buon modo per sostenere l'Energized Work. La colazione è davvero il pasto più importante della giornata. Gli abbassamenti di metà pomeriggio sono anche comuni. Cereali, latte, verdure, ed energia spuntini sono una buona scelta. Snack e cibo spazzatura, anche se popolari, contribuiscono al crollo di metà pomeriggio.

Alleato

Visione

La natura del lavoro fa anche la differenza. [McConnell 1996] riporta che gli sviluppatori di software sono motivati ​​a fare bene, il lavoro intellettualmente stimolante. Non tutti i progetti saranno in grado di nutrire i poveri o risolvere problemi completamente, ma una chiara affermazione convincente del perché il prodotto è importante può avere un lungo cammino. Creare e comunicare questa visione è la responsabilità del manager di prodotto.

Alleato

Il Gioco di pianificazione

Un obiettivo raggiungibile va di pari passo con una visione convincente. Nulla distrugge il morale più velocemente di essere ritenuti responsabili per un obiettivo irraggiungibile. Il gioco pianificazione risolve questo problema unendo valore per il cliente con le stime degli sviluppatori di creare piani realizzabili.

Parlando di piani, ogni organizzazione ha una certa quantità di politiche. A volte, le politiche portano alla trattativa sana e compromettente. Altre volte, portano a richieste irragionevoli ed al cercare colpevoli. Il project manager dovrebbe occuparsi di queste politiche, lasciando che la squadra sappia cosa è importante e proteggendoli da ciò che non lo è.

Alleati

Workspace Informativa

Segnalazione

Il project manager può anche aiutare i membri del team nel soddisfare il lavoro spingendo indietro le riunioni inutili e le chiamate in conferenza. Fornire uno spazio di lavoro informativo e di reporting appropriato può eliminare la necessità di riunioni. In un ambiente con un sacco di distrazioni esterne, vengono spesso rese inutili ore centrali di sviluppo ogni giorno, sarebbe necessario isolare almeno una o due ore di inizio giornata. Durante il quale tutti sono d'accordo di non interrompere la squadra.

Infine, le squadre "inquadrate" hanno un sacco di energia. Sono molto soddisfatte, anche. È possibile riconoscere una squadra "inquadrata" da quanto i suoi membri amano trascorrere del tempo insieme. Vanno a pranzo insieme, condividono barzellette, e possono anche socializzare al di fuori del lavoro. Come Energized Work, non è possibile forzare l' "inquadrameto", ma si può incoraggiarla; molte delle pratiche di XP farlo. Il classico lavoro su questo argomento, [DeMarco e Lister 1999] 's Peopleware , vale la pena di leggerlo.

Prendere Pause

Fermarsi quando si sta facendo più errori del progresso.

Quando stai facendo più errori che progressi, è il momento di prendersi una pausa. Se siete come me, però, quello è il momento più difficile in cui fermarsi. Mi sento come se la soluzione fosse proprio dietro l'angolo, anche se è stata proprio dietro l'angolo per gli ultimi 45 minuti, e io non voglio smettere finché non la trovo. Ecco perché è utile per qualcun altro mi ricordi di smettere. Dopo una pausa o una buona dormita la notte, io di solito vedo il mio errore subito.

A volte uno spuntino o passeggiata intorno all'edificio è abbastanza buono. Per i programmatori, commutare le coppie può aiutare. Se è già la fine della giornata, però, andare casa è una buona idea.

Di solito è possibile dire quando qualcuno ha bisogno di una pausa. Arrabbiarsi, imprecando al computer, e bruschi movimenti sono tutti segni. In un ambiente altamente collaborativo, oscurarsi -non parlando- può anche essere un segno che qualcuno ha bisogno di una pausa. Quando ho noto un paio di programmatori che sussurrano gli uni agli altri, mi chiedo quanto tempo è passato dal loro ultimo passaggio dei test. Spesso ricevo una risposta imbarazzata, e ciò quando ricordo loro di prendere una pausa.

Suggerire una pausa richiede una certa quantità di delicatezza. Se qualcuno ti rispetta come un leader, allora dovresti essere in grado di dirgli semplicemente di smettere di lavorare. In caso contrario, lo allontanarsi dal problema per un minuto in modo che possa schiarirsi le idee. Provare a chiedergli di aiutarvi per un momento, o per fare una breve passeggiata con voi per discutere qualche problema che stai affrontando.

Domande

Cosa succede se non sono pronto a testare il mio codice ed è tempo di tornare a casa?

Alleati

Test-Driven Development

Continuous Integration

Se stai praticando sviluppo test-driven e continuos integration, il codice dovrebbe essere pronto per il check-in ogni pochi minuti. Se siete alle prese con un problema e non è possibile il check-in, andate a casa comunque. Spesso la risposta sarà evidente al mattino.

Alcune squadre revertano (cancellano) il codice che non passa tutti i test alla fine della giornata. Questa suona dura, ma è una buona idea: se non si può fare facilmente check-in, siete andati fuori pista. Potrai fare meglio il lavoro al mattino. Se stai praticando bene continuos integration, la perdita del codice sarà il minimo e avrai ancora imparato dall'esperienza.

Io lavoro in una startup e 40 ore solo non sono sufficienti. Posso lavorare di più?

Se avete paura di andare a lavorare la mattina, non si è eccitato.

Un ambiente di startup ha spesso un sacco di emozioni e di cameratismo. Questo porta ad avere più energia e potrebbe significare che si può lavorare per molto tempo e dedicare ancora molta attenzione. D'altra parte,le start-up a volte confondono lunghe ore di lavoro con dedizione alla causa. Fare attenzione a non lasciare che la dedizione ignori il vostro buon giudizio in merito a quando si è troppo stanchi per fornire contributi utili.

Abbiamo una scadenza importante e non c'è modo di farlo senza tenere la testa bassa e spingere oltre. Abbiamo messo da parte Energized Work per ora?

Uno sprint verso il traguardo potrebbe aumentare la vostra energia. Non c'è niente come un Code Party a tarda notte, quando la squadra porta in pizza, ognuno lavora sodo, tutti i cilindri scottano, e il lavoro arriva tutto insieme all'ultimo momento. Un grande sprint può aiutare la quadratura del team, dando il senso di realizzare qualcosa di importante di fronte alle avversità. Tuttavia ...

Straordinari estesa non risolverà i vostri problemi di pianificazione.

Sprintare per il traguardo è una cosa; sprintare per chilometri è un'altra. Straordinari estesi non risolveranno i vostri problemi di pianificazione. In realtà, ciò ha gravi conseguenze negative. DeMarco chiama straordinari estesi "una tecnica di riduzione-produttività  importante," che conduce alla ridotta qualità, alienazione del personale, aumento del turnover del personale, e l'uso inefficace del tempo durante il normale orario [DeMarco 2002] (p. 64).

Se si lavora fuori orario una settimana (qualunque "straordinario" si intende nella tua situazione), non funzionerà più lo straordinario della prossima settimana. Se vedo una squadra sprint più di una volta o due volte a trimestre, cerco problemi più profondi.

Risultati

Quando la tua squadra è Energized, c'è un senso di eccitazione e di cameratismo. Come gruppo, presta attenzione ai dettagli e cerca nuove opportunità di migliorare le vostre abitudini di lavoro. Si fanno progressi costanti ogni settimana e si sentono in grado di mantenere il progresso all'infinito. Apprezzi la salute sul progresso a breve termine e il sentire produttivo e di successo.

Controindicazioni

Energized Work non è una scusa per bighellonare. Generiamo fiducia mettendoci in una giornata di fiera del lavoro.

Alcune organizzazioni possono rendere l'Energized Programming difficile. Se l'organizzazione utilizza il numero di ore lavorate come metro per giudicare la dedizione, potrebbe essere meglio sacrificare l'Energized Work e fare lunghe ore di lavoro. La scelta tra la qualità della vita e l'avanzamento di carriera è una scelta personale che solo voi e la vostra famiglia potete fare.

Alternative

Alleati

Pair programming

Pianificazione di uscita

Se l'organizzazione rende l'Energized Work difficile, gli errori sono più probabili. Programmare in coppia potrebbe aiutare i programmatori stanchi a rimanere concentrati e catturare tutti gli altri errori. Ulteriori test potrebbero essere necessari per individuare i difetti extra. Se è possibile, aggiungete sempre un tempo di emergenza supplementare al vostro piano di rilascio per fixarlo.

La forma estrema di questo tipo di organizzazione è la "marcia della morte", tipo di organizzazione, che richiede (o "fortemente incoraggia") i dipendenti di lavorare per tante ore di straordinari settimana dopo settimana. Purtroppo, "progetti di marcia della morte sono la norma, non l'eccezione."[Yourdon] (p. ix).

Per aggiungere la beffa al danno, [DeMarco e Lister 2003] (p. 161) pesa: "Nella nostra esperienza, la caratteristica comune tra i progetti di "marcia della morte" è basso valore atteso. Sono progetti finalizzati a mettere fuori i prodotti di insignificanza monumentale. L'unica vera giustificazione per la marcia della morte è che con un valore così minuscolo, fare il progetto a costo normale sarebbe chiaramente comporterebbe costi che sono maggiori di benefici ... se il progetto è così essenziale, perché non può la società di trascorrere la tempo e denaro per farlo correttamente? "

Approfondimenti

Peopleware [DeMarco e Lister 1999] è un classico lavoro sulla motivazione del programmatore e la produttività. Dovrebbe essere in cima alla lista di lettura di ogni responsabile sviluppo software.

Sviluppo rapido [McConnell 1996] ha un capitolo su "Motivation" con un bel grafico di confronto motivazioni programmatore alle motivazioni dei dirigenti e la popolazione in generale.

Slack [DeMarco 2002] esamina gli effetti di straordinario estesa e troppi impegni.

Death March [Yourdon] descrive come sopravvivere ad un progetto di "marcia della morte".