bias

Il bias è una forma di distorsione della valutazione causata dal pregiudizio. La mappa mentale di una persona presenta bias laddove è condizionata da concetti precedenti non necessariamente connessi tra loro da legami logici e validi. Il bias, contribuendo alla formazione del giudizio, può quindi influenzare un'ideologia, un'opinione e un comportamento

modelli di business per Linux e l'Open Source

pubblicato 27 mar 2016, 02:12 da Calogero Bonasia

Mai come in questi ultimi anni il termine innovazione tecnologica è apparso tante volte sui giornali o sulle riviste specializzate e mai come in questi ultimi anni, nel nostro paese soprattutto, questo termine è divenuto frequente nei discorsi di imprenditori, politici e rappresentati delle organizzazioni sindacali.

La necessità sociale dell'innovazione tecnologica è stata riscoperta, dopo anni di torpore e di teorie non vincenti ancora oggi, purtroppo, in auge.

La crisi economica e industriale hanno messo in discussione molti dei principi sui quali era basata la politica industriale sul modello anni '60, orientata ai relativamente facili incrementi di potenzialità produttiva quale conseguenza di una forte domanda di beni di consumo e di investimento.

Oggi in parecchi non si spiegano come mai colossi dell'industria dell'informazione si siano "gettati" nel mondo di "Linux", condividendo le idee di Stallmann e di quelli che come lui sostengono le "libertà del software", apparentemente in contrasto con le dure leggi del profitto.

Ci si chiede da più parti come possa competere sul mercato un'azienda che rivela il suo prezioso bagaglio di conoscenze agli altri (concorrenti) senza chiederne niente in cambio? Quanto potrà durare il "fenomeno" Linux/Open Source? (mi si perdoni l'accostamento, visto che si tratta di due argomenti complementari ma distinti).

Il processo di innovazione tecnologica esula dal concetto più limitante che in genere si dà alla "progettazione" pura e semplice, ma con la quale si è tentati a volte di farla coincidere.

In termini economici classici, a ciascuna fase del procedimento di sviluppo di un prodotto, e cioè: la conoscenza di una domanda potenziale, la ricerca e sviluppo del prodotto finalizzata a soddisfare la domanda potenziale di mercato, l'ingegnerizzazione del prodotto delineato dalla ricerca, l'allestimento e l'avvio della produzione e l'avvio della commercializzazione, corrispondono certe entità di spesa.

In genere l'ingegnerizzazione e l'avvio della produzione assorbono anche più della metà della spesa globale delle fasi operative prima citate, specialmente quando si parla di produzione manifatturiera di grande serie, e oggi la produzione di "pacchetti software" è ad essa assimilabile per molti versi.

Specialmente oggi, in una situazione in cui la produzione industriale classica ristagna, specie nei settori di prodotti ad alto contenuto tecnologico, e in presenza di una continua riduzione dei prezzi dei componenti base in funzione dell'innovazione tecnologica, la ricerca e lo sviluppo, finalizzate alla realizzazione di un prodotto finale tale da poter reggere il mercato in termini di prezzo e di prestazioni, richiede un'assoluta attenzione e la capacità di operare ai livelli più sofisticati.

L'open source, o meglio, le conoscenze acquisite da chi si adopera nella ricerca e nel miglioramento continuo di qualcosa adottandone i principi libertari, è un enorme patrimonio tecnologico, oggi finalmente fruibile a costi così bassi, pressoché nulli, che chiunque può essere al tempo stesso, fruitore delle idee scientifiche e "scienziato".

L'accostamento di un appassionato di tecnologia ad un ricercatore in camice bianco può fare rizzare i capelli a qualcuno, certo.

Prima ancora di leggere Stalmann e l'ampia bibliografia sul tema "software libero", da semplice appassionato di astronomia mi accorgevo che sovente anche gli astrofili davano il loro contributo, in rapporto ai mezzi sicuramente inferiori di cui dispongono, alla comunità internazionale degli astronomi di professione.

La conoscenza è patrimonio comune di tutta l'umanità e in quanto tale non dovrebbe essere "rivenduta".

La condivisione di programmi per calcolatore a sorgente aperto (open source) permette quindi ad una azienda qualsiasi, non solo informatica, se si estende il concetto stesso di "software" inteso come "conoscenza", di scambiare continuamente esperienze tra i tentativi di soluzioni dei problemi interni e le informazioni che arrivano dall'esterno.

È essenziale per una buona riuscita del processo che nell'ambito aziendale vi siano dei "gate keeper", cioè degli organismi che rappresentano le "antenne tecnologiche" mediante le quali catturare le informazioni giuste nei tempi giusti, in una condizione odierna di sovraccarico della quantità di informazioni disponibili (veritiere o meno).

L'attività di queste unità aziendali, o di queste persone, ha un'importanza primaria nel generare e mantenere il necessario afflusso di informazioni per lo sviluppo delle idee.

Il vantaggio dell'open source è quello di prescindere dalla dimensione aziendale e di riuscire nel contempo a mantenere il passo con la concorrenza puntando più che sull'innovazione tecnologica, sulla capacità di mantenere una fetta significativa del mercato grazie alla propria capacità di produrre prodotti e componenti già assestati, a costo inferiore rispetto ai concorrenti.

