Ho notato che ogni giorno in cui imparavo qualcosa di nuovo era un buon giorno per me. Qualsiasi giorno in cui mi sentivo migliorato in qualcosa aveva un significato speciale per me: imparare a suonare una nuova canzone, imparare una nuova apertura agli scacchi, sperimentare con la fotografia, ecc. In quel momento ho sentito che imparare e condividere ciò che avevo imparato con gli altri era qualcosa di significativo, e forse il senso della mia vita.

Sapete chi è d’accordo con me? Neil deGrasse Tyson un bambino casuale di 6 anni. 10 anni fa quel bambino chiese a Neil del senso della vita, e se quel bambino ha seguito il consiglio ricevuto scommetto che oggi è un sedicenne molto intelligente.

Imparare o non imparare, questo è il dilemma

Sapete chi altro ama imparare? La Macchina.

Il Machine Learning non è poi così un concetto nuovo. Ricordo di averlo studiato all’università e persino di aver seguito un corso di Andrew Ng intorno al 2013, quando cercavo un modo per introdurre un algoritmo di classificazione in un prodotto che la mia azienda stava creando.

Ma non avevamo mai abbastanza dati rubati o disponibilità computazionale per fare qualcosa come gli LLM che abbiamo oggi, quindi i modelli che creavamo allora erano specifici di dominio e non avrebbero mai potuto fare ciò che gli LLM fanno oggi. Abbiamo imparato molto esplorando i concetti, e anche se i risultati non erano sorprendenti, ci rendeva felici come nerd.

Ciò che mi disturba dello scenario attuale è che l’apprendimento sta perdendo significato per alcune persone perché non vedono motivo di trascorrere il loro tempo ad imparare un mestiere solo per essere superati da un LLM in un paio di secondi.

Ad esempio: mi piace disegnare tutte le immagini che uso in questo blog. Sì, ci vuole tempo. Ma come ho imparato dal mio psicanalista dopo circa 5 anni di terapia: Non devi essere produttivo in ogni momento, Mario!

Perché dovresti scrivere codice se l’LLM può scriverlo 1000 volte più velocemente?

Beh… Perché un Drauzio Varela di 79 anni dovrebbe correre una maratona? Ha impiegato quasi 5 ore per coprire quella distanza! Se avesse preso un taxi avrebbe raggiunto la destinazione in 30 minuti! È riuscito a farlo perché si è allenato duramente dai 50 anni in poi, e durante quel percorso i suoi muscoli, il suo cuore e il suo cervello hanno imparato a sopportare uno sforzo così estenuante.

Il mio punto è: c’è valore nel percorso, e imparare è sempre un percorso.

Creare vs Reagire

Durante il Regional Scrum Gathering South Africa, Chris Garvey ha fatto un gioco di parole divertente con le parole CREATING e REACTING, che si adattava perfettamente al tema di questo post. Ha usato le stesse lettere per creare due parole diverse, e queste parole rappresentano due modi molto diversi di lavorare con gli LLM. Dopotutto, quanto puoi imparare quando stai solo reagendo allo tsunami di contenuti generati dagli LLM oggi? Puoi usare gli LLM per sviluppare davvero un mestiere e imparare mentre vai avanti?

Fondamentalmente, vedo due approcci diversi quando si lavora con un LLM:

1- Puoi scrivere un testo per me? Veloce. Potenzialmente nessun apprendimento coinvolto.

2- Ehi, ho scritto questo. Puoi darmi un feedback? Lento. Potenzialmente qualche apprendimento coinvolto.

Uso il secondo. Scrivo i miei post, e questo mi dà una leva incredibile nell’usare un LLM per fornire feedback su ciò che ho scritto. Prima di tutto: se l’LLM fornisce un feedback che non ha senso, lo ignoro. O lo metto in discussione.

Oltre a ciò, ho un progetto Claude con tutti i miei post e un file values.txt dove dichiaro la mia missione personale (lo stesso contenuto che puoi leggere sulla mia Pagina About). Ogni volta che scrivo un nuovo post, chiedo di:

• Tenermi responsabile dei miei valori
• Trovare connessioni significative tra il post attuale e i post precedenti che ho scritto
• Trovare errori di battitura e aiutarmi a migliorare il mio vocabolario in inglese
• Controllare le persone che ho menzionato e suggerire persone diverse per poter rompere la mia bolla e fare la mia parte per rendere il mondo IT più eterogeneo.

Non riesco a dirti quanto ho imparato facendo questo. Ho trovato molte persone al di fuori della camera d’eco dell’IA che è LinkedIn, e ho ricevuto una raccomandazione di un libro che ha cambiato il modo in cui mi sento e mi rapporto agli LLM in generale: “The Empire of AI” di Karen Hao. È pesante, e anche se conoscevo alcune delle problematiche dietro l’intero ecosistema AI, il libro ha fatto luce su altri impatti di cui ero precedentemente ignaro. Nei suoi capitoli finali ha anche mostrato come gli LLM e gli SLM possono essere creati e usati in modo più consapevole e produrre benefici reali per l’umanità nel suo insieme.

Non perché i post finali siano scritti meglio (non posso nemmeno dire se lo sono), ma perché il percorso della scrittura ha iniziato a farmi imparare di più. E la stessa idea può essere applicata alla programmazione, al disegno o a qualsiasi cosa tu trovi piacere nel fare, purché tu continui a creare invece di semplicemente reagire a ciò che l’LLM ha creato per te.

Penso ancora che imparare dia significato alla mia vita, e cerco di farlo il più possibile. È più difficile ora, con tutto il rumore dell’IA intorno a noi, eppure… non solo è ancora possibile imparare, ma possiamo scegliere consapevolmente di farlo quando inevitabilmente interagiamo con gli LLM nelle nostre vite quotidiane. Creare è ancora una scelta che possiamo fare, e imparare è il risultato che potremmo ottenerne.

La maggior parte delle persone (me compreso) sta imparando a gestire l’AI in modi produttivi. Ma nota che questa è una lezione che viene con una dipendenza: togli l’LLM, e non hai un’abilità preziosa. E indovina un po’? Gli LLM non sono gratuiti. Puoi usarli per imparare a lavorare senza di loro, per rompere la tua bolla.

Questo è ciò che sto cercando di fare: esplorazione. Imparare per il gusto di imparare. Sto cercando di creare di più e reagire di meno.

Ma poi è arrivata l’enshittification.

Metriche, sempre loro

Substack è una piattaforma dove alcuni autori rilasciano i loro testi gratuitamente, mentre altri fanno pagare un certo importo per testi più importanti. Quindi, cosa diventa rilevante per chi scrive?

• Numero di visualizzazioni
• Numero di menzioni
• Numero di iscritti
• Numero di iscritti paganti

E fin qui tutto bene, tutto normale. C’è molto contenuto buono là che vale il denaro richiesto, e molte persone abbastanza competenti da riuscire a vivere di questo modello.

Il problema non sono tutti gli autori, ma ciò che la piattaforma fa per cercare di rendere queste metriche abbastanza attraenti da mantenere gli autori lì e attirare nuovi scrittori. Col tempo, Substack ha aggiunto:

• Una specie di Twitter
• Popup che chiedono continuamente al lettore di iscriversi alla newsletter
• Opzione predefinita per iscriversi a TUTTI i substacks che un autore consiglia quando ci si iscrive alla sua newsletter

Leggere un post su Substack è diventato un esercizio di pazienza e ho iniziato a sentirmi male a far passare le persone che dedicano un po’ del loro tempo per leggere ciò che scrivo attraverso tutto questo. Così la mia voglia di scrivere lì è andata diminuendo.

Dove ho tracciato la linea

Come se tutto questo non bastasse, le metriche hanno fatto sì che newsletter completamente spregevoli diventassero interessanti per il business perché generano entrate per l’azienda.

E questo include newsletter naziste.

Lì lasciare Substack ha smesso di essere un’opzione ed è diventata una necessità per me.

Dove sono andato e dove puoi andare tu?

Se inviare newsletter è super importante per te, Ghost è l’opzione migliore. È open-source, facile da configurare ed è piuttosto leggero. Molte persone hanno fatto questa transizione, e in termini di funzionalità è quello che più assomiglia a Substack.

Se vuoi solo scrivere e le immagini non sono molto importanti per te, puoi usare WriteFreely. Poiché è stato realizzato in Go, è abbastanza leggero (nel test che ho fatto sul mio server consumava solo circa 50MB di memoria RAM!). L’esperienza di scrittura è piacevole e va dritta al punto. Curiosamente, WriteFreely è stato sviluppato come alternativa a Medium perché il suo fondatore si è stancato dell’enshittification di Medium.

Se vuoi qualcosa di gratuito, con un alto livello di personalizzazione e avendo la totale proprietà dei tuoi contenuti, la cosa migliore da fare è usare un generatore di siti statici come Jekyll, Hugo o Astro. Questo blog è stato fatto con Jekyll, che è realizzato in Ruby ed è stato creato più tempo fa, e ho finito per seguire questo percorso perché avevo già acquisito un tema che si adattava a ciò che avevo immaginato per il mio sito. Hugo è un’opzione più moderna, e probabilmente la scelta migliore qui, specialmente se pensi di scrivere in più di una lingua.

Un altro vantaggio dei generatori di siti statici è che puoi ospitarli gratuitamente su GitHub Pages, per esempio. Non hai nemmeno bisogno di pagare un server.

Se vuoi qualcosa da leggere, suggerisco fortemente di usare un RSS Reader, che non è altro che un’applicazione dove aggiungi i blog che ti piace leggere e ti avvisa di nuovi post senza ingombrare la tua casella email. L’RSS è anche una forma di lettura più consapevole: devi scegliere ciò che vuoi leggere e seguire, e nessun algoritmo cerca di spingerti nient’altro.

Attualmente, i software/servizi che uso sono:

• Scaleway, per ospitare il mio sito.
• Typora, per scrivere i post.
• Plausible, self-hosted. Per raccogliere metriche rispettando la tua privacy (niente Google Analytics qui).
• Procreate, per creare le immagini che uso nel blog
• Vivaldi, browser che ha anche un lettore RSS

Ma… e la newsletter?

Beh, per ora non esiste, ma potrebbe essere che in futuro ne crei una. Ringrazio di cuore tutti coloro che si sono iscritti alla newsletter su Substack, e spero che continuerete a seguire ciò che scrivo qui.

