Home
5 risposte su… organizzare una programmazione Agile davvero Clean

06 Aprile 2020

5 risposte su… organizzare una programmazione Agile davvero Clean

di

Agile è un’idea meravigliosa quando viene eseguita facendo attenzione a queste tre semplici parole da seguire: pulizia, pulizia, pulizia.

Le 5 risposte

  1. I sistemi di gestione di progetti Agile sono buoni, ma non per tutti
  2. Che cosa vuol dire rilasciare in piccole release
  3. Non è detto che a un team Agile serva un coach
  4. Che cos’è il Cerchio della vita in Agile
  5. Perché non esiste un Agile “in grande”

1. I sistemi di gestione di progetti Agile sono buoni, ma non per tutti

Dopo l’affermazione di Agile, hanno cominciato ad apparire numerosi sistemi software per la gestione di progetti Agile. Questi sistemi Agile Lifecycle Management (ALM), che vanno da prodotti open source a lussuosi quanto costosi prodotti confezionati, consentono di raccogliere i dati del team Agile, gestire lunghi elenchi di funzionalità (backlog), produrre grafici sofisticati, fornire riepiloghi multi-team e svolgere alcune elaborazioni numeriche.

Sembra comodo avere un sistema automatizzato che ci aiuti in questo tipo di lavoro. Tuttavia, nonostante la loro ricchezza di funzionalità e il loro successo commerciale, gli strumenti ALM falliscono miseramente nell’essere considerati davvero ottimi. Questo fallimento ci fornisce alcuni ottimi spunti di riflessione.

  • I migliori strumenti possono essere appresi piuttosto bene rapidamente: i sistemi ALM tendono a essere complicati, e normalmente richiedono un notevole addestramento. Ma anche dopo l’addestramento, i membri del team spesso devono ricorrere a ricerche su Internet per cercare di capire come svolgere attività che dovrebbero essere semplici. Molti tollerano questa complessità dello strumento e finiscono per accettare metodi di lavoro lenti e macchinosi.
  • I migliori strumenti divengono trasparenti agli utenti. Vediamo costantemente membri del team controllare un driver per cercare di capire come funziona lo strumento. Fanno strane operazioni per manipolare le schede delle storie. Inciampano su storie, attività e assegnamenti, nel tentativo di tenere insieme il tutto. Una gran confusione. Questi strumenti spesso richiedono una costante attenzione.
  • I migliori strumenti sono aperti agli adattamenti e a utilizzi imprevisti. Vogliamo aggiungere dei campi a una scheda virtuale ALM? Innanzitutto dobbiamo trovare un programmatore esperto e dedicato (o, sarebbe meglio dire sacrificato) al supporto dello strumento. O potremmo addirittura dover inviare una richiesta di modifica al produttore. Un’operazione da cinque secondi con strumenti low-tech si trasforma in un ritardo di cinque giorni o cinque settimane con un costoso sistema ALM. Non sempre è facile adattarli.
  • I migliori strumenti sono economici. I costi della licenza d’uso di uno strumento ALM, che possono raggiungere le molte migliaia di dollari l’anno, sono solo l’inizio. L’installazione e l’uso di questi strumenti possono richiedere altre e ingenti spese sotto forma di corsi di addestramento, supporto tecnico e talvolta personalizzazione. La manutenzione e l’amministrazione incrementano ulteriormente gli ingenti costi di proprietà.
  • I migliori strumenti aiutano le persone a conseguire i loro obiettivi. Gli strumenti ALM solo raramente funzionano in un modo adatto al nostro team e spesso il loro funzionamento standard è contrario ai metodi Agile. Per esempio, molti strumenti ALM presuppongono che i membri del team abbiano assegnamenti individuali in termini di compiti, il che rende impossibili le collaborazioni nel team.