Anche una realtà medio-piccola del settore informatico, attingendo all'open source, focalizzandosi su una buona organizzazione produttiva, processi snelli, e lucrando particolari condizioni di favore in termini di costo delle risorse o della mano d'opera, ad esempio, potrebbe competere sui mercati internazionali alla stregua di queste nostre piccole e medie imprese che vendono prodotti italiani nel mondo.

Nel caso specifico, la "mano d'opera" diviene non più mera esecutrice, ma patrimonio aziendale. È quindi la risorsa umana e non il software prodotto, ad essere la vera ricchezza dell'azienda, che può in questo modo permettersi il "lusso" di elargire a terzi, e sembra un controsenso, addirittura senza immediati ritorni economici, il proprio codice sorgente.

leggi il libro


resisto dunque sono

pubblicato 27 mar 2016, 02:11 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 02:11 ]

Definirsi professionista informatico non è semplice: solitamente rientra in questo insieme sia il semplice appassionato di grafica computerizzata oppure il web master dilettante che colui che progetta un sistema informativo per la gestione di un impianto nucleare o il sistema di prenotazione di una compagnia aerea.

Il motivo è dovuto sia alla passione per la tecnologia che di solito accomuna questi soggetti e le barriere d’accesso molto basse: chiunque, in sostanza, può definirsi professionista dell'informatica e proporsi sul mercato.

Un concetto nevralgico della questione è dovuto al risultato della disoccupazione di massa, che provoca la progressiva alienazione dal resto della società dei giovani che vogliono ancora un lavoro, nonostante le difficoltà per ottenerlo. Giovani che sperano ancora di poter fare una carriera soddisfacente.

Mi è capitato di visitare il sito di Claudio Erba e leggere un interessante documento dal titolo "Mucche da mungere e gatti selvatici" nel quale si affronta il tema di come proporsi sul mercato informatico mediante semplici regole di marketing.

In termini più generali, esiste il pericolo che nel decennio futuro la società non solo sarà segnata da una crescente divisione tra “noi” e “loro” (intendendo, grosso modo, con questi due termini i dirigenti e la manodopera), ma vedrà aumentare le fratture all’interno dei gruppi più importanti, perché i giovani e coloro che sono relativamente privi di protezione sociale si troveranno in contrasto con i lavoratori che hanno maggiore esperienza e che sono maggiormente tutelati.

Il mercato dei professionisti dell’informatica è molto agguerrito, oltre che molto dinamico, per via della congiuntura economica che ha ristretto la frequenza dell’alternanza tra i periodi positivi e periodi negativi, costringendo gli operatori economici a contrarre o espandere di conseguenza la domanda di personale specializzato. Il terreno fertile in cui si sono sviluppati i cosiddetti contratti flessibili.

In uno scenario di questo tipo le certezze del dipendente che venti anni fa poteva contare sul posto fisso e di conseguenza sulla liquidazione e sulla pensione, oggi sono scemate o scomparse del tutto, perché si lavora per pagare la pensione a chi già gode di benefici acquisiti che è impossibile togliere. In Italia, inoltre, ci si trova a dover competere con il ragazzino mantenuto agli studi dai genitori, che quindi non ha i costi di gestione cui va incontro chi invece apre tutti i giorni la porta del proprio studio o si mette in auto per individuare nuovi clienti.

È difficile distinguere il professionista vero da quello improvvisato e i clienti sono poco preparati dal punto di vista informatico per poter discriminare tariffe e competenze. Appunto, una situazione di questo tipo non si rileva in nessun’altra libera professione. Per esempio gli avvocati, i notai o i medici, agiscono nell’ambito di confini prestabiliti. Non si vede un informatico che si improvvisa chirurgo o che convalida un atto di acquisto di una casa, sebbene si trovano più facilmente medici dediti all’informatica (con risultati a volte sorprendenti) e notai e avvocati che provvedono alla redazione di documenti di analisi del rischio informatico.

Si è ormai anche diffusa l’idea che il software e le tecnologie sono “commodity”: significa che si compera, si monta e si usa, senza necessariamente sapere ulteriori dettagli sul suo funzionamento. Non servono professionisti, basta gente che sappia “montare” le cose o “aprire le scatole” di cartone e dare sempre conferma alle domande poste dalla procedura di installazione del programma.

Perché mai si dovrebbe pagare un professionista per compiere questi semplici gesti? È sufficiente un tecnico, come quello che monta l’antenna della televisione satellitare o viene a riparare la lavatrice guasta. Il software e le tecnologie non sono commodity. Non basta la gente con gli MBA che non ne sa nulla di tecnologia per utilizzarle. Servono professionisti esperti dell’ICT.

Nel libro si offrono spunti interessanti. Ad esempio, per i venditori che conoscono il livello di qualità dei loro prodotti (e servizi) ma che non si preoccupano del livello di competenza dei loro acquirenti, si può arrivare a due conseguenze: o non si crea un mercato, oppure vengono venduti solo prodotti di qualità scadente.

