Gitbaritalian
developer
podcast
3

Come ho usato Scrum in un team composto solo da me.

Serie 1
Episodio 3
Durata 22 minuti

Il mio bisogno di migliorare la produttività, iniziare a fare dei profitti e quindi creare in qualche modo un minimo di soddisfazione fittava perfettamente con gli obiettivi dello scrum. In questa puntata vi racconto come ho fatto ad implementarlo nel team composto solo da me!

Ecco alcuni link utili: https://vivereintenzionalmente.com/il-metodo-scrum-per-obiettivi-personali/ https://link.medium.com/dtuLjvfe https://www.raywenderlich.com/585-scrum-of-one-how-to-bring-scrum-into-your-one-person-operation https://link.medium.com/Esn2mlaU42 https://softwareengineering.stackexchange.com/questions/141818/how-can-a-single-developer-make-use-of-agile-methods https://www.researchgate.net/publication/305909312_Scrum_solo_Software_process_for_individual_development#downloadCitation https://geekbot.com/

Music credits: Blan Kytt - RSPN

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

si' terza puntata di kitt barra In questa puntata voglio un po' stravolgere quello che il format realtà un format non esiste di questa trasmissione e voglio provare a raccontarvi un'esperienza e questa esperienza riguarda un prodotto che sto lanciando questi giorni che si chiama politica Alma Garret E', una piattaforma di media 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 e' piuttosto che insomma un altro una nuova piattaforma.
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 perche' vive, diciamo poche.
Ho poco tempo per poter stare in Sardegna, però diciamo in ne ho fatto una chiacchierata con mio fratello e ho provato a raccontargli questo progetto.
Mio fratello però non mi ha lasciato spiegare il tutto, ma interrotto praticamente subito, dicendomi Guarda Mauro, il progetto mi sembra interessante.
Pero' in qualche modo sarà l'ennesimo progetto che buttera' in un cassetto e inizierai con tanto entusiasmo.
Mai non terminerà mai questa cosa in qualche modo, ma 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 del 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 limiti che non mi permettevano di concludere un progetto e per capirlo, per capirlo con qualche modo mi sono guardato indietro e ho provato a vedere quali erano gli elementi che mi limitavano.
In realtà, in questo processo di ragionamento mi sono chiesto ma perché se in azienda riesco a concludere, riusciamo a concludere i prodotti a metterli sul mercato, quindi a finalizzare? Perché nello sviluppo di mese project questo non avviene? Quali sono gli elementi che 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 tre o da cinquanta euro se tu non sai come usarla, fondamentalmente tu non stringerei mai quel maledetto bullone per cui ho provato a capire come andava usata quella chiave inglese.
Guardando a come usava la chiave inglese in azienda, in azienda adottiamo da qualche tempo la metodologia schramm, in realtà il framework schramm, cioè una serie di buone pratiche che in qualche modo aiutano a essere più produttivi, a migliorarsi e soprattutto aiuta a rilasciare prodotti decenti in tempi umani.
La cosa che però mi ha bloccato è stato che lo scranno in realtà è pensato per un'azione in team nei mesi ai progetti o solitamente sono da solo, per cui diciamo che portare lo schramm da un lavoro in team ha un lavoro individuale, non è semplice.
Per farlo ho provato a tornare indietro troppo alla base e provare a capire bene quelli che sono analizzare bene quelli che sono i principi di gram.
I principi fondamentalmente sono semplici e sono tre.
Il primo è l'azione, naturalmente va bene quindi la quantificazione della produttività, cioè la necessità di capire di misurare quello che si sta facendo e misurare quello che si sta facendo il tempo.
Il tempo è una parola impropria.
Poi lo vedremo che si sta impiegando le risorse.
Anzi me.
Forse sarebbe meglio dire che si stanno impiegando per raggiungere un certo obiettivo nella quantificazione.
Dobbiamo darci dei tempi no, delle piccole online.
Queste devono essere necessariamente piccole.
Perché? Perché in realtà le misurazioni devono essere continue e costanti.
Questo ci permette, qualora diciamo, prendessimo una strada che è insomma annunciare avvicina all'obiettivo vivo odi la tagliassimo 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 dal secondo principio di Schramm, quello apprendimento e della riflessione iter attiva, cioè dividere lo sviluppo o in piccoli cicli nella quale quanti ficchiamo la produttività e al termine del ciclo ci guardiamo indietro e diciamo cosa ho capito cosa ho fatto bene, cosa non ho fatto male e quali sono i problemi che mi hanno bloccato.
A quel punto si entra in un meccanismo e quindi qual e'? Il terzo principio della grammi di ship casher 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 estero.
Nel caso siamo in produzione dai nostri clienti.
Su quale ufficio dobbiamo diciamo 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 come ho adottato alla fine lo Gram, perché poi alla fine bisogna comunque scendere nel pratico dei principi.
Li condividevo? No, a parte la parte di Tim che ho dovuto necessariamente purgare, perche' sono da solo nei mesi project i principi li condivideva appieno.
Per cui adesso il lavoro da fare era quello di portare le metodologie, le azioni, le bombe, le buone pratiche proprio nel dei byte, quindi nel lavoro giorno per giorno, e ho iniziato ad alta pensando al concetto di quindi che cos'e' in realtà lo sprint ehi, un lasso di tempo immaginate uno scatto di una partita di calcio.
Bene, è quel lasso di tempo che parte che racchiude la nazione che ha un obiettivo ben preciso.
L'obiettivo è andare in porta e finisce con la realizzazione dell'obiettivo e fondamentalmente si tratta di un ciclo di sviluppo di circa due settimane.
Nel mio caso sono due settimane proprio è 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, quindi nella lista delle funzionalità da sviluppare perché essendo il tempo limitato solo quelle posso materialmente fare.
Quindi dicevo uno sprint e' una blog il cui obiettivo esplicitato di una durata limitata.
Ma nel quotidiano, giorno dopo giorno cosa faccio? Agirò da sviluppatori, quindi mi mettero' la mia maglietta e battere sui tasti come se non ci fosse un domani.
Ma prima di buttarsi a capofitto nello scrivere il codice necessario avere un piano preciso.
Questo piano si chiama Spring Plant e viene fatto prima dello sprint.
Serve per avere un'idea in realtà di cosa fare nello Spring durante la fase di sviluppo.
In realtà non abbiamo energia 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 produttore, che non è altro che la lista delle funzionalità della nostra applicazione ordinate, in cui in qualche modo, per priorità e si inizia a dividere appunto queste funzionalità in tasca, in azioni, in compiti, questi compiti hanno in qualche modo un valore, una difficoltà.
Questa difficoltà non viene calcolata in termini di giorni uomo a uomo? No, perché comunque non riusciremo mai a stimare a priori quello che è il tempo che possiamo impiegare per un tasca, anche perché fondamentalmente è sempre in agguato o il sistema non funziona.
Ho tutto esplode come sempre.
Quindi per la stima dei task usa una sequenza di fibonacci.
Cosa ci permette questa sequenza di Fibonacci? Che nel momento in cui andiamo a dare un valore di complessità del tasche, non ci perdiamo in valori intermedi.
Per esempio, noi abbiamo il valore tre, il valore cinque.
Non stiamo a pensare se un tasche piu' complesso di tre sei più complesso di tre sara' cinque senza pensano mai quattro e cinque.
Questo ci aiuta in realtà, ma non sottostimare i tasti, che è uno dei problemi appunto di quando si sviluppa.
E 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' intuito.
Quindi nella prima iterazione, nel 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 a quanto corrispondono i nostri point rispetto al tempo e piu' sprint facciamo piu' questa stima diventa precisa, per cui non andiamo di testa anno stare giù dei tempi che non sono legati in realtà con quella che è la realtà, appunto.
Ma questo questo valore sia fine da iterazione dopo iterazione diventerà sempre più preciso perché è figlio di una tendenza il fatto di limitare uno sprint a un numero massimo di tasca, cioè il mio sprint, per esempio, presuppone non più di trenta that's.
Poi quindi in realtà ci costringe a inserire all'interno dello solo quelli che sono i tasche importanti.
Una volta che abbiamo fatto questo piano, possiamo buttare giu' 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 sì o e provare a riguardare quello che il nostro spring plant, in modo da tanto avere una visione generale che una volta alla settimana ci aiuta riorganizzare i task, eliminare funzioni, magari buttare un'occhiata alle statistiche, leggere le email e pensare a nuove funzioni da inserire per esempio nel prodotto blog.
Insomma a fare tutte quelle azioni che ci aiutano ad avere una visione d'insieme tutti i miei tasca di uno sprint e vanno a finire nella mia tasca board che cosa è semplicemente una lavagna con una marea di post-it attaccati sopra.
In realtà la lavagna e divisa in tre colonne, una sorta di campane nella prima o poi tasche da fare dello sprint.
Quindi tu tu ordinati per priorità e non devono mai superare all'inizio della dello sprint i trenta storie per quello che vi dicevo prima quello che vi spiegavo prima nella seconda colonna o il wing, cioè tutti tasche che sto lavorando in quel momento in realtà tutti task vuol dire una non ho mai più di un task in wing e questo mi permette di focalizzarmi solo su quella funzionalità o su quello che sto facendo, in modo da terminarlo nel minor tempo possibile con la maggiore concentrazione.
E poi io la colonna più figa che la colonna dei tasca don quindi quelli completati.
In realtà perché uso una lavagna fisica usa una lavagna fisica perché è importante proprio spostare il post-it da una colonna all'altra il fatto di farlo fisicamente da una sorta di gratificazione e soprattutto ti stacca per un attimo dallo sviluppo e dal monitor e quindi scandisce in qualche modo il ritmo di sviluppo nel senso che sviluppo finisco la funzionalità all bucks mi alzo, sposto il post-it e sono pronto a iniziare il prossimo tasche, 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 Otello che comunque mi aiuta ad avere la visione sempre a portata di mano, anche quando magari metta a sviluppare dentro Starbucks, cosa che questo periodo sta succedendo molto spesso.
Un altro elemento che ho introdotto nel mio sviluppo quotidiano il Daily Schramm.
Adesso chi conosce scarran sa che il degli scramble 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 questo 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 degli che sono cosa ho fatto, cosa non ho fatto e quali sono stati i problemi che ho incontrato.
Però scriverlo non mi non mi gratifica.
Intanto e poi soprattutto non traspariva anche la parte emotiva, la parte di motivazione fondamentalmente per cui ho deciso di registrare un video di quarantacinque secondi direttamente nel mio cellulare dove giorno per giorno rispondevo a queste tre domande naturalmente dovra' essere il piu' conciso possibile video che poi utilizzo e utilizzato e utilizzo ancora nella retrospettiva retrospettiva e' quel momento in cui alla fine dello dello sprint mi ferma e prova a capire cos'e' andato e cosa non è andato.
Funziona fondamentalmente questo per capitalizzare e poi alla fine quello che si è fatto la retrospettiva l'ultimo giorno dello sprint in quel giorno veramente tolgo via tutti i vestiti dal programmatore e metto quelli del sì o per un'intera giornata è questo mi aiuta davvero a non portarmi dietro tutti i limiti, anche i lati caratteriali poco simpatici tipici dello sviluppatore.
Di solito ci metto due ore a farlo e all'inizio pensavo fosse un giorno perso.
In realtà si tratta di un giorno dove indossando gli abiti del sì o guardo cosa è successo in tutto lo stato print e cerco di trovare delle soluzioni un po' come quando il marinaio, mentre in navigazione si sposta e guarda la mappa o il mentre si trova in montagna, sospende un attimo e guarda la cartina per capire quello che so alla direzione che si sta apprendendo 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 sprinter 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? Cos'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 appunto azioni da fare per migliorare il lavoro di tutti i giorni.
A questo punto vado e mi faccio una bella passeggiata fu possibilmente vicino al mare, è un po', come come in questo momento infatti penso che avrete sentito il il verso di qualche uccellino sta svolazzando qua è in mentre passeggio.
A questo punto apporto il ragionamento su due punti che sono secondo me quelli più importanti dello che sono la produttività felicità.
Quindi prova a pensare a un elemento che in qualche modo migliora la mia produttivita' 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 e quindi all'inizio della giornata e prima di tornare a casa.
Il secondo punto che, secondo me quello più importante perché è, diciamo, il mondo torre il volano per per per avviare dei processi di soddisfazione personale, quindi alimentare la motivazione e lei Pines.
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 lei lei, potrei dirvi che lavorando a casa o comunque da da Digital Nomad, ho deciso, per esempio di nella nella fase di termine del lavoro, uscire di casa a farmi una passeggiata e poi ritornare a casa stessa.
Qui, in questo modo, con quella passeggiata, riuscivo a staccare fisicamente il World Food dalla modalità appunto di vita quotidiana con mia moglie o a casa mia.
Ecco, e quindi in modo generale, questo è stato appunto la il metodo che ho adottato.
E alla fine ha funzionato.
Perché politica Bennett in produzione inizia anche qualche cliente, per cui solo utilizzando un metodo, un metodo chiaro è sono riuscito no 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 piu' utile.
E' questa cosa diciamo una cosa molto importante tante 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 pur sapendo che in qualche modo sono controproducenti, spurgo e giorno dopo giorno, interazione dopo, nel processo di agisci osserva quindi misura e apprendi.
Si va alla finale a limitare purgare di tutte le azioni e i metodi superflui, 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 è non ce l'ha neanche una riga scritta e neanche, diciamo una scaletta.
Sono andata a braccio, per cui non posso garantire sulla qualita' della puntata.
E una cosa però per me è importante.
Se utilizzi un metodo, hai trovato dei modi per lavorare meglio e raggiungere gli obiettivi e magari mettere in produzione il tuo prodotto, condividerli con con noi sin.
Fondamentalmente siamo un circolo nasce come circolo dove il full stack developer condividono le proprie esperienze, per cui puoi condividerle o mandandoli via email a In Part White oppure scrivendo su Twitter all'indirizzo etnico il repo e vi rispondero'.
Ci sentiamo la prossima settimana e parleremo di fronte, quindi vi aspetto ciao.
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