Fine 2018: è tempo di tirare le somme sul percorso Agile

Siamo all’ultimo giorno del 2018 e, come spesso accade, si riflette su quanto accaduto nell’ultimo anno.

In particolare le riflessioni vammo verso il procorso di trasformazione agile su cui ho lavorato molto negli ultimi anni nella mia azienda, Cerved Group, e che ci ha portato negli ultimi 5 anni, a costruire un settore IT più dinamico, più reattivo, più aperto e sensibile all’innovazione.

Come in tutti i percorsi di trasformazione, non si può mai dire quando la trasfromazione è completata, ma la sensazione è che il 2018 segni la fine di un primo ciclo di trasformazione e getti le basi per i prossimi passi

E’ stato un percorso lungo, complesso, che ha richiesto tanta passione e impegno da parte di tanti collaboratori; ho avuto modo di parlarne in una intervista rilasciata per InfoQ, la principale community tecnologica al mondo che si occupa di software e di tutto quello che gira intorno al mono della produzione del software: tecnologie, metodologie, linguaggi, organizzazione, ecc…

https://www.infoq.com/articles/scaling-agile-data-driven-company

Sono stato molto onorato di raccontare la nostra esperienza in un sito come InfoQ che ho sempre seguito e mi ha sempre ispirato nel lavoro di responsabile di team di produzione di soluzioni software, in Cerved. L’intervista è stata rilasciata in seguito al talk tenuto all’evento Agile Business Day 2018 a Venezia, inzieme ad alcuni più che validi compagni di viaggio (di seguito la registrazione dell’intervento)

Se mi guardo indietro e ripenso al viaggio effettuato sin qui, la lezione principale che mi viene in mente è che in un processo di trasformazione è importante provare, testare, fallire subito e imparare dai propri errori.

Sembra un concetto scontato, quando si parla di agile e di approccio lean, ma farlo in una grande realtà, in un settore consolidato, richiede coraggio, passione, pazienza e fiducia. Solo facendo proprio il paradigma dell’Inspect & Adapt e applicandolo nei percorsi di trasformazione è possibile intraprendere un percorso di successo.

D’altronde non ci sono ricette precostituite quando si parla di percorso Agile. Più è grande l’azienda è più il sistema che si vuole trasformare e complesso. E nei sistemi complessi, il Cynefin Framework ci insegna che non ci sono regole predittive, non ci sono best o good practises da applicare per raggiungere un risultato; e la trasformazione non si può imporre dall’alto; anzi è importante convolgere tutti, e agire con approccio Probe-Sense-Respond.

D’altronde le aziende, i team, sono organizzazioni umane e come tali non sono liquide, ovvero non sono strutturalmente pronte ad adattarsi a qualunque contentore in cui vengono inseriti; anzi mostrano una certa resistenza al cambiamento, hanno bisogno di tempo per capire come cambiare, tendono a permanere nella loro posizione di equilibrio.

Ma per fortuna non sono neanche solide: una trasformazione è sempre possibile, e le trasformazioni avvengono sempre: nelle famiglie, nei gruppi di amici, nei circoli, nei partiti, nelle aziende. E’ più corretto dire che le organizzazioni sono più simili al caro buon vecchio DAS, che qualcuno meno giovane ricorderà:

Il DAS non è solido, non è liquido, ma è modellabile; richiede una carta pressione per poter essere trasformato, e occorre fare molta attenzione alla pressione perchè troppa rischia di rompere la struttura.

E più il DAS è vecchio, ovvero l’organizzazione stratificata, e più si fa fatica a modellarlo ed è necessaria maggiore delicatezza e cura nel farlo.

Se volete cambiare la vostra organizzazione ricordate che vi trovate di fronte ad un blocco di DAS: non premete troppo, non abbiatte fretta, modellate, cercate di capire come risponde al cambamento e imparate giornalmente le pratiche migliori; e non è detto che il risultato sarà esattamente quello che volevate. Anzi in alcuni potrebbe essere anche meglio (per me è stato così)