Infatti, il modello di mercato dei bidoni teorizzato da Akerloff dimostra che i consumatori, non potendo distinguere beni di alta qualità da beni di qualità inferiore o scadente, sono disposti a pagare un prezzo medio che soddisfa solo i produttori di beni di scarsa qualità. Anche senza arrivare a questi estremi è indubbio che un’incompleta informazione porti ad una riduzione del livello qualitativo in un determinato mercato di riferimento.

I consumatori non sono in grado di riconoscere e valutare correttamente i beni, perciò i produttori non sono incentivati a realizzare alta qualità. La soluzione a questa situazione è la pari informazione tra le parti.

L’Italia si distingue per i cosiddetti distretti produttivi (tessile, meccanico, anche elettronico o manifatturiero in generale), caratterizzati da piccole imprese, spesso a conduzione familiare, che però hanno sostenuto l’economia nazionale fino ad oggi e che in moltissimi casi riescono persino ad eccellere sui mercati internazionali, tendenzialmente caratterizzati dalla presenza di uno o pochi monopolisti che in nome della cosiddetta globalizzazione pretendono di uniformare prodotti e consumatori di ogni continente.

Anche nel campo informatico esistono aziende che in alcuni casi detengono, più o meno realisticamente rispetto al valore intrinseco del loro prodotto (intendo per qualità tecnologica) il monopolio del mercato di riferimento.

Grazie ai programmi a codice sorgente aperto, un informatico professionista o una piccola software house italiana, può potenzialmente concorrere con una grande azienda o persino con il monopolista del suo mercato di riferimento. Grazie alla naturale predisposizione alla collaborazione di gruppo ad un progetto comune, persone e realtà aziendali anche distanti tra di loro, persino in continenti diversi, possono costituire una sorta di “distretto virtuale” nel non luogo rappresentato da Internet.

Mediante la circolazione delle informazioni e grazie alla collaborazione reciproca di una squadra di esperti, si forma uno strato di base sul quale poggiare un’eventuale strategia di business per aggredire quote di mercato. Solitamente, inoltre, la peculiarità geografica di alcuni degli attori interessati al particolare processo economico, impedisce che si formi un’elevata concorrenza: ciascuno riuscirà, in virtù della propria dimensione, ad agire all’interno di un’area geografica circoscritta.




liberarsi dalle scatole nere

pubblicato 27 mar 2016, 02:07 da Calogero Bonasia   [ aggiornato in data 17 giu 2016, 06:12 ]

In un paese in cui la ricerca scientifica trova possibilità di finanziamento e di incentivi da parte dello Stato le necessità di creare tali capacità all'interno dell'azienda sono ovviamente minori, in quanto gli operatori economici, concorrendo attraverso le spese dello Stato al conseguimento di un tale risultato, possono usufruire di ritorno, per così dire, dei benefici di una tale attività collettiva. 

In quei paesi in cui lo Stato finanzia, per propria necessità comunitaria, gli studi e gli sviluppi in determinate tecnologie, non solo le aziende interessate possono usufruire direttamente di tali benefici, in modo diretto come finanziamento alla ricerca ed aiuto alla produzione di prodotti innovatori, ma anche le altre aziende non direttamente coinvolte dal programma finanziato dallo stato possono godere del "fallout tecnologico", della ricaduta cioè della conoscenza che comunque, da tali operazioni, viene distribuita sul tessuto sociale del paese.

La struttura propria di ricerca e sviluppo di un'azienda dipende anche dal grado di sviluppo tecnologico in senso generale del paese stesso o della zona geografica del paese in cui l'azienda deve operare: in un paese ad alto livello tecnologico la presenza di istituti privati e pubblici, di università e di enti di ricerca può indubbiamente facilitare l'acquisizione di know-how da parte dell'azienda e non richiedere quindi al suo interno la presenza di un gruppo di ricercatori troppo grande. 

Si può persino giungere all'apice del processo, e cioè che lo Stato divenga "esportatore" di conoscenza verso altri stati che necessitando di risorse umane altamente specializzate, possono comprare da università o enti di ricerca per produrre poi tecnologia. 

Ad esempio l'India acquista conoscenza dagli USA, sotto forma di programmi universitari, scienziati e ricercatori, che vanno a trasmettere agli indiani quelle ""materie prime" che altrimenti non avrebbero o che costerebbero troppo (tempo) per essere ottenute.

Un po' come comprare il petrolio o le automobili per muoversi... solo che qui le autostrade sono "quelle dell'informazione" e arrivano dappertutto a costi molto bassi... Capita sempre più spesso difatti di trovarsi ad utilizzare codice Open Source scritto in nazioni considerate terzo mondo dal punto di vista industriale classico. Il vantaggio è però che mantenendo la mano d'opera in un'altra nazione, alla quale si vende solo il know-how, i costi di gestione rimangono in quella nazione.

È insomma un modo per accrescere le quote di mercato, invadendo, pacificamente in un certo senso, altri paesi, giacché la regola basilare dell'economia mondiale attuale, è l'invasione dei mercati per sopravvivere, essendo comunque destinati a morire non appena tale mercato si verrà a saturare.