Non volevo scrivere nulla di superficiale a riguardo, quindi ho provato a leggerlo attentamente, con basse aspettative, e ho fatto alcune note lungo il percorso.

Non è perfetto…

Scrum è un framework e quindi è incompleto per natura. Ci dà il compito di completarlo con pratiche, tecniche e strumenti, e questa è la parte migliore del Framework Scrum secondo me.

Quando ho sentito per la prima volta del pacchetto di espansione, temevo che avrebbe riempito le lacune e reso l’intera cosa più prescrittiva, e penso che la maggior parte delle persone condividesse lo stesso sentimento. Gli autori sono riusciti a evitare abbastanza bene quel problema, tuttavia, c’erano altri problemi che ho trovato.

Non è un pacchetto di espansione

Invece di aggiungere solo nuove informazioni, gli autori hanno anche cambiato alcuni concetti originali (es: tornando all’uso della parola roles invece di accountabilities).

Dice anche che il Product Backlog Refinement potrebbe essere un evento, cosa che non apprezzo davvero dato che nella mia esperienza questo tipo di linguaggio favorisce un comportamento meccanico.

Non è un singolo documento. Come gli autori affermano all’inizio:

“Questo documento è una raccolta di lavori indipendenti. Ogni sezione mantiene la sua licenza originale o stato di copyright, come indicato.”

Quindi la lettura è una strada piena di buche, e a volte ripetitiva.

A parte questo, direi che è praticamente innocuo.

In realtà potrebbe aiutare chi ha difficoltà con Scrum

Insegno sviluppo software e Scrum dal 2013, e oso dire che una buona parte delle domande che le persone mi fanno durante le sessioni di formazione possono essere risposte dal pacchetto di espansione.

E la maggior parte delle volte lo SGEP è riuscito a farlo espandendo il PERCHÉ delle cose, con un enorme focus sull’empirismo.

Più parole rendono più facile capire

Lascia che ti dia un esempio concreto: la Sprint Review. Lo Scrum Guide originale è un po’ criptico quando dice:

Lo scopo della Sprint Review è ispezionare il risultato dello Sprint e determinare adattamenti futuri

Scrum Guide, 2020

Dice anche che Il Product Backlog può anche essere aggiustato per soddisfare nuove opportunità.

Nelle mie lezioni spesso mi prendo del tempo per discutere questo: dobbiamo determinare adattamenti futuri, il che significa cambiare il Product Backlog in qualche modo. Quindi, una Sprint Review che non cambia il Product Backlog è qualcosa che dovrebbe causare qualche riflessione. Inoltre, se la Sprint Review è un evento obbligatorio, significa che lo Scrum Team non è passivamente aperto a cambiare il Product Backlog: stanno attivamente cercando questi cambiamenti.

Lo SGEP usa più parole per descrivere questo:

“Il Product Backlog (il cosa) VIENE adattato” - Non “può anche essere aggiustato”, ma un forte “VIENE.”

Questo è il tipo di differenza che conta per me. Rafforzando che Scrum riguarda l’apprendimento attraverso la sperimentazione così possiamo usare informazioni fresche per sviluppare cose.

Focus sull’Empirismo

Il problema principale che la maggior parte delle persone ha con Scrum, a volte senza nemmeno notarlo, è che usano il framework credendo che aumenterà la velocità di sviluppo. Questo spesso mette Product Owner e Developer in confronto invece che in collaborazione. Questo problema è così comune che l’ultimo aggiornamento dello Scrum Guide ha cambiato il termine “Development Team” in “Developers”, e la spiegazione del perché l’hanno fatto era:

L’obiettivo era eliminare il concetto di un team separato all’interno di un team che ha portato al comportamento “proxy” o “noi e loro” tra il PO e il Dev Team.

Ora c’è solo uno Scrum Team focalizzato sullo stesso obiettivo, con tre diversi set di responsabilità: PO, SM e Developers.

- Scrum Guide 2020 Revisions

Non fraintendermi: mi piace questo cambiamento. Ma per i principianti o anche per le persone che hanno usato il Framework Scrum in modo disfunzionale per molto tempo, questo non risolverà nessun problema. Voglio dire, nemmeno lo SGEP, ma almeno penso che abbia fatto un lavoro migliore nel provare a raggiungere questo.

Per esempio, lo SGEP:

• Afferma chiaramente che essere una feature-factory o una discovery factory non è desiderabile

• Stabilisce che il Product Owner deve comunicare efficacemente i risultati

• Il Prodotto diventa un artefatto con metriche basate sui risultati

Lo SGEP crea anche la Definition of Outcome Done, e ho sentimenti contrastanti a riguardo. Da un lato aggiunge un altro pezzo al puzzle e rende il framework Scrum più prescrittivo, ma dall’altro potrebbe essere particolarmente importante per chi sta iniziando o ha difficoltà con Scrum.

Parlando di questo, lo SGEP fornisce anche alcuni preziosi insight per chi sta iniziando o ha difficoltà con il proprio lavoro come Scrum Master.

Fornisce migliori indicazioni agli Scrum Master

Lo Scrum Guide originale descrive lo Scrum Master in mezza pagina. E se hai una buona dose di esperienza con il framework, questo è più che sufficiente.

Lo SGEP tuttavia entra più nello specifico, ma senza limitare troppo il tuo lavoro. Afferma per esempio, che lo Sprint Backlog dovrebbe avere abbastanza lavoro per iniziare, es: inizia con uno o due Product Backlog Item verso lo Sprint Goal. E puoi leggere questa frase come: “non c’è Definition of Ready”.

Un altro esempio è il Product Backlog: mentre la guida originale afferma che lo Scrum Master deve trovare tecniche per una definizione efficace del Product Goal e gestione del Product Backlog, lo SGEP aggiunge alcune informazioni preziose sopra a questo, come: Un Product Backlog più piccolo spesso fornisce più Trasparenza o anche il suggerimento di usare un Outcome Criteria per i Product Backlog Item.

Ancora una volta, so che queste sono vecchie notizie per alcuni. Tuttavia rende ovvie alcune delle cose che le persone spesso faticano a imparare.

Quindi, è prezioso?

Può esserlo. Ma non per tutti. Ma leggerlo è comunque un buon esercizio, quindi vai avanti. Il focus sull’empirismo è quello che me l’ha fatto piacere, ed è un pacchetto di espansione, il che significa… è opzionale comunque. Puoi anche prendere alcune delle idee e applicarle se non vuoi aggiungere tutto.

Quindi, se te la cavi bene con Scrum, non ne hai bisogno. Dopotutto, probabilmente stai già facendo la maggior parte delle cose descritte lì.

Se senti che lo Scrum Guide è criptico e ti lascia con la sensazione che dovrebbe elaborare un po’ di più su alcuni aspetti perché sei bloccato, allora lo Scrum Guide Expansion Pack potrebbe essere una buona cosa per te.

Ora, torniamo alle nostre insidie e parliamo anche di una “guerra” che va avanti da 40 anni: la Guerra degli Editor. Potrebbe sembrare una guerra sciocca, o una semplice questione di preferenze, ma fidati: non è solo tribalismo geek, riguarda filosofie fondamentalmente diverse dell’interazione uomo-computer.

Sono un utente NeoVim. Questo significa che sono uno di quei geek che preferisce digitare codice nel terminale invece di usare qualcosa di più moderno come VSCode. Mentre uso NeoVim non uso mai il mouse o il touchpad: digito solo cose e uso un mucchio di combinazioni di tasti per navigare nel codice. Ma non sono solo! Il primo editor Vi è stato creato nel 1976 e da allora la sua popolarità è solo cresciuta tra i più geek degli sviluppatori software.

Perché? Beh, spieghiamolo mentre parliamo di una delle insidie che ho menzionato a Monaco:

Insidia 4: La Visione a Tunnel nella Codifica

Vi e i suoi fratelli (Vim, Neovim) sono diventati popolari perché permettevano agli sviluppatori di navigare nel codice più velocemente. Invece di muovere la mano verso il mouse, scorrere verso il basso, selezionare una parte del codice che vuoi cambiare e poi digitare il cambiamento, questi editor hanno proposto un’idea diversa: avrebbero avuto modalità. Mentre in modalità INSERT, tutto quello che digiti sulla tastiera apparirebbe sullo schermo, proprio come succede in qualsiasi altro editor. Ma in modalità NORMAL, ogni tasto sulla tastiera può essere usato per navigare nel codice.

Per esempio: se premi 3wce cambieresti istantaneamente il contenuto della terza parola in quella riga. (Qualcosa come: Vai alla 3a Word Change fino al suo End).

Fondamentalmente crea un dialetto così puoi dire al tuo editor dove vuoi andare e cosa vuoi fare con il tuo codice senza dover usare mouse, menu, ecc. E accelerare come navighiamo nel codice è importante perché gli sviluppatori software passano più tempo a navigare e capire il codice che a scriverlo.

Un grafico che rappresenta i risultati di una ricerca su come gli sviluppatori passano il loro tempo

Quindi, perché ci stiamo concentrando sull’uso degli LLM per generare codice quando possiamo anche usarli per aiutarci a capire il codice? Voglio dire, sono ottimi programmatori, non lo nego. Ma nella mia esperienza possono fornire molto più valore spiegando il codice invece di crearlo.

Ecco un esempio pratico di come l’ho fatto: sto attualmente scrivendo un software per migliorare le attività pratiche che faccio nelle mie classi. E a un certo punto ho deciso di chiedere a Claude di spiegarmi la mia stessa architettura. Dato che Claude eccelle nell’output testuale ho pensato che sarebbe stato bello usare uno strumento come Mermaid, uno strumento che trasforma input testuali in diagrammi ordinati. Ho chiesto a Claude di spiegare la struttura usando MarkDown e Mermaid, e ho incollato il risultato in un editor di testo compatibile con entrambe le tecnologie chiamato Typora. Ecco il risultato:

Questa è un’ottima documentazione che può essere usata per spiegare sia agli sviluppatori del mio team che allo stesso LLM come funziona l’architettura! Specialmente perché il diagramma può essere letto dall’LLM come un semplice input testuale, minimizzando la quantità di token consumati in ogni interazione.

Il punto è che, non importa se hai scritto il codice manualmente o se un LLM ha scritto l’intera cosa per te, sarai comunque responsabile delle conseguenze. Quindi, capire cosa sta succedendo è fondamentalmente importante.

Ricorda: se qualcosa funziona e non sai come, quando smette di funzionare non saprai perché.