Alcuni strumenti ALM forniscono anche una sorta di gogna: un cruscotto che mostra il carico di lavoro, le prestazioni e i progressi (o non progressi) dei singoli programmatori. Invece di evidenziare il flusso di lavoro con l’obiettivo del completamento e di promuovere una responsabilità condivisa – in tipico stile Agile – lo strumento diviene un’arma usabile per puntare il dito sui programmatori e spingerli a lavorare di più e più a lungo.

Mentre i team dovrebbero riunirsi per le loro riunioni in piedi (le mischie quotidiane), finiscono per riunirsi per aggiornare il loro ALM. Lo strumento ha sostituito le interazioni fra persone con un report automatizzato dello stato dei lavori.

Peggio ancora, gli strumenti ALM spesso non riescono a diffondere le informazioni come gli strumenti fisici. Dobbiamo eseguire il login e cercare per trovare quello che desideriamo. Quando poi troviamo l’informazione di cui abbiamo bisogno, spesso otteniamo anche una grande quantità di altre informazioni inutili.

Magari in futuro, ma non oggi

Non vi è alcun motivo per cui gli ALM non possano, in futuro, diventare ottimi strumenti. Ma se dobbiamo solo gestire una parete di schede e dobbiamo usare un software, adottiamo uno strumento generale come Trello. Il panorama cambia costantemente).È facile, immediato, economico, espandibile e non provoca la nausea.

Dato lo stato corrente della maggior parte degli strumenti ALM, può essere più sicuro e intelligente iniziare a lavorare con gli strumenti fisici. Successivamente, potremo considerarel’uso di uno strumento ALM che sia di rapido apprendimento, trasparente nell’uso quotidiano, facile da adattare e alla nostra portata, in termini di prezzo d’acquisto e di utilizzo. Soprattutto, che supporti il modo in cui lavora il nostro team e che fornisca un reale ritorno dall’investimento.

Torna all’inizio.

2. Che cosa vuol dire rilasciare in piccole release

La pratica Piccole releasesuggerisce che un team di sviluppo software debba rilasciare il proprio software il più frequentemente possibile. Negli anni Novanta, ai primi tempi di Agile, pensavamo che questo significasse una release ogni mese o due. Al giorno d’oggi, al contrario, abbiamo un obiettivo molto, molto più breve: il Rilascio continuo, dopo ogni modifica.

Questa descrizione potrebbe essere fuorviante, perché il termine Rilascio continuofa sembrare che il ciclo che vogliamo accorciare sia solo quello di rilascio. In realtà, vogliamo accorciare ogniciclo.

Sfortunatamente, esiste una significativa inerzia storica ad accorciare i cicli. Tale inerzia ha a che fare con il modo in cui gestivamo il nostro codice sorgente qualche tempo fa.

Una breve storia del controllo del codice sorgente

La storia del controllo del codice sorgente è la storia dei cicli e delle loro dimensioni. Inizia negli anni Cinquanta e Sessanta, quando il codice sorgente si trovava nei fori praticati su schede cartacee.

Una scheda perforata

Una scheda perforata.

Molti di noi, a quei tempi, usavano schede perforate. Una scheda conteneva 80 caratteri e rappresentava una riga di un programma. Il programma stesso era costituito da una sequenza di schede, tipicamente tenute insieme da un elastico e conservate in una scatola.

Gruppi di schede perforate in una scatola

Gruppi di schede perforate in una scatola.

Il proprietario di tale programma metteva il mazzo di schede in un vassoio o un armadietto. Se qualcuno voleva controllare il codice sorgente, doveva estrarlo dal vassoio o dall’armadietto, con il permesso del proprietario.

Se avevamo controllato il codice sorgente, eravamo l’unica persona che potesse modificarlo, perché ne avevamo il possesso fisico. Nessun altro poteva toccarlo. Quando avevamo finito, restituivamo il mazzo al proprietario, che lo rimetteva nel vassoio o nell’armadietto.