Inventando sempre nuovi mercati si procrastina di volta in volta questa "morte annunciata". Pur essendo, quindi, la funzione di ricerca e sviluppo abbastanza simile in qualsiasi tipo di azienda, le sue strutture, il suo costo in termini di impegno economico e di struttura organizzativa variano molto da azienda ad azienda, da paese a paese, da settore a settore e nella singola azienda nell'ambito del settore. I problemi di carattere interno all'azienda dipendono in parte, come abbiamo visto, dalla situazione esterna in cui tale azienda si trova. 

Ma vi sono anche dei motivi tipici dell'azienda che ne condizionano l'atteggiamento verso i problemi di ricerca e sviluppo. Se ne potrebbero citare molti, ma secondo me i più importanti sono l'origine dell'azienda; l'atteggiamento del management verso i problemi dell'acquistare piuttosto che produrre e l'atteggiamento "interno".

Se il fondatore dell'azienda era un ricercatore o un tecnico di grandi capacità, l'azienda molto probabilmente risentirà della verticalizzazione, per così dire, della ricerca nella persona dell'imprenditore, e così la struttura dei laboratori sarà orientata, soprattutto se la produzione è in qualche modo una diretta conseguenza dell'innovazione tecnologica, o dell'invenzione, dell'imprenditore.

Al contrario, un'azienda in cui non esista una simile figura, i laboratori di ricerca rappresentano l'evoluzione di più discipline e di più ricercatori: da qui la necessità di un articolato organigramma e di sistemi di informazione interna che dovranno supplire alla mancanza di una spinta basata sull'io dell'imprenditore-inventore. Il management si sostituisce in questo caso all'iniziativa puramente personale.

L'atteggiamento del management delle moderne aziende verso i problemi dell'acquistare piuttosto che produrre (make or buy) deriva dal fatto che alcune aziende ritengono vantaggioso e più facile reperire il know-how per ottenere certi risultati mediante ampie politiche di acquisizione di attività già avviate o di centri di ricerca. 

Infine, l'atteggiamento interno delle aziende alimentano nei confronti della ricerca e sviluppo caratterizza anche l'entità degli investimenti che l'azienda è portata a realizzare per la ricerca e sviluppo.

Per concludere, l'importante, pur tenendo nel debito conto i problemi derivanti dalle differenti situazioni sopra indicate, è che la ricerca e sviluppo all'interno di un'azienda siano correttamente impostati in funzione dei risultati che l'azienda vuole ottenere e della strategia che essa si è scelta; altrettanto importante è che essa, tenuto conto di tali obiettivi, riesca ad ottenere un alto grado di efficienza, abbia cioè la capacità di usare nel modo più proficuo le proprie e delle altrui capacità.



social business e gestione documentale

pubblicato 27 mar 2016, 02:05 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 02:05 ]

"social business": un nuovo modo di lavorare che supera i vecchi modelli organizzativi aziendali, rigidi e schematici (...)

La gestione elettronica dei documenti sta cambiando in modo radicale. La spinta proviene innanzitutto dalla crescente necessità di collaborazione con altre persone all’interno dell’azienda mediante nuove forme di interazione diretta che superino le abusate comunicazioni via posta elettronica.

Le tecnologie social, permette di connettere le persone più efficacemente, ottenere il loro coinvolgimento, mettere meglio a frutto l’intelligenza e l’energia collettive, favorire le nuove idee e i cambiamenti organizzativi.

Vengono quindi creati gruppi di lavoro centrati sulla collaborazione e la condivisione fra persone eterogenee di settori diversi, interni e anche esterni all'azienda, favorendo lo scambio di nuove idee: i partecipanti operano all'interno di un ambiente comune, condividendo contenuti e messaggi in modo veloce ed efficiente, svincolato dall'uso delle e-mail e basato invece su insieme di notifiche semplici e meno invasive.

Inoltre una grande quantità di conoscenza preziosa per l’azienda resta "imprigionata", sequestrata nelle caselle inbox dei client di posta elettronica, ed è difficoltoso ricercarla e recuperarla quando occorre. 

Problemi come questi hanno spinto diverse organizzazioni a bandire l’utilizzo delle e-mail nelle comunicazioni al proprio interno.

Si stima che dal 25 al 30% del tempo totale dedicato alla gestione delle e-mail potrebbe essere reimpiegato, se il canale predefinito per le comunicazioni fosse convertito sulle piattaforme sociali.

E l'e-mail rappresenta solo un aspetto. Infatti le organizzazioni potrebbero innalzare ulteriormente l’efficienza di una buona parte della giornata che i knowledge worker spendono ricercando e raccogliendo informazioni.

In aggiunta ai criteri di archiviazione dei documenti rigidi e prestabiliti dall'azienda in funzione dei processi, con l'uso dei tag gli utenti possono usare una classificazione ulteriore, personale e informale, che fornisce maggiore flessibilità e semplicità al loro lavoro.

Rilevante è anche la portata delle notifiche, che non sono effettuate tramite e-mail ma mediante un sistema di messaggistica interna che opera come strumento di comunicazione istantaneo fra la piattaforma e gli utenti e fra utente e utente, alleggerendo così la casella di posta elettronica.