Insidia 5: Il Bias del Volume

Alcune persone si lamentano ancora della qualità del codice generato dagli LLM e sono fortemente in disaccordo con questa opinione. Nella mia esperienza, il codice generato è in realtà piuttosto buono.

Quello che mi disturba è la quantità di codice.

Specialmente perché non credo nel “vibe coding” (cioè: fidarsi del codice generato e non dargli nemmeno un’occhiata). Devo revisionare il codice e assicurarmi che faccia quello che dovrebbe fare perché… sono un adulto responsabile? Quindi, quando l’LLM cambia 8 file e aggiunge 200 righe di codice per ogni prompt che faccio, il mio lavoro diventa estremamente doloroso e beh, noioso. Ho provato molteplici approcci e prompt diversi per ridurre questo problema ma devo ancora trovare una soluzione.

Per essere onesto Claude 4.0 ha presentato un grande miglioramento quando si tratta di questa particolare insidia, e penso che avremo una soluzione definitiva a questo in un futuro prossimo. Ma non ci siamo ancora.

Un prompt, MOLTI cambiamenti

Quello che sento è che invece di aiutarci a camminare più velocemente gli LLM ci stanno aiutando a fare passi più grandi. Entrambi gli approcci possono aiutarci a coprire una distanza maggiore nella stessa quantità di tempo, ma il secondo comporta anche un alto costo quando stai camminando nella direzione sbagliata. Anche il modello di business contribuisce a questo: quando uso Cursor per esempio, ho token/interazioni limitati, il che mi incentiva a trarre il massimo da ogni prompt.

Conclusione

Scrivere sul lavorare con gli LLM è una cosa strana. Credo sinceramente in tutto quello che ho scritto in questo post oggi. Ma le cose stanno cambiando velocemente, e questo post potrebbe invecchiare come latte o vino a seconda dei prossimi sviluppi. Se apprezzi imparare di più su questo argomento, ti suggerisco fortemente di fare due cose: usalo per creare qualcosa invece di solo leggerne su LinkedIn (ancora meglio: allontanati del tutto da LinkedIn), e prova a leggere opinioni diverse sull’argomento. Il libro di Karen Hao “The Empire of AI” potrebbe essere un buon inizio.

La cosa divertente di questa conferenza è che sono andato a due interventi successivi che si collegavano direttamente a quello che ho presentato: Nigel Baker e Paul Goddard hanno parlato di Pair Programming (e sono ancora deluso che non abbiano menzionato Penn & Teller nei loro esempi di pairing) e il keynote finale di Henrik Kniberg che ha parlato di IA agentica nel software e nello sviluppo software agile. Quindi, collegherò anche insight dalle loro presentazioni per arricchire la nostra conversazione. Per farlo, cambierò l’ordine in cui ho inizialmente presentato le insidie.

Insidia 1 - Fissazione sulla Scrittura

La mia prima lamentela su come la maggior parte delle persone ha usato l’IA riguardava come continuiamo a scrivere e usare il testo come l’unico modo per parlare con i nostri LLM. Kniberg ha usato due forme diverse di comunicazione durante la sua presentazione: voce e un disegno su tovagliolo. Ed è proprio di questo che stavo parlando: il linguaggio ha limitazioni, e queste sono vecchie notizie. Nietzsche ha notoriamente detto che Ogni parola è un pregiudizio e William James ha sfidato la nostra capacità di comprendere il significato dietro le parole con il suo aneddoto dello scoiattolo che gira intorno all’albero.

Se vuoi provare come potrebbe funzionare, puoi integrare Aider con ChatGPT per usare la tua voce per programmare (e forse questo potrebbe essere il mio prossimo post). Ma se non vuoi spingerti così lontano, disegna, fai screenshot da usare come esempi, fondamentalmente: sperimenta.

Un diagramma che mostra come i moduli della mia applicazione dovrebbero interagire tra loro

Ora, il diagramma ci porta immediatamente alla prossima insidia…

Insidia 2 - Atrofia nell’Apprendere

Se un’IA può programmare, perché dovrei imparare a programmare?, beh… questa è una domanda interessante. Nel mio intervento ho menzionato che il codice generato dagli attuali LLM (come Sonnet 3.7) è in realtà piuttosto buono, e spesso migliore di quello che scriverebbe un umano. E gli LLM stanno migliorando più velocemente di noi in questo momento, quindi…

Quindi dobbiamo ancora imparare. Guarda il diagramma nella sezione precedente: parla di struttura software e come organizzare il codice. Se non sai programmare, non puoi creare diagrammi come questi e le tue opzioni saranno limitate. Queste limitazioni possono portarti a vicoli ciechi e problemi che non sei in grado di risolvere, e se anche il tuo collega IA non è in grado di risolverli allora…

Il lato oscuro del vibe

Come hanno detto Nigel Baker e Paul Goddard nel loro intervento: il pairing è un ottimo modo per imparare. Probabilmente imparerai che persone diverse usano gli LLM in modi diversi, e dovrai capire quando usare ogni approccio. Per esempio: al giorno d’oggi puoi letteralmente programmare un agente che controllerebbe tutto quello che il tuo partner ha postato su internet e comprerebbe automaticamente regali per loro in date speciali. E probabilmente saranno buoni regali!

Ma è una buona idea? Beh, non credo. Simon Wardley propone una domanda interessante per risolvere questo dilemma, e in ogni caso, se non hai ancora visto il suo intervento per favore fallo:

Quanto valorizzi un umano coinvolto in quella decisione?

E a volte, quando sviluppi software, conta. Ma ancora una volta: le tue capacità decisionali saranno limitate dalla tua conoscenza. Quindi, continua a imparare (e prova a fare pairing con qualcun altro così puoi imparare di più e più velocemente).

Insidia 3 - L’Approccio Monolitico

Ho fatto una battuta durante la mia presentazione e ho detto che Vibe Coding dovrebbe essere rinominato Conversational Reactive Assisted Programming, o C.R.A.P.. Tutti hanno riso, e momenti dopo stavamo tutti guardando Henrik Kniberg fare un’impressionante dimostrazione usando Cursor.

Quindi, penso che dovrò spiegarmi. :)

Il termine Vibe Coding è stato coniato da Andrej Karpathy, e ha detto che la tecnica è “non troppo male per progetti usa e getta del weekend”. Una parte chiave della definizione di vibe coding è che l’utente accetta il codice senza piena comprensione, e il ricercatore di IA Simon Willison ha persino detto che “Se un LLM ha scritto ogni riga del tuo codice, ma l’hai revisionato, testato e capito tutto, questo non è vibe coding secondo me—questo è usare un LLM come assistente di digitazione.”

Quindi, per quella definizione di Vibe Coding, mantengo la mia battuta. Almeno per ora. Il concetto di non preoccuparsi del codice generato da un LLM può essere una buona idea, ma solo se sappiamo quando usarlo, e per ora non dovrebbe essere il 100% del tempo a meno che tu non stia costruendo un prototipo.

Il punto è che, se non sai programmare, il Vibe Coding sarà la tua unica opzione quando usi un LLM per sviluppare software. E non è veramente programmare, perché è non-deterministico: lo stesso prompt potrebbe generare risultati diversi. Preferisco il termine che usa Simon Wardley: Vibe Wrangling.

Una slide del mio intervento: Se hai più conoscenza tecnica, avrai più opzioni

Forse in futuro avere il Vibe Coding come unica opzione non sarà un problema, ma non ci siamo ancora. Potrebbe succedere l’anno prossimo, nel 2035, o potrebbe non succedere mai. Ma qualunque sia la risposta, imparare a programmare è ancora rilevante perché espanderà le tue opzioni. E questa è la mia principale (e forse unica) critica sull’ottima sessione keynote di Kniberg: non penso che il Vibe Coding sia un’evoluzione del copiare e incollare codice generato da un LLM, per esempio. Vedo tutti questi approcci essere usati in contesti diversi, e la decisione si ridurrà sempre a una versione leggermente modificata della domanda proposta da Simon Wardley:

Quanto consapevole devo essere sul modo in cui questo verrà implementato?

Per me la risposta è ancora “abbastanza spesso”. Gli LLM sono biased, non-deterministici e replicano tutti i problemi che erano presenti nei loro dati di training. Faranno errori, e alcuni di questi errori potrebbero danneggiare le persone, specialmente in gruppi che sono sotto-rappresentati nei dati usati per addestrare i modelli (puoi e dovresti controllare il lavoro della Dott.ssa Timnit Gebru). Quando accettiamo codice generato dall’IA senza piena comprensione, stiamo ereditando non solo la soluzione ma anche i pregiudizi concettuali incorporati in essa.

Quindi, rispondere a quella domanda è qualcosa che inizieremo a fare sempre di più. E tornando alla sessione di Nigel Baker e Paul Goddard: non devi rispondere a quella domanda da solo.

Insegno e faccio coaching costantemente con le persone su come sviluppare prodotti migliori, che sia in corsi CSM/CSD, come consulente o come mentore. Ho la mia quota di storie da condividere durante questi eventi, ma sai com’è… mentre queste storie sono nuove ed eccitanti per gli studenti, non posso dire lo stesso dopo averle ripetute una dozzina di volte.

E inoltre… ho bisogno di una scusa per toccare il codice. :)

Il Prodotto

Come formatore, cerco di creare simulazioni così i miei studenti possono imparare dalla propria esperienza la maggior parte del tempo. Ecco perché nel 2019 ho creato il gioco di carte Scrumchkin, per esempio. Ma dalla pandemia, la maggior parte delle mie sessioni di formazione sono state online, il che rende molto difficile replicare lo stesso ambiente dinamico che avevo con le vere carte Scrumchkin in una formazione in presenza.

Quindi, ho deciso che il mio prodotto avrebbe provato a risolvere quel problema:

Gli studenti dovrebbero essere in grado di imparare argomenti complessi attraverso esperienze dinamiche e simulazioni.

Era un fit perfetto dopotutto: ho corsi periodici dove posso portare il prodotto a un test sul campo e raccogliere feedback e ho accesso a una comunità di formatori che potrebbero essere interessati a provare il prodotto e fornire un tipo diverso di feedback.

Dato che tutto ciò di cui avevo bisogno era una scusa per iniziare a scrivere codice, ero soddisfatto di questo.

Decisione: Scegli una libreria di componenti UI dall’inizio e attieniti ad essa. Puoi cambiare tutto dopo, se necessario.

Decisioni sugli Strumenti

