fix: formatting

docs/it/stime.md

@@ -1,14 +1,13 @@
 #### 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.
+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 per molti versi 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 nello comprendere, prima di tutto, quale è la natura del processo di creazione del software stesso, cerchiamo quindi di andare a definirnr la natura e quali incognite nasconda. I processi si categorizzano in base alla variabilità cioè di delle incognite che si incotrano 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.
 
-
 Partendo da questo concetto il processo di produzione di un qualsiasi prodotto è delineabile come definito, statistico ed empirico; il tipo definito è il più semplice, non c'è alcuna sorpresa durante lo svolgimento, è qualcosa che abbiamo già fatto quindi non richiede alcuno sforzo perché sappiamo già prevederlo a monte. Nel nostro campo l'esempio tipico è quello della configurazione di un servizio, l'installazione di un software e così via, non ha alcuna variabilità se non minima quindi qui la stima è deterministica e non comporta problematiche.
 Quello statistico è similare ma con variabilità più alta, significa che lo abbiamo già fatto ma sappiamo che potrebbero esserci dei problemi durante lo svolgimento; qui si possono fare delle stime basate, appunto, su esperienze precedenti, abbiamo una vasta gamma di pattern che si ripresentano e quindi predire un tempo di esecuzione è meno semplice del precedente ma sempre fattibile magari con una forbice.
 L'ultimo è quello più ostico e lo è perché percorriamo una strada non battuta: è quello che spesso ci si trova ad affrontare nel software che ha a che fare precisamente con ricerca e sviluppo; questo è di fatto il caso peggiore e richiede un approccio più complesso perché lo si conosce una volta che lo abbiamo fatto, non abbiamo un'esperienza specifica che lo possa descrivere. Dobbiamo cercare quindi di portarci verso gli altri due casi e diminuire l'incertezza mano mano per raffinazioni successiva, in maniera incrementale. In altre parole, dobbiamo delineare delle strategie.
@@ -23,18 +22,18 @@ Nella suddivisione si possono scorgere, come si è visto, criticità; sono le pa
 
 #### 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. 
+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.
 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.
 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
 
 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 il cui scopo è proprio quello di chiarire i flussi e nomi del dominio il più possibile. Qui la contaminazione col business è fondamentale per un prodotto di qualità e ridurre al minimo i fraintendimenti.
+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 il cui scopo è proprio quello di chiarire i flussi e nomi del dominio il più possibile. Qui la contaminazione col business è fondamentale per un prodotto di qualità e 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. 
+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.