Ciascun utente visualizza sulla propria schermata di lavoro sul PC o sul proprio dispositivo mobile le notifiche di propria competenza: lo informano sull'esito dell’elaborazione di un lotto di documenti, ad esempio di una spedizione massiva, oppure gli segnalano la necessità di un suo intervento per l’approvazione ad esempio del pagamento di una fattura, l’emissione di un ordine o l’invito a partecipare ad un gruppo di lavoro.

L’uso delle interfacce native dei dispositivi non obbliga gli utenti ad imparare le funzioni di un client, come finora richiesto dalla gestione documentale.

La prevista diffusione dei processi collaborativi e l’allargamento della gestione documentale a tutti gli utenti aziendali richiedono il supporto di un sistema documentale che non sia un semplice pacchetto applicativo ma abbia tutte le caratteristiche di sicurezza, affidabilità e scalabilità tipiche di un sistema enterprise, ad esempio di un ERP aziendale.

Il problema è come convincere i vari addetti di un’organizzazione ad incamminarsi su questo percorso di profonda trasformazione culturale, di cambiamento dell'approccio mentale per affrontare lo svolgimento dei vari compiti lavorativi.

La strategia aziendale deve incoraggiare la nuova modalità di collaborazione: infatti, più i partecipanti connessi al social network aziendale hanno un’esperienza positiva di questo modo di lavorare, più lo integreranno di buon grado nei propri schemi operativi. 

Una positiva esperienza collaborativa crea fiducia, che è la chiave fondamentale per concretizzare un reale cambiamento culturale.



i benefici del rilascio continuo

pubblicato 27 mar 2016, 01:50 da Calogero Bonasia   [ aggiornato in data 03 ago 2016, 01:18 ]

Lo sviluppo del software si sta muovendo verso la cosiddetta "integrazione continua" ossia built-in test e monitoraggio costante per aumentare la capacità di reagire e diventare imprese "real-time business". Con la sigla "CD" si indica la continuous delivery, una metodologia, mi piace definirla tale, che tante organizzazioni stanno già adottando dove esiste l'esigenza di garantire alte prestazioni, come Netflix ed Etsy ad esempio.

I benefici della CD sono abbastanza evidenti: 

Tempi di reazione più rapidi
Il vantaggio più evidente del CD è che consente reazioni rapide agli stimoli, sia esterni che interni, per esempio la classica riduzione degli sprechi finanziari oppure l'implementazione di "quello che non va fatto" nell'ambito della gestione della sicurezza delle informazioni.

Rischio ridotto
Capita a molte organizzazioni di focalizzarsi troppo sulla forma delle procedure di rilascio. È corretto porre attenzione a questa fase delicata, perché dopo il rilascio, l'applicazione è nelle mani del cliente e tutto deve andare bene. Il rovescio della medaglia è che per garantire che tutto vada nel verso giusto, occorre investire tempo e risorse per costituire un buon team di QA (Quality Assurance) oltre che quello di Release Engineering. In questo senso va inteso il rispetto della "forma" nelle procedure, come fosse una sorta di revisione continua (e quindi miglioramento continuo) del processo di rilascio stesso.

Individuazione chiara dei costi e delle inefficienze
Sia che si tratti di un servizio sul WEB che di una copia master ISO, ogni organizzazione software affronta un certo costo per consegnare "i bit" al cliente. Spesso, questi costi non sono del tutto chiari per chi si occupa soltanto degli aspetti amministrativi e finanziari. La metodologia del rilascio continuo rende questo processo più chiaro a tutti i livelli aziendali. 

Per esempio, se immaginiamo di costruire un oleodotto, sarà chiaro (a tutti) dove sono impiegate le risorse, quali sono i colli di bottiglia e quali procedure adottare per automatizzare la "consegna" del prodotto che transita all'interno dell'oleodotto. 

Una volta collegate le tubature, come dire, avremo un "circuito" collaudato che renderà semplice (ed economica) la consegna del prodotto al cliente.

Opzioni di rilascio flessibili. Trasformare i processi di progettazione, sviluppo, collaudo e consegna di un prodotto adottando un modello di erogazione continua comporta l'adeguamento dell'infrastruttura informatica, sia in un contesto operativo che come strumenti software. 

Poiché CD richiede una "intelligente" revisione dei processi tecnici, cultura operativa e pensiero organizzativo, spesso si rinuncia credendo che siano ostacoli insormontabili. 

Certamente il lavoro da svolgere sarà proporzionato a quanto potrebbero essere stati trascurati questi aspetti nel corso degli anni.

Molte iniziative di CD sono deragliate a causa dell'insistenza del product manager che convince la gestione aziendale sull'importanza (eccessiva) di una certa funzionalità, dandole priorità assoluta. Spesso sottostimando la possibilità di rientrare "sui binari" delle procedure di rilascio non appena superata l'eccezionalità anzidetta. 

Invece sappiamo tutti come andrà a finire: è come staccare le radici ad un albero che ha appena iniziato a dare i suoi frutti seppure acerbi.

