Capitolo Stime

[eppak]

Ecco la prima bozza del capitolo, attendo feedback

[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]

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 !

[Cadienvan]

Questi primi due o tre punti mi sembrano troppo "ricchi" dal punto di vista lessicale, ho dovuto leggerlo un paio di volte per capire ahah magari riscriverei l'inizio in maniera più semplice. "Dal punto di vista della variabilità è delineabile come definito, statistico ed empirico", per esempio, potrebbe diventare "Possiamo definire principalmente tre modalità di produzione del software: Definito, statistico ed empirico" o qualcosa di simile, cosa ne pensi?

[Cadienvan]

Suggested change

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.

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

[Cadienvan]

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é conoscere la nomenclatura e il perimetro delle cose da un vantaggio non indifferente. È necessario poi 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.

[Cadienvan]

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

[Cadienvan]

Ho capito il senso del paragrafo, ma la struttura lo rende di difficile lettura, almeno dal mio punto di vista.

Ci provo:

Suggested change

	La ricerca di pattern, abbiamo detto, è molto utile perché ci consente di riconoscere cose già viste o fatte; per quelle non conosciute il PoC e/o del tempo allocato per lo studio è un ottimo approccio. Resta però che così è vincolato alla nostra mera conoscenza dell'argomento, abbiamo un solo punto di vista che al più possiamo contaminare leggendo quello degli altri su articoli o libri ma l'opinione dal vivo racchiude molto più valore.
	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.

[Cadienvan]

Suggested change

	Si può infrangere questa barriera effettuando dei meeting di condivisione e di stima delle entità dei problemi in gruppo; il problema visto da angolazioni differenti può svelare caratteristiche di cui non avevamo tenuto conto, anche solo un singolo confronto può portare grande valore ma più è di gruppo meglio è.
	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.

[Cadienvan]

Suggested change

In alcuni framework agili ci sono proprio dei momenti per questo tipo di approccio, per citarne uno: "planning poker". Una gamification di questo processo che si svolge intorno ad un tavolo dove ogni uno, usando un mazzo di carte appositamente numerato (spesso usando Fibonacci), dà la sua stima esprimendo il suo punto di vista. Si svolgono più mani proprio come a poker, ascoltare il punto di vista degli altri e le loro considerazioni consentono di arrivare ad una convergenza appunto di una visione condivisa del problema e quindi ad una stima.

In alcuni framework agili il problema viene risolto alla fonte tramite delle apposite cerimonie, per citarne uno: _Planning Poker_. Una _gamification_ di questo processo che si svolge intorno ad un tavolo dove ognuno, usando un mazzo di carte appositamente numerato (spesso usando la sequenza di Fibonacci), dà la sua stima esprimendo il suo punto di vista. Si svolgono più mani proprio come a poker, ascoltando il punto di vista degli altri e le loro considerazioni, consentendo di arrivare non solo ad una convergenza e ad una visione condivisa del problema, ma anche ad una stima.

Aggiungerei un "Come mai si usa la sequenza di Fibonacci?", che ne pensi?

[Cadienvan]

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!

[serenasensini]

Suggested change

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, chiedendo a dieci persone probabile che 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.

[serenasensini]

Suggested change

Nell'ambito informatico, la stima, può essere usata per dare una dimensione ad un task o ad un intero progetto, aiuta 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, per molti versi lo stiamo facendo anche noi quando programmiamo.

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.

[serenasensini]

Suggested change

Viene piuttosto naturale capire che, il cosiddetto Time To Market (tempo di arrivo su un certo mercato), può risultare determinante nella riuscita di un prodotto; impatta per forza di cose anche su come il business lo percepisce perché determina quando inizieranno a tornare i profitti da quello che di fatto è investimento. In poche parole il business prende decisioni su questo parametro che diventa perno, insieme ad altri fattori, per delineare le strategie aziendali. Pianificare in base ad una stima temporale non è l'unica maniera di gestire questo aspetto, ma è sicuramente il preponderante che quindi merita di essere prima di tutto compreso come processo.

Viene piuttosto naturale capire che il cosiddetto Time To Market (tempo di arrivo su un certo mercato), può risultare determinante nella riuscita di un prodotto; impatta per forza di cose anche su come il business lo percepisce perché determina quando inizieranno a tornare i profitti da quello che di fatto è investimento. In poche parole, il business prende decisioni su questo parametro che diventa perno, insieme ad altri fattori, per delineare le strategie aziendali. Pianificare in base ad una stima temporale non è l'unica maniera di gestire questo aspetto, ma è sicuramente il preponderante, e quindi merita di essere prima di tutto compreso come processo.

[serenasensini]

Suggested change

Cercando di comprendere meglio la natura di quello che facciamo dobbiamo andare a definire cosa è il processo di produzione del software e quali incognite nasconde. Dal punto di vista della variabilità è 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. 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, qui si possono fare delle stime basate 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.

Cercando di comprendere meglio la natura di quello che facciamo dobbiamo andare a definire cosa è il processo di produzione del software e quali incognite nasconde. Dal punto di vista della variabilità è 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. 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, qui si possono fare delle stime basate 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.

[serenasensini]

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. Dobbiamo cercare quindi di portarci verso gli altri due casi e diminuire l'incertezza mano mano per raffinazioni successiva, in maniera incrementale; dobbiamo delineare delle strategie.

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

[serenasensini]

Suggested change

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 quindi un lavoro più piccolo ci consente di essere compreso meglio, il cervello umano non è in grado di tenere sotto controllo una moltitudine di elementi, ma una visione prima di insieme e poi del dettaglio rende le cose più facili da dominare. La riduzione rende anche chiare altre due cose, le criticità: ovvero 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ù 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.

[serenasensini]

Suggested change

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.

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.

[serenasensini]

Suggested change

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.

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.

[serenasensini]

Questo passaggio non mi è molto chiaro... Non fare della matematica? A che domanda vorresti rispondere?

[serenasensini]

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.

[serenasensini]

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

[serenasensini]

Suggested change

In alcuni framework agili ci sono proprio dei momenti per questo tipo di approccio, per citarne uno: "planning poker". Una gamification di questo processo che si svolge intorno ad un tavolo dove ogni uno, usando un mazzo di carte appositamente numerato (spesso usando Fibonacci), dà la sua stima esprimendo il suo punto di vista. Si svolgono più mani proprio come a poker, ascoltare il punto di vista degli altri e le loro considerazioni consentono di arrivare ad una convergenza appunto di una visione condivisa del problema e quindi ad una stima.

In alcuni framework agili ci sono proprio dei momenti per questo tipo di approccio, per citarne uno: "planning poker". Una gamification di questo processo che si svolge intorno ad un tavolo dove ogni persona, usando un mazzo di carte appositamente numerato (spesso usando Fibonacci), dà la sua stima esprimendo il suo punto di vista. Si svolgono più mani proprio come a poker, ascoltare il punto di vista degli altri e le loro considerazioni consentono di arrivare ad una convergenza appunto di una visione condivisa del problema e quindi ad una stima.