Il tempo di ciclo di tale programma era la quantità di tempo nella quale un programmatore ne manteneva il possesso. Tale tempo poteva essere di giorni, settimane o mesi.

Nastri magnetici

Negli anni Settanta, abbiamo gradualmente eseguito una transizione, con la quale il nostro codice sorgente è finito, sotto forma di immagini di schede, su nastro magnetico. I nastri magnetici potevano contenere una grande quantità di moduli di codice sorgente ed erano facili da duplicare. La procedura di editing di un modulo era la seguente.

  1. Estrarre il nastro master dal rack master.
  2. Copiare i moduli da sottoporre a editing dal nastro master a un nastro di lavoro.
  3. Ricollocare il nastro master nel rack master, in modo che altre persone potessero accedere ad altri moduli.
  4. Porre una puntina colorata sulla lavagnetta accanto al nome dei moduli sui quali intervenire (io avevo il blu, il mio capo aveva il rosso e l’altro programmatore del mio team aveva il giallo e… sì, alla fine avevamo esaurito tutti i colori).
  5. Modificare, compilare e sottoporre a test i moduli usando il nastro di lavoro.
  6. Estrarre di nuovo il nastro master dal rack master.
  7. Copiare i moduli modificati dal nastro di lavoro a una nuova copia del nastro master.
  8. Riporre il nuovo nastro master nel rack master.
  9. Rimuovere la puntina dalla lavagnetta.

Ancora una volta, il tempo di ciclo era il tempo in cui la puntina restava sulla lavagnetta. Questo tempo poteva essere misurabile in ore, giorni o anche settimane. Fintantoché le puntine rimanevano sulla lavagnetta, nessun altro poteva toccare i moduli contrassegnati.

Naturalmente, questi moduli rimanevano comunque sul nastro master e, per errore, qualcun altro poteva violare le regole e modificare i moduli contrassegnati. Pertanto, le puntine erano solo una convenzione, non una barriera fisica.

Dischi e SCCS

Negli anni Ottanta, abbiamo trasferito il nostro codice sorgente su disco. All’inizio, continuavamo a usare le puntine sulla lavagnetta; poi cominciarono ad apparire i primi veri strumenti di controllo del codice sorgente. Il primo che mi ricordo si chiamava SCCS (Source Code Control System). SCCS si comportava come una lavagnetta. Si bloccava un modulo su disco, per impedire a chiunque altro di modificarlo. Questo tipo di blocco è chiamato blocco pessimistico. Di nuovo, il tempo di ciclo era dato dalla durata del blocco, che poteva essere di ore, giorni o mesi.

Il SCCS lasciò il posto al RCS (Revision Control System), che lasciò il posto al CVS (Concurrent Versions System), che usavano tutti una forma o un’altra di blocco pessimistico. Così il tempo di ciclo rimaneva lungo. Tuttavia, i dischi erano un supporto di memorizzazione molto più comodo dei nastri magnetici, che ci consentiva di ridurre drasticamente le dimensioni dei nostri moduli. Semplicemente non c’era più nessun problema ad avere tanti piccoli moduli invece di pochi e grandi. Questo ebbe l’effetto di ridurre effettivamente il tempo di ciclo, dato che la quantità di tempo necessaria per operare su un piccolo modulo era relativamente poca.

Il problema era quando le modifiche da apportare a un sistema impattavano su molti moduli. Dal momento che il sistema era profondamente accoppiato, i tempi di editing rimanevano piuttosto lunghi. Alcuni fra noi impararono a disaccoppiare i moduli, in modo da ridurre i tempi di blocco. Ma la maggior parte di noi ignorò semplicemente il problema.

Subversion

Poi venne Subversion (SVN). Questo strumento offriva blocchi ottimistici. Un blocco ottimistico non è un vero blocco. Uno sviluppatore potrebbe intervenire su un modulo contemporaneamente a un altro sviluppatore. Lo strumento rilevava questo fatto e univa automaticamente le modifiche apportate ai moduli. Se lo strumento rilevava un conflitto (ovvero i due sviluppatori avevano modificato le stesse righe di codice) costringeva il programmatore a risolvere il conflitto prima di procedere.