Come un albero da frutto, la CD richiede fondamentalmente una certa quantità di impegno per potare i rami secchi e curare quelli che fruttano. Si tratta di una rivoluzione culturale che necessariamente intacca i "silos organizzativi" presenti in ogni azienda. Le persone all'interno di questi silos vanno aiutate nel cambiamento, supportate con documentazione e con formazione specifica, altrimenti, comprensibilmente, combatteranno per mantenere salde le loro posizioni di rendita.

Come scrive Martin Fowler ci sono diverse attività necessarie per far funzionare il rilascio continuo: 

"mantenere tutto il codice sorgente in un solo luogo (source repository), a cui chiunque può accedere per ottenerne la versione più recente (e quelle precedenti); automatizzare il processo di compilazione e "impacchettamento", in modo che a chiunque basti utilizzare un unico, semplice comando per costruire il sistema, partendo dai sorgenti; automatizzare i test in modo da poter eseguire, in qualsiasi momento e con un unico comando, una sequenza di controlli completa; assicurarsi che chiunque possa ottenere l'ultima versione eseguibile, di cui si è certi essere al momento quella migliore."

Il beneficio fondamentale derivante dalla Continuous Delivery è la rimozione di sessioni di lavoro durante le quali le persone trascorrono il loro tempo a caccia di bug, che si verificano quando il lavoro fatto da una persona si sovrappone a quello fatto qualcun altro, senza che nessuno dei due si renda conto di quello che è successo.

riferimento al libro: "Partire leggeri. Il metodo Lean Startup: innovazione senza sprechi per nuovi business di successo" -- http://goo.gl/dz8AsB

#googleplus #facebook



attivare la definizione assoluta della data in JIRA

pubblicato 27 mar 2016, 01:48 da Calogero Bonasia   [ aggiornato in data 03 lug 2016, 03:50 ]


Normalmente la data viene visualizzata come "Yesterday 6:12 PM" mentre sarebbe più comodo, come richiesto da alcuni utenti, visualizzare la data nel suo formato tradizionale, ovvero 12 giugno 2014 ore 06.12 PM"

Il problema è stato affrontato (e momentaneamente risolto) nella segnalazione

https://jira.atlassian.com/browse/JRA-41506

in pratica occorre modificare il file jira-application.properties inserendo, se non presente la direttiva

jira.lf.date.relativize = false 



etica hacker e "modello fordista"

pubblicato 27 mar 2016, 01:47 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 01:47 ]

Ogni decisione presa nella vita emerge dai valori e dagli obiettivi personali, che possono variare da individuo a individuo: la fama, il denaro, l'amore, la sopravvivenza, il divertimento e la libertà sono soltanto alcuni degli obiettivi perseguiti da una persona. Quando l'obiettivo è quello di aiutare tanto gli altri quanto sé stessi, lo si definisce idealismo.

La passione di chi scrive, per il software libero è motivata da uno scopo idealistico: diffondere la conoscenza e stimolare la collaborazione; sostituendo il software proprietario che vieta la cooperazione, per contribuire, così, al miglioramento della società.

Esiste una contraddizione fondamentale tra cieca fede nel progresso della tecnologia e la dura realtà caratterizzata dalla lotta per la sopravvivenza, che coinvolge la stragrande maggioranza degli abitanti di questo pianeta. Il progresso dovrebbe facilitare la sopravvivenza, perché avviene il contrario? Se il fine ultimo è fare soldi, si trascura completamente la passione per quello che si fa ogni giorno, e si finisce per smettere di coltivare passioni.

Cosa c'entra tutto questo con gli hacker? Semplice: un hacker è soprattutto un uomo mosso dalla passione per ciò che fa. Non ha una particolare fede ideologica, né disdegna il lavoro che comunque si manifesta nell'economia odierna. Il fine da raggiungere non è quindi il denaro, bensì rendere il mezzo informatico e la tecnologia digitale, un bene rivolto alla maggioranza delle persone per migliorarne le condizioni di vita e le aspirazioni di benessere. 

È sentirsi responsabili per le conseguenze a lungo termine della società digitale e aiutare direttamente coloro che rimangono ai margini.

Preoccuparsi, in modo più generale, degli altri è un fine a sé stante e rivela il desiderio di eliminare la logica della lotta per la sopravvivenza, che ispira gran parte delle azioni nelle società capitalistiche. Il sistema del diritto d'autore è nato e cresciuto con la stampa: una tecnologia per la produzione di massa di copie e si adatta bene a questa tecnologia perché pone restrizioni solo ai produttori di massa di copie. Non riduce la libertà dei lettori di libri. 

Inoltre, un lettore ordinario, che non possiede una sua tipografia, può copiare i libri solo a mano e pochi lettori sono stati perseguiti per questo. La tecnologia digitale è ovviamente più flessibile della stampa tipografica: l'informazione si può copiare facilmente per condividerla con altri: questo spiega le misure draconiane che vengono oggi usate per far rispettare il diritto d'autore sul software.

Nella ex Unione Sovietica ogni fotocopiatrice aveva una guardia per impedire le copie proibite e le persone erano costrette a copiare le informazioni in segreto. Il motivo per il controllo dell'informazione nell'Unione Sovietica era politico; negli Stati Uniti il motivo è il profitto. Quello che ci riguarda sono le azioni, non il loro motivo. 