Quali saranno i prossimi obiettivi? Chi può dirlo; c’è ancora tanto da fare e sarà bello scoprirlo con i colleghi e collaboratori di tutti i giorni

Benvenuto 2019!!!

Pubblicato in Uncategorized | Contrassegnato | Lascia un commento

La legge di Postel – ovvero il Principio di Robustezza

Nella storia di Internet, Jon Postel ha sicuramente ricoperto un ruolo fondamentale e spesso poco conosciuto. Se Tim Barners Lee ideò il WWW, l’ipertesto, il concetto di browser e l’HTML, se Vint Cerf ideò il protocollo TCP e quindi i protocolli che permettono la comunicazione tra i nodi collegati sulla rete, Postel, meno famoso degli altri due, ideò il protocollo IP, pensato per la gestione complessiva della rete; e di fatto fu, fino al 1998, il garante del funzionamento di Internet, della sua neutralità e del suo sviluppo, al punto che in quegli anni l’Economist scrisse “Se internet ha un Dio, quello è probabilmente Jon Postel”, sottolineando il ruolo e l’enorme lavoro che per anni svolse Postel per garantire che le varie reti mondiali potessero comunicare su Internet.

E, in mezzo a tanti fisici e ingegneri geniali, ma spesso “arroganti” o comunque difficili da mettere d’accordo, fu un mediatore che seppe spesso trovare la soluzione e l’approccio giusto per superare alcune divergenze. Fino a definire un principio alla base di Internet che ha fortemente influenzato il suo funzionamento fino ai nostri giorni, il Principio di Robustezza:

be conservative in what you do, be liberal in what you accept from others.

ovvero:

sii conservatore in ciò che fai, Liberal in ciò che accetti dagli altri

Continua a leggere








Pubblicato in Leggi Sviluppo Software | Contrassegnato | Lascia un commento

La Regola del 90-90

La trilogia dedicata al processo di stima dei progetti software (e non solo software) si chiude con l’ultima regola che probabilmente è anche la più cinica verso chi fa del software il proprio lavoro. Se la Legge di Hofstadter lega la difficoltà della stima alla complessità della realtà, se la Legge di Parkinson spiega la difficoltà del rispetto delle stime legandola ad aspetti psicologici sulla gestione del tempo, la Regola 90-90 in maniera umoristica e cinica ci dice che nei progetti software stimare o provare a rispettare le stime è praticamente inutile.

La Regola 90-90 fu ideata nel 1985 da Tom Cargill, un ingegnere dei Bells Labs, ragionando con alcuni colleghi sulla difficoltà di concludere i progetti software, sentenziò la seguente frase:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

ovvero

“Il primo 90% del codice occupa il primo 90% del tempo di sviluppo. Il restante 10% del codice occupa il restante 90% del tempo di sviluppo”.

Continua a leggere








Pubblicato in Leggi Sviluppo Software | Contrassegnato | Lascia un commento

La legge di Parkinson

Altra puntata legata al mondo delle stime, sicuramente uno degli aspetti più controversi nel mondo del software. Come per altro è controversa questa legge enunciata dallo storico britannico Cyril Northcote Parkinson nel libro “The Parkinson’s Law“.

Parkinson scrisse questo libro a seguito di un articolo satirico che scrisse sull’Economist in cui ironizzava sulla burocrazia; e dai temi dell’articolo ne trasse ispirazione per scrivere un libro in cui in modo satirico e spesso cinico, parlava dei difetti della burocrazia, sopratutto in merito alla gestione delle attività e del tempo all’interno delle pubbliche amministrazioni.

E formulò questa legge:

Il lavoro si espande fino a occupare tutto il tempo disponibile; più è il tempo e più il lavoro sembra importante e impegnativo

Continua a leggere








Pubblicato in Leggi Sviluppo Software | Contrassegnato | Lascia un commento

La legge di Hofstadter