Questo ridusse drasticamente il tempo di ciclo al solo tempo necessario per modificare, compilare e sottoporre a test una serie di piccole modifiche. L’accoppiamento rimaneva però un problema. Un sistema a elevato accoppiamento manteneva lunghi i tempi di ciclo, perché più moduli dovevano essere modificati tutti insieme. Un sistema a basso accoppiamento poteva prevedere cicli molto più rapidi. Il tempo di blocco non era più il fattore limitante.

Git e i test

Al giorno d’oggi impieghiamo Git. Con Git i tempi di blocco sono ridotti a zero. Il concetto non esiste. Piuttosto, ogni intervento su un modulo viene immediatamente accettato. I conflitti vengono risolti come e quando desiderano i programmatori. La combinazione fra piccoli moduli disaccoppiati e una rapida frequenza di accettazione genera tempi di ciclo dell’ordine dei minuti. Aggiungiamo a questo la possibilità di creare un ampio e veloce pacchetto di test che metta alla prova quasi tutto e siamo arrivati al Rilascio continuo.

Inerzia storica

Sfortunatamente, è difficile per le organizzazioni sbarazzarsi dei comportamenti del passato. Il tempo di ciclo di giorni, settimane e mesi è profondamente radicato nella cultura di molti team e permea anche la QA, il management e le aspettative dei committenti. Partendo da tale cultura, il concetto di Rilascio continuopuò sembrare ridicolo.

Piccole release

Agile tenta di spezzare questa inerzia storica suggerendo al team di ridurre sempre più i cicli di rilascio. Se produciamo una release ogni sei mesi, proviamo a farlo ogni tre mesi, poi proviamo ogni mese, poi proviamo ogni settimana. Continuiamo a ridurre il ciclo di rilascio fino a farlo tendere asintoticamente a zero.

Per farlo, l’organizzazione dovrà spezzare l’accoppiamento fra release e deployment. Il termine release, rilascio, significa che il software è tecnicamente già pronto per l’uso, per il deployment. La decisione di eseguire il deployment diviene esclusivamente una decisione commerciale.

Questo è lo stesso linguaggio che abbiamo usato per descrivere le iterazioni. Le iterazioni sono tecnicamente pronte al deployment. Se le nostre iterazioni richiedono due settimane, ma vogliamo offrire una release più spesso, basta accorciarle, anche così che tendano asintoticamente a zero.

Torna all’inizio.

3. Non è detto che a un team Agile serva un coach

Un team Agile ha bisogno di un coach? La risposta breve è: No. La risposta più lunga è: Talvolta.

Innanzitutto, abbiamo bisogno di distinguere fra istruttori e coach Agile. Un istruttore Agile insegna a un team a condurre la propria attività in modo Agile. Spesso vengono reclutati da una società esterna o sono addestratori interni, ma esterni al team. Il loro obiettivo è formare ai valori Agile e insegnare la disciplina Agile. Il loro impegno sarà breve. Ogni team di una decina di sviluppatori richiederà non più di una o due settimane di addestramento. Tutto il resto lo impareranno da soli, indipendentemente da quello che l’istruttore Agile ha detto o fatto.

Nelle prime fasi della transizione di un team, un istruttore può ricoprire temporaneamente il ruolo del coach, ma questa è una situazione temporanea. Tale ruolo dovrà essere assunto il più presto possibile da qualcuno che è all’interno del team.

In generale, i coach Agile non sono istruttori. Sono membri del team il cui ruolo è quello di proteggere il processo all’interno del team. Nel pieno dell’impegno di sviluppo, gli sviluppatori potrebbero essere tentati di allontanarsi dal processo. Magari smettono inavvertitamente di lavorare a coppie, fermano il refactoring o ignorano i fallimenti nelle build continue. È pertanto compito del coach notare questi cedimenti e puntualizzarli al team. Il coach funge da coscienza del team, ricordandogli sempre le promesse che hanno fatto a se stessi e i valori cui hanno accettato di aderire.