Ogni tentativo di bloccare la condivisione delle informazioni, quale ne sia il motivo, porta agli stessi metodi e alla stessa severità. I proprietari di software usano vari tipi di argomenti per ottenere il potere di controllare in che modo usiamo l'informazione.

Le conoscenze/competenze dei cosiddetti "hackers" corrispondono a un tipo di sapere difficilmente conservabile perché tende, per sua natura, a invecchiare subito; le tecnologie di rete, tra novità e sperimentazione, mutano velocemente, di conseguenza anche le competenze per usarle, testarle, ripararle e modificarle. 

Occorre rivedere di continuo i profili professionali individuali, e spesso la scuola pubblica e la formazione in generale sono carenti e anacronistiche nell'offrire la preparazione adeguata.

La necessità di sapere coinvolge più individui, spingendoli a creare gruppi e a fare comunità, evidenziando come questo sapere-tecnico costituisca un collante sociale.

Gli hacker non sono quindi pirati che rubano i dati o inventano infernali virus per rovinare i computer che usiamo tutti i giorni. Spesso queste figure sono confuse con i "cracker", i quali per l'appunto, si dilettano per diversi motivi, ad acquisire dati illegalmente, creare virus o danneggiare siti in diversi modi.

Il lavoro degli hacker ha permesso, piuttosto, la creazione dei calcolatori stessi, dei modem, l'affermazione planetaria di Internet, l'invenzione della realtà virtuale. Si tratta di risultati straordinari, nati da un approccio al lavoro opposto agli schemi "fordisti" che scandiscono l'esistenza quotidiana.



il caffè puoi prenderlo anche amaro ...

pubblicato 27 mar 2016, 01:45 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 01:46 ]

Avete presente quando siete davanti alla macchinetta del caffè e viene fuori il bicchiere senza la bacchettina di plastica per mescolare lo zucchero?

Poco male... i più "ingegnosi" proveranno a risolvere il problema, inducendo un moto centrifugo al caffè oppure impiegando una bacchettina del giorno prima che è rimasta "a disposizione" sul tavolo in ufficio intrattenuta dai batteri di passaggio...

Ma una certa parte di "utenti" della macchinetta del caffè potrebbero invece pensare che i soldi inseriti nella fessura siano stati "spesi malissimo".

Io credo che sia la stessa sensazione che prova un cliente quando, dopo avere investito tempo e denaro, si affida ad una software house di provincia legata mani e piedi al "colosso americano del software proprietario" e scopre di avere sperperato appunto tempo e denaro perché si trova per le mani un software "senza la bacchettina di plastica".

Per evitare di "dimenticare la bacchettina di plastica", chiedete al vostro fornitore se, ad esempio, durante lo sviluppo del software, applica metodologie agili oppure Test Driven Development.

Quest’ultima, è una pratica piuttosto difficile, forse è per questo che ho raramente incontrato aziende dove viene applicata, nonostante esista una quantità enorme di documentazione (anche in lingua italiana).

In queste realtà ho sentito le giustificazioni tipiche: "non abbiamo mai il tempo per scrivere quei test", oppure "ma noi i test li facciamo, rilasciamo il programma e mentre il nostro commerciale se ne va in giro a vendere il software che siamo coscienti ha dei bug, correggiamo i difetti nella prossima release che uscirà tra 12 mesi..., il cliente deve capire e deve aspettare".

Il cliente ovviamente non aspetta e non intende "capire" ...

Come suggerito dal nome, TDD è fondamentalmente una pratica di sviluppo software incentrata sui test. Lo sviluppo tradizionale viene "stravolto": in TDD si sviluppa in primo luogo il codice di test della funzionalità d'interesse, poi il codice applicativo che tale funzione implementa. Solo (e solo se) si ha un test che fallisce, si potrà procedere allo sviluppo del codice applicativo.

Il TDD si basa su queste due regole:
non scrivere codice applicativo se non si dispone di un test automatico che fallisce
eliminare le eventuali duplicazioni in modo tale da mantenere il codice quanto più possibile semplice.
Più in dettaglio, il processo TDD è definibile in questo modo:
aggiungere un test prima di codificare la funzionalità applicativa
codificare la funzionalità applicativa in una forma minimale ancorché compilabile
lanciare il test (che ovviamente dovrà fallire)
modificare il codice applicativo che implementa la relativa funzionalità
eseguire di nuovo il test

A questo punto il processo ha due possibili uscite:
se il test fallisce, bisogna provvedere alle relative modifiche del codice applicativo e quindi eseguire di nuovo i test
se il test ha successo occorre ripulire il codice da eventuali duplicazioni e ripetere la sequenza indicata sopra.
Il processo si considera concluso quando si verifica con successo l'ultimo passo (secondo punto di uscita).

