Capitolo Stime #225

eppak · 2024-04-22T15:13:00Z

Ecco la prima bozza del capitolo, attendo feedback

docs/it/stime.md

BrianAtzori

Ho lasciato qualche correzione per degli errorini ma per il resto per me ci siamo, un altro buon capitolo!
Forse chi ha piu esperienza puo aggiungere altro in termini di nozioni ma l'ho trovata un'ottima panoramica generale 🚀

eppak · 2024-04-23T19:12:21Z

Ho lasciato qualche correzione per degli errorini ma per il resto per me ci siamo, un altro buon capitolo! Forse chi ha piu esperienza puo aggiungere altro in termini di nozioni ma l'ho trovata un'ottima panoramica generale 🚀

Grazie @BrianAtzori !

Co-authored-by: Brian Atzori <[email protected]>

docs/it/stime.md

Cadienvan · 2024-04-27T07:10:42Z

docs/it/stime.md

+L'espressione della stima è intuitivamente temporale in ore o giorni uomo, ma non è l'unica possibilità. In alcuni framework agili la sostituisce 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. 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


Espanderei un pochino tutta questa sezione.

Parli di requisiti, dominio applicativo, andare alla fonte (Product Team / Business Owner di riferimento), cerimonie..

Sono cose che dal punto di vista di chi sa già cosa siano sono chiare, ma per il target di questo libro potrebbero essere cose nuove o comunque difficilmente comprensibili. Che ne pensi? Lo espanderei anche a 15-20 paragrafi se necessario, magari mettendo un cappello iniziale a tutto il capitolo dicendo che quando parliamo di stime dobbiamo considerare il contesto aziendale e che questo è composto da tanti fattori, tra cui....

docs/it/stime.md

Cadienvan · 2024-04-27T07:20:48Z

docs/it/stime.md

+
+#### 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.


Espanderei tutta la sezione dedicandogli qualche paragrafo in più, dall'introduzione del concetto di MVP al contesto e al risultato che questo comporta. Come sopra, è una lettura che risulterebbe sufficiente e sensata solo a chi già conosce il concetto - anche a grandi linee -, ma non al target tipico di questo contenuto. Terrei comunque il significato immutato, perché comunque è corretto, semplicemente lo espanderei per aiutare chi sente il termine per la prima, o seconda, volta.

Cadienvan

Mi piace molto, è un capitolo complesso quindi ho deciso di metterci bene la testa.

Ho segnato alcuni appunti, in generale mi torna, è sensato e scorre, ma mancano delle premesse e delle descrizioni di termini e significati che avrebbe senso indicare prima di far proseguire l'utente nella lettura.

serenasensini

Capitolo estremamente importante perché non esiste materiale chiaro sul tema ed è allo stesso tempo qualcosa di molto controverso. Oltre ai commenti di @Cadienvan , mi sento di aggiungere che avete più esempi pratici lo renderebbe più immediato. Come sempre, ottimo lavoro!

docs/it/stime.md

serenasensini · 2024-05-04T15:47:31Z

docs/it/stime.md

+#### 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é la già una nomenclatura delle cose da uno slancio non irrisorio. Poi è necessario parlare con chi ha questa conoscenza, andarle 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 es. 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.


Suggested change

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é la già una nomenclatura delle cose da uno slancio non irrisorio. Poi è necessario parlare con chi ha questa conoscenza, andarle 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 es. 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.

Rivedrei questa sezione, perché il rimando all' event storming non mi è chiaro

docs/it/stime.md

Co-authored-by: Michael Di Prisco <[email protected]>

Co-authored-by: Serena Sensini <[email protected]>

…esso

Co-authored-by: Michael Di Prisco <[email protected]>

Co-authored-by: Michael Di Prisco <[email protected]> Co-authored-by: Angelo Cassano <[email protected]> Co-authored-by: Michael Di Prisco <[email protected]> Co-authored-by: Nicola Erario <[email protected]>

Co-authored-by: Michael Di Prisco <[email protected]> Co-authored-by: Michael Di Prisco <[email protected]> Co-authored-by: Brian Atzori <[email protected]> Co-authored-by: Paolo Martinoli <[email protected]> Co-authored-by: Angelo Cassano <[email protected]> Co-authored-by: Nicola Erario <[email protected]> Co-authored-by: Corrado Petrelli <[email protected]> Co-authored-by: Serena Sensini <[email protected]>

docs/it/stime.md