Ho deciso di evitare l’uso di un database all’inizio, finché non capisco che tipo di dati voglio memorizzare e come voglio memorizzarli.

Elixir (il mio linguaggio preferito) ha qualcosa che fa il lavoro abbastanza bene: i GenServer. Posso usarli per memorizzare temporaneamente i dati senza dover ricorrere a un database. L’informazione sarà lì finché non accade una di tre cose:

• Riavvio il server

• Si verifica un errore e il GenServer viene riavviato

• Termino il GenServer

Questo approccio mi ha permesso di muovermi più velocemente e dimenticare le migrazioni, per esempio.

Ma, ma… Mario! Non è rischioso?

Il rischio dipende dal contesto. Le mie sessioni di formazione sono brevi, e nel peggiore dei casi perderei circa 15 minuti di tempo e gli studenti dovrebbero ricominciare un esercizio se un GenServer fallisce durante la formazione.

Quindi, è un rischio che sono consapevolmente disposto a correre.

Parlando di fallimenti…

Non posso dire che sto facendo puro TDD, ma sto scrivendo molti test. Specialmente perché sto usando Claude per generare alcuni pezzi di codice per me (scriverò dopo su quali pezzi di codice Claude sta scrivendo per me).

È molto difficile usare il TDD con un LLM. Questi modelli generano enormi pezzi di codice in una volta. Nel frattempo, il TDD è tutto su quel ritmo incrementale: un test, fallo passare, e poi affronta il prossimo. Quello che sto facendo è scrivere test per i miei GenServer, chiedere a Claude di proporre test extra che potrei aver dimenticato e poi chiedere a Claude di implementare le funzioni che farebbero passare i test.

Ho imparato che i test ora sono molto più importanti di quanto fossero prima dell’IA. Quando un LLM fa dozzine di modifiche al tuo codice, è impossibile per te garantire che il tuo codice faccia ancora quello che dovrebbe fare. E Claude ha rotto i miei test più volte di quante possa contare, specialmente quando ha provato a modificare molti file contemporaneamente.

Decisione: Usare l’IA come copilota aumenta la necessità di test automatizzati. E l’IA può aiutarti a scrivere anche i tuoi test.

Decisioni di Design

Ho acquisito tailwindui molto tempo fa e mi piace usare i suoi blocchi di costruzione per creare le mie applicazioni. Posso usarlo per rendere il mio prodotto bello senza spendere molto tempo a raffinare eccessivamente il mio design.

Ovviamente, essendo un non-designer ho anche difficoltà con il layout generale. Anche se ho bei blocchi con cui lavorare sono ancora abbastanza capace di rovinare tutto quando li metto insieme. Quindi, a volte uso Lovable per capire meglio modi di visualizzare come i componenti potrebbero stare insieme.

Decisione: Prova a posticipare l’avere un database. Pensa a modi diversi per farlo così puoi imparare di più sui tuoi dati prima di impegnarti in una struttura di modello.

Meccanismo di Autenticazione

Quando sono in una sessione di formazione, non voglio che i miei studenti creino account e ricordino password per un’esperienza che durerà 2 o 3 giorni. Non voglio nemmeno spendere tempo a armeggiare con un meccanismo di autenticazione.

Ora, so che alcuni di voi stanno pensando: “Ehi Mario, è il 2025! Puoi configurare un meccanismo di autenticazione in un paio di minuti”. Forse sì, forse no. Ma sono sicuro che avere un meccanismo di autenticazione completo aggiungerebbe istantaneamente almeno un po’ di complessità a tutto il resto che voglio sviluppare.

Quindi il mio meccanismo funziona così:

Mi dici il tuo nome, lo salvo nella tua sessione e sei a posto. A meno che tu non sia il formatore, ovviamente. Allora tutto quello che devi fare è inserire il tuo nome come SUPER_SECRET_PASSWORD e avrai accesso alle funzionalità avanzate.

È sicuro? No.

È abbastanza buono da usare in una classe con 20 persone? Decisamente sì.

Decisione: L’autenticazione arriva all’ultimo momento responsabile. Pensaci, lavora attorno ad essa e forse finirai per creare qualcosa di innovativo.

Deploy

Ho recentemente letto l’incredibile libro Simplicity di Dave Thomas, e ci sono molte buone idee lì. Una che mi piace particolarmente è: automatizza il tuo deploy dal giorno zero, così puoi fare deploy spesso.

L’ho fatto usando github workflow e la mia dedibox su Scaleway. Ora faccio deploy facendo solo un semplice:

git push origin deploy

E ovviamente, il deploy avviene solo se tutti i miei test passano. Roba piuttosto basilare, lo so. Ma fare questo dal primo giorno mi permette di fare deploy spesso e raccogliere feedback rapidamente.

Decisione: Crea un hello world, fai il deploy e automatizza l’intero processo di deployment prima di fare qualsiasi altra cosa.

Considerazioni Finali

Un buon progetto personale è un progetto personale che puoi rapidamente deployare e far usare ad altre persone. Nel mio caso, come formatore, l’idea di creare una piattaforma per simulare cose della vita reale durante le sessioni di formazione sembra un fit perfetto.

Rivedrò alcune di queste decisioni? CERTO! Questa è l’intera idea dietro ciascuna di queste decisioni. Un giorno avrò un meccanismo di autenticazione appropriato e un database, ma quando quel giorno arriverà avrò una ragione per implementare queste cose.

Come direbbe Jaqen di Game of Thrones:

Cosa diciamo al nostro bisogno di implementare l’autenticazione nei nostri prodotti? Non oggi.

“Come posso iniziare ad applicare il Test-Driven Development?” Questa domanda echeggia nelle mie sessioni di formazione come una chiamata di funzione ricorsiva. Mentre la mia risposta predefinita è sempre stata “Inizia correggendo i bug,” ho scoperto un approccio ancora più coinvolgente: Advent of Code.

Il mio approccio predefinito: correggere un bug esistente

Esaminiamo un esempio semplice. Immagina di avere una funzione calcolatrice:

Quando qualcuno prova a dividere per zero, la nostra applicazione crasha senza cerimonie. Questo presenta un’opportunità perfetta per il TDD – possiamo scrivere un test che esprime il nostro comportamento desiderato:

Il mio test fallirà ovviamente, perché il mio codice fallisce. Ora posso correggere il mio codice e far passare il mio test.

L’Approccio Gamificato: Advent of Code

Come un autoproclamato geek con un’affinità per i puzzle, ho scoperto che Advent of Code è il terreno di allenamento perfetto per il TDD. Ogni puzzle fornisce:

• Un campione di input

• Un output atteso

Questa struttura ti guida naturalmente nella mentalità TDD – scrivi il tuo test basato sull’esempio prima di implementare la tua soluzione. È come avere una specifica incorporata!

Voglio dire, non solo è un buon modo per imparare il TDD, ma è anche divertente. Stai affinando le tue capacità di sviluppo, risolvendo un puzzle e praticando una tecnica molto preziosa.

Man mano che avanzi nelle sfide, potresti iniziare a sperimentare di più con il TDD e forse ridurre la granularità di alcuni dei tuoi test. Per esempio, potresti dover fare il parsing di un input di testo complesso in una Map per risolvere il problema, e poi questo potrebbe essere un test a sé stante.

Strumenti che Migliorano l’Esperienza

In Elixir (il mio linguaggio preferito), l’operatore pipe (|>) è particolarmente potente per il TDD:

Quel piccolo triangolo dice fondamentalmente: prendi l’output della funzione sopra e passalo alla funzione seguente. Questa sintassi elegante ti permette di abbozzare il flusso ad alto livello della tua soluzione prima di tuffarti nei dettagli di implementazione.

Combina questo con strumenti come mix test.watch, che esegue automaticamente i test quando i file cambiano, e hai un ciclo di feedback rapido che rende il TDD naturale e intuitivo.

Pronto per Iniziare?

Scegli il tuo linguaggio di programmazione preferito e tuffati! Puoi esplorare il mio repository Advent of Code 2024 per ispirazione:

https://github.com/mariomelo/advent_of_code24

Ricorda: L’obiettivo non è la perfezione ma la pratica. Ogni puzzle è un’opportunità per rafforzare i tuoi muscoli TDD mentre ti diverti!

Per approfondimenti sul TDD, dai un’occhiata all’eccellente articolo su Software Design: Tidy First?

Software Design: Tidy First? - Canon TDD

Buon coding!

Durante questi anni sono stato sviluppatore, imprenditore, consulente, formatore, e ho imparato (principalmente commettendo errori) molte cose sia sul lato tecnico che su quello sociale dello sviluppo software.

Quello che ho scritto qui è basato su quello che ho vissuto in questo mercato, il che significa: è basato su molti anni di esperienza, ma è anche influenzato da queste stesse esperienze. Ma dato che ho visto cose cambiare e altre non cambiare, vorrei provare a elaborare il mio ragionamento su quali sono le cause e le conseguenze di questi risultati.

Quindi, iniziamo!

Cosa è cambiato in 20 anni?

Beh… Ovviamente, la tecnologia è cambiata. E con essa, tutto è cambiato.

Quando ho iniziato a programmare non avevamo iPhone o telefoni Android, e curiosamente stavo lavorando con il mobile computing. Pocket PC 2002 era il sistema operativo e stavo scrivendo codice C++ che doveva essere altamente ottimizzato a causa di tutte le restrizioni di memoria che avevamo all’epoca.

Mobile negli anni 2000: Questi dispositivi potevano far sembrare fragile il Nokia 3310

Ma soprattutto: le organizzazioni sono cambiate. E la maggior parte dei cambiamenti che ho visto sono stati causati da innovazioni tecnologiche.

Complicato, poi più semplice, poi complesso

Se hai mai scritto un’applicazione web usando J2EE e Enterprise Bean, ricorderai quanto era burocratico. Il deploy non era diretto, dovevamo scrivere molto codice per fare la cosa più semplice e i cambiamenti allo schema del database erano un incubo. Il punto è che stavamo principalmente creando applicazioni web private perché il web non era quello che è oggi (nemmeno Orkut era stato creato ancora).

All’inizio, questi punti dolenti hanno incentivato le organizzazioni a spingere per team più grandi, un dipartimento di gestione database specializzato e anche un dipartimento operazioni.

D’altra parte, gli sviluppatori hanno iniziato a creare strumenti per risolvere questi punti dolenti: framework ORM come Hibernate hanno iniziato a diventare popolari, poi framework come Rails hanno iniziato a introdurre modi più semplici per creare database evolutivi e anche un approccio più diretto per creare un’applicazione web.