Questo ruolo in genere passa a rotazione da un membro del team a un altro in modo informale e in base alle esigenze. Un team maturo, abituato a lavorare secondo le regole, non avrà alcun bisogno di un coach. Al contrario, un team che sta operando sotto un qualche genere di stress – di tempi, commerciali o interpersonali – può decidere di chiedere a qualcuno di ricoprire temporaneamente questo ruolo.

Il coach non è un manager. Il coach non è il responsabile del budget o dei tempi. Il coach non dirige il team, né rappresenta gli interessi del team nei confronti del management. Il coach non è il legame fra clienti e sviluppatori. Il ruolo del coach è rigidamente interno al team. Né i manager né i clienti sanno chi è il coach, né sanno che esista, un coach.

Scrum Master

In Scrum, il coach è chiamato Scrum Master. L’invenzione di questo termine e la sequenza di eventi che ne seguì, sono fra le migliori e le peggiori cose che si sono verificate nella comunità Agile. I programmi di certificazione attrassero una grande quantità di project manager. Questo influsso, inizialmente aumentò la popolarità di Agile, ma alla fine portò a far confluire il ruolo del coach in quello del project manager.

Al giorno d’oggi, è fin troppo frequente vedere Scrum Master che non sono affatto coach, ma semplicemente project manager, e fare quello che i project manager hanno sempre fatto. Sfortunatamente, il titolo e la certificazione tendono a fornire loro un’indebita influenza sul team Agile.

Torna all’inizio.

4. Che cos’è il Cerchio della vita in Agile

La figura rappresenta lo schema di Ron Jeffries che descrive le pratiche XP. Siamo soliti chiamare questo grafico il Cerchio della vita.

Il Cerchio della vita in Agile

Il Cerchio della vita.

Ho scelto le pratiche XP per questo libro perché, di tutti i processi Agile, XP è quello meglio definito, il più completo e il meno adulterato. Praticamente ogni altro processo Agile è un sottoinsieme o una variante di XP.

Kent Beck è il padre di XP e Ward Cunningham ne è il nonno. Lavorando insieme in Tektronix a metà degli anni Ottanta, essi hanno esplorato molte delle idee che, alla fine, divennero XP.

Il Cerchio della vita è suddiviso in tre anelli. L’anello esterno mostra le pratiche XP rivolte alla società esterna. Questo anello è sostanzialmente l’equivalente del processo Scrum (o almeno di come Scrum è stato originariamente concepito. Al giorno d’oggi, Scrum ha assorbito molte più pratiche XP). Queste pratiche forniscono la struttura per il modo in cui il team di sviluppo software comunica con l’azienda e i principî in base ai quali l’azienda e il team di sviluppo software gestiscono il progetto.

  • Incontri di pianificazione (“Planning game”) svolge un ruolo fondamentale in questo anello. Ci dice come suddividere un progetto in funzionalità, storie e task.
  • Piccole release esorta il team a lavorare in piccoli incrementi.
  • Test di accettazione fornisce la definizione di “finito” per le funzionalità, le storie e i task.
  • Intero team fornisce il concetto che un team di sviluppo software è composto da molte e differenti funzioni, comprendenti programmatori, tester e manager, che collaborano per raggiungere lo stesso obiettivo.

L’anello centrale del Cerchio della vita presenta le pratiche rivolte al team. Queste pratiche forniscono la struttura e i principi mediante i quali il team di sviluppo comunica internamente e si gestisce.

  • Passo sostenibile è la pratica che impedisce a un team di sviluppo software di bruciare risorse troppo rapidamente e di esaurire le energie prima del traguardo.
  • Proprietà collettiva garantisce che il team non divida il progetto in un insieme di silos di competenze.
  • Integrazione continua mantiene il team concentrato su una frequente chiusura del ciclo di feedback.
  • Metafora è la pratica che crea e promulga il vocabolario e il linguaggio che il team e l’azienda usano per comunicare sul sistema.

