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]

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!

[Cadienvan]

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

[AngeloAvv]

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

[eppak]

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]

@AngeloAvv @eppak a posto!

[Cadienvan]

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

[eppak]

@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

[Cadienvan]

Dal mio punto di vista è tutto ok, ciò che doveva essere espanso è stato espanso.
@serenasensini lascio a te la palla per dare una riletta e capire se secondo te ora torna.
Ho visto qualche punto in cui probabilmente la forma è da rivedere, ma preferisco lasciare la palla al @Il-Libro-Open-Source/drafting-group per evitare rework inutili!

[allevo]

Questo capitolo ha delle enormi potenzialità!
Ho iniziato a lasciare qualche commento.

Ti consiglio, prima di iniziare a risolvere le discussioni, di strutturare il capitolo utilizzando diversi headers (pensala come se fossero degli h1, h2, h3 etc) in modo da organizzare meglio la struttura delle informazioni.

Ultimo ma non meno importante, si parla solo di stime temporali: quando si stima una task ha senso parlare solo di quelle (opinabile).

Invece quando si hanno a che fare con progetti interi, ci sono altri parametri, come:

• la stima dalla capacity (non ho idea di come si traduca bene in italiano): quante persone servono? Quando si introducono le persone nel progetto? Posso per esempio partite "piano" con un paio di persone e rinforzare in team più avanti quando effettivamente ce n'è necessità. Pratica molto usata in caso di poc.
• stima delle competenze richieste: che siano tecniche o meno, un progetto dovrà sempre essere contestualizzato all'interno di un mondo in cui ci sono già altre cose. Angular? React? C#? Java? DevOps? E altro. Devo quindi capire e stimare quali siano le competenze richieste per fare un progetto
• stima economica di sviluppo: in particolare in consulenza le persone "costano" in modo diverso, banalmente perché magari hanno uno stipendio diverso. Personalmente trovo brutto dire che "le persone hanno un costo", ma dal punto di vista prettamente aziendale é vero 😢
• stima economica di installazione: non é detto che sia 0. Per esempio potrebbe richiedere un consulente esterno che di configura la macchina come necessario e, per qualche regola aziendale, non puoi farlo tu
• stima economica di runtime: quanto costa tenere su tutta la barca? Qui rientrano i costi sia delle macchine, sia di network (sul Cloud questo impatta tanto), sia di licenza sui prodotti terzi (CRM, tutti i SaaS)
• stima interazioni umane (non so come chiamarle): se lo sviluppatore mi deve tenere d'occhio anche le email perché "si sa mai" o deve scrivere le minute o organizzare meeting o mettere tutto d'accordo su una soluzione, difficilmente scrive codice. Nascono quindi figure professionali che fanno quello. In base a quanto si stima l'entropia comunicativa, questa stima può essere alta o bassa. Esempio: se hai un solo interlocutore é semplice; se hai 4 stackholders diversi un po' meno perché ognuno avrà la sua idea e trovare una unica soluzione potrebbe essere complicato.
• altri...

Scusa se sto scrivendo un muro di testo, ma credo possiamo mettere da qualche parte in questo capitolo questo elenco per dare idea che in base al livello di visibilità, le stime possono essere di diverso tipo.

Che ne pensi?

[allevo]

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.

[allevo]

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.

[allevo]

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.

[allevo]

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

[allevo]

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

[allevo]

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

[allevo]

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

[allevo]

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

[allevo]

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.

[allevo]

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.