Questi cambiamenti hanno dato potere agli sviluppatori e permesso a piccoli team di essere ancora più produttivi di quanto lo fossero i grandi team aziendali. Con questo abbiamo visto un cambiamento nel mercato: tutti volevano team più piccoli con i cosiddetti Sviluppatori Full-stack. Il cloud computing era disponibile per tutti per meno di $5/mese con Heroku, DigitalOcean e AWS, e molte startup hanno iniziato a spuntare ovunque.

Ma poi… tutto è cambiato.

Il web si è evoluto e quello che era un semplice REQUEST/RESPONSE con HTML e CSS è diventato un puzzle complesso usando Ajax, jQuery, e poi Angular, Ember, React, Vue, Svelte. Le aziende hanno iniziato a richiedere sviluppatori frontend.

Sul backend, le cose sono diventate ancora più complesse. I giganti dell’industria stavano affrontando le sfide causate dal loro stesso successo: come gestire una quantità così massiccia di utenti simultanei? Come memorizzare efficientemente questa quantità massiccia di dati?

Ancora una volta, gli sviluppatori sono venuti in soccorso e hanno creato soluzioni come Docker, Kubernetes, Grafana. I giganti hanno condiviso le loro storie di successo e le aziende di medie dimensioni hanno deciso di aggiungere tutta questa complessità ai loro prodotti per raggiungere gli stessi risultati. In parte, questo movimento è stato causato anche dagli sviluppatori: volevamo lavorare con la tecnologia all’avanguardia usata dai giganti del mercato, anche se chiaramente non era necessaria per i nostri server che gestivano molti meno utenti di Google o Facebook.

Sviluppare un software semplice sembrava… inutilmente complesso. La maggior parte delle aziende con cui ho lavorato all’epoca non stavano creando prodotti per le masse, ma prodotti di nicchia con poca o nessuna necessità di tale complessità. Ed è stato proprio quando ho iniziato a lavorare di più con consulenza e formazione di nuovo. Stavo costantemente sostenendo modelli più semplici ogni volta che erano abbastanza buoni.

Lo faccio ancora.

Cosa non è cambiato in 20 anni?

Molte cose:

• Abbiamo ancora bisogno di sviluppatori software

• Le persone stanno ancora cercando di capire come misurare la produttività nel campo dello sviluppo software

• Le stime sono ancora un problema per la maggior parte delle persone

• Le persone discutono ancora su qual è il miglior editor di testo/IDE/framework/linguaggio

• E beh… lo sviluppo software mi porta ancora gioia :)

Non sento di aver detto tutto quello che volevo dire. Devo ancora riflettere di più su come sono cambiato durante questi 20 anni.

Forse scriverò di più su questo in futuro.

Circa un anno fa ho creato un gioco di carte per insegnare Scrum: Scrumchkin. Il gioco ha reso il processo di apprendimento più divertente ed è stato adottato da Scrum Trainer di diversi paesi, finché la pandemia non ha reso impossibile qualsiasi lezione in presenza.

Ed è da lì che è nato il mio progetto personale: creare una versione online di Scrumchkin. Che sarebbe stata un’ottima opportunità per giocare e imparare di più su Phoenix Liveview.

Inizialmente, ho pensato alla seguente struttura per il progetto:

In questo modo, sarebbe possibile creare giochi in processi separati e avere un registro con identificatori unici per ogni gioco in modo che ogni partita potesse essere accessibile attraverso un URL diverso.

Esempio:

• L’utente accede all’URL http://scrumchkin.com/game/abc123

• L’applicazione web chiede al Registro dei Giochi dove si trova il gioco abc123

• Il Registro dei Giochi trova il PID della partita e lo restituisce all’applicazione web

Il Registro dei Giochi come libreria

Tenendo a mente il principio di responsabilità singola, il design sopra rende evidente l’esistenza di 3 progetti diversi: Il Registro dei Giochi, il Server di Gioco e l’Interfaccia Web.

I prossimi paragrafi parleranno di alcuni aspetti tecnici di Elixir come curiosità. Se vuoi solo capire la differenza tra una libreria e un’applicazione OTP sentiti libero di saltare questa parte :)

Tecnicamente il Registro dei Giochi è estremamente semplice: collega un ID unico a una partita. È fondamentalmente un dizionario che ha un UUID come chiave e un PID di un GenServer come valore per una partita.

Inizialmente, ho creato il Registro dei Giochi come una libreria capace di eseguire operazioni CRUD su una tabella ets:

defmodule GameRegister do
  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

  def save(value) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, value})
    key
  end

  def delete(key) do
    :ets.delete(:scrumchkin, key)
  end

  def get(key) do
    :scrumchkin
    |> :ets.lookup(key)
    |> format_result
  end

  def list_all do
    :ets.tab2list(:scrumchkin)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

TL;DR - La libreria memorizza lo stato corrente delle partite e le collega a un codice identificatore. È capace di elencare, ottenere, salvare ed eliminare partite dal registro.

Un piccolo problema

Per poter usare la tabella ets, doveva esistere. Questo significa che a un certo punto la funzione init dal codice sopra avrebbe dovuto essere chiamata dalla mia applicazione web.

  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

Ma questo va contro il principio di responsabilità singola che ho usato per dividere questo progetto in parti più piccole, giusto?

Il Registro come applicazione

Ma cos’è una dipendenza come libreria? È un ingranaggio che fa parte di un tutto; qualcosa di molto simile a un pezzo di Lego. Sappiamo dove sono i perni e i buchi e lo usiamo per costruire qualcosa di più grande.

La dipendenza da un’applicazione OTP è un po’ diversa.

Pensa a un’auto. Di solito, le auto hanno un meccanismo di raffreddamento del motore che si avvia quando giri la chiave e avvii l’auto. L’auto dipende da questo meccanismo per funzionare, ma è in qualche modo indipendente: molte volte si attiva quando spegniamo l’auto (quel rumore di ventola che viene da sotto il cofano, specialmente nelle giornate calde).

Questo meccanismo di raffreddamento ha interfacce con il motore dell’auto, ma controlla il proprio stato. C’è una chiara relazione di dipendenza, ma non di controllo. Il motore dipende dal sistema di raffreddamento per non surriscaldarsi, ma non lo controlla.

E lo stesso doveva succedere con il mio Registro dei Giochi, che è diventato così:

defmodule GameRegister do
  use GenServer

  def start_link(state) do
    GenServer.start_link(__MODULE__, state, name: __MODULE__)
  end

  def init(stack) do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
    IO.puts("Tabella scrumchkin creata")
    {:ok, stack}
  end

  def handle_call({:save, game}, _from, state) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, game})
    {:reply, key, state}
  end

  def handle_call({:delete, game_id}, _from, state) do
    :ets.delete(:scrumchkin, game_id)
    {:reply, :ok, state}
  end

  def handle_call({:get, game_id}, _from, state) do
    result =
      :scrumchkin
      |> :ets.lookup(game_id)
      |> format_result

    {:reply, result, state}
  end

  def handle_call(:list_all, _from, state) do
    {:reply, :ets.tab2list(:scrumchkin), state}
  end

  def save(game) do
    GenServer.call(__MODULE__, {:save, game})
  end

  def delete(game_id) do
    GenServer.call(__MODULE__, {:delete, game_id})
  end

  def get(game_id) do
    GenServer.call(__MODULE__, {:get, game_id})
  end

  def list_all do
    GenServer.call(__MODULE__, :list_all)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

Ma… cosa cambia?

La mia applicazione web non è responsabile della creazione della tabella ets. Dice solo che dipende dal Registro dei Giochi e che ora è un’applicazione extra.

La modifica nel file mix.exs è semplice:

  def application do
    [
      mod: {Scrumchkin.Application, []},
      extra_applications: [:logger, :runtime_tools, :game_register, :game_engine]
    ]
  end
  defp deps do
    [
      {:game_engine, path: "../game_engine"},
      {:game_register, path: "../game_register"}
    ]
  end

Ora, ogni volta che avvio la mia applicazione con mix phx.server, il mio registro dei giochi viene automaticamente avviato e si assume la responsabilità di creare la tabella ets dove memorizzerà i PID delle partite di Scrumchkin.

La mia applicazione web dipende dal Registro dei Giochi, ma si fida che possa risolvere i suoi problemi da solo.

Disclaimer: questo post è stato scritto originariamente il 24 marzo 2014 e pubblicato su Medium. Penso che sia ancora molto rilevante (forse con qualche riferimento musicale datato qua e là), quindi l’ho portato anche qui.

Sbagliare o non sbagliare

Come esseri umani, siamo tutti inclini all’errore. Ma alcuni si rifiutano di accettarlo.

Dai il massimo per qualcosa solo per scoprire che non è andato come avevi pianificato. C’è qualche tipo di punizione in arrivo?

Ambienti che stigmatizzano il fallimento

Qualunque sia la tua risposta, è stata almeno in parte creata dagli ambienti in cui hai vissuto finora. Eri libero di fallire quando eri giovane? Lavori in un’azienda dove le persone vengono punite quando commettono errori? Ti senti a tuo agio quando affronti persone che hai deluso?

Un ambiente che stigmatizza il fallimento è un posto dove a nessuno è permesso fallire, perché se lo fanno, subiranno qualche tipo di dura punizione. Come essere licenziato dal capo, sculacciato dai genitori o persino lasciato dal partner. Scegli tu.

Hai sbagliato. Vergognati.

- Noi stessi

Se hai mai vissuto in questo tipo di ambiente (e le probabilità sono che tu l’abbia fatto), sai quanto duramente devi pensare prima di fare un singolo passo avanti. O indietro. Devi pensare e ripensare ogni mossa perché se fallisci c’è qualcosa di brutto che ti aspetta.

Conseguenze della stigmatizzazione del fallimento

Beh, se guardi in faccia il male, il male ti guarderà indietro, e non potendo fallire potresti iniziare a odiare quando le persone ti deludono.

È successo a me, e quando ho iniziato a invertire questo processo sono diventato in grado di percepire alcune conseguenze di questo tipo di cultura.

Stagnazione

Spesso evolviamo per tentativi ed errori. Accettiamo i concetti appresi con la pratica più velocemente di quelli appresi dalla teoria.

Perché cadiamo, signore? Così possiamo imparare a rialzarci.