L’anello più interno del Cerchio della vita rappresenta le pratiche di natura tecnica che guidano e vincolano i programmatori a garantire la più elevata qualità tecnica.

  • Pair programming (programmazione a coppie) permette al team tecnico di condividere la conoscenza, di rivedere il progetto e di collaborare a un livello che promuova l’innovazione e l’accuratezza.
  • Simple Design guida il team a evitare di sprecare energie.
  • Refactoring incoraggia un continuo miglioramento e raffinamento di tutti i prodotti elaborati.
  • Test-Driven Development è la misura di sicurezza impiegata dal team tecnico per procedere rapidamente mantenendo la massima qualità.

Queste pratiche si allineano decisamente agli obiettivi dell’Agile Manifesto in, almeno, i seguenti modi:

  • individui e interazioni più che processi e strumenti;Intero team, Metafora, Proprietà collettiva, Pair programming, Passo sostenibile;
  • software funzionante più che ampia documentazione;Test di accettazione, Test-Driven Development, Simple Design, Refactoring, Integrazione continua;
  • collaborazione con il cliente più che negoziazioni sui contratti;Piccole release, Incontri di pianificazione, Test di accettazione, Metafora;
  • reattività ai cambiamenti più che aderenza a un piano;
  • Piccole release, Incontri di pianificazione, Passo sostenibile, Test-Driven Development, Refactoring, Test di accettazione.

Torna all’inizio.

5. Perché non esiste un Agile “in grande”

Il movimento Agile nacque verso la fine degli anni Ottanta. Venne rapidamente riconosciuto come un mezzo per organizzare un piccolo team di 4-12 sviluppatori software. Questi numeri sono flessibili e raramente sono specificati, ma tutti hanno compreso che Agile (o comunque si chiamasse prima del 2001) non era adatto per grandi team composti da migliaia di sviluppatori.

Ciononostante, quasi immediatamente, sorse la domanda. Come si comporterebbe nei grandi team?

Nel corso degli anni, molte persone hanno tentato di rispondere a tale domanda. Quasi subito, gli autori di Scrum proposero la cosiddetta tecnica Scrum-of-Scrums. Successivamente, iniziammo a veder comparire alcuni approcci commerciali, come SAFe e LeSS). Sono anche stati scritti molti libri su questo argomento.

Sono sicuro che non vi sia nulla di sbagliato in questi approcci. Sono sicuro quei libri vadano bene. Ma non ho tentato quegli approcci, né ho letto quei libri.

Agile è per team medio-piccoli, punto. Funziona bene per quel tipo di team. L’approccio Agile non è rivolto ai grandi team.

Perché non abbiamo cercato di risolvere il problema dei grandi team? Semplicemente perché quello dei grandi team è un problema sul quale molti esperti hanno già lavorato per oltre cinque millenni.

Come sono state costruite le piramidi? Qualcuno deve necessariamente aver risolto il problema dei grandi team. Come è stata vinta la Seconda guerra mondiale? Qualcuno deve necessariamente aver risolto il problema dei grandi team. Come è stato possibile inviare uomini sulla Luna e poi riportarli a casa sani e salvi? Qualcuno deve necessariamente aver risolto il problema dei grandi team.

Come si realizza una rete telefonica o una rete autostradale o Internet o gli iPhone o le automobili? Tutto questo è opera di grandi team.

Quello dei grandi team è un problema ormai risolto.

Il problema che non era ancora risolto verso la fine degli anni Ottanta, quando ebbe origine il movimento Agile, era quello dei piccoli team software. Non sapevamo come organizzare efficacemente un gruppo relativamente piccolo di programmatori. E fu esattamente questo il problema risolto da Agile.