I vantaggi principali quindi sono due:
i test permettono di individuare con precisione le specifiche del codice, e quindi il suo comportamento in base alle situazioni a cui sarà sottoposto. Ciò facilita la produzione di un codice funzionante in qualunque circostanza, più pulito e più affidabile
scrivendo i test prima del codice, si utilizza il programma prima ancora che venga realizzato.
Quest'ultimo punto è abbastanza importante per evitare che venga fuori un bicchiere di caffè senza la bacchetta per girare lo zucchero, perché ci si assicura che il codice prodotto è testabile singolarmente.

Tutto il processo è scandito da tre ben precise fasi:
fase rossa: scrivere un test che non funziona
fase verde: fare in modo che il test funzioni sviluppando l'opportuna logica applicativa
fase di rifattorizzazione: eliminare le eventuali duplicazioni (e gli eventuali "rattoppi") di codice creati durante la modifica del codice applicativo "alla ricerca dello status verde".
È dunque possibile accorgersi per tempo che "non verrà fuori la bacchettina di plastica"...

L'applicazione di TDD obbliga ad avere una visione precisa del modo in cui verrà utilizzato il programma prima ancora d'essere implementato. Occorre anticipare gli errori concettuali durante la realizzazione dell'implementazione, senza che si siano definiti gli obiettivi.

Quindi non basta essere solo "bravi sviluppatori" ma occorre anche pensare in modo "agile", confidando sulle procedure di refactoring del codice e sui test che funzioneranno quando richiesto. Ci si potrà permettere di effettuare cambiamenti radicali di design, stando certi che alla fine otterranno un programma che si comporterà sempre alla stessa maniera (essendo i test sempre verificati).

Ovviamente il caffè potete prenderlo anche senza zucchero, quindi potete fare a meno della bacchettina di plastica.




rto e rpo, partiamo dalle basi

pubblicato 27 mar 2016, 01:37 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 01:37 ]


Il recovery point objective (RPO) e il recovery time objective (RTO) sono due parametri molto specifici strettamente associati con le attività di ripristino. Il parametro RTO indica quanto a lungo è possibile fondamentalmente andare avanti senza una specifica applicazione.

Questo è spesso associato con la massima interruzione ammissibile o tollerabile.

Il parametro RTO è realmente usato per prescrivere l’utilizzo della replicazione o del backup su nastro o disco. Ciò stabilisce anche cosa metterete assieme per un’infrastruttura, che si tratti di un cluster ad alta disponibilità per il failover senza soluzione di continuità, o di qualcosa di più modesto.

Se il vostro RTO è zero (non è possibile avere interruzioni) allora potete optare per un’infrastruttura completamente ridondante con dati replicati fuori sede e così via.

Se il vostro RTO è 48 ore o 72 ore, allora forse il backup su nastro è OK per quella specifica applicazione. 

Questo è l’RTO.

Il parametro RPO è leggermente differente. Questo disciplina la perdita di dati ammissibile – ossia quanti dati mi posso permettere di perdere? In altre parole, se faccio un backup serale alle 7pm e il mio sistema va in fiamme alle 4 del pomeriggio del giorno seguente, tutto ciò che è stato cambiato dal mio ultimo backup è perduto.

Il mio RPO in questo particolare contesto è il backup del giorno precedente. Se sono un’azienda che fa elaborazione di transazioni online – ad esempio American Express – bene forse il mio RPO risale fino all’ultima, recentissima transazione, fino agli ultimi bit d’informazione che sono entrati. Di nuovo, ciò indica il tipo di soluzione di protezione dati che volete mettere in atto.

Quindi entrambi i parametri, RTO e RPO, effettivamente influenzano il tipo di ridondanza o di infrastruttura di backup che metterete assieme. Più ristretti sono l’RTO e l’RPO, più denaro spenderete sulla vostra infrastruttura.




non buttare via la borraccia con l'acqua

pubblicato 27 mar 2016, 01:34 da Calogero Bonasia   [ aggiornato in data 27 mar 2016, 01:34 ]

Adriano Olivetti sosteneva già nel libro "L'ordine politico delle comunità e Società Stato Comunità":

Né lo Stato né l'individuo possono da soli realizzare il mondo che nasce. Sia accettato e spiritualmente inteso un nuovo fondamento atto a ricomporre l'unità dell'uomo: la Comunità concreta"

Forse pochi lo sanno o lo ricordano, ma fu proprio Olivetti, antesignano di uno dei principi che oggi stanno alla base del cosiddetto Agile, ad introdurre le unità di montaggio integrate, che rendevano gli operai responsabili dall'inizio alla fine del processo di realizzazione del prodotto, con maggiore autonomia lavorativa.

Anticipando i tempi con una sorta di "metodo Toyota"...

L'imprenditore sembra avere come unica strada per rimanere "vivo" sul mercato quella di socializzare il proprio rischio d'impresa con il professionista o il lavoratore destinato a diventare sempre più autonomo.

Questo va contro la tendenza, tipica dei "consulenti abbigliati come cresimandi, di ridurre il personale e i "costi" in generale, magari portando in outsourcing servizi fondamentali o addirittura il core business.

È come se un maratoneta pensasse di poter fare meglio buttando via le borracce con l'acqua per alleggerire il suo peso... alla lunga potrebbe disidratarsi a tal punto da non riuscire più a raggiungere la fine del percorso.



1-10 of 73