— Alfred Pennyworth

Dove lavoro, proviamo costantemente cose nuove e facciamo brainstorming. Non importa cosa viene in mente, tutti si sentono liberi di dire qualsiasi cosa a chiunque. I fallimenti sono tollerabili finché impariamo qualcosa da loro, e questo ci fa evolvere molto più velocemente di quanto ci si aspetterebbe.

Se nessuno avesse questa libertà di fallire, i miei colleghi perderebbero l’autonomia e la fiducia in sé stessi per provare le proprie idee e saremmo bloccati nel 2011.

Procrastinazione

Non posso fallire quindi devo lavorarci finché non è perfetto, non importa quanto tempo ci vuole.

Voglio un nuovo errore, perdere è meglio che esitare.

— Queens of the Stone Age

Una volta ho lavorato a un progetto che mirava a migliorare un certo indicatore aziendale a qualcosa sopra il 90%. Dopo 5 mesi, il progetto poteva migliorare questo indicatore dal 10% a qualcosa sopra il 65% se fosse stato distribuito. I responsabili non volevano distribuirlo così com’era e hanno continuato a cercare modi per migliorare quel 65% al desiderato 90% per 2 maledetti anni.

Per 2 anni l’azienda ha avuto il 10% su qualcosa che avrebbe potuto avere il 65% perché nessuno voleva dire Ehi, non sono riuscito a consegnare il 90%, ma iniziamo con il 65% e cresciamo da lì. È probabile che se avessero provato, avrebbero capito come raggiungere più del 90% in meno di 2 anni.

Quindi, se fallisci velocemente, evolverai più velocemente.

Bugie e Apatia

Tutto è in fiamme, ma nessuno si farà avanti per fare qualcosa. A proposito, l’accendino è stato buttato via perché poteva far sembrare qualcuno colpevole.

Non sono stato io

— Shaggy (e il 94,7% dell’umanità)

È difficile trovare qualcuno con più informazioni su un problema della persona che l’ha creato per prima. Se questa persona si sente abbastanza a suo agio da ammetterlo, il suo aiuto può essere la chiave per risolvere il problema. Tuttavia, se non c’è spazio per questo, molte cose importanti rimarranno sotto il tappeto.

Cerco di fare riunioni retrospettive con i miei colleghi periodicamente. È salutare avere un dibattito aperto sui nostri difetti e cercare miglioramenti insieme, qualunque sia l’argomento.

TL;DR

Lotta per il tuo diritto di fare errori, prova le tue idee senza aver paura di fallire e non essere cattivo quando vedi qualcun altro fallire, anche se ti fa male.

Se mai ti trovi in una situazione difficile causata da un errore che hai fatto, dai un’occhiata a www.experienceproject.com. Troverai molte persone amichevoli come te che condividono le loro esperienze in modo molto aperto.

Questo è tutto. Continua a fallire. ☺

La cosa più curiosa è che i trasferimenti di altri valori funzionavano perfettamente. Beh, quasi tutti. Le persone hanno iniziato a scoprire altri casi specifici dove il problema si verificava: R$32,23 o R$155,17.

L’idea di questo post non è discutere la causa del problema, ma mostrare una tecnica che può aiutare i team a rilevare problemi simili.

Il testo include del codice in Elixir, ma include anche illustrazioni per spiegare ogni concetto. L’obiettivo è rendere questo contenuto utile sia per le persone tecniche che non tecniche.

I test unitari aiuterebbero? Beh… non esattamente.

Non fraintendermi: sono un fan dei test unitari e (quasi) sempre pratico TDD.

Ma un test convenzionale per una funzione di trasferimento di denaro sarebbe probabilmente qualcosa di simile all’esempio qui sotto:

Non è troppo specifico?

Nota che il test dove il trasferimento è possibile si concentra su un solo caso: un trasferimento di R$25,00. E in questo caso, i test hanno successo:

Ma possiamo scrivere un test per il caso dei R$17,99, giusto?

Certo! Dopo aver saputo dell’esistenza dell’errore potremmo includere un test aggiuntivo per garantire che anche i bonifici bancari di R$17,99 possano essere effettuati:

Qui possiamo mettere in azione il famoso ciclo TDD (Test Driven Development): Red, Green, Refactor.

Questo test fallisce (RED), e poi possiamo correggere il problema finché il test non passa (GREEN). E ora, avendo il test come rete di sicurezza possiamo alterare il codice per renderlo più leggibile senza paura di rompere nulla (REFACTOR).

Il test fallisce perché il saldo rimanente era R$2,02 e non R$2,01

Fatto! Ora quando faremo passare questo test garantiremo che i trasferimenti di R$17,99 funzioneranno perfettamente. Ma alcune domande rimangono:

• Il trasferimento di R$32,23 funzionerà?

• E se ci sono altri valori che generano lo stesso errore?

• E se ci sono valori che generano un errore diverso?

• Come possiamo impedire che problemi come questo raggiungano i nostri clienti?

Ed è qui che entra in gioco il PBT — Property Based Testing, ovvero Test Basati su Proprietà.

PBT: pulire dove i test convenzionali non arrivano

È piuttosto semplice scrivere il test dei R$17,99 dopo che sappiamo dell’esistenza dell’errore.

Quello che succede è che scriviamo test con casi che già abbiamo in mente, in modo molto lineare e specifico. Ma il test è così specifico che testa solo un caso. E se il problema continua a verificarsi con trasferimenti di altri valori?

In questo caso, il problema è apparso solo quando si è provato a trasferire R$6,05

Ma… come potremmo identificare valori problematici prima ancora di sapere del problema? È qui che entrano in gioco i test basati su proprietà.

Lavorare con le proprietà significa non pensare a casi specifici, ma piuttosto alle caratteristiche di ogni variabile coinvolta nel test. In questo caso, possiamo dire che:

• Il saldo iniziale di chi sta per trasferire il denaro può essere qualsiasi valore maggiore di zero.

• Il valore del trasferimento è maggiore di zero e minore o uguale al saldo disponibile.

Per sapere se il trasferimento è stato fatto con i valori corretti, basta “verificare il nostro lavoro”, come facevamo alle elementari. :)

Valore trasferito + Saldo rimanente = Saldo prima del trasferimento

Quando definiamo le regole in questo modo, gli strumenti di test automatizzati sono in grado di validare diversi casi differenti. E molte volte questi “casi diversi” finiscono per includere situazioni che non abbiamo mai nemmeno immaginato, e quindi non scriveremmo mai un test convenzionale su di esse.

Ora, eseguendo i test scopriamo che ci sono altri valori che generano anch’essi l’errore:

Ops! Se ho R$0,98 e provo a trasferire R$0,71 il problema si verifica anche!

Ah! Nota che la libreria di test dice: Counter example stored.

Le librerie PBT di solito memorizzano i valori che hanno generato errori e li usano di nuovo finché il problema non viene risolto. Cioè, quando il test passa è perché il problema è stato risolto, e non perché la libreria ha selezionato solo valori per i quali il problema non si verifica.

Ok, ma cosa c’entra questo con l’agilità?

Beh, l’agilità è la capacità di cambiare e generare risultati rapidamente.

È come essere in un’auto da corsa su una pista tortuosa: per fare curve velocemente e senza perdere molta velocità avrai bisogno di un veicolo solido e ben costruito. Senza di esso, sei limitato a due opzioni:

• Fare la curva moooolto lentamente per assicurarti che il veicolo non si rompa

• Fare la curva velocemente e smontare il tuo veicolo

Esempio:

Immagina che la banca decidesse di permettere conti in Bitcoin. Dovrebbero ora lavorare con una valuta che ha molti più di due decimali.

Ora immagina che la banca possa avere un’applicazione che:

a) Non ha test automatizzati

b) Ha alcuni test automatizzati

c) Ha test automatizzati convenzionali e alcuni che usano PBT

In quale scenario la banca sarebbe in grado di avere un prodotto funzionante in produzione più rapidamente?

In sintesi: Non c’è agilità senza eccellenza tecnica.

Codice Sorgente e considerazioni finali

Ho scritto il codice per generare l’errore di proposito e quindi illustrare come una certa tecnica potrebbe aiutare a risolvere un problema.

Se sei curioso, il codice usato in questo post è disponibile su: https://github.com/mariomelo/post_pbt

Scrum is simple to understand, but difficult to master

- Scrum Guide, versione 2017

In altre parole, c’è un universo di distanza tra capire Scrum e padroneggiarlo davvero. Ed è lì che sta il pericolo: questa distanza è l’habitat perfetto per le vittime dell’effetto Dunning-Kruger.

Immagine creata da www.investificar.com.br

Da Wikipedia: L’effetto Dunning-Kruger è una distorsione cognitiva a causa della quale individui poco esperti in un campo tendono a sopravvalutare le proprie abilità autovalutandosi, a torto, esperti in quel campo.

Detto questo, andiamo alle tre fake news!

1 — Il problema di Scrum è che è troppo semplice

Scrum è un framework, ma è comune sentire persone riferirsi a Scrum come una metodologia. Può sembrare pignoleria, ma questo semplice scambio di parole dice molto sulla comprensione di Scrum.

Dopotutto, cos’è un framework? Beh, secondo il dizionario Cambridge:

A supporting structure around which something can be built

- Dizionario Cambridge

Scrum è una struttura sulla quale dovresti costruire il tuo modo di lavorare. È come Ruby on Rails, ExpressJS o Hibernate: non funzionano da soli, ma ti aiutano a lavorare in modo più strutturato e produttivo.

I framework sono incompleti per default e di proposito. Sono creati affinché tu possa pensare ed espanderli nel modo che ha più senso nel tuo contesto lavorativo. Ed è da lì che vengono le pratiche agili come Story Points, User Story Mapping, Prioritizzazione Rischio x Valore, User Stories, ecc.

Dato che Scrum implementa il ciclo PDCA, è possibile adottare una certa pratica agile, validare i suoi effetti e decidere se vale la pena continuare con quella pratica. E ovviamente, è necessario sperimentare nuove idee e ripetere questa riflessione alla fine di ogni Sprint.

In sintesi:

Scrum è semplice e incompleto di proposito per farti pensare a modi per completarlo.

Se qualcuno ti dice che il problema di Scrum è essere troppo semplice, questa persona non ha ancora capito nulla del framework.

2 — Management 3.0 e DevOps sono arrivati per sostituire Scrum

In Brasile abbiamo un’espressione comunemente usata quando qualcuno dice qualcosa del genere:

