Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capitolo Stime #225

Open
wants to merge 41 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
Show all changes
41 commits
Select commit Hold shift + click to select a range
7cc8eb9
feat: capitolo stime
eppak Apr 22, 2024
f5760fe
Apply suggestions from code review
Cadienvan Apr 27, 2024
75c710d
Update docs/it/stime.md
eppak Jul 1, 2024
aa6d61f
Update docs/it/stime.md
eppak Jul 1, 2024
99d2d99
Update docs/it/stime.md
eppak Jul 1, 2024
800f8b7
Update docs/it/stime.md
eppak Jul 1, 2024
b5fc771
Update docs/it/stime.md
eppak Jul 1, 2024
74da95f
Update docs/it/stime.md
eppak Jul 1, 2024
bb06ef2
Update docs/it/stime.md
eppak Jul 1, 2024
8b8b9b2
Update docs/it/stime.md
eppak Jul 1, 2024
7958b8a
Update docs/it/stime.md
eppak Jul 1, 2024
d3e59e7
Update docs/it/stime.md
eppak Jul 1, 2024
c19af6d
Update docs/it/stime.md
eppak Jul 1, 2024
f9d3c31
fix: chiarimento del termine fare della matematica con le stime
eppak Jul 1, 2024
d0ecdd4
fix: chiarito il concetto di time to market e di variabilità del proc…
eppak Jul 1, 2024
dd4aedc
Update docs/it/stime.md
eppak Jul 1, 2024
f77ef2e
Aggiunto capitolo CV per un developer (#112)
GuidoPenta May 4, 2024
c48cc1c
chore: adattamenti stilistici del libro
Cadienvan May 4, 2024
865f808
chore: lint
Cadienvan May 4, 2024
581573c
Aggiunge Mutation al capitolo sul testing (#215)
Cadienvan May 4, 2024
27b5c55
fix: introduce text auto on gitattributes (#230)
corradopetrelli May 17, 2024
8c4ddd3
Capitolo "Metodologie Agile e ciclo del feedback" (#212)
Jean85 May 31, 2024
296d866
chore: inseriti url corretti a capitolo agile
Cadienvan May 31, 2024
6bdf3c1
chore: inserito nome corretto del capitolo
Cadienvan May 31, 2024
208ed6d
Fix linguaggio (#232)
serenasensini May 31, 2024
919b3b1
Aggiunge capitolo AI (#221)
serenasensini Jun 1, 2024
4d48a98
Add/refactoring (#228)
mrkrash Jun 27, 2024
8fc2d4c
chore: adattato nome capitolo refactor
Cadienvan Jun 27, 2024
e1e1422
fix: formatting
eppak Jul 22, 2024
1e2b0e7
Update docs/it/stime.md
eppak Aug 12, 2024
fce5fc2
Update docs/it/stime.md
eppak Aug 12, 2024
e604ee1
Update docs/it/stime.md
eppak Aug 12, 2024
bd8dbd0
fix: formattazione delle modifiche recenti
eppak Aug 12, 2024
3d2bf81
Update docs/it/stime.md
eppak Aug 12, 2024
dcee185
fix: planning poker
eppak Aug 12, 2024
3b44dee
fix: specificato meglio i processi
eppak Sep 4, 2024
50f676a
Update docs/it/stime.md
eppak Sep 5, 2024
79fb3ce
Update docs/it/stime.md
eppak Sep 5, 2024
78eaaab
fix: aggiunto event storm e chiarimento software come parte del business
eppak Sep 13, 2024
ecb7df9
fix: formattazione
eppak Sep 13, 2024
d600490
Merge branch 'main' into add/mvp-/-stime
Cadienvan Sep 16, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions docs/it/stime.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
#### Comprendere il processo

Quando si parla di stima si intende riuscire a delineare un confine temporale per la realizzazione di un'opera di qualche genere. Ci troviamo di fronte ad un tema controverso, e sicuramente chiedendo a dieci persone cosa rappresenta per loro una stima, probabilmente otterremo dieci risposte diverse con metodi o approcci anche molto distanti. Qui non vogliamo andare nel profondo di uno o più metodi, ma chiarire il tema per comprenderlo e dare degli strumenti e spunti di approfondimento.

Nell'ambito informatico, la stima può essere usata per dare una dimensione ad un task o ad un intero progetto, aiutando il business a delineare un'idea o a pianificare le attività ed è quindi piuttosto importante perché consente di prendere decisioni su come spendere le risorse. Dobbiamo ricordarci infatti che lo sviluppo è parte del business, e lo stiamo facendo anche noi quando programmiamo.

Un parametro importante nello sviluppo di un progetto è il cosiddetto Time To Market (tempo di arrivo su un certo mercato), può risultare determinante nella riuscita di un prodotto; rappresenta quando riuscirete ad essere pronti per i clienti e quindi quando arriverete rispetto alla concorrenza. Il business lo tiene molto in considerazione perché è un buon indicatore di quando i profitti potrebbero iniziare ad arrivare cominciando, quindi, a rientrare degli investimenti. Questo parametro diventa perno, insieme ad altri fattori, per delineare le strategie aziendalie; delineare la pianificazione in base ad alla stima temporale non è l'unica maniera di gestire questo aspetto, ma è sicuramente spesso il preponderante.

Ma come mai la stima e la pianificazione, nel nostro campo, è così complessa? La risposta sta nel comprendere, prima di tutto, qual è lo scopo del processo di creazione del software stesso. Questo ci permette di definire meglio quelle variabili fino a quel momento incognite per cui le stime possono variare.

I processi si categorizzano infatti base ad una serie di variabili, ossia delle incognite che si incontrano durante il percorso; più è difficile predire quello che succederà durante il lavoro e più si dice che la variabilità cresce; è un poco come percorrere una strada e non sapere quanto traffico troveremo, se faremo quella strada molto spesso avremo comunque un'idea di cosa possa succedere e di quanto ci metteremo ad arrivare.

Per capire meglio quanto delicata sia questa tematica bisogna ricordarsi che il software è di fatto equiparabile alla produzione di un bene, è un prodotto che deve soddisfare le esigenze di uno o più clienti, un mercato.
Il processo di creazione di un prodotto, dal punto di vista prettamente ingegneristico, è suddivisibile secondo questa categorizzazione: definito, statistico e empirico, va applicato quello migliore per la situazione in cui siamo.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non ho capito la frase dopo il ":": é un elenco di tre elementi? Conviene mettere un elenco puntato?
Toglierei comunque la frase dopo la virgola che potrebbe confondere il lettore.


Il processo definito è quello più semplice, è qualcosa che abbiamo già fatto e di cui conosciamo bene le specifiche e il cui processo di esecuzione è ben definito; in questa sitazione conosco sia tempi che modi e non mi aspetto alcuna variabilità che in parole povere significa solo che non ci sono sorprese durante il processo, avviene sempre alla stessa maniera.
Un esempio nel nostro campo questo potrebbe essere l'installazione di un sistema operativo, di un CMS; non ci aspettiamo grandi soprese da queste operazioni, al più possono chiederci qualche pacchetto accessorio ma nulla che possa impattare nè sui tempi nè sui risultati.

Il processo statistico, invece, ha una variabilità più alta cioè durante la sua esecuzione le cose possono andare diversamente da quanto previsto e questo impatta sui tempi e costi.
L'esempio classico è la produzione di un bene materiale dove per forza di cose, errori, difformità di materiali e altre variabili possono incidere sul risuotato che produciamo; ci troviamo di fronte ad un processo che può essere dominato con la statistica, cioè so che avrò un certo scarto percentuale.
Questa casistica è piuttosto rara in campo informatico ma comunque presente, per fare un esempio potremmo pensare all'installazione di un plugin su un CMS e alla sua configurazione che può variare da cliente a cliente.
In questo caso non è detto che ci metteremo lo stesso quantitativo di tempo per ogni cliente, ecco qui che quindi è meglio esprimere la stima in una forbice perché abbiamo un'esperienza che ci dice che possiamo metterci da un minimo ad un massimo.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Qui spiegherei meglio perché per ogni cliente é diverso. Immagino che il motivo sia perché ogni cliente ha esigenze leggermente diverse che, seppur sapute a priori, hanno comunque delle incertezze.


Nei due precedenti processi, definito e statistico, ci accorgiamo presto che un elemento determinante è avere una specifica ben definita di cosa vogliamo ottenere, "cosa significa fatto?", "dove vogliamo arrivare?".
Il cliente ha un'esigenza e spesso non è in grado di esprimerla da subito in termini chiari e precisi, in un contesto come meccanica ed elettronica è più facile perché il cliente è in grado di descrivre le specifiche con caratteristiche fisiche misurabili; un cliente che chiede un sito internet invece difficilmente potrà fare altrettanto.
Ad esempio possiamo trovarci di fronte a percezioni di un prodotto terzo e molto qui può fare l'analisi perché ci può chiarire meglio la specifica, la definizione di cosa si vuole ottenere.

In questo contesto di incertezza nasce il processo empirico che ha preso piede negli ultimi venti anni, si tratta di abbracciare un po' questa incertenzza e procedere in maniera iterative.
Nei processi precedenti si nota che abbiamo un input, eseguiamo una lavorazione, emettiamo un output, a questo punto quello che abbiamo ottenuto è qualcosa che può andare bene o no; non abbiamo in mano specifiche molto precise (lo voglio lungo X e largo Y) e quindi il rischio di non soddisfare il cliente è alto.
Possiamo pensare di ragionare come nel caso di un pittore che deve creare un quadro che di per sè ha un soggetto e un tema ma non ha una definizione precisa del risultato finale.
Si procede prima con un disegno, che poi viene ripassato a tempera per poi venire ritoccato più volte per andare incontro alle esigenze del committente.
Il processo empirico è proprio questo, partire da una o più caratteristiche base, da uno scheletro, e agginugere elementi interagendo così da ottenere qualcosa che si adatta man mano che viene creato.
Partire da elementi di base e poi costruire in manirea iterativa ci consente di scomporre tutto in elementi più piccoli e semplici, più predittibili e quindi più gestibili; questa scomposizione ci consente di riportarci ai due processi precedenti che possono essere predetti meglio e, obiettivo principale, automatizzati.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automatizzati? In che senso?
E perché l'obiettivo principale non é la predizione?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automatizzati? In che senso?
E perché l'obiettivo principale non é la predizione?


#### Scomposizione

La prima tattica è quello di dividere il problema in problemi più semplic: un task o un progetto diventano via via più raffinati e più piccoli e al tempo stesso più semplici da stimare ma anche più facili da confinare come problematica. Come in precedenza, si cerca di trovare un pattern conosciuto e partire con quello. Questo vuol dire gestire un lavoro più piccolo, il che ci consente di comprenderlo meglio, visto che il cervello umano non è in grado di tenere sotto controllo una moltitudine di elementi, ma ci consente di avere una visione prima di insieme e poi del dettaglio, così da rendere le cose più facili da dominare. La riduzione rende anche chiare altre due cose, ovvero le criticità: parliamo di quelle parti meno esplorate e in cui ci sono più difficoltà. Mette in luce anche le dipendenze, cioè quali siano le fondamentali e quali siano le parti accessorie, cominciando anche a delineare una sequenza.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
La prima tattica è quello di dividere il problema in problemi più semplic: un task o un progetto diventano via via più raffinati e più piccoli e al tempo stesso più semplici da stimare ma anche più facili da confinare come problematica. Come in precedenza, si cerca di trovare un pattern conosciuto e partire con quello. Questo vuol dire gestire un lavoro più piccolo, il che ci consente di comprenderlo meglio, visto che il cervello umano non è in grado di tenere sotto controllo una moltitudine di elementi, ma ci consente di avere una visione prima di insieme e poi del dettaglio, così da rendere le cose più facili da dominare. La riduzione rende anche chiare altre due cose, ovvero le criticità: parliamo di quelle parti meno esplorate e in cui ci sono più difficoltà. Mette in luce anche le dipendenze, cioè quali siano le fondamentali e quali siano le parti accessorie, cominciando anche a delineare una sequenza.
La prima tattica è quello di dividere il problema in problemi più semplici: un task o un progetto diventano via via più raffinati e più piccoli e al tempo stesso più semplici da stimare ma anche più facili da confinare come problematica. Come in precedenza, si cerca di trovare un pattern conosciuto e partire con quello. Questo vuol dire gestire un lavoro più piccolo, il che ci consente di comprenderlo meglio, visto che il cervello umano non è in grado di tenere sotto controllo una moltitudine di elementi, ma ci consente di avere una visione prima di insieme e poi del dettaglio, così da rendere le cose più facili da dominare. La riduzione rende anche chiare altre due cose, ovvero le criticità: parliamo di quelle parti meno esplorate e in cui ci sono più difficoltà. Mette in luce anche le dipendenze, cioè quali siano le fondamentali e quali siano le parti accessorie, cominciando anche a delineare una sequenza.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Le parti meno esplorate non é detto che siano le "più difficili", sono quelle dove incertezza di stima é maggiore! Metterei il focus su questo.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L'ultima frase é molto potente. La espanderei dando idea di come sia possibile espanderle (facendo domande, coinvolgendo esperti esterni per avere un opinione, documentandosi).
Da notare che tutto ciò richiede del tempo e che quindi va stimato, per esempio scegliendo investigazione time-boxed


#### Isolare le criticità
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Criticità secondo me non é il termine corretto: userei di più incertezza, "poca conoscenza", dubbio, known-unknown.


Nella suddivisione si possono scorgere, come si è visto, criticità; sono le parti più complesse da stimare, quelle che ci pongono di fronte a situazioni nuove dove un pattern già conosciuto non è visibile o proprio è assente. Si possono adottare due strategie concatenate: la prima è quella di "assegnare ad una stima del tempo di stima": sembra un gioco di parole ma non lo è. Se un tema è complesso e non scomponibile e ha bisogno di essere studiato è necessario prendersi il tempo per farlo. Assegnare a questo task una stima per consentirci di avere le idee più chiare ci da la maniera di introdurre il concetto di PoC: proof of concept. Di fatto è un micro task orientato alla creazione di uno o più proprietà del progetto finale che sono critiche e che, una volta sbrogliate, rendono tutto il processo di creazione più chiaro. Può anche essere utile mostrarlo, a volte può bastare provare se l'idea funziona a livello tecnico, ma a volte è possibile anche mostrarlo a chi poi prenderà decisioni perché dà immediatamente un'idea di dove si vuole arrivare, che prestazioni o di che interattività si parla.

#### Forbice

L'espressione della stima è intuitivamente temporale in ore o giorni uomo, ma non è l'unica possibilità. In alcuni framework agili questa viene sostituita con delle unità adimensionali o addirittura con qualcosa di non numerico: l'esempio classico sono le taglie delle magliette. Questo approccio è tipico di quei team che lavorano per sessioni (chiamati a volte sprint) che durano da una settimana in su dove il gruppo sa che entreranno un certo numero di task con una determinata taglia, rimanere vaghi è un metodo per evitare due cose, la prima è che si faccia della matematica non opportuna sulle stime: la sequenza di come si svolge il lavoro è importante e sommarle ciecamente può comportare problemi nello svolgimento poi; capita spesso, infatti, che chi sovraintende il lavoro abbia bisogno di avere una scaletta (ancora meglio una data) e la cosa più immediata è sommare i tempi ma magari non è la solzione migliore perché ci sono dipendenze tra i lavori o si ha un'idea globale del lavoro ma non sufficientemente dettagliata e possono sorgere fraintendimenti.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
L'espressione della stima è intuitivamente temporale in ore o giorni uomo, ma non è l'unica possibilità. In alcuni framework agili questa viene sostituita con delle unità adimensionali o addirittura con qualcosa di non numerico: l'esempio classico sono le taglie delle magliette. Questo approccio è tipico di quei team che lavorano per sessioni (chiamati a volte sprint) che durano da una settimana in su dove il gruppo sa che entreranno un certo numero di task con una determinata taglia, rimanere vaghi è un metodo per evitare due cose, la prima è che si faccia della matematica non opportuna sulle stime: la sequenza di come si svolge il lavoro è importante e sommarle ciecamente può comportare problemi nello svolgimento poi; capita spesso, infatti, che chi sovraintende il lavoro abbia bisogno di avere una scaletta (ancora meglio una data) e la cosa più immediata è sommare i tempi ma magari non è la solzione migliore perché ci sono dipendenze tra i lavori o si ha un'idea globale del lavoro ma non sufficientemente dettagliata e possono sorgere fraintendimenti.
L'espressione della stima è intuitivamente temporale in ore o giorni uomo, ma non è l'unica possibilità. In alcuni framework agili questa viene sostituita con delle unità adimensionali o addirittura con qualcosa di non numerico: l'esempio classico sono le taglie delle magliette. Questo approccio è tipico di quei team che lavorano per sessioni (chiamati a volte sprint) che durano da una settimana in su dove il gruppo sa che entreranno un certo numero di task con una determinata taglia, rimanere vaghi è un metodo per evitare due cose, la prima è che si faccia della matematica non opportuna sulle stime: la sequenza di come si svolge il lavoro è importante e sommarle ciecamente può comportare problemi nello svolgimento poi; capita spesso, infatti, che chi sovraintende il lavoro abbia bisogno di avere una scaletta (ancora meglio una data) e la cosa più immediata è sommare i tempi di stima. Purtroppo però questa scelta potrebbe non essere la soluzione migliore perché ci sono dipendenze tra i lavori o ci sono aree ancora troppo poco chiare per avere una stima affidabile.

La seconda è che si vuole semplificare il lavoro di stima evitando di dare un numero in ore e quindi si sa che ce la si farà in una sessione ma si evita di approfondire quanto anche per non creare fraintendimenti.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Se si vuole dare idea di voler descrivere due cose, é meglio separarle in 2 paragrafi diversi o fare un elenco puntato con la descrizione.
Leggendo un po' velocemente, mi ero perso che erano 2 le cose: usare elementi grafici con i paragrafi o gli elenchi, aiuta il lettore a tenere in mente che le cose che leggerà saranno 2.

Se la stima invece è scritta sotto forma di tempo possiamo usare lo stratagemma di creare una forbice con un tempo minimo e massimo per lo svolgimento del lavoro, questo per conteggiare il rischio soprattutto di quelle parti che risultano nuove che potrebbero portare con sé delle criticità. Un altro modo è spesso quello di indicare una stima e poi aggiungere un margine, questo è forse il metodo più incerto perché il margine è spesso arbitrario; generalmente si usa Pareto aggiungendo il venti per cento a quanto ottenuto.

#### Specifiche
Cadienvan marked this conversation as resolved.
Show resolved Hide resolved

Partendo sempre dal metodo empirico ci accorgiamo prima di tutto che l'incertezza comporta una cosa tanto banale quanto vera: sappiamo quanto ci abbiamo messo quando lo abbiamo fatto. Questo perché è solamente alla fine che è chiaro quello che si voleva produrre, in una parola serviva sapere quale era la definizione di fatto.
Per saperlo è necessario avere delle specifiche ed è facile intuire che più sono precise più è semplice pianificare. Anche chi lavora da poco nel settore sa che sono complicate da ottenere e a volte fumose. Il primo consiglio qui è quello di studiare il dominio applicativo perché avere una nomenclatura delle cose dà uno slancio non irrisorio. Poi è necessario parlare con chi ha questa conoscenza, andare a cercare alla fonte e chiedere più chiarimenti possibili; anche in questo caso la scomposizione e l'iterazione sono utili. Ci sono delle cerimonie specifiche in alcuni framework e metodologie che possono venirci incontro, ad esempio l'[event storming](https://en.wikipedia.org/wiki/Event_storming) il cui scopo è proprio quello di chiarire i flussi e nomi del dominio il più possibile; questo è un vero e proprio workshop che ha lo scopo di far incontrare chi sviluppa con chi ha bene chiaro il dominio dove l'applicazione che vogliamo sviluppare va ad operare, se per esempio stiamo creando una web app per degli ordini di una pizzeria, parlare col personale e raccogliere informazioni e far si che il software segua i processi è molto utile perché di fa capire quali problemi stiamo risolvendo in maniera diretta, la contaminazione è fondamentale per un prodotto di qualità e per ridurre al minimo i fraintendimenti.

#### Condivisione

La ricerca di pattern, come già citato, può essere molto utile poiché ci consente di riconoscere requisiti o funzionalità già visti o fatti; abbiamo poi accennato al concetto di Proof of Concept, che aiuta laddove ci si trovi davanti ad un problema nuovo.

Il problema di entrambi gli approcci è che si basano sulla nostra conoscenza e capacità di osservazione e studio.

La condivisione e la contaminazione con il business e con figure con esperienze diverse dalla nostra possono risultare una chiave fondamentale per risolvere i problemi apparentemente più complessi.
Ma come possiamo ottenere contaminazione e condivisione in maniera efficace?

Si possono organizzare dei meeting di condivisione e di stima dei problemi; il problema visto da angolazioni differenti può svelare caratteristiche di cui non avevamo tenuto conto, e anche un singolo confronto può risultare fondamentale nel risolvere una problematica che sembrava insormontabile.

In alcuni framework agili ci sono proprio dei momenti per questo tipo di approccio, per citarne uno: "planning poker"; questa è quella che si chiama "gamification", cioè trasformare l'attività in qualcosa di simile ad un gioco per renderla più leggera. Questa attività si svolge in maniera simile ad una mano di poker dove ogni partecipate ha un mazzo di carte dove al posto dei semi ci sono dei numeri. Si inizia spiegnado per bene il problema da risolvere e che si vuole stimare, si inizia poi un giro in cui ogni persona sceglie una carta col numero che rappresenta la sua stima (es. 8 ore) e la appoggia sul tavolo, a questo punto bisonga giustificare la propria scelta; si procede in questo senso fino a che non c'è una convergenza su una stima comune o una forbice. La base di questo procedimento è dire quanto ci si metterebbe ma soprattutto perché, questo accresce nel gruppo la consapevolezza degli ostacoli da superare dal punto di vista di ogni componente del gruppo; consapevolezze che, magari, singolarmente poterebbero non così evidenti o richiedere più iterazioni di studio. Le carte sono facilmente reperibili, sono spesso numerate con unità temporali base come l'ora, la giornata o la settimana (e così via) oppure si usano sequenze come quella di Fibonacci, quest'ultima è spesso utilizzata come referimento perché approssima meglio la realtò anche come si presentano in natura come in botanica o musica.

#### MVP

Il concetto di riduzione e scomposizione porta con sé un approccio naturale, cioè definire quali siano le parti fondamentali dell'applicativo. Si può introdurre un concetto semplice ma piuttosto efficiente ed efficace: dare una risposta alla domanda "quali sono le funzionalità minime per poter andare sul mercato?"; questo accorcia di molto il tempo di arrivo sul mercato perché elimina le funzioni non necessarie, semplifica la visione e lo sviluppo. Questo concetto è alla base del pensiero agile e va sotto il nome di Minimum Viable Product (MVP), abbassa il rischio rendendo più corto lo sviluppo, chiarisce meglio i goal del progetto e aiuta ancora una volta a scomporre le cose in elementi più piccoli o, se vogliamo, minimi perché il progetto abbia quel valore sul mercato che il business si aspetta.
Cadienvan marked this conversation as resolved.
Show resolved Hide resolved