ℹ️ Implementazione di Scrum in piccola azienda 📅 Data: 27/06/2023 ⏱️ Durata: 39 minuti
📑 Sommario
In questo episodio, intervistiamo Stefano Berretta, uno sviluppatore con oltre 20 anni di esperienza che ha guidato l’adozione di Scrum in una piccola software house. Scopriamo come il framework Scrum può essere implementato in realtà più piccole, i benefici ottenuti e le sfide ancora da affrontare.
🎧 Ascolta l’Episodio
🎯 Punti Chiave dell’Intervista
Background e Contesto
20+ anni di esperienza nello sviluppo software
Lavoro in una software house di 10-15 dipendenti
Sviluppo di soluzioni per aziende manifatturiere
Motivazioni per l’Adozione di Scrum
Progetti problematici e stress del team
Necessità di migliorare la qualità del software
Ricerca di un approccio più umano e collaborativo
🔄 Principali Cambiamenti Implementati
Passaggio dal lavoro individuale al lavoro in team
Introduzione di pratiche di test e quality assurance
Maggiore collaborazione e condivisione delle responsabilità
Materiale sulla gestione del cambiamento organizzativo
Risorse sulla qualità del software
🎓 Note del Trainer
“L’esperienza di Stefano dimostra come Scrum possa essere implementato con successo anche in realtà più piccole, ponendo l’accento sull’importanza delle persone e del miglioramento continuo. Il cambiamento richiede pazienza, dedizione e una visione chiara dei benefici che si vogliono ottenere.”
In questo episodio intervistiamo Alessandro Bignami, un professionista con oltre 25 anni di esperienza nel mondo del software development, di cui gli ultimi 7 dedicati all’Agile e Scrum. Esploriamo come il mindset agile sia una caratteristica naturale che paradossalmente dimentichiamo con il tempo, e come riscoprirlo possa portare a risultati sorprendenti nei progetti software.
🎧 Ascolta l’Episodio
🎯 Punti Chiave dell’Intervista
Background di Alessandro
25+ anni nel software development
7 anni di esperienza in Agile e Scrum
Transizione da developer a Scrum Master nel 2018
Certificazioni Scrum e continuo apprendimento sul campo
L’Agilità come Comportamento Naturale
Il mindset agile è insito nel nostro modo di apprendere fin dalla nascita
Impariamo naturalmente per incrementi (esempio: linguaggio)
Paradossalmente, nelle organizzazioni tendiamo a complicare i processi
Caso di Studio: Successo con Scrum
Progetto con proof of concept iniziale
Team piccolo con approccio Scrum adattato
Collaborazione costante con il cliente
Sprint di 2 settimane con feedback continuo
Risultato: prodotto di successo in 10 mesi
💡 Lezioni Apprese
Importanza della volontà di mettersi in gioco
Necessità di adattare il framework al contesto
Valore della trasparenza e della collaborazione
Focus sui principi più che sulle pratiche
⚠️ Sfide nell’Adozione Agile
Resistenza al cambiamento nelle dirigenze
Crisi identitaria dei manager tradizionali
Necessità di un approccio graduale al cambiamento
Importanza di iniziare con progetti pilota mirati
📚 Consigli per Chi Inizia
Partire con una formazione di base solida, guarda i corsi disponibili!
Concentrarsi sul significato dietro le pratiche
Accettare la “sindrome dell’impostore” come normale
Non perdere il prossimo episodio del podcast Scrum Italia, un’altra intervista sulla tematica del miglioramento continuo.
Questo articolo è basato sull’episodio 26 del podcast Scrum Italia con Alessandro Bignami e Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio speciale, intervistiamo Emanuele Vecchio, sviluppatore software e appassionato di Scrum. Scopriamo il suo percorso di adozione di Scrum, i benefici ottenuti nel suo team e le sfide affrontate. Un’intervista ricca di spunti e riflessioni sul valore dell’empirismo e dell’approccio Scrum non solo nel lavoro ma anche nella vita.
🎧 Ascolta l’Episodio
🎯 Chi è Emanuele Vecchio
Sviluppatore software dal 2007
Autore di una saga fantasy Midda’s Chronicles pubblicata tramite blog dal 2008
La prima regola per fare Scrum è fare Scrum. Come per cucinare una torta di mele servono ingredienti specifici e una ricetta da seguire, allo stesso modo per Scrum servono impegno, focus, apertura, rispetto e coraggio – i valori Scrum – miscelati in un continuo reiterarsi di trasparenza, ispezione e adattamento.
Emanuele Vecchio
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast Scrum Italia, un’altra intervista dove parleremo di come l’agilità sia una caratteristica naturale che perdiamo col tempo.
Questo articolo è basato sull’episodio 25 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio, intervistiamo Luca Giancristofaro, ingegnere dell’automazione con esperienza nello sviluppo hardware e firmware. Scopriremo il suo percorso di adozione di Scrum in un contesto di prodotti fisici, le sfide affrontate e i benefici ottenuti nel passaggio da un approccio waterfall a Scrum.
🎧 Ascolta l’Episodio
🎯 Chi è Luca Giancristofaro
Luca è un ingegnere dell’automazione laureato nel 2008, con esperienza nel campo dell’elettronica, hardware e firmware. Ha lavorato inizialmente con metodologie waterfall per poi abbracciare Scrum negli ultimi anni. Attualmente si occupa dello sviluppo di prodotti che combinano hardware e software nel settore degli elettrodomestici.
🔄 Principali Punti Discussi
Il Passaggio a Scrum
Transizione da waterfall a Scrum per gestire meglio le richieste multiple
Miglioramento nella prioritizzazione delle attività
Maggiore chiarezza e consenso sulle direzioni di sviluppo
Aumento della trasparenza nel team
Benefici Riscontrati
Riduzione degli sprechi
Maggiore trasparenza attraverso le Sprint Review
Migliore allineamento tra stakeholder
Facilitazione della comunicazione tra team interni ed esterni
Sfide Attuali
Gestione di team ibridi (personale interno ed esterno)
Applicazione di Scrum su prodotti fisici
Implementazione efficace della Definition of Done
Mantenimento della coesione del team
💡 Consigli per Chi Inizia con Scrum
Comprendere le fondamenta di Scrum prima di applicarlo
Non vedere Scrum come un semplice insieme di regole da seguire
Cercare di capire il “perché” dietro ogni elemento del framework
Iniziare con piccoli cambiamenti se non si ha supporto completo
Vivere l’adozione di Scrum positivamente a livello personale e di team
L’esperienza di Luca dimostra come Scrum possa essere applicato con successo anche in contesti non puramente software. La chiave del successo sta nella comprensione profonda dei principi e dei valori di Scrum, oltre che nella capacità di adattarli al proprio contesto specifico.
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdete il prossimo episodio del podcast Scrum Italia, parleremo di Scrum e le torte di mele.
Questo articolo è basato sull’episodio 24 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
Project Manager e Scrum Master sono due mestieri diversi. Se sei un project manager, senti parlare sempre di più di Scrum e vorresti capire cosa c’è di così diverso fra questi due ruoli? Perché dovresti scegliere fra l’uno o l’altro e non si può fare un pò dei due?
In questo articolo provo a condividere le risposte a queste domande, con i principi e le ragioni che differenziano Scrum Professionale dal Project Management.
L’obiettivo non è quello di convincere che Scrum è la soluzione miracolo a tutto, al contrario. La mia esperienza come project manager mi porta ad apprezzare tutto quello che ho imparato durante gli anni spesi a gestire progetti in modo tradizionale.
Aggiornamento del 6 luglio 2023 – aggiunta del video dell’evento in diretta relativo a questa tematica.
Premessa
Ho avuto tre esperienze principali di lavoro:
Sviluppatore software per sistemi industriali complessi (essenzialmente C, C++ e SQL) dal 2001 al 2006 (6 anni)
Team leader, project e program manager nel settore bancario, trasporto e logistica, finanza dal 2007 al 2014 (8 anni)
Scrum Master e Professional Scrum Trainer dal 2015 ad oggi (9 anni)
Conosco bene cosa pensa (e cosa vive) uno sviluppatore, un project manager o uno Scrum Master. In particolare, per averli vissuti personalmente, conosco le sfide che un project manager deve affrontare se vuole diventare un buon Scrum Master.
Esploriamole insieme!
Project Manager e Scrum Master
Sono due mestieri diversi. È importante capirlo, perché il focus e le responsabilità di questi due ruoli sono diametralmente opposti.
Il Project Management funziona bene in contesti complicati o semplici (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Project Manager: ha per missione di tenere sotto controllo costi, time e scope del progetto. Garantisce all’azienda che gli investimenti strategici sono correttamente gestiti. Spesso è un esperto tecnico o funzionale e dice ai colleghi cosa fare, assegna i task e controlla che siano eseguiti secondo i piani. Ne parlo in questo articolo.
Un project manager lavora per soddisfare il management interno, ovvero controllare che il lavoro sia eseguito secondo i piani.
Fabio Panzavolta
Scrum funziona bene in contesti complessi (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Scrum Master: ha per missione di assicurarsi che Scrum è correttamente capito ed utilizzato. Contrariamente al project manager, i risultati del team “non gli interessano”. Se i membri dello Scrum Team hanno capito cosa vuol dire creare prodotti complessi in modo empirico, i risultati arriveranno.
Lo Scrum Master è un servant leader, aiuta a rimuovere gli ostacoli che impediscono il raggiungimento degli obiettivi del team (ne parlo in questo articolo).
Uno Scrum Master (con tutto lo Scrum Team) lavora per soddisfare gli utilizzatori del prodotto il più rapidamente possibile.
Fabio Panzavolta
Project Manager e Scrum Master, focus interno o esterno all’azienda?
La ragione di esistere di un project manager è quella di limitare i rischi aziendali garantendo il controllo degli investimenti.
Questo funziona principalmente per progetti altamente prevedibili, per i quali non sono previsti cambiamenti sostanziali durante lo sviluppo.
Quando lavoravo come project manager i primi cambiamenti al piano del progetto arrivavano molto rapidamente. Questo portava inevitabilmente a ginnastiche improbabili per non stravolgere il piano.
Project Manager – Focus interno
Per un Project Manager il focus è interno all’azienda, si passa più tempo a negoziare un paio d’ore di lavoro a destra e sinistra con gli sviluppatori che a sviluppare effettivamente il prodotto.
Questo focus interno porta a perdere di vista il perché si fa un progetto concentrandosi principalmente su budget, time e scope.
Ho personalmente conosciuto sviluppatori software che lavoravano da due anni su un progetto e non avevano mai visto il prodotto finito… immaginate la motivazione e l’impegno che potevano mettere al lavoro.
Scrum Master – Focus esterno
Uno Scrum Master, aiuta lo Scrum Team e gli stakeholders a fare un focus sui problemi da risolvere agli utilizzatori, ad ottimizzare il lavoro non fatto per concentrarsi solo su ciò che è veramente importante: il valore creato per gli utilizzatori del prodotto.
Questo non vuol dire che i limiti aziendali sono ignorati, perché il Product Owner fa attenzione a massimizzare il valore del prodotto. Quindi, per esempio, il budget a disposizione è speso in maniera opportunistica e non pianificata su un anno o due, ma con cicli di un mese al massimo.
Massimizzare il valore del prodotto vuol dire, fra l’altro, che la strategia del Product Owner implica la creazione di un prodotto che si auto-finanzierà il prima possibile.
Project Manager e Scrum Master, Scope fisso o variabile!
Altro cambiamento fondamentale, uno Scrum Master aiuta ad acquisire un modo di lavorare orientato sugli obiettivi, i requirements ci interessano, ma fino ad un certo punto.
Il project manager raccoglie tutti i requisiti, che molto spesso fanno parte del contratto. Per ottimizzare (sigh, sob 😊) si cerca di elencare tutte le funzionalità, con il cliente, nelle prime fasi del progetto. In modo tale da non doversi più vedere per un annetto o due (ri-sigh, ri-sob).
Ovviamente questo modo di lavorare funziona, come dicevo prima, se ciò che state facendo non ha incertezze sostanziali.
Purtroppo (in particolare per l’informatica), molto spesso il cliente non sa nemmeno cosa vuole. Oppure (che è anche peggio) è assolutamente convinto di sapere cosa vorrebbe avere (poi si scopre che gli utenti e i loro problemi quotidiani non li conosce veramente).
Quindi il povero project manager (esperienza vissuta) fa dei piani nel momento in cui il team, il cliente e lui stesso hanno meno esperienza e meno informazione possibile… conoscete i risultati… altrimenti non sareste arrivati fino qui a leggere 😊.
Questo problema è risolto in Scrum, perché invece di lavorare a scope fisso, si lavora con obiettivi fissi, concedendo una certa “liquidità” nelle funzionalità da implementare grazie all’ordinamento del Product Backlog.
Lo Scrum Master insegnerà a tutti (anche al cliente) come fondare il lavoro su obiettivi, generare risultati concreti per gli utilizzatori e farà in modo che le esigenze emergano con l’esperienza, grazie al feedback degli utilizzatori ed alla collaborazione regolare con il cliente.
In un mondo complesso ed incerto, quando non si sa veramente cosa si vuole, un prodotto non si pianifica, emerge dall’esperienza.
Fabio Panzavolta
Scegliere di fissare un obiettivo ed avere funzionalità variabili avrà come conseguenza una migliore qualità, più implicazione da parte di tutti, più innovazione nella ricerca di soluzioni e più rilasci in produzione.
Project Manager e Scrum Master, dalle esigenze agli obiettivi
Parlavo di contratto prima… quante volte, da project manager, mi sono trovato a dover discutere con il cliente per giorni, settimane per cambiare una virgola in una particolare esigenza… con il risultato che dopo la discussione ci volevano altre settimane per avere il GO per implementare il cambiamento (che nel frattempo, a volte, era già stato fatto).
Purtroppo, in certi casi, ci siamo anche trovati ad implementare delle cose che sapevamo sbagliate, o incoerenti, per non dover subire il processo descritto sopra.
Il focus sulle esigenze è un focus malato in un contesto complesso e mutevole.
Fabio Panzavolta
Il giusto focus è negli obiettivi… in Scrum ce ne sono due:
Product Goal: definito dal Product Owner, è un obiettivo a medio termine, un passo in più verso la visione del prodotto
Sprint Goal: definito dallo Scrum Team, è un obiettivo a corto termine (un mese massimo), un passo in più verso il Product Goal
In un contratto si possono fissare i Product Goal, facendo attenzione a non renderli troppo stringenti, bensì sufficientemente vaghi per dare una direzione e lasciare libertà nel decidere cosa e come sperimentare nuove soluzioni.
Segui questo link se vuoi saperne di più sui contratti agili.
Riuscire a fare un focus sul goal (Scrum Professionale) e non sui requirements (Project Management), vuol dire concentrarsi sul perché si vuole fare qualcosa, non sul come. Le discussioni sul cosa e come raggiungere l’obiettivo saranno legate al perché si vogliono fare, con un focus maggiore, più o meno funzionalità a seconda del contesto e degli esperimenti che si faranno collaborando.
Conclusioni
Project Manager e Scrum Master sono due mestieri diversi, con focus diverso. Non si può pensare di accettare un ruolo di Scrum Master senza aver capito Scrum Professionale o le responsabilità di uno Scrum Master (ne parlo in un episodio del podcast Scrum 🇮🇹).
La difficoltà non è Scrum, bensì il cambiamento nel modo di pensare, agire e prendere decisioni.
Uno Scrum Master si accontenta di rivelare ciò che non funziona secondo Scrum, non dà soluzioni o dice agli altri cosa fare. Piuttosto, aiuta le persone a trovare e sperimentare le soluzioni grazie alle idee che emergono discutendo.
Se sei un Project Manager e desideri cominciare o continuare il tuo percorso di professionalizzazione, puoi cominciare da autodidatta.
Personalmente ho letto tanto, questi sono i libri, ho praticato in condizioni differenti (prima in contesti al di fuori del lavoro, poi al lavoro) e non smetto mai di pensare che sto ancora imparando.
Un’altra fonte inesauribile di conoscenza è ovviamente il sito scrum.org, ma anche i blog di Ken Schwaber e Gunther Verheyen, i miei due punti di riferimento.
Se vuoi imparare o migliorare la tua conoscenza di Scrum Professionale, facendoti accompagnare, puoi anche scegliere di partecipare ad una delle nostre formazioni.
In questo episodio esploriamo l’empirismo, uno dei pilastri fondamentali di Scrum. Scopriremo perché l’approccio empirico è essenziale nella risoluzione di problemi complessi e come si differenzia dall’approccio predittivo tradizionale. Vedremo anche come questo pilastro si integra con i tre elementi chiave: trasparenza, ispezione e adattamento.
🎧 Ascolta l’Episodio
🎯 Cos’è l’Empirismo in Scrum
L’empirismo in Scrum rappresenta un approccio fondamentalmente diverso dalla gestione tradizionale predittiva. Si basa sul principio che:
La conoscenza deriva dall’esperienza diretta
Le decisioni si basano su ciò che si è osservato
Il futuro non è completamente prevedibile
🔄 Caratteristiche Principali
Approccio Iterativo e Incrementale
Permette l’emergere di soluzioni non previste inizialmente
Aiuta a controllare vari tipi di rischi (investimenti, direzione, tecnici)
Costruisce fiducia gradualmente nel team
I Tre Pilastri dell’Empirismo
Trasparenza: sullo stato del prodotto e elementi decisionali chiave
Ispezione: verifica regolare dei risultati e progressi
Adattamento: modifiche basate su ciò che si è appreso
L’empirismo non significa rinunciare a fare previsioni o piani, ma cambiare il modo in cui li facciamo. Si tratta di basare le decisioni su dati reali e osservazioni concrete, costruendo gradualmente la fiducia attraverso risultati tangibili.
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdete il prossimo episodio, la prima intervista ad un praticante di Scrum.
Questo articolo è basato sull’episodio 23 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo il Lean Thinking e la sua profonda connessione con Scrum. Scopriremo come questi due approcci si completano a vicenda e come il Lean Thinking influenza la cultura aziendale, l’eliminazione degli sprechi e la creazione di valore per il cliente.
🎧 Ascolta l’Episodio
🎯 Cos’è il Lean Thinking
Il Lean Thinking, termine coniato da John Krafcik nel 1988, è un approccio che mira a:
Creare valore il più rapidamente possibile
Eliminare qualsiasi tipo di spreco
Ottimizzare i processi aziendali
Allineare la soddisfazione del cliente con quella dei dipendenti
Developers: focus sulla qualità e soluzioni tecniche efficienti
Scrum Master: facilitazione del pensiero lean nel team
⚙ Benefici dell’Approccio Lean in Scrum
Riduzione dei costi di sviluppo
Maggiore soddisfazione degli utenti
Incremento della qualità del prodotto
Miglioramento del coinvolgimento del team
Ottimizzazione dei processi aziendali
📚 Approfondimenti Consigliati
Storia del Lean Thinking in Toyota
Implementazione dei principi Lean nel software development
Tecniche di eliminazione degli sprechi
Metriche di misurazione del valore
🎓 Note del Trainer
“Il Lean Thinking non è solo una metodologia, ma una vera e propria filosofia che, combinata con Scrum, permette alle organizzazioni di creare prodotti di valore superiore con meno sprechi. La chiave del successo sta nell’adozione di questa mentalità a tutti i livelli dell’organizzazione.”
Fabio Panzavolta
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo l’empirismo in Scrum.
Questo articolo è basato sull’episodio 22 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo le differenze fondamentali tra Agile e Scrum, partendo dalle origini storiche fino alla loro applicazione moderna. Scopriremo come Scrum sia uno strumento pratico per implementare i principi Agile e perché questa distinzione è cruciale per le organizzazioni che vogliono migliorare il loro modo di lavorare.
“La differenza tra Agile e Scrum è fondamentale per comprendere come implementare efficacemente pratiche agili nelle organizzazioni. Agile fornisce i principi guida, mentre Scrum offre un framework pratico per metterli in azione. Il successo sta nel comprendere entrambi e utilizzarli in modo sinergico.”
Fabio Panzavolta
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo lean thinking e Scrum.
Questo articolo è basato sull’episodio 21 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio ascolteremo l’audiobook completo della Guida Scrum, il documento scritto da Ken Schwaber e Jeff Sutherland che definisce il framework Scrum. Scopriremo la teoria, i valori, gli eventi e gli artefatti che compongono Scrum, direttamente dalla fonte ufficiale tradotta in italiano.
La Guida Scrum è il punto di riferimento per comprendere il framework. Ascoltarla in formato audio permette di assimilarne i concetti fondamentali in modo diverso rispetto alla lettura, offrendo nuove prospettive e una comprensione più profonda.
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio dove parleremo della differenza fra Agile e Scrum.
Questo articolo è basato sull’episodio 20 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio approfondiamo il concetto dell’Incremento in Scrum, uno degli artefatti fondamentali del framework. Esploriamo come rappresenti una pietra miliare verso il Product Goal, le sue caratteristiche essenziali e il ruolo cruciale della Definition of Done nel garantire la qualità del prodotto.
🎧 Ascolta l’Episodio
🎯 Cos’è l’Incremento
L’Incremento rappresenta una versione utilizzabile del prodotto che:
Si aggiunge in modo cumulativo agli increment precedenti
È verificato accuratamente per garantire l’integrazione con gli increment precedenti
Deve essere usabile per fornire valore
Può essere rilasciato prima della fine dello Sprint
Viene presentato durante la Sprint Review per supportare l’empirismo
🔄 Caratteristiche Principali
Definition of Done
Descrizione formale dello stato dell’incremento
Definisce le metriche di qualità richieste
Crea trasparenza nel team
Fornisce una comprensione condivisa del lavoro completato
Gestione dell’Incremento
Può essere rilasciato prima della Sprint Review
La Sprint Review non è un gate obbligatorio
Deve soddisfare la Definition of Done per essere considerato un Incremento
Richiede integrazione quando più team lavorano sullo stesso prodotto
“L’Incremento è il cuore pulsante di Scrum: rappresenta il valore tangibile che consegniamo ai nostri stakeholder. La chiave del successo sta nel mantenere alta la qualità attraverso una Definition of Done chiara e condivisa, evitando scorciatoie che potrebbero compromettere la trasparenza dell’empirismo.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo altri aspetti fondamentali di Scrum.
Questo articolo è basato sull’episodio 19 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci permetterà di elaborare dati come il comportamento di navigazione o ID unici su questo sito. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.