Risultati immagini per eterna ghirlanda brillanteUn bel po’ di anni fa ormai, mi sono imbattuto nella lettura di un saggio che mi ha letteralmente folgorato. Si trattava di: “Gödel, Escher, Bach: un’eterna ghirlanda brillante“, di  Douglas Hofstadter. Il saggio è un viaggio tra le opere di logica di Godel, i quadri visionari di Escher e la musica di Bach: apparentemente sembrano cose molto lontane fra di loro ma in realtà dietro c’è un processo logico-mentale che accomuna le tre opere. Ad una seconda lettura, il saggio è ancora molto più articolato perché si rivela essere una riflessione sui processi mentali alla base del pensiero e sulle regole formali relative.

Senza volersi addentrare troppo nei contenuti del saggio, al suo interno viene enunciata una legge che ha segnato (e segnerà sempre) le metodologie di sviluppo del software, ed è legata alla percezione umana dei fenomeni complessi e del tempo

La legge enuncia:

It always takes longer than you expect, even when you take into account Hofstadter’s Law

ovvero

Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter

Continua a leggere








Pubblicato in Leggi Sviluppo Software | Contrassegnato | Lascia un commento

Articolo Interessante: The Art of Crafting Architectural Diagrams

Vi segnalo questo articolo Interessante:

The Art of Crafting Architectural Diagrams

The Art of Crafting Architectural DiagramsKey Takeaways Designing architectural diagrams might not be an easy task; it can be tricky or error prone, even for the simplest ones. Creating consistent and meaningful diagrams brings clarity and consensus across different stakeholders.

Continua su: http://ift.tt/2v6TRHn








Pubblicato in Uncategorized | Contrassegnato , , | Lascia un commento

Leggi Sviluppo Software – Legge di Linus

Tutti conoscono Linus Torvalds come il padre del sistema operativo Linux.

A lui si devono tante idee, innovazioni nel mondo dell’informatica: dal primo sistema operativo libero (Linux appunto), a Git (per la gestione dei sorgenti), ecc…

Nella fase di realizzazione del sistema operativo Linux, per la gestione delle funzionalità del progetto, optò per usare un approccio che viene chiamato bazaar. In che cosa consiste? Continua a leggere








Pubblicato in Leggi Sviluppo Software, Uncategorized | Contrassegnato , | Lascia un commento

Leggi Sviluppo Software – Principio di Pareto

Joseph Juran è stato un importante ingegnere americano, di origini rumene, che si è occupato nella sua vita sopratutto di qualità e di gestione della qualità, scrivendo diversi libri di successo.

Il suo punto di vista della qualità era decisamente in contrapposizione con il modello del taylorismo, riportando il concetto della qualità come legato alla dimensione umana, e sottolineando come la sfera umana, le interazioni tra le persone, l’ostacolo al cambiamento, siano spesso gli elementi che maggiormente mettono in crisi la qualità dei prodotti o dei processi, compreso ovviamente il software e tutto quanto ruota attorno al software, dalla progettazione allo sviluppo, test e rilascio.
Continua a leggere








Pubblicato in Leggi Sviluppo Software | Contrassegnato , | Lascia un commento

Le leggi alla base dello Sviluppo del Software

  • Ci sono alcune leggi che riguardano la logica, il comportamento umano, la matematica, la sociologia, la psicologia, ecc… che hanno un enorme impatto nei processi legati allo sviluppo del software

Alcune sono sotto gli occhi di tutti quelli che si occupano di software tutti i giorni, altri, invece, sono un po’ più difficili, ma ci sono. E quando ci si rende conto della loro esistenza e della loro ineluttabilità, appare molto più chiaro il perché di alcuni eventi, o di alcuni comportamenti, ecc…

In questa rubrica proverò a descriverne alcune che sento molto vicino al quotidiano e che vivo e osservo continuamente

Lista degli articoli pubblicati:

 








Pubblicato in Leggi Sviluppo Software | Contrassegnato , | Lascia un commento

Articolo Interessante: Big Data Infrastructure @ LinkedIn

Vi segnalo questo articolo Interessante:

Big Data Infrastructure @ LinkedIn

Big Data Infrastructure @ LinkedInYou are now in FULL VIEW | by | Sponsored Content

Continua su: http://ift.tt/2otga9L








Pubblicato in Uncategorized | Contrassegnato , , | Lascia un commento