Ah, eccoci qua, puntata 99.Cacchio, sono già le 9.40 della sera, avremmo dovuto iniziare a registrare alle 9, però ci siamo presi un po' in chiacchiere, ma è normale così.Questa settimana abbiamo un nuovo episodio e sono in compagnia di Carmine e Luca.Ciao ragazzi, com'è? Ciao Mauro, ciao a tutti.Ciao ragazzi, benvenuti ad un'altra puntata.Mamma mia.bellissimo wow ciao ragazzi state usando trueball anche oggi? in realtà mi avete infatti mi avete liberato dalla cantina del nostro github per due settimane sono stato assente ma eccomi qua devo dire che piano piano col tempo la cantina diventa sempre più confortevole Però prima di introdurre l'argomento di oggi che andremo a provare ad analizzare a capire con Carmine e Luca il mio compito è quello di ricordarvi i contatti info@gitbar.it @brainrepo su Twitter Il gruppo Telegram lo potete trovare cercando i gruppi cercando Gitbar ci sarà il nostro logo con il meme del nostro brainrepo, non potete sbagliare.Assolutamente, è il gruppo diagramma più bello d'Italia per quanto riguarda il software development e non è come quei gruppi, diciamo sempre asterisco asterisco, Italia, dove si fanno flame su RAL, su linguaggi di programmazione, su cose inutili.Noi facciamo flame sulle cose importanti, parliamo di politica estera e di Drupal.Un gruppo solo su Drupal.In questo periodo stai flammando Drupal e ti garantisco...Un periodo di sofferenza.Un periodo di sofferenza.E ti garantisco che faremo un episodio su Drupal.Guarda, Drupal...in questo momento ho la Triade, che è il Drupal magento, e Jumla.Jumla? Esiste ancora? Sì, nella pubblica amministrazione.Esiste ancora, io ne lo so.Fa "guarda io voglio fare esattamente di tutto ciò che ho messo su Joomla"."Guarda ma io ti devo fare una roba per la...non lo so, tipo una roba che ho accetto un cazzo col gestionare con Joomla".Fa "no, noi abbiamo tutto su Joomla".Tutto va bene.E tra l'altro ho rivisto anche quel simpaticone di CakePHP.Esiste ancora anche quello? Esiste ancora anche CakePHP e sembra andare, ovviamente con Apache e non con Nginx.Ma andare dove? Dove sta andando? In questo momento sta andando nella mia cartella tmp perché faccio clone e poi lo cancello perché mi fa troppa rabbia vedere quelle cose in questo momento sta andando lì però in realtà ci sono anche dei dei dei progetti nuovi con khp io ho visto che delle scale up lo stavano utilizzando adesso non so con quanto è successo e con quanto...cioè io sono rimasto a PHP che non supportava la dependency injection quindi non so cosa sia successo nel mentre, vi dico la verità.Però mi sembra un po' vecchiotto, ma ripeto potrei dire fesserie.Carmine sta controllando la versione se supporta la dipendenza di Injection? In realtà, secondo me poi si ritorna anche a quel discorso dove si dice sempre che il prodotto conta più della tecnologia, almeno nella fase iniziale, eccetera eccetera.Devo dire comunque che non mi aspettavo una quantità di...sicuramente ci sarà chi da una nuova stavolta in situazione di "io con Drupal faccio partire i missili".Però comunque su alcune cose rispetto magari ad altre tecnologie che ho avuto modo di usare, mi sembra comunque incastonato in un paradigma che non mi è molto ergonomico.Sto cercando di essere quanto più democristiano possibile e light possibile in questa cosa.però però la facciamo un'arena allora io so che e lo salutiamo Paolo, Edo e tutti i ragazzi di Spark Fabric loro sono espertissimi in Drupal quindi sarebbe figo comunque fare fare una puntata dove proviamo davvero a capire se questo viene dai nostri pregiudizi viene dal fatto che il tool viene utilizzato come un martello per riparare i rubinetti e cose di questo tipo.E quindi questo è un invito ufficiale ai ragazzi di Spark Fabric di Continuous Delivery per venirci a trovare.Sì, sì, ma infatti poi alla fine è un CMS, Drupal, ora che tu usi il CMS per fare il sistema di fatturazione della tua piccola e media impresa, nel senso che stai utilizzando male lo strumento.È l'opinione di una persona che per 4 ore al giorno scrive ancora SQL a mano perché non usa Yormulando quando fa Go, poi non ha l'ora di rimettere mano su Active Record.Ma diciamo che ognuno programma e utilizza le cose che vuole.Programma come vuole e utilizza le cose che vuole.E fa le stime come vuole tra l'altro.E fa le stime come vuole.Stime che faremo subito dopo la sigla dell'episodio.Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer.I mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Eh sì, eh sì, avevo preparato una super introduzione dove parlavo di induzione, deduzione, realtà avevo scritto in scaletta di doverla preparare e non l'ho fatto.Quindi questa introduzione manca e la puntata la introduciamo così.Allora da uomini noi abbiamo sempre il desiderio di misurare qualunque cosa.Spesso misuriamo il passato, talvolta proviamo a misurare il presente ma ci gasa tantissimo misurare il futuro e proprio nell'ottica di misurare il futuro si posiziona il concetto di stima cioè quando proviamo a capire in anticipo quanto tempo ci metteremo per fare qualcosa piuttosto che qualcos'altro e quindi mi viene da chiedere a Luca e a Carmine ma avete qualche esperienza sulle stime? Allora bella domanda la stima è stata proprio per quanto mi riguarda il primo muro contro il quale sono andato a sbattere tipo il primo giorno o il secondo giorno di lavoro, in assoluto.Nel senso ero fresco fresco, pischello e il capo mi fa "ma quanto ci metti a fare questa cosa qui?" e io assolutamente spiazzatissimo, dice "che ne so, io ho sempre programmato alla buona, ho sempre detto "ma faccio questo, domani faccio quell'altro.Avevo già la consapevolezza che cose che credevo dovesse impiegarci pochissimo sono stato lì per mesi e mesi e cose che invece credevo essere super complicate, alla fine le ho fatte in 30 secondi e quindi quella domanda mi spiazzò e mi ricordo che litigai, no, però discussi circa mezz'ora con lui e dice "no, no, io la stima non lo so, non so che dirti, proprio non ci riesco" e lui dice "no, ma io ho bisogno di sapere quanto tempo ci metti, ma io non te lo so dire, come faccio a dirtelo? Cioè può dipendere da mille fattori" e all'epoca non avevo l'esperienza per poter fare un ragionamento complesso e non ce l'ho tuttora.Insomma, e dai e dai, ti remolla, alla fine glielo ho buttato lì, due settimane.E lui, senza dire, senza obiettare, ha scritto nel suo taccuino digitale o nel quaderno, non so che cosa sasse due settimane.La cosa bella è che le ho azzeccate, cioè ci ho impiegato due settimane precise spaccate.Adesso non so se la misurazione che ho fatto, se la stima che ho fatto ha influito sul tempo effettivo del del lavoro o se ero particolarmente dotato nel fare stime o se ho avuto più probabilmente più semplicemente una grande botta di culo.Però questo è stato il proprio il primo muro contro cui ho sbattuto nel mio lungo cammino da programmatore.In realtà, nel senso, la mia storia è molto più semplice.È la storia di una persona che fa questo lavoro da anni e che, diciamo, con il menestare di tutti i supermanager delle le nostre migliori aziende non sa ancora dare una stima in ore uomo.Diciamo che è una metà tra non la sa dare e non la vuole dare, anche perché in Associazione di Stato ci sono tante di quelle variabili che è impossibile effettivamente dare una stima precisa a ore, minuti, ho conosciuto gente che fa le mezz'ore, non so come facciano, e spesso e volentieri, in realtà qui Sotomayor si entra anche in un altro discorso, dice "guarda, se tu me le chiedi a ore, ti dico 200 ore per fare una cosa che magari ce ne metto 30, così stai zitto".La mia sorella è che anche io nella mia giovinezza lavorativa ho peccato di iubris, come direbbero un po' gli anni fa, e ho fatto stime e ho detto cose che non erano nel mio senso, di cui poi me ne sono contato dopo e ne ho pagato anche le conseguenze.In questo momento io stimo a taglie, ci metto questa taglia, quella taglia e quella taglia.Poi che per il mio datore di lavoro, comunque a un certo punto queste taglie vengono tramutate in ore, quella è una cosa assolutamente normale, sarebbe anti-economico dire il contrario, però comunque per quanto riguarda io mi sono fatto male, ho detto che ci mettevo poche ore, sono stato weekend a lavorare, perché mi ero anche autoimposto una deadline, quindi alle persone che stanno cominciando ora non fatelo.La differenza tra la sindrome dell'impostore e la Dunning-Kruger all'inizio è veramente labile.Io ho sofferto prima della seconda, come tutte le persone quando iniziano, e io ovviamente soffro della prima, e ora sono un grande impostore, ma non tentate nemmeno di fare colpo sulle persone con cui lavorate, perché non è professionale, è semplicemente stupido.Sì è vero, quando ti chiedono una stima e tu non hai abbastanza informazioni per darla si crea quella cosa che tu devi dare necessariamente una risposta per dimostrare il tuo valore, ma non avendo informazioni fondamentalmente tu prendi una carta dal mazzo e qualunque valore è buono a quel punto una volta che hai dato la tua parola se sei una persona che dà peso alle proprie parole sei pronta a mantenerla con tutti i sacrifici perché da una parte c'è la posizione che tu vuoi mantenere all'interno di quel contesto dall'altra si va a creare anche una sfida con se stessi come per dire sì ma se non ci riesco a farlo in questo time slot forse sono incapace e questa cosa triggera attiva tutta una serie di meccanismi che poi portano al burnout possiamo anche dirlo no e quindi è diciamo una cosa altamente esplosiva però nel contempo possiamo anche dire che le stime hanno una loro utilità.Carmine diceva che le stime servono proprio per perché viviamo in un contesto che comunque misura un contesto economico un contesto dove il tempo l'effort sono delle variabili da prendere in considerazione e in quanto variabili da prendere in considerazione sono delle variabili che dobbiamo misurare nel prima nel durante e possibilmente dobbiamo provare a prevedere, immaginare il valore di queste variabili nel futuro.Allora la domanda che voglio farvi è, cos'è sono le stime e quanto sono importanti? Le stime sono come andare dal dentista, quella cosa che non vorresti mai fare, però poi ad un certo punto ti tocca.Secondo me le stime sono un modo per riuscire...Allora, secondo me sulle stime, non sto parlando di quelle stime ore, se il vostro manager vi impone delle stime al minuto, comunque non metto un layer di trasparenza tra quanto ci metti e come traduco quella cosa in ore, a meno che non siete veramente signori in alcuni contesti eccetera eccetera, vi dico storracete il naso insomma perché ha veramente poco senso.Secondo me le stime sono quella cosa che permette di affrontare il futuro con meno in certezza.Ora so che sarà flame, proprio così, ok.Io sono per le stime, come ho già detto a taglie, e sono per le stime e le milestone, ma non le deadline.E qui lancio la palla, anche perché già la parola deadline, io sono andato in burnout, assolutamente una cosa di cui parlo liberamente, quello che dico è già la parola deadline, una cosa che ha insidame non una cosa bruttissima.Si lavora a milestone.Se c'è una deadline si può gestire in tantissimi modi ma non vi ammazzate.Però nella vita di tutti i giorni le deadline ci sono.Nella vita di tutti i giorni comunque ci troviamo davanti a delle situazioni tale per cui si deve uscire nel mercato in una certa data e in un certo momento preciso ma quello che secondo me è importante sottolineare è che esistono delle condizioni dove le stime in qualche modo sono guidate dalle deadline io le chiamo le stime deadline driven che è quella condizione anche psicologica nel quale ci troviamo a lavorare dove il management che stima al posto dell'area engineering cioè è il management che dice se va bene tutto quello che ti pare ma noi dobbiamo uscire con questo prodotto in questa data e a quel punto tu puoi stimare quanto vuoi ma in quella data devi uscire e quindi o tagli di feature o trovi delle soluzioni tali per cui qualcosa la delivery.Ma questa cosa è tossica per il prodotto e per l'operatore? Non mi sbaglio Luca? Convieni con me? No assolutamente quello che dico spesso, per fortuna non spesso perché non mi capita spesso di avere deadline così serrate, però se c'è una deadline e la cosa non è tecnicamente fattibile, quella è l'opzione, cioè andare a castrare il prodotto, io dico sempre mettere un cartonato davanti, farlo vedere da lontano e sperare che non se ne accorgano e poi dopo la deadline aggiustiamo quello che c'è da aggiustare, però qui c'è una mancata organizzazione o una mancata comunicazione tra il management o sales o chi sta nel mezzo e la parte sviluppo.Penso che tanti di noi hanno avuto esperienza di sales manager che vendono cose non tecnicamente possibili, quando ci va bene ci si danno le deadline di cose fattibili, quando ci va male ci danno deadline su cose assolutamente non possibili da fare, è un danno per l'azienda, in qualche modo bisogna fare qualche capriola per restare a gallo.Capriole molto brutte, molto brutte perché poi alla fine è sul filo della presa in giro, però questa è la vita vera.Per fortuna per quanto mi riguarda mi riguarda quel tipo di azienda dove ho lavorato in questo modo, ricordo di un lontano passato.Per fortuna non mi riguarda più.No, però spesso come dicevo queste estime deadline driven in qualche modo dimostrano mostrano le stime come risultato di una negoziazione e mostrare le stime quanto appunto risultato di una negoziazione rende di per sé le stime non efficaci perché non stai stimando stai facendo lo yes man o comunque stai negoziando un valore questa negoziazione non è aderente alla percezione che l'operatore ha della realtà di lavoro ecco perché tutte le stime che sono in qualche modo conseguenza di una negoziazione sono delle stime a priori falsate che andranno comunque a decadere e allora ci troviamo davanti a un contesto dove possiamo trovarci davanti a un contesto dove chi non si trova davanti a questo contesto ringrazio dio perché come faccio io si reputa particolarmente fortunato un contesto dove da una parte abbiamo delle stime che da parte di alcuni management sono viste come risultato di questa famosa negoziazione.Dall'altra abbiamo questa pressione e in più si aggiunge la paura di fare delle stime sbagliate.Come gestire tutti questi stimoli, tutte queste influenze esterne nel momento appunto in in cui si va a stimare? LM: Posso dire "tiri un D20 e stimi così".No, non posso dirlo.LM: Ci starebbe un "dipende grande" quanto una casa.LM: No, qui c'è appunto tanta comunicazione, ma a tutti i livelli.è un problema che sta un po' dappertutto o quantomeno davanti a aziende che lavorano tanto col mercato e quindi hanno bisogno di uscire con determinati prodotti, con determinati feature in un determinato momento, ma questo problema lo possiamo risolvere o meglio lo lo stiamo risolvendo guardandolo dall'angolazione giusta oppure no? Non ho una risposta a questo perché altrimenti avrei fatto la mia azienda che risolve tutti i problemi del mondo.Secondo me la differenza sta nella cultura aziendale in cui vivi.La cultura aziendale dove hai paura di stimare, dove hai paura delle deadline, dove la pressione sociale fa sì che tu non… alla fine, insomma, magari sono stato un attimino così, forse l'avete già detto, ma alla fine per me stimare è un modo, per me in primis, di dare valore a quello che faccio.Tenendo conto che metto tutte le mani avanti, che non si è la stima, non si fa a ore, per lo sviluppatore una stima deve essere una linea di massima, una cosa quanto più spannometrica possibile, è un modo in primis per me per dare un valore, una proprietà a quello che faccio.Se il contesto in cui mi trovo è un contesto dove stimare, dove dare un valore al mio lavoro è qualche cosa che mi genera malessere e e spesso comunque è così, perché magari comunque soffri della cosa che il tuo collega quello lì bravo, quello lì lo faccio subito, bando l'exec, non lo so, con qualunque strumento, essere comunque in una condizione del genere, secondo me, qualunque discorso possiamo fare viene comunque meno.Se la cultura aziendale è una cultura sana ci ci si può ci sommettere d'accordo, altrimenti no, per quanto le stime possono essere come tirare un dato, se tirare questo dato fa sì che io devo avere paura per cui va a finire il resto della partita, secondo me non ha proprio senso ragionare, non so che ne pensate.Le stime si possono fare se sei nella condizione in cui le puoi fare, non che le devi fare.Infatti, adesso l'ho dato anche un po' per scontato, sopra chi ti sta chiedendo la stima deve avere la consapevolezza di che cosa è una stima e di quanto fragile essa è, quindi deve avere fallback, deve avere chiaro che io ti sto stimando in ore o in punti o quello che vuoi, ma è una stima e per questo può essere completamente sballata.Certo, il lavoro di tutti è far sì che la stima possa essere quanto più vicino possibile a quella vera, al tempo vero, finale, però tutta l'azienda deve essere consapevole del fatto che la perfezione non c'è e le cose possono andare anche molto male e devono avere compito di chi sta sopra e avere un fallback, un piano di recupero.Questo incide anche sulle paure del singolo che fa una stima e con un clima un po' più sereno le cose vanno meglio.Vero io dico anche che però ci sono delle situazioni tale per cui il contesto economico di un certo territorio.È malato e ti porta a lavorare in ambienti malati perché è una cosa che capita spesso all'interno della nostra community è vedere che c'è proprio una disparità di contesto dal contesto che ti permette di lavorare bene al contesto dove volenti o nolente ti trovi a fare delle stime con l'acqua alla gola a fare delle stime come dicevo prima negoziate e su questo ci batto molto.Nel senso che è una non stima quella cioè quella è un'imposizione anche se è frutto di una negoziazione ma il compromesso è comunque un'imposizione.quindi ci andrebbe un dipende grande quanto una casa.Però volendo in qualche modo provare a fare sintesi.Secondo me nella stima entrano in gioco due elementi.Il primo è la comprensione del contesto quello che vi ho detto prima.Quindi di questo tipo di pressioni possiamo vederla anche come una visione esogena della della stima no una visione del fuori.un'altra invece una visione endogena cioè che sta dentro la persona qualcosa che si attiva dentro la persona.Allora per quanto riguarda quello che si vede da fuori quindi il contesto aziendale secondo me bisogna capire bene che significato ha la stima cioè la stima non è quello strumento che ti dice questo task lo termini, lo concludi, lo chiudi in tot tempo.Se tu vuoi usare la stima per avere con chiarezza questa informazione, beh stai sbagliando perché la stima lo dice la parola stessa, è una supposizione, ti mancano troppe variabili e queste troppe variabili che ti mancano e sono frutto e possono essere un valore relativo e che varia a seconda di come è gestito la divisione in task e l'organizzazione del progetto poi la andiamo a vedere dopo quindi secondo me la Steam è quello strumento che aiuta un'organizzazione a sviluppare una consapevolezza della propria velocity dove per velocity si intende la consapevolezza di in che ordine di misura di effort si possono risolvere una serie di problemi questo se lo vediamo nell'ottica di un'organizzazione in funzione di questa analisi e questa comprensione il manager il risultato appunto di questa analisi è che il manager ha un ordine di grandezza e non un valore finito ha un ordine di grandezza per poter giocare le proprie carte ma è un ordine di grandezza da gestire con buffer e quant'altro questo poi dipende appunto da come viene gestito il management dall'altra parte c'è lo sviluppatore, l'ingegnere che anche lui non deve sentire la stima come l'elemento per misurare quel ticket specifico perché il ticket come abbiamo detto prima contempla troppe variabili che la mente umana non può in qualche modo riassumere e/o prevedere ma deve vederlo quanto il modo per capire qual è la propria velocity in linea di massima e poi dove intervenire per potenziarla e portarla al regime per cui la stima ti deve dare una mano a capire qual è la tua velocità ideale e non la velocità ideale che è quella che noi vediamo sempre nelle stime che facciamo io sfido chiunque, stimate un ticket e mi dite ok questo ticket sono tre punti poi vedremo un po' come calcolare come molti calcolano le stime ma state ragionando in termini di worst case scenario o di best case scenario potrete dire no worst case worst case siamo sicuri siamo davvero sicuri io ho sempre stimato con un qualcosa che si avvicinava al best case scenario e anche imponendomi a fare una stima al caso peggiore spesso andava a finire con un certo ottimismo e allora a questo punto mi chiedo ma la ricerca della stima precisa è qualcosa che in qualche modo accende un campanello d'allarme e ti dice "Ehi, forse l'organizzazione c'ha qualcosa che non va" la palla di Fieno che adesso sta rotolando, voi non la vedete.Mentre parlavi mi stavano venendo in mente un po' di pensieri che sono andati via insieme alla palla di Fieno, però pensavo alla velocità del team, o la tua insomma, forse nella velocità c'è anche il coefficiente di come tu fai le stime, quindi non importa la velocità di quanti ticket fai a settimana, ma la velocità di quanto lavoro prevedi di poter fare una volta che hai diviso il lavoro in tic e tissue, quello che sono, e poi stimarlo in quello che vuoi, in punti, ore, minuti o quello che vuoi.Un'altra cosa importante secondo me è che il dover fare la stima ti costringe a scomporre il problema, però anche programmare che lo stringe a scomporre il problema.La domanda è se forse non fai il doppio lavoro.Non fai due volte.Posso dirti una cosa Luca? Certo.No, nel senso sì fa il doppio lavoro, vero, però questo doppio lavoro, questa fase preliminare è quello strumento che genera consapevolezza o nel management o nel produtt owner e che comunque fa comprendere che quel pulsante che tu stai chiedendo e che dice che ci vuole a mettere un pulsante ha un livello di complessità che né il P.O.né tu prima di aver fatto un certo livello d'analisi potete prevedere e sta là il vero valore dell'estime cacchio Si può dire l'hot take brutto, che la differenza tra chi fa l'analisi prima e stima e chi si butta a capo fitto perché tanto ce l'ho in testa, perché tanto ci vogliono 5 minuti, perché tanto che ci vuole tutto nel controller e tutto, è quella linea non tanto sottile, non è sottile per niente, tra il programmatore e lo sviluppatore.Tra chi progetta qualcosa e chi invece fa e basta.Hai ragione ma io ci metto anche nei contesti un po' più grandi anche la figura del P.O.Il prodotto oner che spesso non ha quel livello di consapevolezza o il problema è che in realtà.Cacchio chi fa prodotto deve saperle queste cose.Quindi adesso mi arrabbio e lancio la bomba.Il vero valore dello stimare e scrivere delle di storie in grazia di dio e non lo facciamo quasi mai se non quando viviamo in un contesto che ti porta a farlo io per esempio adesso sto lavorando in un progetto dove le storie sono l'elemento centrale e non si può scrivere una riga di codice se non c'è una storia con l'analisi del contesto c'è gli step per i QA ancora prima di scrivere una riga di codice bisogna scrivere gli step per la quality insurance e c'è una cacchio di definition of don.Altra cosa che in realtà va a giocare un elemento fondamentale delle storie e delle nostre estime.Le nostre estime falliscono il 90% dei casi è perché non si è concordata una cavolo di definizione che vada a dire ok questo ticket è concluso in questo dato momento quando c'è questo questo questo questo sfido chiunque a guardare i propri ticket e andare a cercare una definition of dan e vedere quante volte la mettiamo se non si è se non entra nel processo questa è una cosa che nelle mie ultime esperienze sono andato a proprio ad apprendere e l'ho appresa a 17 anni che faccio il software ingine e l'ho appresa un anno a questa parte la fissazione per avere una definition of done.Però se tu vuoi chiudere un ticket vuoi stimare quanto tempo ci metti devi anche sapere quando cacchio finirà o quando vorrà dire che questa cosa è finita no? Scusate mi sono un po riscaldato.Sì e io aggiungerei poi lascio la parola, attenti mi incazza anch'io, non è finito quando avete finito di scrivere codice, perché non è finito per niente, non è finito quando avete finito di scrivere codice, non è finito quando i test passano, non è che se il test passa va nella DOD, il test è una condizione che è necessaria ma non sufficiente, ci sono tanti step da fare, bisogna coordinarsi anche con operations, con i produttori, secondo me è un errore che spesso si fa, abbiamo parlato prima di come è necessario, sono d'accordo, isolare i vari contesti, nel senso che se io sono sviluppatore non devo preoccuparmi del monte di ore che esigo sul progetto, comunque me ne posso preoccupare marginalmente, ma deve essere un'informazione che preme sulle mie onestime.Però spesso è vero anche che non c'è una conoscenza totale del progetto e della direzione aziendale per quel progetto, perché così come è vero che bisogna scomporre le cose, se sono d'accordo e ci sono tool che ti permetto di farlo più o meno bene, questo magari si tornerà dopo, è vero anche che se non hai una conoscenza di tutto il dominio, comunque di quella parte di dominio che ti serve per lavorare bene, non farei mai delle stime affidabili e secondo me non riesci nemmeno a percepire il valore del tuo lavoro.Qui ci si riconduce alla cosa che quelli che sono fortunati a non lavorare in un posto dove sostanzialmente si è l'elemento in una catena di montaggio, ovviamente hanno un approccio diverso alla cosa.Se si lavora in un contesto dove tu hai quella singola task e vivi nel contesto di quella singola di quella singola cosa, questa cosa è effettivamente una catena di montaggio, non potrai secondo me ne fare delle stime affidabili, ne percepire davvero il valore del tuo lavoro, quindi si, isolate e fate lo sviluppo più spezzettare possibile, ma non dovete avere paura di chiedere di più.Io sto implementando questa nuova funzione, sì, ma perché? Qual è la visione a lungo termine? Quella cosa vi permette anche, se così possiamo dire, di misurarvi la palla su quello che è l'intero progetto, su quello che è il vostro apporto all'intero progetto e come quello che state facendo oggi può ritornarvi dietro domani, perché spesso questa è una cosa a cui non si pensa.È importante la singola story e la singola task, ma se non avete una visione d'insieme secondo me è effettivamente complesso fare qualcosa.La visione d'insieme non significa che dovete conoscere vita e morte di tutto, ma sicuramente i vicini delle user story a cui state lavorando, i vostri vicini di Epic.Ecco perché secondo me la stima è un processo collettivo.La stima è qualcosa che è alla fine di un processo e l'output di un percorso più articolato che coinvolge dal mio punto di vista pur non essendo un elemento negoziato coinvolge un po' tutti gli stakeholder con compiti ruoli differenti.ho avuto esperienza di delle sessioni di grooming che penso tutti lo sappiamo ma giusto per ricapitolare quel momento in cui si stimano i vari ticket che hanno visto coinvolti anche i produtt owner o il produtt manager hanno visto coinvolti i lead hanno visto coinvolti parte del management e sono state secondo me le stime vincenti perché quel elemento di cui parlava carmine no del avere una visione a medio lungo e posso anche dirla no quello sviluppare l'ownership collettivo del progetto è un elemento affondante anche perché secondo me il Il vero processo di stima è quel processo che porta anche da una parte al condividere la conoscenza del progetto, dall'altra a capire bene quello che ho detto prima di definition of done.I team spesso sono eterogeni.Nel team possono capitare delle situazioni dove la stima di un ticket possa essere dichiarata come da due giorni a quattro settimane perché una persona dice ci vogliono due giorni un'altra persona dice ci vogliono quattro settimane.Questa informazione in realtà in team non affiatati può creare dei problemi di comunicazione ma se il team è affiattato e se qua molta responsabilità va al lead che è quello che spesso dice no io ci metto quattro ore al posto di quattro giorni grazie al piffero tu sei il lead tu hai questo il contesto complessivo dell'applicazione se c'è un momento in cui si condivide il contesto, il lead non spara i suoi tempi precisi ma prova a capire il tempo del team non il tuo tempo, cioè quanto ci mette il team a fare questa cosa? Io mi sono trovato, credetemi, a fare delle stime dove la mia stima nel tempo dopo un un paio di iterazioni, dopo un paio di sprint coincideva completamente con la stima del lead e con la stima dei tutti gli altri miei colleghi.Perché c'era questo allineamento? Sembrava qualcosa di magico, mi credete? Sembrava davvero qualcosa di magico, cioè se dicevamo per questa cosa ci vogliono due punti di complessità, tre punti di complessità o cinque punti di complessità eravamo quasi tutti allineati perché perché ormai avevamo avevamo la sensazione di quanto ci mettevamo a fare una cosa e grosso modo quello era forse avevi avevate raggiunto una conoscenza del sistema tale che vi permetteva di fare la stima giusta alla fine.Semplicemente quello che facevamo è quando un ticket non aveva una conoscenza condivisa e in quel momento il lead non poteva spiegare o analizzare bene con chiarezza quel punto del codice si faceva uno spike e una presentazione del lavoro dello spike e a quel punto era chiaro cosa si doveva fare perché l'output dello spike cioè della prova era cosa si doveva fare e grosso modo come lo si doveva fare fondamentalmente sì anche con un pezzettino di codice A volte ci sono nodi che vengono fuori soltanto quando ti metti a scrivere la prima linea di codice, almeno mi è successo spesso, dove si fanno problemi, si studiano alla lavagna, la lavagna lucida, siamo tutti d'accordo, ok, 5 minuti sulla tastiera e no, c'è qualcosa che non c'è qualcosa che non funziona.Però poi si vede, si rianalizza e si va avanti.Sì ma alla fine lo spike che cos'è? Se no la presa di consapevolezza che quel determinato problema non si può stimare.Cioè tu stai prendendo consapevolezza che in quel contesto stai troppo incognite e non puoi più stimarlo e allora trovi una soluzione provi a comprendere meglio il problema come dici tu in modo da portare in output le informazioni per poter fare una stima poi il 90% dei casi lo spike risolve il problema ma lo fai col martello e con la chiave inglese e alla fine il vero ticket è quello poi di andare a fare una roba fatta bene.Quindi in realtà sul fatto che non si può stimare secondo me molto dipende dal dal contesto molto dipende dal "non conosci il problema" e molto dipende anche dal fatto che probabilmente quello che stiamo cercando di stimare è un problema troppo grande.a questo punto la mia domanda è come fate a capire intanto che un ticket è troppo grande e va scomposto in problemi più piccoli e poi potete identificare dei pattern per dividere il problema in problemi più piccoli? Vi è mai capitato? Allora noi in genere facciamo proprio questo, proprio come prima analisi, quando abbiamo una feature, qualcosa da sviluppare, cerchiamo di scomporlo nel maggior numero di ticket, di issue possibili, quanto più atomiche possibili perché in questo modo anche chi gestisce poi lo sprint o quello che è, riesce anche a coordinare il parallelismo del lavoro tra i vari sviluppatori.Un altro effetto che si ha di questo è che da un grande problema hai decine di problemi più piccoli, hai più possibilità di sbagliare in più direzioni le stime e per la legge dei grandi numeri queste stime poi alla fine saranno nel complesso, la somma di queste stime saranno nel complesso abbastanza corrette, perché la difficoltà qual è? Le stime sono difficili da fare perché sono imprevedibili, non è che è difficile estimare perché dico un giorno e invece ce ne impiego tre, è difficile estimare perché dico un giorno e e una volta impiego mezz'ora e una volta impiego una settimana, e quello è il difficile.Allora, se io ho una sola issue la canno e non so in quale direzione la canno, ma se io ne ho 100 di issue, 100 forse sono un po' troppe, se io ne ho 20 di issue la questione viene d'aiuto la distribuzione statistica, ti viene d'aiuto il fatto che se una issue la sbagli al ribasso, un'altra issue la sbagli a rialzo e nel complesso la stima del problema iniziale, quello più generale è corretta.secondo me una cosa, almeno nel mio caso, è il ticket chi te lo apre? questo secondo me nella esperienza è fondamentale se il ticket te lo apre il prod...innanzitutto sono me vanno effettivamente divisi i vari tipi di ticket, no? così si sta andando più o meno per scontato che siano task, use, story, epic, technical, insomma delle cose che rientrano più o meno in un contesto agile, insomma.Se invece vogliamo essere un po' più generici, io ti apro un ticket, una card, qualunque cosa, ecco una cosa da fare.Ecco, una cosa che nella mia esperienza è stata illuminante è il fatto che, dove sono ora, i bug non si stimano.C'è un bug nell'applicazione, mettici quanto ci devi mettere.Ok? Perché spesso e spesso volentieri il bug è frutto anche o di una errata analisi o progettazione e spesso e volentieri anche di una stima sbagliata, perché magari hai sbagliato taglia e per farlo splendido, tra virgolette, non sei andato a cambiarlo o non hai diviso quella task bene e quindi è uscito fuori il bug.Questa cosa per dire che bisogna effettivamente distinguere di che tipo di task stiamo parlando.Ovviamente la differenza tra una task in un progetto, in uno sprint di ricerca e sviluppo sarà comunque diverso rispetto a qualcosa che devo consegnare per un cliente o comunque in una situazione in cui sono con l'acqua alla gola.Sono d'accordo con voi quando dite che bisogna spezzettare, che bisogna analizzare e secondo me questa cosa qui è una cosa che va fatta almeno per gli sviluppatori più junior.in realtà non c'entra niente di uno a seno per le persone che sono poco avvezze per questa cosa, è una cosa che va guidata, perché è semplice spezzettare, ma riuscire a trarre il filo delle dipendenze è complesso, è quella lì la cosa complessa, perché magari ti possono anche spezzettare uno dei suoi stori in 50 ticket e sono così bravo e una brava persona che sa prevedere il futuro ma non va a giocarsi il lotto perché non è morale e quindi io ti ho detto che ogni task ci metto 5 ore, ok? Bene.Ho spezzettato così tanto che anche lì ho peccato di hubris e non so più tirarne le fila, ok? E questa secondo me è sintomo anche di un workflow che non funziona.Ad esempio noi prima in azienda dove siamo adesso ci avevamo dato una stima di massima su quanto dovesse essere grande ogni singola task, una stima fatta veramente molto stretta e ci siamo cominciati a far male da soli, perché si spezzettava troppo.Secondo me il livello giusto di granulità te lo dà il tipo di progetto su cui sei.Se sto facendo una cosa per un bando pubblico che ha il capitolato che è scritto nella pietra e non è agile ed è waterfull proprio 101 ovviamente tutto questo discorso assume un sapore diverso, se invece siamo in un contesto dove più o meno ti puoi muovere, allora c'è tutto quanto un altro sapore.Secondo me una cosa importante è riuscire a trovare anche lo strumento giusto per fare queste cose.Come strumento non intendo metodologia, come strumento intendo effettivamente strumento.momento.Io l'ho visto fare sulla lavagna, con la cambamboard, con i santini, nel senso ognuno può farlo come vuole, però secondo me anche il modo in cui lo fai impatta tanto sul risultato finale.Questo lo dico per tutti quanti i "Gira Master" che con Gira mi ci fanno anche il caffè insomma, nel senso lo strumento è importante se non mi alpare anche della metodologia.A caso butto questo flame.Io ti posso dire che spesso ci si concentra quasi troppo sullo strumento e si dimentica come si dividono le storie e questo te lo porto perché stesso strumento, due progetti diversi mia esperienza primo progetto storie divise dalla produtt manager da dio ragazzi da dio dei lead che facevano del lavoro eccezionale tutti ritrovati queste storie dove avevi praticamente quattro valori da stimare.La cosa importante prima abbiamo parlato degli spike.occhio a non cadere nel tranello che gli spike come i bug che diceva carmine difficilmente si stimano anzi gli spike assolutamente non si devono stimare perché se tu stai facendo uno spike è per capire il contesto e quindi perché non puoi stimare se stimi lo spike stai stimando una cosa dopo che hai preso consapevolezza che non si può stimare e quindi secondo me lo spike è solo adatta a inboxare e basta quindi dire ok ci metto ci devo mettere non più di tre ore mi devo dare queste tre ore per capire il più possibile e poi chiudo detto questo lo strumento ripeto stesso strumento gira per quanto io un amore odio e carmine ha solo odio lo vedo dalla sua faccia per questo strumento io ti posso dire stesso strumento diverso product manager diversa gestione del flow perché sappiamo che Gira può gestire dei workflow differenti, io ti posso dire che in un progetto mi sono trovato da dio con Gira, nell'altro no, uno schifo.Ma allora la mia domanda è mi sono trovato male con Gira o erano quelle storie che facevano proprio cagare o quei ticket che facevano proprio cagare? È vero secondo me entrambe le cose, la fine è il team che fa comunque la differenza grande.Secondo me è anche sullo strumento, nel senso che...Allora, secondo me qui ha proprio un outtake grandissimo.Ci sono strumenti che sono per tecnici e ci sono strumenti che non sono solo per tecnici.Io ho provato, e sto anche facendo tutt'ora in alcuni progetti, Sto utilizzando GitLab, ok? GitLab tra tecnici è meraviglioso, ma fai fare project management su questo attrezzo di project management di GitLab, una persona che non sviluppa proprio su quel repository ed è un inferno, ok? Io ho visto repository finti con la Kanban, attrezzi per accorpare organization, repository, il measuring, semplicemente andare subito.Il mio, c'è lo strumento giusto per fare la cosa e anche una cosa di non confondere, ok? Diciamo, ciò che è lo strumento per tecnici da quello che è lo strumento di project management, non è detto che debba essere la stessa cosa.Noi in alcuni setup abbiamo tutta la parte dei sviluppatori su GitHub e c'è la ISHU, c'è la Milestone, c'è la CI e c'è quello che vogliamo insieme al codice e le cose che riguardano strettamente il codice si gestiscono lì il project management più ad alto livello si fa con uno strumento diverso che ha comunque un collegamento con quelle eventuali issue che sono legate a quella cosa lì diciamo nella mia esperienza Gira è stato lo strumento per dominarli tutti e secondo me non è lo strumento per dominarli tutti ma perché? mi spieghi perché scusa io non capisco cioè ad oggi Gira è lo strumento per la gestione del progetto quindi lo strumento che te sviluppatore, te team di ingegneri ti aiuta a capire cosa stai facendo, dove lo stai facendo e soprattutto ti aiuta a capire il tuo contesto all'interno dell'organizzazione del prodotto quindi anche uno strumento di comunicazione.Certo, gira non la CI, non ha...no, già solo i ticket.Esatto.Le EPIC, i vari progetti se ce n'è più di uno e fine e nel ticket c'è la sua struttura bellina bellina dove c'è il pezzettino a cura della QA che ti deve scrivere quando è scritto il ticket male "oh figlio mio ma questo step cos'è dev QA o QA normale" c'è la parte dei criteri d'accettazione dove il prodotto ti dice "oh figlio mio ma quando mi hai messo i miei criteri d'accettazione ti lancio la scarpa" cioè è uno strumento di comunicazione dove la CIA non c'entra niente ma non più sopra.Il problema è che io ho visto Gira essere usato come un misto tra Asana, Excel e GitHub.Il problema, secondo me, è quello lì, è quando ci si abbandona ad un solo strumento.Nel senso, e il fatto che comunque Gira abbia un costo, che abbia che sembra che faccia tutto anche a chi non è tecnico, è quella cosa che ti porta poi a martellarlo, che è una cosa che strumenti più per tecnici, come può essere GitHub o la gestione dei progetti di GitHub, che è penosa in questo momento, sono comunque strumenti dove il dominio di ragiolazione sono più ristretti.Ho visto anche io utilizzato male Gira, non ha avuto questo grande concorrente.Perché è complesso come software.Sì, esatto, e secondo me spesso la complessità e il fatto di voler essere complessi, secondo me ti porta anche un po' fuori stato.Io ho l'idea che è meglio utilizzare 6 strumenti diversi per sei cose piuttosto che tentare di adattare questo unico grande strumento per tutto insomma.Non lo so io per le mie esperienze ti devo dire che secondo me il vero problema non era lo strumento poi è vero che Gira soffre del suo gigantismo nel senso che come tutti gli strumenti che fa tutto alla fine dopo un po' hai un cockpit dove hai 70.000 pulsanti e per mettere in moto quella macchina devi chiamare il consulente e diciamolo esistono i consulenti che ti fanno il primo setup di gira perché nell'azienda dove stavo lavorando gira era stato configurato da un consulente era devo dire configurato da Dio perché perché il consulente si era preso i responsabili dell'organizzazione aveva analizzato il flow e aveva poi creato lo strumento ma se tu in autonomia non hai quel tipo di conoscenze anche di contesto di quella sensibilità nel capire quali sono i processi perché devo devo dire che spesso sia Il problema che abbiamo nel capire la nostra posizione dell'universo Come capiamo la nostra posizione dell'universo se facciamo parte di quell'universo Come ci osserviamo diventa molto complesso e Luca dall'alto del suo telescopio ci può dire "ci osserviamo riflessi" no? Giusto Lu? Si esatto, è poetica questa immagine però si.A questo punto vi faccio anche una domanda che c'entra secondo me poco con le stime però più o meno razzicca.Voi misurate la vostra performance personale? Occhio apro e chiudo prezzi.Se lavorate in un posto dove misurano la vostra performance personale in minuti, ore, è un posto in merda e va bene, su quello siamo comunque d'accordo.Ma se lo fate per voi stessi, quindi non c'è una imposizione, ok? Poi è inutile che poi, io immagino già il commento "eh", ma a Netflix lo fanno, non tutti lavorano a Netflix, la maggior parte lavora nella peepopapera SPA che si integra con il gestionale della Zucchetti.Comunque, a parte questo, se voi avete mai avuto la necessità, avete mai sentito la necessità di misurare le vostre performance personali, che non significa semplicemente che metto toggle e vedo quanto ci metto a fare una cosa, quello l'ho fatto per un po' ma comunque c'è il tempo che trova.Se misurate la vostra performance io lo faccio in termini di come spendo il mio tempo, nel senso il tempo nella documentazione, il tempo nello sviluppo spiccio, il tempo nella risoluzione il tempo dell'analisi.Dove tempo? Non è detto che sia un uguale, ma una percentuale, una metà di misura, che più ci aggrada.Questa cosa qui mi permette anche a me di fare un bilancio totalmente personale e non richiesto di come sto andando e considerando comunque che la nostra vita lavorativa spesso ci porta il lavoro a casa, non è un vero lavoro dalle 9 alle 5, comunque una cosa di più complessa mi dà anche un indice tangibile su come sto di testa.Devo essere sincero? No, non ho mai sentito l'esigenza di misurare le mie performance professionalmente parlando, non dopo la sigaretta, come sempre.Professionalmente parlando.La sigaretta fa parte della performance.Io mi ricordo un grandissimo amico che mi diceva "io in 45 minuti mangio, faccio quello che devo fare".Mi sono fumato due sigarette e ho preso una birra.Anche quello fa parte della performance.Smettiamoci tutto.No, appunto, le stime, lo speed, la velocity, lo faccio solo quando sono costretto a farlo e quindi quando qualcuno me lo chiede, perché sinceramente non avrei, cioè le KPI personali non sono misurabili, non provo soddisfazione nel dire "ah oggi ho risolto dieci problemi, ieri nove, allora sto migliorando", almeno per quanto mi riguarda, almeno se proprio devo fare una valutazione personale, sulla qualità dei problemi che risolgo.Posso risolvere un problema particolarmente difficile o con un colpo di genio o di culo, a seconda dei punti di vista, e lì mi sento più prolifico, produttivo, esatto, e quindi è una cosa che dipende proprio da da progetto a progetto, da task a task, per esempio mi ricordo dovevo fare, ce l'avevo come obiettivo dell'anno, dovevo fare delle analisi di dati, l'obiettivo dell'anno me l'ero ridotto al 9 dicembre tipo e il 10 avevo il colloquio per fare il punto della situazione di tutto.Alla fine, sì, va bene, a noi gli obiettivi sono qualcosa di disastroso.Se tu non vuoi veramente fare una cosa, mettitelo come obiettivo dell'anno e stai sicuro che non lo fai.Comunque, Lì appunto dovevo fare sto grafico, non si sapeva come, bisognava vedere i dati, allora il manager stava già cominciando a pensare, facciamo un form 20 pagine, 40 grafici, torte, linee, barre eccetera eccetera.A me mi è venuto un colpo di culo, Ho pensato a mettere questi dati in un grafico in un certo modo assolutamente fuori standard, ho provato a farlo con Kibana, non si poteva fare, ho provato a farlo con tutto, alla fine l'ho fatto con D3 perché era l'unico tool talmente...era l'unico tool che lasciava la libertà di fare cose completamente pazze.Si narra che esistono i maestri di D3, io D3 lo so installare con npm e basta.D3 è bellissimo comunque uno spotone.Tra l'altro c'è una puntata su D3 all'interno del nostro podcast.È vero, credo anche di averla sentito.Comunque, alla fine ho fatto sto grafico, il mio capo e soprattutto tutti fuori di testa perché era una cosa bellissima con una potenza espressiva allucinante, ho scoperto poi che c'erano altre aziende partner che stavano lavorando su sugli stessi dati e poi il giorno dopo andato li ha fermati e ha detto "state fermi" stavano lavorando da mesi "state fermi, state fermi avevamo trovato la soluzione, tutto appreciato, tutto vivo, che bello.E quello era, cioè, è stato un lavoro di un pomeriggio, però è stata una soddisfazione che non mi avrebbe dato nessun delta di velocity o di nessuna KPI.Come l'avresti stimata? Se l'avresti dovuta stimare? No, no, era impossibile stimare una cosa del genere, perché lì veramente ho aspettato un anno perché mi venisse l'idea giusta.Era una cosa assolutamente inostimabile, se mi avessero detto "fallo entro un mese" probabilmente non… oppure se mi avessero detto "in quanto tempo lo fai" io avrei diviso, detto "ok, facciamo il form, facciamo la paginetta, facciamo questo, facciamo quell'altro" e sarebbe venuto fuori una cosa standard e poco poco utile alla fine.Io devo dire che sempre ritornando alla domanda di Carmine da quando ho avuto la bimba da quando è venuta l'AMDA è una cosa che sto facendo è quella di prendere questa Moleskine e con colori diversi appuntarmi le attività e lo faccio a mano.Luca diciamo è d'accordo con questa cosa ma giusto per avere una soddisfazione fisica nel farlo e e soprattutto utilizzo dei colori diversi nella visione mensile del calendario per identificare il tempo o comunque le attività che impiego a livello lavorativo per un progetto piuttosto che un altro oppure quanto tempo ci metto nel front end e nel back end per questo progetto sto dividendo i due elementi quanto tempo ci metto a cazzeggiare su Twitch, a guardarmi gli streamer di GTA RP che è una voce all'interno della mia visione calendario, ma non per stimare in realtà quindi non per prevedere quanto tempo ci metterò, quanto effort ci metterò in un'attività piuttosto che nell'altra ma quantomeno per esserne consapevole dopo perché se stimare è veramente difficile, vuol dire prevedere il futuro spesso fare una piccola retrospettiva di quello che si è fatto è una cosa che in realtà si può fare i cui valori sono grosso modo abbastanza precisi e soprattutto una cosa che ti fa capire dove è speso l'effort per poi a poter utilizzare delle azioni correttive e aggiustare un po' in corso d'opera le tue attività in un contesto più grande che non necessariamente è un progetto.LM: Sì, quello è quando per troppi giorni ti chiedi che cosa caspita hai fatto.Allora cosa che succede? Allora sì, è utile dire ok oggi che cosa ho fatto o che cosa sto facendo, quanto tempo ho impiegato a fare questo, perché mi sembra di non aver fatto niente.Allora questo caso assolutamente una piccola retrospettiva.Anche io lo faccio per lo stesso motivo e secondo me, nel senso sarebbe anche utile, ovviamente questa cosa va nel secchio delle cose belle ma che è difficile fare, avere anche un momento di team, di retrospettiva, retrospettiva personale, non sul singolo progetto, che non significa fare una performance review, ma significa poter parlare liberamente.Spesso si fa nelle sessioni one on one, magari con il tuo manager o con il tuo direttore superiore, ma secondo me può essere qualcosa di utile anche farla in team.Io alcune volte lo faccio con alcuni colleghi ed è qualcosa secondo me utile sia dal punto di vista lavorativo sia per capire anche dal punto di vista personale dove stiamo andando.Io non ho mai creduto alla cosa che quando comincio a lavorare si lavora e basta.Perché? Perché non è vero.Ci spendi otto ore con i tuoi colleghi.Ci spendi otto ore.Con le persone che vedi di più insomma alla fine.Quindi con cui interagisci di più.Sento più i miei colleghi che mia moglie.Nel senso avere comunque un rapporto del genere che serve anche come bussola personale.Una cosa assolutamente che ha un valore.E spesso, almeno a me è capitato, sia con i colleghi che, nel senso, reputo amici, sia con i colleghi dove magari non c'è un rapporto così stretto, avere in questi momenti un feedback tangibile, senza di guarda, ma che cosa ti sta succedendo? Per me è una cosa che è effettivamente un valore per guardarsi dall'esterno e per capire se c'è effettivamente qualcosa da migliorare fuori dal contesto lavorativo che però incide anche sul contesto lavorativo.I miei momenti più cupi, per quanto mi sforzassi di stare in una black box per quelle otto ore, è una cosa in cui ovviamente non ci sono mai riuscito e avere un momento in cui un mio collega mi dice "guarda, è tutto a posto, sta succedendo qualcosa" mi ha fatto effettivamente rinzavire, perché nella mia testa io ero produttivo come sempre e ho potuto prendere dei provvedimenti.Questo aspetto si riconduce comunque al fatto che se non sei nel contesto giusto per poter fare le cose così come non hai la libertà e la tranquillità di poter stimare, non hai nemmeno la libertà e la tranquillità di poter fare una cosa del genere.Non so che ne pensa.LM: Sul fatto di fare delle retrospettive anche in un'ottica personale secondo me è fondamentale ed è una cosa che in realtà oggi sto facendo e non tornerei più indietro tra l'altro proprio su questo argomento ci tengo a dire che in realtà in un'ottica di team sono fighissime ma secondo me hanno anche un valore in un'ottica personale e individuale se...infatti se buttate un occhio siamo quasi alla puntata 99 ma se andate a vedere la puntata numero 3 e che era praticamente la terza puntata di GeekVar, una delle primissime ho proprio raccontato come ho provato a utilizzare Scrum quindi con retrospettive con mi faceva il grooming delle mie attività da solo in modo completamente individuale è stato un esperimento, di quell'esperimento mi sono portato via una parte di cose che hanno funzionato, un'altra parte di cose dopo un paio d'anni mi sono reso conto che non hanno funzionato e quindi mi sono alleggerito e alla fine sì, concordo con te Carmine, hanno un un valore importante, diciamo che sai, se la stima va nel prevedere una certa attività utilizzando le unità di misura quello che diciamo noi è la presa di consapevolezza di quello che è stato ma voglio fermarmi un attimo, quando noi stimiamo di per sé stiamo solo prevedendo l'effort che ci mettiamo a fare un task o in quella previsione stiamo provando a immaginare anche potenziali problemi che si possono sviluppare nel tendere una serie di comportamenti del team verso un tempo T1? Non so se ho espresso bene la domanda perché è un po' complicata.Quando facciamo la retrospettiva noi cerchiamo di capire qual è stata la nostra produttività e poi analizziamo anche degli altri elementi che sono un po' più personali, sono un po' anche slegati da quella che è la produttività intrinseca.Ma in fase di previsione noi prevediamo solo quell'elemento di produttività intrinseca o possiamo avere una visione un pochino più ampia? Secondo me sì, si può assolutamente avere una visione più ampia.Per me quando faccio una stima di qualcosa, la stima cambia veramente dal giorno alla notte in base a come sto, che cosa ho da fare anche dal punto di vista personale nei giorni dopo, in base anche al mio stato d'animo.Nel senso come ho take così, la stima è tecnica, ma anche una forte componente umana.Se io so che io e il mio team abbiamo comunque altre cose per la testa, comunque siamo in un momento delicato o per l'azienda o personale o quello che sia, la stima è completamente diversa.Se io dovessi fare la stima per la stessa cosa oggi o un un anno fa in lockdown, la stima sarebbe completamente diversa, perché il contesto era completamente diverso e sapevo che la mia produttività e comunque la mia predisposizione verso quella cosa era comunque diversa.Ecco perché secondo me avere anche una retrospettiva personale è un indicatore anche di salute del team, inteso proprio come non voglio entrare in campi che non mi competono, però avere proprio anche un'immagine più o meno clinica di come sta il team, in senso poter avere anche una cosa di questo tipo qui e se magari in azienda sono presenti delle figure che si occupano proprio di stare a fianco dei dipendenti da questo punto di vista, secondo me è anche comodo coinvolgere una retrospective di questo tipo, una figura che sia sostanzialmente clinica, per riuscire anche a capire magari il non detto o comunque riuscire ad interpretare meglio quello che ci stiamo dicendo.Questa cosa qui va comunque nel secchio delle cose che vorrei ma che è complesso fare, ovviamente ogni azienda, ogni contesto è diverso, la scala è diversa, quindi è utopico pensare che un'azienda di 15 dipendenti possa fare una cosa del genere con una figura dedicata solo per questa cosa qui, se non potremmo incontrarti il dominato.LM: Scusami, non metti troppe variabili poi al fuoco, anche per la tua retrospettiva, fai la retrospettiva però già il peso, il valore delle issue, di quello che hai fatto è cambiato in base al tuo stato, poi non riesci più a capire qual è la tua velocità o comunque come stai andando perché ti stai...sono troppe variabili.Sono troppe variabili però secondo me, al senso, io parlo dal mio punto di vista personale, so distinguere la mia taglia L di un anno fa dalla mia taglia L di ora.Come lo so distinguere io, lo so distinguere anche i miei colleghi, Quindi secondo me può comunque essere un indicatore importante del team e di quella singola persona come sta andando.Alla fine, ovviamente non vado a scrivere su Redmine o su GiraGuardia questa settimana, mi è successo questo, questo e quest'altro e ho tanti cazzi per la testa, però comunque personalmente quando vado a stimare una certa cosa è una cosa che considero.E non è una cosa per cui mi sento in colpa, nel senso se io sto lavorando e devo darti una stima quanto più possibile realistica, non mi sento in colpa a darti magari una stima diversa rispetto alla stessa cosa in un altro periodo per il semplice fatto di doverlo fare.Sto prendendo in giro me e sto prendendo in giro te.Io la vedo così insomma.Ok, se hai ragione è perché tu parli comunque di stime temporali.Sì sì sì.Esatto, esatto.L'elemento che secondo me va evidenziato è, scusami Luca, entro così a gamba tesa violentamente, l'elemento che va evidenziato è, di cui non abbiamo parlato oggi ma secondo me è importante citare è il fattore di decadimento di una stima cioè le stime in realtà hanno una data di scadenza e questa data di scadenza non è molto lontana nell'asse del tempo perché perché il contesto cambia è mutevole e non possiamo frizzarlo in un certo punto per cui tutto tutto quello che ha detto Carmine è vero a patto che la stima non sia troppo in là nel tempo perché poi più si allontana dal momento in cui è stata stimata e meno diventa affidabile.Questo secondo me è importante da ricordare.Chiaro ma dicevo anche io non avevo in testa la stima di tempo per una issue ma in generale io le stimo proprio a massa.Cioè questa issue pesa 5 kg usando la serie di fibonacci.Ecco massa e taglie.Avete due modi diversi o due parole diverse per identificare.Come stimate? Stimo in due modi, la complessità e la taglia temporale.Proprio perché c'è questo dualismo.Se io sono nel mood giusto, ho la produttività giusta, una cosa che ha taglia di complessità XL, ci posso anche mettere meno.Allo stesso modo, se qualcosa ha una complessità bassa, ma il contesto in cui quella cosa va fatta è un contesto diverso, può diventare la cosa più lunga del mondo.Non parlo solo di contesto personale, comunque non siamo oggetti nel vuoto, quindi la situazione aziendale può essere diversa, la situazione del team può essere diversa, la situazione personale può essere diversa, la situazione del mondo come abbiamo potuto vedere può essere comunque diversa.Io faccio queste due stime così e vanno a competere su due indicatori diversi e poi c'è chi è sopra di me che le mette insomma, nel senso che si occupa di prendere questi due e che gli pia, insomma, alla fine.LM: Noi invece abbiamo un solo indicatore, che è appunto la massa, che comprende tutto, penso alla fine credo sia il numero che quello che sta sopra, quello che diceva Carmine, quello che fa, che comprende un po' il peso, non l'importanza dell'eissu, ma proprio il peso.Tendenzialmente si cerca di dare appunto, rispettando la serie di Fibonacci, e si cerca di non andare oltre il 34, il 34 deve essere il peso.Quanto? 34.34 il peso massimo che sarebbe se proprio si da una valutazione temporale è il giorno, però anche lì non è proprio un giorno perché dipende anche da chi la prende la issue, perché c'è chi è part time, c'è chi è all'80%, c'è chi è più nuovo, c'è chi lavora da un anno e quindi sicuramente impiegherà più tempo nel risolvere questo problema e quindi cambia però il peso intrinseco della issue è quello, cambia il contesto, il contesto lo si vede durante il planning, cioè ok abbiamo 200 chili, 300 chili da fare, però questa settimana tizio in ferie, io ho altri colloqui da fare, alla fine ce ne sta soltanto soltanto uno che lavora e ovviamente ci si regola lì, diciamo "ok 200 kg sono troppi, facciamone di meno e cerchiamo di fare le cose più importanti".Noi finora stiamo facendo così, riusciamo appunto a dividere le issue facendo in modo che ognuno non abbia un peso più di 34, se ha più di 34 vuol dire che o può essere spezzatata, questo probabilmente perché la nostra struttura e i nostri progetti sono fatti in modo che puoi spezzare le iscio in più parti, ci vuole tanta conoscenza del sistema, infatti non sempre funziona, a seconda delle parti di sistema su cui lavoriamo la stima va bene, se lavoriamo in altre parti dove abbiamo meno coscienza, meno esperienza, cambiamo molto più facilmente, però si impara anche lì, non ci vuole tanto, ci fissiamo delle regole, euristiche e vediamo come fa, però cerchiamo di avere meno variabili in gioco, anche se le variabili, come detto giustamente da Carmine, ci sono, però cerchiamo comunque di tirare una sintesi, perché tanto una sintesi alla fine è quella, bisogna tirare la sintesi temporale, perché gira di gira hai bisogno di timeboxare le cose da fare.il tempo è del'aro alla fine, è vero io ho un modo un po' diverso in realtà di stimare le storie ho fondamentalmente al massimo ma proprio esagerando 5 valori lo sto tirando per le orecchie uno che è il valore più basso che può essere utilizzato per il one liner o per i task particolarmente semplici robe di CSS o dei piccoli bug fixing.Due che è intermedio e tre che è generalmente impegnativo poi c'è il 5 che vuol dire oh guarda che questo è grosso vedi di affettarlo un po'.8) che invece Pirla è talmente grosso che probabilmente il contesto non è condiviso quindi oltre che affettarlo fate un bel meeting dove share la conoscenza.Questi sono i valori che utilizzo.Il tempo lo canno fisso nelle prime interazioni ma lo canno di brutto, di bruttissimo e lo canno nelle prime interazioni di team quindi quando il team è nuovo e lo canno quando il progetto è nuovo.Ma è normale che sia così.Quindi stesso team con il nuovo progetto oppure vecchio progetto con il nuovo team.Questo perché fondamentalmente mancano tante variabili quindi di fare un paio di sprint perché io uso scram un paio di sprint per capire bene a regime e poi diventa una cosa istintiva no.vedi un ticket e sei già, sei uno, due, tre.Fine.Sei cinque vuol dire che bisogna partire con una discussione.E questa cosa è veramente figa.Se poi dei cinque agli otto si capisce che veramente manca il contesto allora a quel punto si fa spike driven development.Cioè si dice belli miei ok il problema del problema conosciamo una cippa.ok, uno si prende l'incarico, bene, quanto vale la soluzione di questo problema all'interno del contesto, all'interno del prodotto? e caspita è importante! beh, allora abbandoniamo la serie di fibonacci e abbiamo una scala da 1 a 10, che sono le ore, e timeboxiamo lo spike lo spike non va stimato per quello che dicevo prima no perché è un qualcosa che non puoi stimare però puoi timeboxare cioè dire io ci metto dell'effort per 5 ore per capire di più e l'output è un documento che può essere 10 righe 12 pagine o un po sì a quel punto una volta che hai questi documenti Sicuramente Hai le idee più chiare sia tu che il team perché i documenti sono condivisi Magari c'è anche una piccola presentazione di cinque minuti davanti a una birra a quel punto si può provare a ristimare Se c'è ancora il problema vuol dire che si sta totalmente pirla che o Il ticket lo devi accantonare perché l'effort nel fare un ulteriore spike per approfondire ancora di più l'argomento non genera valore nel prodotto finale oppure se questa cosa genera valore fai un altro piccolo spike lo lottare a seconda delle lacune che hai e hai bello che stimato e analizzate il problema il 90 per cento dei casi quando vai alla seconda al secondo spike sullo stesso problema c'è già la soluzione devi solo aggiustare un po I test e sistemarlo ma solitamente nella mia esperienza al secondo spike sulla stessa roba è più o meno la soluzione definitiva quindi alla fine ti rimane un ticket da due punti uno due punti e hai chiuso il Problema questo è un po come Io Lavoro e come adoro lavorare perché mi piace tantissimo però ripeto questa cosa la puoi fare se hai un team rodato quindi se hai cannato a palla le prime iterazioni o se hai un progetto che non è un greenfield e quindi hai un po' di informazioni da qui a tingere.Bello la scala diversa che utilizziamo, adesso capisco anche la faccia che ho fatto e che voi nel podcast non potete vedere.32! 32 per me non dico un anno di lavoro ma… No no 34 mi sembra che… 34… Beh alla fine è un giorno perché comunque tra il tuo 1 e 2 io metto tante zone grigie.Eh ma lo sai Lu qual è il vero problema? È che tutte queste sfumature poi alla fine confondono dal mio punto di vista.Magari mi sbaglio però tra una cosa facile e una cosa mediamente facile ci sono una serie di sfumature che vuol dire che devi prendere in considerazione troppe variabili.Dipende.E quindi secondo me o stimi col tempo oppure ti fotte.Questa va beh è la mia opinione.Credo anche dipende da quante atomiche fai le issu in tasca.Per quanto riguarda le atomiche le vuoi fare o ti puoi permettere di farle.Ovviamente non in tutti i progetti non in tutti i contesti.Ma ne avete parlato tanto del ti puoi permettere di farle ma io boh.Ma siamo davvero sicuri che è così difficile rendere atomiche certe task? Secondo me se fai ricerca e sviluppo no.Se fai ricerca e sviluppo è complesso.Noi facciamo tanta ricerca e sviluppo, quindi sai quello che vuoi, ma come arrivarci ovviamente spesso e volentieri non lo sai.Ecco perché fai insomma R&D.quindi secondo me dipende anche tanto dal contesto insomma.Ma fai spike a quel punto? Ti chiarisce di idee? Ci fanno troppi spike, specialmente adesso nella mia esperienza anche recente, è dover fare un blocco informativo per il canale che abbiamo.Lì avevamo troppe variabili in ballo e lo spike comunque non è servito, perché anche con lo spike anche ti hai in boxato, lì dovevi avere, ok, un po' di contesto, c'erano tre API esterne da chiamare, esterne vuol dire che non era roba nostra, dovevamo valutare la qualità dei dati e se c'era bisogno di un intervento manuale, dovevamo vedere come nel tempo si adattavano questi dati perché d'inverno abbiamo dei dati, d'estate abbiamo altri.Però vedi che mi stai dando dei ticket tutti separati? Cioè sono tutti dei ticket atomici.Il problema è che alla fine poi non hai nessunissime idee del risultato e può essere di tutto, cioè puoi anche buttare tutto quello che hai fatto e dover cercare altre strade.LM: Ma secondo voi non dipende anche dal tipo di persona con cui lavori, non dal team inteso come professionalità, io ho avuto la fortuna, specialmente ora, di lavorare con tutte persone brave, ma proprio dal carattere della persona e io lo vedo su me stesso, sono una persona abbastanza ansiosa e paranoica.Quando mi accoppio con un mio collega o una mia collega che ha quella mia stessa attitudine, le stime vengono a merda.Cioè, secondo me la bravura del lead sta anche nel bilanciare chi fa la stima e che peso dare a ogni cosa.Aspetta Carmine, quindi le tue stime non sono comunque un'operazione collettiva? Sono legate, c'è un massimo 2-3 a fare la stima.No no no no no no, ecco, forse la differenza viene da là.Noi facciamo una riunione, quindi facciamo il grooming, dove tutto il team, tutto quanto, si prende il backlog col product manager e dice "ok, io in priorità ho questi 20 ticket, andiamoli uno per uno.Capiamo cosa vogliono dire in linea di massima.Se si hanno domande è bellissimo questa questa riunione perché una delle secondo me una davvero delle poche riunioni veramente produttive.Ecco perché prima ho battuto così forte sul fatto della condivisione della conoscenza.Noi si fa questa riunione questo questo grooming moment.Si scela la conoscenza.Si capisce un po di che cosa vuol dire.Questo aiuta poi anche a chi ti farà la review perché sa già cosa fa quel ticket che stai facendo quella PR collegata e a quel punto ci sono sei persone che stimano.Questa cosa qui noi la facciamo post nel senso se c'è da stimare con le storie due tre persone che sono magari quelli che hanno più conoscenza tecnica della cosa fanno una prima stima dovrei che nella progett review collettiva, si ne parla con tutti e si raccolgono feedback.Almeno questo è il nostro modo di fare.Ecco perché dicevo che, almeno dal mio punto di vista, dipende anche tanto con chi la fa.In 10-11 persone, una cosa che viene mitigata poi quando si fa la progetta più generale, di "guarda, ma come? Ma io quella cosa lì si fa così, l'ho già fatta, la faccio io".Quindi magari si fa una roba del genere, oppure "guarda, secondo me dovresti valutare questo, quell'altro eccetera.Il fatto comunque di fare una prima fase in pochi è qualcosa che effettivamente dipende con chi capri e dalla personalità della persona con cui capi.Ecco perché ci tengo a mettere il punto che la stima è tecnica fino ad un certo punto, perché la stima non è fatta nel vuoto, insomma, nel bene o nel male della la cosa.Poi nel senso ci sono le persone, secondo me qui si va proprio sul flume flame, che dicono "da noi non si stima".Io non so come faccio, nel senso si possono fare le rapine ai portavalori ma senza stima.Non lo so, sono anche in quel caso.hai aperto un capitolo nel senso che spesso si parla del movimento "Noi sti miei" tra l'altro parlavamo con con Alessio preso benissimo e quindi qua lo dico Alessio ci devi dare questo vocale da inserire nella nostra puntata perché vogliamo sapere bene la tua posizione.In realtà c'è questo movimento tra i diciamo i sostenitori più in vista abbiamo Vasco Duarte che è una figura importante del panorama e fondamentalmente l'obiettivo è quello di cercare delle vie alternative alla stima di tempo fatica e costo perché fondamentalmente le stime vengono utilizzate per prendere delle decisioni no e quindi il movimento no estimate dice sì vabbè ok noi stiamo usando fondamentalmente delle scommesse delle stiamo prevedendo il futuro siamo dei maghi stiamo prevedendo il futuro.Adesso sto ironizzando ma fondamentalmente questo è il messaggio che passa no stiamo prevedendo il futuro e su questa previsione del futuro da una palla trasparente stiamo prendendo delle decisioni aziendali anche di un certo di una certa importanza.quindi esiste un altro modo per un'alternativa per poter prendere queste decisioni senza basarsi sulle stime? e la mia domanda è io non ho sentito magari sono io non abbastanza documentato ma delle proposte concrete tra le varie cose che emergono...Lo può fare il monopolista secondo me.Il monopolista non ha bisogno delle stime.Se non hai concorrenza, se non hai pressioni anche di mercato, probabilmente puoi permetterti di prendere delle decisioni aziendali così, credo.non lo so, io non saprei come farlo onestamente.In video un po' che dice "noi non le facciamo" anche se poi se va a vedere un po' sotto sotto c'è una metrica perché nel senso non puoi non avere metriche però effettivamente non so come si fa a stare senza un KPI che sia anche, non lo so, quante cose ho fatto, non lo so, non so come si fa.Infatti alcuni sostengono appunto che per esempio contare le storie è abbastanza è sufficiente per prendere delle decisioni di business.Naturalmente se tu conti le storie una a 32 l'altra a 0 o 34 l'altra a 0 il valore è talmente, la differenza è talmente alta che questa differenza la devi annegare come diceva Luca in una distribuzione statistica.questo vuol dire che le tue estime hanno senso in range di tempo enormi.Poi è vero che se io ti dico un'altra cosa che dice il movimento non estimi.Dimmi qual è il decimo elemento che c'è nel backlog.Non è importante quindi perché stimarlo.Questo è esattamente quello che il momento è e fondamentalmente su questa cosa posso concordare.Però allo stesso tempo devi in qualche modo.Provare a immaginare dove posizionarti anche perché in qualche modo devi prendere una direzione e se tra brancolare nel buio o provare a immaginare una direzione devo scegliere tra queste due cose io provo a immaginare una direzione.Però ripeto la nostra community ha tutti gli strumenti per argomentare su questa cosa.Luca tu sei un nuovo estimate? No, no però io forse posso portare qualche tesi.Cioè secondo me oltre al tipo di azienda che si può permettere il nuovo estimate, come ha detto giustamente Carmine, se c'è un monopolio non ha concorrenza, detta lui i tempi, detta lei i tempi, i modi e chi se ne frega, però magari ci sono anche altre condizioni in cui il No Estimate può avere senso e può anche essere un'arma vincente.Io posso immaginare, ma me lo posso immaginare anche guardando e vedendo chi è il sostenitore di questo movimento o i sostenitori di questo movimento, se tu sei in un team pieno di, come dire alla Netflix, superstar, quindi persone che sanno il fatto loro dalla A alla Z, conoscono perfettamente l'azienda, hanno perfettamente chiaro qual è il contesto dove si muove il team, dove si muove l'azienda, dove si muove tutto il sistema che tocca l'azienda sopra e sotto, questa coesione collettiva allora forse sì, ok, non è importante stimare disappiatamente quando andare per il verso giusto e facciamo le cose che ha senso fare quando ha senso farle.Sì, questo è possibile quando hai tutte queste condizioni al contorno, quindi un team assolutamente perfetto.LM: Certo, poi questa cosa qui se lo metti fa anche ad incrociare con la cultura dell'eterna una emergenza e la cultura del peso scambiato per priorità, che non è una cosa che è mai capitata.Il fatto che una cosa sia stimata in un certo modo non la rende assolutamente prioritaria, e se si vive sempre nell'emergenza, sempre nella pressione di dover fare le cose tutto è subito, ovviamente poi alla fine non viene via nulla, insomma che è una condizione che ho visto tanti amici, tanti colleghi vivere in questa situazione dove erano de facto non estimates che non si poteva stimarsi, doveva fare e basta.E quindi poi vengono gli acrochi, poi viene il burnout, poi viene il licenziamento di massa e poi viene il sito dell'Ips.È importante se andiamo a riuscire a capire veramente il contesto in cui operano queste persone che alla fine è una "fortuna" quella di poter lavorare senza stime e di di potersi prendere non tutto il tempo che ci vuole, ma tutto il tempo che si vuole alla fine per fare le cose in una certa maniera.Infatti, secondo me, una cosa che va a braccetto con lo stimare le cose e con il planning è il concetto di MVP.Se io mi trovo in una situazione emergenziale con una scadenza non prevista per qualunque motivo, poi si può a raccomentare del fatto che non esistono delle scadenze che non sono previste, va bene, si può ragionare di qualunque cosa, ma il fatto comunque di riuscire a far pace con l'idea di un MVP e avere la possibilità di poter proporre una soluzione del genere a me fa tanto, alla fine non tutto si può avere subito.bellissimo prima stavi appunto dicendo di capire quello che era urgente da quello che era importante o non era importante mi è riportato alla mente una cosa che vi suggerisco di andarla a guardare perché io adesso la racconterò malissimo ma secondo me è una cosa importante da capire e che a me sinceramente ha cambiato la vita ma è una cosa che si chiama matrice di Eisenhower non so se l'avete mai vista, è un grafico fatto da quattro quadrati dove sopra hai tutti i task urgenti e non importanti, sulla destra hai urgenti e importanti, sotto hai non urgenti e non importanti e poi c'hai non urgenti e importanti.La combinazione tra il concetto di urgenza e il concetto di importanza alla fine ti indirizza sulla decisione che devi fare noi spesso come diceva carmine mischiamo i due concetti no di urgenza e d'importanza in realtà per esempio se un ticket è urgente ma non importante perché dobbiamo farlo noi possiamo delegarlo lo diamo in outsourcing o lo passiamo al junior e va bene e risolviamo se abbiamo un ticket urgente e importante beh la non scappiamo lo dobbiamo fare se abbiamo invece una roba non urgente non importante indovinate un po' cosa dobbiamo fare batterci nelle palle e qua non ci metto neanche un bip sono quei tipici task che magari ci arrivano dal marketing solo perché forse posso prendere il cliente x e spesso arrivano se c'è un product manager che in qualche modo non li identifiche non ce li cestina prima di noi e poi c'è appunto non urgente ed importante beh a quel punto possiamo attivare un percorso di pianificazione ve lo ricordo è la matrice di Eisenhower trovate una una un'interessante descrizione anche su wikipedia quindi andatevelo a guardare perché secondo me è una di quelle cose che ci deve servire per capire i nostri backlog detto questo stavo guardando l'orologio siamo a un'ora e 53 minuti siamo stati abbastanza sintetici oggi devo dire voi siete ancora vivi ragazzi? poco scusa stanchi allora devo dire che siccome non c'è per ora nessun donatore qualora ci fosse lo aggiungiamo infine all'episodio è arrivato il momento del paese dei balocchi con il paese dei balocchi aaaah il paese dei balocchi *musica* aaaah il paese dei balocchi a questo punto chiedo eeeeeeeh qualcuno di voi ha un balocco per i nostri ascoltatori? *ruggiti* *ruggiti* io lo ho al neve scusate avevo tolto la webcam invece che microfono.L'ho già consigliato ma con l'occasione lo riconsiglio perché ha tanti strumenti utili per stimare a volte e stimare anche cross team.Il libro si chiama Game Storming di Dave Gray, Sunny Brown, James Montalvo.Sì, è utilissimo per fare i meeting, le riunioni, che sono tanto noiose quanto inutili, però quantomeno ci sono dentro alcuni giochi da fare con post-it, con disegni, quello che garba, per andare veloci, andare subito al punto, risolvere i problemi e in alcuni casi anche dare delle stime appropriate.LM: bello.Alleghiamo come sempre il link alle note dell'episodio.In realtà il mio balocco non è un balocco attinente al tema, anche perché io voglio essere onesto, ho letto Clean Agile, ho letto Agile Coaching for Teams, ne ho letti diversi, anche un libro sulle user stories di Ken Beck, non mi ricordo come si chiama, ne ho letti diversi, non me ne è mai piaciuto davvero nessuno, quindi non ve ne consiglio nessuno.Vi consiglio due cose che ho già consigliato, ormai sono ambassadore di tutto ciò che è una brutta UI, Quindi vi riconsiglio Redmine, se proprio avete bisogno di un software per poter gestire le cose che fate e che non fate.Ci si trova bene ed è veramente flessibile, una curva di apprendimento spaventosa, però poi diventa effettivamente un ottimo strumento.e come libro in realtà che sto leggendo, è un libro di Russell, ed è "Introduction to Mathematical Philosophy".Ovviamente non badate la mia bruttissima pronuncia.Non so se esiste in realtà una versione in italiano, io non l'ho trovata, lo potete trovare su Amazon, e secondo me è un bel libro da leggere e non voglio spoilervi, ma è secondo me qualcosa che va letto e può essere apprezzato da persone tecne come noi.E come ultimo consiglio vi dico, non fate le stime che siano solo tecne, questo è il mio più grosso balocco.Dalle mie parti si dice che "A cape na sfoglie de cipolla" e questa cosa va sempre considerata quando facciamo vestiti.LM: Bellissimo.Una cosa, scusami Mauro, aggiungo che questo Gamestorming, oltre a essere un libro, è anche un sito dove si possono trovare già alcune cose, ci sono blog, articoli, giochi, eccetera.Il sito è anche gamestorming.com.Così aggiungo un balocco in più.L'uovo.Ottimo.Mauro sei muto? Sì scusate ma qua nel frattempo sono successe cose, è passata gente.Il mio balocco.Allora io ne ho due.il primo è un articolo su InfoQ che spiega l'utilizzo del modello Monte Carlo per le stime Agile è un articolo anche abbastanza semplice rispetto del nome dove fondamentalmente però ci aiuta a capire in realtà la qualità e la tipologia delle nostre stime attraverso un modello statistico infatti ci indica se le nostre estime sono molto conservative quindi direi anche paracule e conservative realistiche, ottimistiche o molto ottimistiche e lo fa appunto con una distribuzione statistica calcolata sullo sprint e su un concetto che si chiama program increment che è fondamentalmente un'iterazione generale di prodotto che contiene più sprint, è un modello di proiezione per farci capire come stiamo stimando i nostri ticket, forse un po' overkill, me ne rendo conto ma a me ha inquiusito tantissimo altra cosa importante e carina come gingillo è un giocattolino nuovo che ho preso per il nostro podcast, è la stream deck con la quale adesso finalmente possiamo far partire i nostri jingle adesso è sparito tutto non si sente niente fantastico va benissimo io ho lanciato gli avessi sentito qualcosa ok come non detto è un gingillo bellissimo con il che conto di configurare per riuscire a fare delle puntate con più effetti sonori, insomma un cazzillo che non serve fondamentalmente a niente ma è molto carino da avere sulla scrivania, è uno stream deck, una pulsantiera ti permette di configurare una serie di azioni collegate ai vari tasti, tasti programmabili, è programmabile anche lei utilizzando javascript, c# o altre robe è una roba carina insomma che mi piaceva condividere con voi detto questo è superate le due ore di puntata è arrivato il momento di salutarci si può fare un bel saluto a ASMR? perché purtroppo non c'è Mattia, però Mattia lo sa fa' veramente bene ebbene si Mattia è il master dell'ASMR ormai vista l'ora potrebbe anche starci ecco ma facciamo un saluto normale gli ASMR faremo un canale twitch/git ASMR dove Mattia e Carmine si daranno i turni nelle varie puntate vi leggiamo la documentazione di Magento però ora devo drooparmi ce l'hai con Magento e drooparti guarda veramente è proprio...che rimpiango Prestashop ritatemi Prestashop però secondo me avrà successo, lo si deve fare occhio che la prossima consulenza o il prossimo progetto che dovrei prendere in mano sarà cosa? Com'è che si chiama? Nuke PHP Madonna, bello bello mi ha fatto super piacere provare ad analizzare questo argomento poi ognuno di noi sull'estima realtà c'ha la propria visione, le proprie esperienze, spesso sono molto diverse tra di loro anche perché fondamentalmente ognuno di noi lavora in un contesto differente per cui cioè fondamentalmente sono appunto riflessi del contesto dove si lavora.Detto questo io vorrei ricordare i contatti ma sono ormai completamente bullito visto che è quasi mezzanotte e quindi info@gitbar.it @branrepo su twitter gruppo telegramma ma in asmr? ah si in asmr biscottini ci vediamo sul gruppo telegramma siamo tutti per voi siamo la più grande community di bhp53 in italia benvenuti gruppo telegram cercate gitba gruppo telegram cercate gitba ciao a tutti i biscottini mi raccomando rimanete così non si rompono il microfono è bello ciao ragazzi ciao ciao alla prossima GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Death.[Musica] *urla*
