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!

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

[eppak]

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?

Questo mi piace tanto come punto di vista, lo metterei come cappello spiegando poi che si da il focus sul tempo (al netto che sarebbe bello anche espandere il resto, altra rev? altro capitolo?)

Come intro cosa ne pensi?
Grazie

[allevo]

Concordo sul "restare semplici" (se no non si finisce più).
E concordo sul fare un cappello introduttivo che spieghi bene che il termine "stima" é complesso e declinato in diverse sfaccettature.

[allevo]

Ho messo dei commenti per correggere qualche typo e suggerire dei titoli diversi, ma non ho una forte opinione in merito, sentiti pure libero di ignorarli e risolverli.

Non ho trovato invece la intro di cui si parlava la review scorsa. Secondo me quella può dare veramente molto valore e contesto.

[allevo]

Suggested change

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.

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 aziendali; delineare la pianificazione in base ad alla stima temporale non è l'unica maniera di gestire questo aspetto, ma è sicuramente spesso il preponderante.

[allevo]

Suggested change

	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.
	L'esempio classico è la produzione di un bene materiale dove per forza di cose, errori, difformità di materiali e altre variabili possono incidere sul risultato che produciamo; ci troviamo di fronte ad un processo che può essere dominato con la statistica, cioè so che avrò un certo scarto percentuale.

[allevo]

Suggested change

	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.
	In questo contesto di incertezza nasce il processo empirico che ha preso piede negli ultimi venti anni, si tratta di abbracciare un po' questa incertezza e procedere in maniera iterativa.

[allevo]

Suggested change

	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 importante, automatizzati magari per un riuso in altri ambiti.
	Partire da elementi di base e poi costruire in maniera 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 importante, automatizzati magari per un riuso in altri ambiti.

[allevo]

suggerisco di fare un elenco puntato con le due strategie in modo da dividere bene il testo (anche visualmente). Inoltre si eviterebbe il ":" dentro un altro ":".

[allevo]

Suggested change

	#### Forbice
	#### Unità di misura

O simili.

[allevo]

Suggested change

	#### Specifiche
	#### L'impatto delle specifiche sulla stima

che te ne pare ?

[eppak]

@allevo

Non ho trovato invece la intro di cui si parlava la review scorsa. Secondo me quella può dare veramente molto valore e contesto.

Non l'ho ancora fatta fino a che il corpo centrale non è definitivo per evitare di accavallare le cose, una volta che commenti e cambi sono a posto procedo.

Grazie mille