Terza puntata di Geek Bar.In questa puntata voglio un po' stravolgere quello che è il format.In realtà un format non esiste di questa trasmissione.Voglio provare a raccontarvi un'esperienza.Questa esperienza riguarda un prodotto che sto lanciando questi giorni che si chiama Political Magnet.È una piattaforma di media listening che serve ai politici locali e non per capire cosa succede in un dato territorio, in una data tematica oppure cosa un competitor politico dice piuttosto che un altro.Una nuova piattaforma, la stiamo lanciando questi giorni ma è nata come side project.Sono un appassionato di politica per cui nel mio tempo libero mi è venuta l'idea di realizzare questo progetto, però questo progetto ha una genesi un po' particolare.Solitamente quando mi viene in mente un side project lo condivido con mio fratello e così ho fatto anche con questo.Eravamo a tavola a casa dei miei genitori ormai sono veramente pochi i tempi che riesco a dedicare a questa cosa perché vivendo a Lione ho poco tempo per poter stare in Sardegna però diciamo in quell'occasione ho fatto una chiacchierata con mio fratello e ho provato a raccontargli questo progetto.Mio fratello però non mi ha lasciato spiegare tutto ma mi ha interrotto praticamente subito dicendomi "guarda Mauro il progetto mi sembra interessante però in qualche modo sarà l'ennesimo progetto che butterai in un cassetto e inizierai con tanto entusiasmo ma non terminerai".Questa cosa in qualche modo mi ha colpito anche perché sono una persona abbastanza orgogliosa diciamo il mio carattere un po' particolare però in qualche modo sentirsi dire anche se non esplicitamente sentirsi dare dell'inconcludente non è la cosa la cosa più bella del mondo.Per cui ho deciso di impegnarmi e provare a capire quali erano gli elementi ostativi, i limiti, che non mi permettevano di concludere un progetto.Per capirlo in qualche modo mi son guardato indietro e ho provato a vedere quali erano gli elementi che mi limitavano.In realtà in questo processo di ragionamento mi son chiesto "Ma perché se in azienda riesco a concludere, riusciamo a concludere i prodotti, a metterli sul mercato e quindi a finalizzare, perché nello sviluppo dei miei side project questo non avviene? Quali sono gli elementi che diciamo mi bloccano?" In realtà una cosa mi è stata da subito chiara.La cosa che ho capito da subito che non si trattava di qualità di codice o di strumenti da usare, ma di metodo.Infatti tu puoi avere una chiave inglese da 3 o da 50 euro.Se tu non sai come usarla fondamentalmente tu non lo stringerai mai quel maledetto bullone.Per cui ho provato a capire come andava usata quella chiave inglese guardando a come usavo la chiave inglese in azienda.In azienda adottiamo da qualche tempo la metodologia Scrum, in realtà il framework Scrum, cioè una serie di buone pratiche che in qualche modo aiutano a essere più produttivi e a migliorarsi, soprattutto aiutano a rilasciare prodotti decenti in tempi umani.La cosa che però mi ha bloccato è stato che lo Scrum in realtà è pensato per un'azione in team.Nei miei site project io io solitamente sono da solo per cui diciamo che portare lo Scrum da un lavoro in team a un lavoro individuale non è semplice per farlo ho provato a tornare indietro alla base e provare a capire bene quelli che sono analizzare bene quelli che sono i principi di Scrum.I principi fondamentalmente sono semplici e sono tre.Il primo è l'azione naturalmente, va beh, e quindi la quantificazione della produttività, cioè la necessità di capire, di misurare quello che si sta facendo.Misurare quello che si sta facendo è il tempo, il tempo è una parola impropria, poi lo vedremo, che si sta impiegando, le risorse anzi forse sarebbe meglio dire che si stanno impiegando per raggiungere un certo obiettivo.Nella quantificazione dobbiamo darci dei tempi, delle piccole deadline.Queste deadline devono essere necessariamente piccole.Perché? Perché in realtà le misurazioni devono essere continue e costanti.Questo ci permette, qualora prendessimo una strada che non ci avvicina all'obiettivo o dilattassimo troppo i tempi, di raddrizzare il tiro, correggere dove stiamo sbagliando e quindi raggiungere l'obiettivo.In realtà questo correggere ciò che si sta sbagliando fa parte del secondo punto, del secondo principio di Scrum, quello dell'auto apprendimento e della riflessione iterativa, cioè dividere lo sviluppo in piccoli cicli, cicli nella quale quantifichiamo la produttività e al termine del ciclo ci guardiamo indietro e diciamo cosa ho capito, cosa ho fatto bene, cosa non ho fatto male, quali sono i problemi che mi hanno bloccato? A quel punto si entra in un meccanismo e quindi qua il terzo principio dello Scrum di "Ship and Share" quindi rilascia e condividi.Il rilascio continuo ci aiuta a fare una cosa molto importante.Quando stiamo sviluppando un progetto, nel mio caso un side project, spesso ci perdiamo in funzionalità superflue.Il rilascio continuo ci aiuta ad avere un feedback costante di quelle che sono le funzionalità che stiamo sviluppando.per cui se noi ci prendiamo un lasso di tempo, nel mio caso due settimane, per fare una serie di funzionalità e le rilasciamo noi sappiamo subito dal feedback che riceviamo dai nostri beta tester o nel caso siamo in produzione dai nostri clienti su quale feature dobbiamo fare all in, quindi investire le nostre energie senza magari perdere tempo, mesi, in funzionalità che magari non servono a nessuno e non generano in qualche modo valore.Quindi come ho adottato alla fine lo Scrum? Perché poi alla fine bisogna comunque scendere nel pratico.I principi li condividevano, a parte la parte dei team che ho dovuto necessariamente purgare perché sono da solo nei miei set project, i principi li condivideva appieno.Per cui adesso il lavoro da fare era quello di portare le metodologie, le azioni, le buone pratiche proprio nel day by day, quindi nel lavoro giorno per giorno.E ho iniziato in realtà pensando al concetto di sprint.Quindi, che cos'è lo sprint? In realtà lo sprint è un lasso di tempo.Immaginate uno scatto di una partita di calcio, bene, è quel lasso di tempo che parte, che racchiude un'azione che ha un obiettivo ben preciso, l'obiettivo è andare in porta e finisce con la realizzazione dell'obiettivo.Fondamentalmente si tratta di un ciclo di sviluppo di circa due settimane, nel mio caso sono due settimane proprio, e in questo ciclo di sviluppo io mi do un obiettivo, devo sviluppare questa funzionalità, questa funzionalità e quest'altra funzionalità, essendo limitato In realtà solo alcune funzionalità entrano nello sprint backlog, quindi nella lista delle funzionalità da sviluppare perché essendo il tempo limitato solo quelle posso materialmente fare.Quindi dicevo uno sprint è uno sprint backlog il cui obiettivo esplicitato di una durata limitata ma nel quotidiano, giorno dopo giorno, cosa faccio? agirò da sviluppatore.Quindi mi metterò la mia magliettina dell'amiga e batterò sui tasti come se non ci fosse un domani.Ma prima di buttarsi a capofitto nello scrivere codice è necessario avere un piano preciso.Questo piano si chiama sprint plan e viene fatto prima dello sprint.Serve per avere un'idea in realtà di cosa fare nello sprint.Durante la fase di sviluppo in realtà non abbiamo energie e tempo per poter pensare a cosa fare nell'istante successivo ma dobbiamo avere diciamo una cartina che in qualche modo ci indichi cosa fare subito dopo senza perdere troppe energie a pensare sì prima questo o prima quello e questo è appunto il compito dello sprint plan quindi si prende in mano una cosa che si chiama product backlog che non è altro che la lista delle funzionalità della nostra applicazione ordinate in qualche modo per priorità e si inizia a dividere appunto queste funzionalità in task, in azioni, in compiti.Questi compiti hanno in qualche modo un valore, una difficoltà.Questa difficoltà non viene calcolata in termini di giorni uomo, ore uomo, no, perché comunque non riusciremo mai a a stimare a priori quello che è il tempo che possiamo impiegare per un task anche perché fondamentalmente è sempre in aguato l'imprevisto o il sistema non funziona o tutto esplode, come sempre.Quindi per la stima dei task uso una sequenza di Fibonacci.Cosa ci permette questa sequenza di Fibonacci? Che nel momento in cui andiamo a dare un valore di complessità del task non ci perdiamo in valori intermedi per esempio noi abbiamo il valore 3 e il valore 5 non stiamo a pensare se un task è più complesso di 3, se è più complesso di 3 sarà 5 senza pensare no ma è 4 e 5 questo ci aiuta in realtà a non sottostimare i task che è uno dei problemi appunto di quando si sviluppa noi in realtà con questa sequenza riusciamo a dare in qualche modo dei valori di complessità che non sono legati al tempo.Ma per capire in realtà quanto tempo ci vorrà per fare un certo task usiamo l'esperienza.Al primo ciclo noi andiamo un po' a intuito quindi nella prima iterazione, nel primo sprint plan, la complessità la diamo un po' a sentimento, diciamo così.Alla fine del primo sprint quando faremo una cosa che si chiama retrospettiva, capiremo in un modo nell'altro a quanto corrispondono i nostri task point rispetto al tempo e più sprint facciamo più questa stima diventa precisa per cui non andiamo di testa a buttare giù dei tempi che non sono legati in realtà con quella che è la realtà appunto ma questo valore si affinerà iterazione dopo l'interazione diventerà sempre più preciso perché è figlio di una tendenza.Il fatto di limitare uno sprint a un numero massimo di task points, cioè il mio sprint per esempio presuppone non più di 30 task points, quindi in realtà ci costringe a inserire all'interno dello sprint solo quelli che sono i task importanti.Una volta che abbiamo fatto questo piano possiamo buttare giù gli occhi sul computer e iniziare a scrivere il nostro codice.Ma una volta a settimana ho imparato che è importante fermarsi, tirar via la maglietta dell'amica e magari indossare i panni del CEO e provare a riguardare quello che è il nostro sprint plan in modo da intanto avere una visione generale che una volta alla settimana ci aiuta a riorganizzare i task, eliminare le funzioni, magari buttare un'occhiata alle statistiche, leggere le email, pensare a nuove funzioni da inserire per esempio nel product backlog, insomma fare tutte quelle azioni che ci aiutano ad avere una visione di insieme.Tutti i miei task di uno sprint vanno a finire nella mia task board.Che cos'è? È semplicemente una lavagna con una marea di post-it attaccati sopra.In realtà la lavagna è divisa in tre colonne, una sorta di kanban.Nella prima ho i task da fare dello sprint, quindi i "to do", ordinati per priorità e non devono mai superare, all'inizio dello sprint, i 30 story point.Per quello che vi spiegavo prima.Nella seconda colonna ho il "doing", cioè tutti i task che sto lavorando in quel momento.In realtà tutti i task vuol dire uno, non ho mai più di un task in doing e questo mi permette di focalizzarmi solo su quella funzionalità o su quel bug fix che sto facendo, in modo da terminarlo nel minor tempo possibile con la maggiore concentrazione.E poi ho la colonna più figa che è la colonna dei task done, quindi quelli completati.In realtà perché uso una lavagna fisica? Uso una lavagna fisica perché è importante spostare il post-it da una colonna all'altra.Il fatto di farlo fisicamente dà una sorta di gratificazione e soprattutto ti stacca per un attimo dallo sviluppo e dal monitor, quindi scandisce in qualche modo il ritmo di sviluppo.Nel senso che sviluppo, finisco la funzionalità o il bug fix, mi alzo, sposto il post-it e sono pronto a riniziare il prossimo task quindi da una sorta di ritmo di cadenza allo sviluppo giornaliero.Naturalmente essendo un digital nomad ho però bisogno di tenere una copia di questa lavagna chiamiamola così di questa task board anche in digitale per fare questo uso Trello che comunque mi aiuta ad avere la visione sempre a portata di mano anche quando magari mi metto a sviluppare dentro Starbucks cosa che in questo periodo sta succedendo molto spesso.Un altro elemento che ho introdotto nel mio sviluppo quotidiano è il Daily Scrum.Adesso chi conosce Scrum sa che il Daily Scrum o lo stand up meeting è quel momento in cui tutti gli sviluppatori si ritrovano in piedi prima di iniziare la loro giornata lavorativa per condividere quello che il giorno precedente è stato fatto, quello che non si è riusciti a fare e quelli che sono i problemi.Ma come portare quest'approccio di gruppo in un processo di sviluppo individuale? Beh, la prima prova che ho fatto è quella di provare a rispondere quotidianamente alle famose tre domande appunto del Daily Scram che sono, cosa ho fatto, cosa non ho fatto e quali sono stati i problemi che ho incontrato.Però scriverlo non mi gratificava tanto e poi soprattutto non traspariva anche la parte emotiva, la parte di motivazione fondamentalmente.Per cui ho deciso di registrare un video di 45 secondi direttamente nel mio cellulare dove giorno per giorno rispondevo a queste tre domande.Naturalmente doveva essere il più conciso possibile.Video che poi utilizzo e ho utilizzato e utilizzo ancora nella retrospettiva.La retrospettiva è quel momento in cui alla fine dello sprint mi fermo e provo a capire cos'è andato e cosa non è andato.Funziona fondamentalmente questo.Per capitalizzare poi alla fine quello che si è fatto, c'è la retrospettiva, l'ultimo giorno dello sprint.In quel giorno veramente tolgo via tutti i vestiti del programmatore e metto quelli del CEO per un'intera giornata.Questo mi aiuta davvero a non portarmi dietro tutti i limiti e anche i lati caratteriali poco simpatici, tipici dello sviluppatore.Di solito ci metto due ore a farlo e e all'inizio pensavo fosse un giorno perso.In realtà si tratta di un giorno dove indossando gli abiti del SIO guardo cosa è successo in tutto lo sprint e cerco di trovare delle soluzioni.Un po' come quando il marinaio, mentre è in navigazione, si sposta e guarda la mappa o il tracker mentre si trova in montagna sospende un attimo e guarda la cartina per capire la direzione che si sta prendendo.Il mio esempio più semplice è quando stiamo camminando guardando il cellulare, magari stiamo scrivendo una bellissima lettera ma se non alziamo gli occhi ogni tanto, in questo caso durante appunto l'ultima giornata dello sprint, rischiamo di centrare un palo con la nostra testa.Prendo quindi un piccolo foglio e mi metto a scrivere cosa mi ferma, cosa ho fatto, se ho raggiunto il mio obiettivo, cosa ha funzionato bene, cosa posso migliorare.Una volta che l'ho scritto, diciamo che dentro la mia testa si concretizza una visione chiara di quello che è stato lo sprint e quindi anche delle possibili soluzioni e le possibili azioni da fare per migliorare il lavoro di tutti i giorni.A questo punto vado e mi faccio una bella passeggiata, possibilmente vicino al mare, un po' come in questo momento infatti penso che avrete sentito il verso di qualche uccellino che stavamo svolazzando qua.Mentre passeggio a questo punto porto il ragionamento su due punti che sono secondo me quelli più importanti dello Scrum che sono la produttività e felicità.Quindi provo a pensare a un elemento che in qualche modo migliora la mia produttività.Per esempio, che ne so, il fatto di andare a leggere le mail troppe volte durante la giornata e quindi decido di leggerle solo due volte al giorno, prima di fare il mio piccolo stand up, quindi all'inizio della giornata e prima di tornare a casa.Il secondo punto, che secondo me è quello più importante, perché diciamo il motore, il volano per avviare dei processi di soddisfazione personale e quindi alimentare la motivazione e l'epines, cioè cosa posso fare per migliorare la mia soddisfazione personale, la mia qualità di vita legata al mio lavoro? Se dovessi farvi un esempio su come migliorare l'epines potrei dirvi che lavorando a casa o comunque da digital nomad ho deciso per esempio di nella fase di termine del lavoro uscire di casa, farmi una passeggiata e poi ritornare a casa stessa.In questo modo con quella passeggiata riuscivo a staccare fisicamente il work mode dalla modalità appunto di vita quotidiana con mia moglie o a casa mia.Quindi in modo generale questo è stato appunto il metodo che ho adottato e alla fine ha funzionato perché Political Magnet è in produzione e inizia ad esserci anche qualche cliente.Per cui solo utilizzando un metodo, un metodo chiaro, sono riuscito a raggiungere l'obiettivo e finalizzare il prodotto.Adottare questa metodologia pensata per il team non è stato facile, però diciamo in qualche modo mi ha aiutato il fatto che non fosse solo una metodologia ma un framework quindi io fondamentalmente da quel modello ho preso quello che mi poteva essere più utile e questa cosa diciamo è una cosa molto importante e ti rende in qualche modo libero e soprattutto ti permette di adattare il metodo a quelle che sono le tue attitudini, le mie attitudini, quindi ci sono degli elementi che diciamo mi limitano non è che li implemento pur sapendo che in qualche modo sono controproducenti, li purgo.E giorno dopo giorno, iterazione dopo iterazione, nel processo di agisci, osserva, quindi misura e apprendi, si va ad affinare, a limitare, a purgare di tutte le azioni i metodi superflui per per poi rimanere con un metodo finito che è il tuo metodo che, detto tra di noi, non è mai finito perché è sempre in continua evoluzione La puntata di oggi è stata un po' un flusso di coscienza, non c'era neanche una riga scritta e neanche, diciamo, una scaletta sono andato a braccio per cui non posso garantire sulla qualità della puntata Una cosa però per me è importante.Se utilizzi un metodo o hai trovato dei modi per lavorare meglio e raggiungere gli obiettivi e magari mettere in produzione il tuo prodotto, condividili con noi.fondamentalmente siamo un circolo, Gitbar nasce come circolo dove i full stack developer condividono le proprie esperienze per cui puoi condividerle o mandandoli via email a info@gitbar.it oppure scrivendomi su twitter all'indirizzo @brainrepo e vi risponderò.Ci sentiamo la prossima settimana e parleremo di frontend quindi vi aspetto ciao [Musica]