È importante comprendere che questo era un problema software, non il problema da piccolo team. Il problema dei piccoli team è stato risolto millenni fa da organizzazioni militari e industriali di tutto il mondo. I Romani non avrebbero potuto conquistare un impero se non avessero risolto il problema dell’organizzare piccoli manipoli di uomini.

La sostanza, qui, è che Agile riguarda il software. In particolare, riguarda i piccoli team software. Mi sento sempre frustrato quando qualcuno mi chiede come applicare Agile all’hardware, alle costruzioni o a qualche altra attività. La mia risposta è sempre stata: Non lo so, perché Agile si occupa di software.

Che cosa dire, quindi di Agile “in grande”? Non penso che ci sia qualcosa del genere. L’organizzazione di grandi team riguarda il fatto di organizzarli in piccoli team. Pertanto, la mia risposta alla domanda su Agile “in grande” è semplicemente di organizzare gli sviluppatori in piccoli team Agile, e poi usare tecniche di gestione standard per gestire questi team.

Questo non è un argomento che abbia studiato approfonditamente. È solo la mia opinione e potrebbe essere anche molto sbagliata. Forse sono solo un vecchio brontolone che urla a tutti questi ragazzini dell’Agile-in-grande di andarsene dal mio prato. Il tempo ci dirà la verità. Intanto, queste sono le mie previsioni.

Torna all’inizio.

Questo articolo richiama contenuti da Clean Agile.

unsplash-logoImmagine di apertura di pan xiaozhen

L'autore

  • Robert C. Martin
    Robert C. Martin, conosciuto anche come “Uncle Bob”, scrive codice dal 1970 ed è un consulente informatico di livello internazionale. Ha fondato le società Uncle Bob Consulting LLC, Object Mentor Inc e - insieme al figlio Micah Martin - The Clean Coders LLC. È stato caporedattore della rivista The C++ Report e presidente dell'Agile Alliance. Firmatario del Manifesto per lo Sviluppo Agile di Software, è autore di Clean Code, bestseller che vanta oltre 160.000 copie vendute nella sola edizione inglese.

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Immagine decorativa form newsletter
Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.

Corsi che potrebbero interessarti

Tutti i corsi

Agile, sviluppo e management: iniziare bene

con Fabio Mora

Non sei soddisfatto delle gestione dei tuoi progetti software? Vuoi scoprire come i metodi agili possono cambiare il tuo modo di lavorare? Il corso di Fabio Mora è quello che ti serve.

Data governance: diritti, licenze e privacy

con Simone Aliprandi

I dati sono ovunque intorno a noi ma per poterli utilizzare in sicurezza bisogna confrontarsi con temi complessi che riguardano licenze, proprietà intellettuale e privacy. Se non ti senti sicuro o hai paura di prendere la decisione sbagliata, il corso di Simone Aliprandi fa per te.

Big Data Analytics - Iniziare Bene

con Andrea De Mauro

Credi che i Big Data siano una grande opportunità ma che spesso se ne parli a sproposito? Excel ti sta stretto e vorresti fare di più? Andrea De Mauro ti aiuta a fare chiarezza e ti insegna a muovere i primi passi nell'analisi dei Big Data.


Libri che potrebbero interessarti

Tutti i libri

Clean Agile

Guida per riscoprire i principi cardine dello sviluppo agile di software

28,00

39,89€ -30%

21,76

22,90€ -5%

16,99

di Robert C. Martin

Agile per tutti

Creare organizzazioni snelle, flessibili e centrate sul cliente

26,80

35,89€ -25%

21,76

22,90€ -5%

12,99

di Matt LeMay

L'arte del Rilascio

Progettazione e deploy di software che funziona

42,40

59,89€ -29%

33,16

34,90€ -5%

24,99

di Michael Nygard


Articoli che potrebbero interessarti

Tutti gli articoli