COSA??? — Traduzione: scusa, cosa hai appena detto?

Questa affermazione non ha senso se hai già capito il concetto di framework: Management 3.0 e DevOps arrivano per completare, non per sostituire.

Dopotutto, lo Scrum Guide dice:

Gli Scrum Team sono cross-funzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint.

- Scrum Guide

Sì, Scrum non parla di automatizzare i deploy, per esempio. Non parla di feedback wrap, delegation board o motivatori intrinseci.

Perché Scrum è un… framework!

Credo che questa rappresentazione visiva usata da Alexandre Magno nelle sue sessioni di formazione illustri molto bene questa idea.

Rappresentazione del framework Scrum completato da tecniche emergenti, creata da Alexandre Magno

3 — Non abbiamo più team Scrum. Abbiamo Squad.

Questa è piuttosto interessante, e l’ho aggiunta qui perché vedo sempre più organizzazioni usare termini del famoso modello Spotify. E spesso la giustificazione è che i team sono multidisciplinari e non segmentati per aree di conoscenza.

Ma, cosa dice lo Scrum Guide del suo Scrum Team?

• Gli Scrum Team sono cross-funzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint.

• All’interno di uno Scrum Team, non ci sono sotto-team o gerarchie. È un’unità coesa di professionisti focalizzati su un obiettivo alla volta, il Product Goal.

Il concetto di Squad è nato in modo collaborativo a Spotify ed è stato parzialmente documentato nel 2012 in questo pdf da Henrik Kniberg e Anders Ivarsson. Nel documento, disponibile a questo link, dicono:

A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working.

Vale sempre la pena riflettere sul modello adottato dall’organizzazione:

• Il tuo Scrum Team ha le caratteristiche menzionate nello Scrum Guide?

• La tua organizzazione fornisce l’ambiente necessario per l’esistenza di Squad/Scrum Team?

• Quale problema viene affrontato con l’adozione degli Squad?

• Cosa differenzia il tuo Squad da uno Scrum Team?

Gli Squad hanno avuto senso nel contesto di scaling di Spotify, e potrebbero anche essere compatibili con la tua organizzazione. Ma è essenziale capire quali problemi Scrum e il “Modello Spotify” cercano di risolvere prima di fare un CTRL+C / CTRL+V.

Alla fine della giornata, la disinformazione esisterà sempre e alla fine le persone possono diffonderla anche con le migliori intenzioni. L’unico modo che conosco per evitare queste trappole è seguire il consiglio del saggio filosofo E.T. Bilu:

E.T. Bilu leggerebbe lo Scrum Guide prima di iniziare a usare Scrum

Allora, ci prendiamo un po’ di tempo per rileggere le 16 pagine dello Scrum Guide?

Beh, e questo è il problema. La prioritizzazione basata su opinioni (che di solito hanno un peso proporzionale al peso del badge di chi sta opinando). Quando in qualche modo riusciamo a rendere tangibile il valore di ogni elemento nel nostro Product Backlog, la discussione diventa molto più razionale.

Un modo per capire meglio il valore di ogni funzionalità viene attraverso una semplice domanda: quanto stiamo perdendo per non aver ancora consegnato questo elemento?

Rispondere a questa domanda non è sempre facile, e spesso implica molto lavoro di ricerca. L’importante è ricordare sempre che non stiamo sempre cercando informazioni super precise qui. Lo scopo di comprendere il valore di ogni elemento è aiutarci a prendere una decisione razionale.

Per esempio: diciamo che un certo elemento mi farà guadagnare tra $6.000 e $40.000. Questo intervallo è molto ampio e può sembrare avere poco valore, ma se so che il costo dell’elemento non dovrebbe superare $3.000, posso già prendere una decisione e non ho bisogno di investire più tempo a raffinare la mia ricerca per restringere questo intervallo.

Ogni elemento può avere un costo di ritardo in un formato diverso: alcuni tendono a crescere linearmente e altri esponenzialmente. Ci sono anche quelli con una data fissa, come la conformità a una legge con una data di entrata in vigore, e altri il cui costo non ha una relazione così rilevante con il tempo di ritardo. Capire quali tipi di elementi hai nel tuo Product Backlog è il primo passo per razionalizzare il tuo processo di prioritizzazione.

Il tipo di elemento più comune da trovare in un Product Backlog sono quelli il cui costo di ritardo tende ad aumentare nel tempo, sia linearmente che esponenzialmente. Immagina un prodotto con i seguenti elementi nel suo Product Backlog:

Ogni elemento ha un costo stimato per settimana di ritardo e un tempo di sviluppo stimato. Se dividiamo il costo di ritardo per la durata di ogni elemento, arriviamo al famoso CD3: Cost of Delay Divided by Duration (costo di ritardo diviso per la durata).

Ma perché questo CD3 è importante? Per rispondere a questa domanda, proviamo a prioritizzare questo backlog in tre modi diversi.

Prioritizzazione per dimensione

Se scegliamo di consegnare prima gli elementi più piccoli, la nostra curva di consegna sarebbe più o meno così:

Nella prima settimana avremmo un costo di ritardo equivalente a tutti gli elementi sommati (2.000 + 5.000 + 6.000 + 1.500), dopotutto non abbiamo consegnato nulla.

Alla fine della settimana 1 siamo riusciti a consegnare l’elemento Notifiche (che è stato prioritizzato per avere la durata più breve) e con ciò abbiamo ridotto il nostro costo totale di ritardo di 2.000. E poi ripetiamo questo processo per i prossimi elementi nel Product Backlog.

Alla fine, abbiamo il seguente scenario:

• 1 settimana con costo totale di ritardo di 14.500

• 2 settimane con costo totale di ritardo di 12.500

• 3 settimane con costo totale di ritardo di 11.000

• 4 settimane con costo totale di ritardo di 6.000

In questo scenario il nostro costo totale di ritardo è stato:

(1 x 14.500) + (2 x 12.500) + (3 x 11.000) + (4 x 6.000) = 96.500

Prioritizzazione per valore

Quando prioritizziamo per valore, le cose cambiano un po’:

• 4 settimane con costo totale di ritardo di 14.500

• 3 settimane con costo totale di ritardo di 8.500

• 1 settimana con costo totale di ritardo di 3.500

• 2 settimane con costo totale di ritardo di 1.500

In questo scenario iniziamo a lavorare con l’elemento APP perché ha il più alto costo di ritardo per settimana. Alla fine abbiamo un costo totale di ritardo di:

(4 x 14.500) + (3 x 8.500) + (1 x 3.500) + (2 x 1.500) = 90.000

Prioritizzazione per CD3

La prioritizzazione per valore ha generato un risultato leggermente migliore, ma abbiamo ancora margine di miglioramento. Guarda cosa succede quando prioritizziamo per CD3:

• 1 settimana con costo totale di ritardo di 14.500

• 3 settimane con costo totale di ritardo di 12.500

• 4 settimane con costo totale di ritardo di 7.500

• 2 settimane con costo totale di ritardo di 1.500

(1 x 14.500) + (3 x 12.500) + (4 x 7.500) + (2 x 1.500) = 85.000

Una buona riduzione, vero? E un ottimo esempio di come una persona che agisce come Product Owner può avere un impatto molto positivo sullo sviluppo del prodotto!

Conclusione

Sapere come prioritizzare bene è importante, e per farlo avrai sempre bisogno di avere una buona comprensione del valore di ogni elemento nel tuo Product Backlog.

Formule come il calcolo del CD3 possono aiutare molto una volta che hai fatto il primo passo: avere questo senso del valore. Ma questo primo passo dipende molto dalla vicinanza del Product Owner al mercato e da una buona comprensione dei problemi dei clienti. E beh, non c’è una formula magica per questo. :)

Un modo semplice per farlo è avere criteri chiave in modo che il team possa valutare qualitativamente lo Sprint appena concluso. Ma quali criteri chiave dovremmo usare?

Daniel Pink definisce attraverso esperimenti nel suo libro Drive che l’Autonomia è uno dei tre pilastri che sostengono la motivazione delle persone sul lavoro. Possiamo sfruttare questo concetto per creare un modello di retrospettiva più partecipativa in 4 passi:

1 — Chiedi al team di pensare a criteri chiave

Imposta un breve limite di tempo e scrivi insieme al team quali fattori influenzano la qualità del lavoro del team.

Ricorda che la partecipazione di tutto il team Scrum è fondamentale durante tutte le fasi.

2 — Limita i criteri chiave

Puoi usare il dot voting per limitare i criteri chiave che verranno utilizzati se necessario. L’ideale è avere tra 5 e 10 criteri alla fine di questa fase.

Importante: Puoi scegliere di unire 2 o più temi se sono molto simili, ricordati solo di farlo prima della votazione.

3 — Chiedi a ogni membro del team di valutare l’ultimo Sprint secondo i criteri più votati

Qui non dobbiamo fare un’analisi super dettagliata. Possiamo usare 3 livelli di soddisfazione, come un semaforo.

Esempio: Una persona può votare verde per il criterio Interruzioni se crede di essere stata raramente interrotta nello Sprint passato.

Fai solo attenzione a due dettagli: assicurati che nessuno nel team abbia difficoltà a distinguere i colori selezionati e garantisci che tutti i membri abbiano valutato tutti i criteri eletti.

4 — Valuta con il team l’evoluzione attraverso gli Sprint

Uno dei principali benefici di questa tecnica è poter dibattere con il team cosa ha influenzato la valutazione di ogni criterio, e avere una piccola cronologia può aiutare molto a percepire alcune tendenze e possibili correlazioni.

Guardare una valutazione congiunta di criteri che il team stesso ha stabilito è un ottimo modo per rompere il ghiaccio iniziale di una retrospettiva.

Questa può essere la spinta iniziale di cui il team ha bisogno per iniziare a proporre azioni ed esperimenti con il potenziale di migliorare il loro modo di lavorare.

Avevo appena finito di spiegare l’origine del Manifesto Agile e avevo elaborato un po’ su cosa è successo dopo quando uno studente mi ha bombardato con la domanda:

Secondo te, quali sono le direzioni future dell’agilità da ora in poi?

In quel momento ho cercato di ripercorrere il cammino che abbiamo fatto finora, e il dibattito che ne è seguito è iniziato con un’analisi di questo percorso per identificare indizi che potessero aiutarmi a delineare cosa ci aspetta.