serenasensini · 2024-07-27T21:49:02Z

docs/it/stime.md

+
+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.


Suggested change

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.

L'ultimo è quello più ostico e lo è perché percorriamo una strada non battuta: è quello più frequente e che ha a che fare precisamente con processi di ricerca e sviluppo. Questo è di fatto il caso peggiore e richiede un approccio più complesso, perché la reale stima la si conosce una volta che il processo giunge a termine, visto che 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.

Aggiungo una nota: rispetto a queste 3 definizioni, questa mi sembra quella che può portare più confusione. Ci può stare che una stima su un processo "non conosciuto" a priori sia difficile da fare, ma non credo riguardi i processi di ricerca e sviluppo (non sempre, almeno) e che la stima la si conosca solo alla fine del processo, mi sembra fuorviante, ma magari sbaglio... Hai della letteratura di riferimento?

@serenasensini rileggendo noto che il mio approccio tende a ritornare molto su quello che è scrum e l'approccio/visione che ha delle cose. Qui la questione è che per sapere quanto ci vuole nella totalità è necessario definire bene cosa significa fatto ma, per farlo, sono necessarie più iterazioni per definire cosa significhi "fatto" per il committente. Qui per stima non intendo quella dell'iterazione singola ma di quella per arrivare alla conclusione. Mi rifaccio a quanto ho imparato tempo fa, ho trovato solo questo video che lo riassume ma, come dicevo, gira sul concetto di definizione di fatto per potare verso scrum e potrebbe essere effettivamente fuorviante.

https://vimeo.com/176463126

Cosa ne pensi?
Sicuramente è da rivedere, se dici che non è troppo legato a scrum (mio dubbio) posso provare a riformulare; nel senso che "è di valore per il lettore esplorare il concetto di definition of done?" non volevo essere troppo dettagliato per non farlo diventare pesante.
Grazie

Sicuramente si vede l'impronta legata a Scrum, che può starci (visto il tema), ma va dettagliato: io credo che sia importante espandere questa sezione mostrando l'esempio anche nel video, per portare più dettaglio. La cosa che mi preme è che sia semplice e contestualizzato anche per chi è a digiuno di Scrum! So che non è un compito facile, ma sono sicura tu possa riuscirci 🙌

@serenasensini ho fatto una bella (spero) integrazione, posso chiederti di dare un occhio? Grazie!

Ho aggiunto la descrizione dell'event storming, ho fatto una cosa leggera

Cadienvan · 2024-07-29T15:17:05Z

Per i conflitti sul file curriculum non vi preoccupate, ci penso poi io prima di mergiare.

Co-authored-by: Serena Sensini <[email protected]>

sensorario · 2024-09-05T11:29:02Z

docs/it/stime.md

+
+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.


Non mi torna la frase "Dobbiamo ricordarci infatti che lo sviluppo è parte del business, e per molti versi lo stiamo facendo anche noi quando programmiamo.". Nel senso che leggo... "lo asviluppo è parte del business" e poi leggo "lo stiamo facendo anche noi quando programmiamo".

Cioè. Certo che chi programma sviluppa. Quell'anche mi disorienta.

Credo che il senso espresso fosse che "anche noi facciamo business quando programmiamo"

@Cadienvan esattamente, @sensorario provo a riformularla

Ho migliorato il fraseggio

docs/it/stime.md

Co-authored-by: Simone Gentili <[email protected]>

AngeloAvv · 2024-09-15T15:25:50Z

Che succede? Perché fra le changes vedo altri capitoli?

eppak · 2024-09-15T19:36:05Z

Che succede? Perché fra le changes vedo altri capitoli?

@AngeloAvv questa stesura dura da un po', é stato fatto un rebase tempo fa con l'idea di sistemare poi. Ti torna?

Cadienvan · 2024-09-16T19:36:43Z

@AngeloAvv @eppak a posto!

Cadienvan · 2024-11-11T08:47:02Z

@eppak preferisci che la metta in draft in attesa di correggere il tutto?

eppak · 2024-11-11T10:38:38Z

@Cadienvan ciao, ho revisionato molte parti, mi manca la verifica di aver soddisfatto tutte le risposte ma molte sono outdated. Cosa consigli? Sarebbe comodo poter capire cosa é pendente, ma non mi è evidente

feat: capitolo stime

7cc8eb9

BrianAtzori reviewed Apr 23, 2024

View reviewed changes