La mia interpretazione dell’illustrazione di Pierre Hervouet sulla storia del Manifesto Agile e cosa è venuto dopo

Se tutto è iniziato nello sviluppo software, come siamo arrivati dove siamo?

Mi sono fatto questa domanda migliaia di volte. E ho visto molte persone arrabbiate perché oggi abbiamo molti agilisti che non hanno mai scritto una riga di codice in vita loro. Beh, confesso che mi sono arrabbiato anche io per questo.

Ma non più.

C’è stato un tempo in cui era necessario convincere le persone che investire tempo nei test automatizzati era effettivamente una buona idea.

Ed era difficile, molto difficile.

Server di integrazione continua, deploy automatizzati, documentazione snella… Tutti questi concetti hanno affrontato una forte resistenza per un bel po’. Ed è lì che gli agilisti investivano la maggior parte del loro tempo e sforzo: al fianco degli sviluppatori, aiutandoli a creare meccanismi per ridurre il dolore causato dai cambiamenti nelle specifiche del software.

Ma a un certo punto qualcosa è cambiato.

Forse il mercato stesso ha eliminato le aziende che non sono riuscite ad adattarsi alle buone pratiche di sviluppo software, o forse internet e i social network hanno aiutato a sensibilizzare sull’importanza dell’eccellenza tecnica e dell’automazione dei compiti più soggetti all’errore umano.

Questa transizione ha portato alla luce una nuova gamma di sfide. Fondamentalmente, se Wagner Moura fosse un agilista questo sarebbe il momento in cui migrerebbe dal film Tropa de Elite a Tropa de Elite 2, realizzando che il nemico ora è un altro.

E chi è questo nuovo nemico?

Questa è la domanda da un milione di dollari. In realtà, la risposta a questa domanda di solito vale molto di più.

I nuovi problemi organizzativi non sono così espliciti e standardizzati come quelli che avevamo a livello operativo. Non abbiamo più una ricetta che possa essere prescritta per risolvere questi problemi e dobbiamo analizzare caso per caso.

Ecco perché lo Scrum Guide che una volta aveva 19 pagine e raccomandava strumenti specifici per tracciare ogni ciclo è diventato solo 13 pagine, di cui 5 parlano esclusivamente della teoria e dei concetti principali del framework.

L’automedicazione senza una diagnosi può generare effetti collaterali peggiori dei sintomi stessi. E questo diventa più vero ad ogni passo che l’agilità fa verso l’ignoto.

Ma allora posso dimenticare la parte operativa?

Non tutte le organizzazioni sono effettivamente riuscite a lasciare il primo “Tropa de Elite”. Ma anche queste possono già visualizzare i prossimi possibili problemi se valutano scenari già esplorati da altre organizzazioni. Allora è necessario lavorare con “un occhio al pesce e un occhio al gatto”.

In fondo, l’agilità cerca di migliorare il sistema organizzativo. Tutto è iniziato nella parte più operativa, ma gradualmente abbiamo scoperto che per cambiare il sistema avremmo dovuto lavorare anche in aree più lontane dallo sviluppo software.

E come direbbe Wagner Moura, il sistema è… difficile.

Ps: Solo per chiarire: non abbiamo davvero nemici, ed era solo un modo di dire. :)

Se hai scaricato o comprato Scrumchkin, potresti volere un aiuto per ottenere il massimo dalle tue sessioni. E anche se c’è una Guida alle Istruzioni disponibile, questo post vuole essere una guida del tipo “leggi mentre giochi” così non devi memorizzare tutto.

Definire i Ruoli

Ok, abbiamo bisogno di almeno 5 persone. Massimo 9. Inoltre, ci servono uno ScrumMaster e un Product Owner.

Spesso chiedo a tutti di puntare le dita verso l’alto, contare fino a tre e chiedere loro di indicare lo ScrumMaster. E poi ripetere il processo per definire il Product Owner. È divertente e evitiamo di perdere tempo a discutere chi dovrebbe assumere il ruolo.

Se ci sono persone che sono veri ScrumMaster e Product Owner, suggerisco loro di vivere nuove esperienze durante il gioco. Anche se può sembrare illogico all’inizio, essere in un ruolo diverso aiuta a creare empatia tra i membri del team e favorisce una comprensione più ampia dell’intero flusso.

Lo ScrumMaster

Lo ScrumMaster può eseguire le seguenti azioni:

• Pescare una carta

• Dare una carta

• Prendere una carta da un membro del Dev Team e darla a qualcun altro

• Rimuovere un Impedimento

Il Product Owner

Il Product Owner può eseguire le seguenti azioni:

• Scoprire una nuova Feature

• Rivelare il Business Value di una Feature

• Riordinare il Backlog

• Raccogliere feedback dai clienti

Il Dev Team

I membri del Dev Team possono eseguire le seguenti azioni:

• Pescare una carta

• Giocare una carta

• Stimare una Feature

Scoprire il Product Backlog iniziale

Il Product Backlog iniziale consiste in 5 Feature. Le prime 2 sono sia stimate che hanno il loro Business Value scoperto. La terza è solo stimata.

Ecco come appare un Product Backlog iniziale in Scrumchkin

Ti suggerisco di lasciare che il Product Owner riveli le carte delle feature e le carte del Business Value mentre un membro del Dev Team rivela le carte Size, dato che questo aiuta a inserirli nel mondo del gioco.

Dopo aver fatto alcune sessioni, potresti voler provare alcune modifiche e variazioni.

Impegnarsi per uno Sprint Backlog

Uno Sprint dura 5 giorni, e durante ogni giorno ogni giocatore può eseguire due azioni. Ci sono carte Work numerate come 1, 2 e 3 punti Work. E queste sono tutte le informazioni che avranno per definire il loro primo Sprint Backlog.

Alla fine dello Sprint, alcune carte feedback potrebbero apparire sul tavolo, secondo la seguente formula:

Feature Consegnate meno Feature Non Consegnate

Non preoccuparti, torneremo alle Carte Feature più tardi.

Dopo che il team decide cosa c’è nel loro Sprint Backlog, prendono le carte e le separano dal Product Backlog.

Eseguire lo Sprint

Non c’è un ordine di turno.

Non c’è nulla che vieti ai giocatori di mostrare le loro carte agli altri.

Non c’è una regola che dice di giocare due azioni di fila.

Sai perché? Sono un team auto-organizzato. E come facilitatore vedrai questo processo accadere continuamente. Se hai un occhio attento, sarai in grado di fare domande molto potenti sul loro comportamento e sulle loro decisioni.

I dubbi sulle regole e sulle decisioni del team sono ottimi spunti di conversazione. E le conversazioni sono il punto di questo gioco, non aver paura di interrompere il gioco e iniziarle.

Un giorno finisce quando tutti hanno giocato le loro 2 azioni. Lo Sprint finisce dopo 5 giorni.

Se il team è riuscito a consegnare tutte le feature pianificate, puoi lasciare che il Product Owner o il Dev Team spendano 2 azioni per spostare la prima Feature del Product Backlog nello Sprint Backlog.

Le carte arancioni sono istantanee. Vengono giocate nel momento in cui qualcuno le pesca, e conta come una singola azione.

I Bug sono fastidiosi. Inoltre, URGENTE!

I Bug hanno la precedenza su qualsiasi feature. Sono bloccanti e mentre c’è un bug sul tavolo, nessuno può lavorare su nient’altro.

Il Technical Debt resta sul tavolo e influenza ogni feature. Il team deve decidere quando è il momento giusto per affrontare il Technical Debt e rimuoverlo dal tavolo.

I Sick Day sono in realtà Sick Week. Chiunque peschi questa carta non può eseguire alcuna azione fino alla fine dello Sprint corrente.

Gli Impedimenti sono bloccanti totali. Nessuno può fare nulla finché lo ScrumMaster non lo rimuove dal tavolo.

Ma ehi, abbiamo anche carte buone! Ci sono due carte che restano sul tavolo e sono cumulative:

I Bug, come ogni famoso cattivo, hanno la loro kryptonite

Gli Automated Tests rendono ogni correzione di bug un po’ più semplice. Man mano che queste carte iniziano a occupare spazio sul tavolo, il team inizia a raccogliere i benefici del miglioramento continuo.

La Continuous Integration aiuta il team a eliminare il Technical Debt. E man mano che il sistema di Continuous Integration migliora, migliora anche la facilità di eliminare questo fastidioso Technical Debt.

Tuttavia, queste carte verdi non sono gratuite. Devi spendere un’azione per giocarle. Ha senso, no? Come nella vita reale, Automated Tests e Continuous Integration non cadono dal cielo (anche se spesso girano nel cloud!).

Raccogliere Feedback

Dopo la fine dello Sprint, il facilitatore fa un semplice calcolo:

Feature Consegnate meno Feature Non Consegnate

Questo è il numero di Carte Feedback che saranno disponibili per il Product Owner durante il prossimo Sprint.

Ci sono anche Carte Feedback buone, lo prometto

Le carte feedback non vengono rivelate subito; il Product Owner deve spendere un’azione per raccogliere ogni Carta Feedback.

Le Carte Feedback restano sul tavolo e influenzano il Business Value di certe feature. Probabilmente avranno un impatto sulla prioritizzazione del Product Backlog, il che di conseguenza darà del lavoro al Product Owner.

Consiglio pro: Come facilitatore, potresti voler scegliere quale Carta Feedback dare al Product Owner, dato che alcune avranno più impatto e quindi inizieranno dibattiti più ricchi.

Fine del Gioco

Scrumchkin non finisce. Tutti vincono se hanno imparato qualcosa divertendosi, e tutti perdono se qualche amicizia è stata rovinata durante il processo.

L’arte non è mai finita, solo abbandonata.

Leonardo da Vinci

Il facilitatore deve percepire quando il gioco diventa più meccanico e meno rumoroso. È lì che finisce. Nella mia esperienza, la maggior parte dei gruppi raggiunge quel punto da qualche parte durante il 3° Sprint, ma questa non è assolutamente una regola.

È bello spendere 20 minuti facendo un piccolo debriefing così tutti possono condividere i loro insight e idee di esperimenti da fare nella vita reale.

A proposito, hai provato il Debriefing Cube?

Questo è tutto! Scriverò alcuni post di “livello Ra” nelle prossime settimane.

Buon gioco!

Scrumchkin Instruction Guide — Shu Level è stato originariamente pubblicato in Scrumchkin su Medium, dove le persone continuano la conversazione evidenziando e rispondendo a questa storia.