Guarda il video del meetup

[This post contains video, click to play]

Un esperimento in diretta: AI e sviluppo software in tempo reale

In questo meetup dell’Agile Community Torino, abbiamo esplorato un tema che sta rivoluzionando il modo di progettare e costruire prodotti digitali: l’intelligenza artificiale generativa applicata allo sviluppo software.
Abbiamo ospitato Tech Reloaded, rappresentata dai due speaker Stefano Marello e Stefano Leli, che ci hanno guidato in un viaggio tra teoria e pratica, mostrando come l’AI possa diventare un alleato potente, ma non privo di rischi.

La serata si è aperta con un’introduzione di Daniel Palmisano, che ha presentato l’esperimento live: mentre Leli raccontava il processo, Marello sviluppava in tempo reale una nuova funzionalità per Raid Atlas, un prodotto nato proprio per testare il potenziale del Vibe Coding.

Cos’è il Vibe Coding?

Il termine Vibe Coding è un approccio allo sviluppo software che consiste nel descrivere ciò che si desidera in linguaggio naturale e lasciare che l’intelligenza artificiale generi il codice necessario.
Per essere veramente efficace, abbiamo visto come il Vibe Coding richieda:

• Agenti AI specializzati (product manager, architetti, sviluppatori, tester)
• Automazione avanzata (IDE potenziati, agenti su linea di comando, server MCP)
• Supervisione umana costante

L’obiettivo? Costruire un flusso end-to-end che parte dalla raccolta dei bisogni utente e arriva fino alla messa in produzione, mantenendo sempre il man-in-the-loop: l’essere umano come guida e validatore.

Il caso Raid Atlas

Raid Atlas è una piattaforma pensata per motociclisti, che permette di creare, vendere e acquistare itinerari di viaggio. Leli ci ha raccontato che alla base del progetto ci sono state quattro fasi fondamentali:

1. Ideazione e pianificazione (con interviste agli utenti tramite agenti AI e creazione di roadmap e PRD)
2. Design e prototipazione (mockup su Miro e conversione in componenti React tramite Figma Make)
3. Setup degli ambienti (con regole, boilerplate e CI/CD su Vercel)
4. Sviluppo (creazione task tecnici, sviluppo e test automatici).

Contemporaneamente, Marello ha implementato in diretta una nuova funzionalità: i commenti sui viaggi.  Un’idea nata spontaneamente dal pubblico, è stata implementata in tempo reale con il supporto dell’AI, in appena trenta minuti (“un pomodoro”).

Pregi e limiti dell’AI nello sviluppo

Pregi:

• Accelerazione drastica dei tempi
• Supporto su tecnologie non conosciute
• Crescita professionale per junior e senior
• Collaborazione cross-funzionale facilitata

Limiti:

• Allucinazioni e inventiva non controllata
• Memoria corta e perdita di contesto
• Tendenza a “barare” nei test
• Rischio di mettere in produzione codice non validato

Un codice etico per il Vibe Coder

I relatori hanno proposto quattro principi guida per chi lavora con l’AI nello sviluppo:

1. Responsabilità: il codice in produzione è sempre responsabilità umana
2. Comprensione : non si mette in produzione ciò che non si comprende
3. Qualità: non ci sono più scuse per codice scadente
4. Guida: l’AI è un amplificatore, non un sostituto

Domande e riflessioni

Il meetup si è concluso con un vivace scambio di domande, tra cui:

• Come integrare il TDD con l’AI?
• Quali strumenti usare per requisiti, test e sviluppo?
• Come si addestrano gli agenti AI?
• Qual è il ruolo del designer in questo processo?

La risposta più potente è arrivata dalla conversazione: “Il man-in-the-loop oggi è la garanzia che l’AI non sostituisce l’essere umano, ma lo affianca. E questo è ciò che rende il processo sostenibile e professionale.”

Daniel

Appassionato, volenteroso e super addicted di Lean e Agile, amo credere che cambieremo il mondo con la sola forza del pensiero! 🙂

More Posts

Follow Me:

L'articolo Vibe Coding: AI generativa e sviluppo prodotto, tra accelerazione e supervisione proviene da Agile Community Torino.

Partendo dallo Scrum Expansion Pack, una proposta aperta disponibile su scrumexpansion.org, abbiamo discusso insieme di come il framework si stia adattando alle nuove sfide che team e organizzazioni incontrano ogni giorno.

Una board, tante prospettive

Come spesso accade nei nostri incontri, la conversazione è stata arricchita dal contributo di tutti i partecipanti. Su una board Miro condivisa abbiamo raccolto spunti, osservazioni ed esperienze dirette. Ci siamo soffermati in particolare su alcuni aspetti che abbiamo trovato interessanti:

• Focus sul prodotto e product goals, discovery, team auto organizzati e professionalità

• Agenti AI come tool utili al lavoro ma anche come product developer facenti parte del team

• Nuove accountabilities come supporter stakeholder

• Validation del valore da realizzare: usability, desirability, viability

• People are not resources!

Il risultato è stato un mosaico di punti di vista che ha reso evidente come Scrum non sia mai statico, ma una pratica viva che evolve insieme alle comunità che la utilizzano.

Cosa ci portiamo a casa

La serata ci ha lasciato alcune riflessioni importanti:

• Scrum come base solida, ma non intoccabile: i principi restano, le pratiche si adattano.

• Sperimentare è fondamentale: solo provando sul campo nuove idee possiamo capire se generano reale valore.

• Il confronto comunitario arricchisce: ascoltare esperienze diverse ci aiuta a vedere opportunità che da soli non coglieremmo.

E adesso?

L’invito per tutti è continuare a sperimentare, leggere e contribuire allo Expansion Pack, e portare poi in community le esperienze vissute.

La conversazione è aperta: probabilmente faremo un follow-up di questo meetup per arricchire ed evolvere la conversazione. Stay tuned!

Daniel

Appassionato, volenteroso e super addicted di Lean e Agile, amo credere che cambieremo il mondo con la sola forza del pensiero!

More Posts

Follow Me:

L'articolo Scrum Reloaded: una conversazione sull’evoluzione di Scrum proviene da Agile Community Torino.

Il mindset Agile si basa molto sulla collaborazione: collaborazione fra cliente e fornitore, fra Leader e Operators, fra membri dello stesso team.

Nel 1999 Kent Beck pubblicò il suo famoso libro “Extreme Programming Explained” nel quale parlava (e si parla tutt’oggi) di tecniche di sviluppo e organizzazione di persone per generare software di qualità superiore in modo più produttivo.

Due di queste tecniche sono il pair programming e la scrittura di test (sia automatici sia di accettazione) prima della scrittura del codice (test first).

Con l’ottima facilitazione di Stefano Marello abbiamo provato ad “unire ed estremizzare” questi due principi in una sessione di Mob o Ensemble Programming.

In cosa consiste? Quali sono le regole e i ruoli?

“Ensemble Programming” significa qualcosa del tipo “Programmazione d’insieme” e la tecnica consiste nel far lavorare un intero team sulla stessa cosa, nello stesso tempo, nello stesso posto, sullo stesso computer (da cui anche “Software Teaming”).

Sono previsti due ruoli:

• Un Navigator che colloquia con l’intero team per trovare la migliore soluzione possibile al problema.
• Un Driver che è colui/colei che è fisicamente alla tastiera e traduce le richieste del Navigator in codice implementando TDD (Test-Driven-Development).

Durante la sessione i volontari che hanno partecipato attivamente, a turno hanno assunto entrambi i ruoli, e ogni 10 minuti (tempo arbitrariamente deciso) la persona che faceva da Navigator diventava Driver, mentre il Driver tornava ad essere un membro del team.

Sembra uno spreco di tempo avere un intero team concentrato su un unico problema? In realtà l’obiettivo pratico delle sessioni di ensemble programming è concludere il task descritto nella storia fornita dal Product Owner riducendo il tempo di rilascio e realizzando codice molto più robusto.

Ma entriamo nel dettaglio della serata.

Una quindicina di esperti e non si sono alternati nello sviluppo del Kata proposto da Stefano: è stato un… Kata-Christmas! Non è propriamente in tema carnascialesco ma è stato molto efficace.

Lo scopo era scrivere un software che seguisse le istruzioni di Babbo Natale per governare una griglia di 100×100 luci e creasse la sequenza di combinazioni vincente per aggiudicarsi la gara di giochi di luci più belli.

Stefano ha lasciato parola e tastiera agli ospiti che si sono cimentati in discussioni tecniche e filosofiche, come capita fra i migliori programmatori, per poi generare del codice seguendo le regole del TDD.

Fra una classe ed un metodo, fra uno unit test ed un commit siamo riusciti ad accendere qualche lampadina in tutti i sensi, sia quelle di Babbo Natale sia nelle nostre teste.

La parte più interessante dell’esperimento è stato vedere come l’intelligenza collettiva sfruttata tramite l’espressione di idee e di opinioni di gruppo senza alcun tipo di ostacolo o paura abbia generato un sano confronto che effettivamente si è tradotto in una soluzione da implementare.

Vi lascio con alcune delle domande che ci siamo posti pensando ai nostri ambienti di lavoro:

1. Quanto è applicabile nei nostri contesti lavorativi?
2. La pratica è davvero percepita come un modo per trovare la miglior soluzione facendo contemporaneamente un check sulla qualità del codice? Oppure è vista come qualcosa che blocca un intero team su un unico problema quando potremmo lavorare in parallelo su diversi task?
3. Come possiamo misurare l’impatto che possiamo avere in termini di:
   1. minor numero di bug
   2. facilità di refactoring
   3. riduzione del tempo di implementazione
   4. condivisione di conoscenze

Probabilmente le risposte sono demandate ai Manager e alla loro capacità di comprensione e di lungimiranza.

Io da parte mia mi sono divertito e ho trovato l’argomento molto interessante.

Ma soprattutto si saranno divertiti coloro i quali hanno continuato a chiacchierare al di fuori del meeting davanti ad un buon cocktail.

Se sei interessato al dojo dai un’occhiata alle slide proiettate durante la serata e non esitare a contattarci!

Coding_Dojo_Intro.pdf

Alla prossima!

Nicola

More Posts

Follow Me:

L'articolo Coding Dojo: sperimentiamo il Mob Programming proviene da Agile Community Torino.

Nel nostro ultimo meetup di 2024, il 10 dicembre da Talent Garden Torino, abbiamo chiuso in bellezza con il nostro buon Stefano Marello che ha portato ai partecipanti un mix and match di due approcci chiave che sono le User Stories e il framework Jobs to Be Done (JTBD). 

Il primo passo per comprendere questi approcci è analizzare la triade fondamentale:

Utente + Bisogno + Outcome

Ricordiamoci che ogni prodotto servizio che creiamo (o aiutiamo a creare) ha la responsabilità di soddisfare un bisogno specifico. Ma qui entra una discussione importante: quanto è cruciale mettere in evidenza (e perciò approfondire) l’utente? Quanto questo elemento, che abbiamo già stabilito essere cruciale, può variare a seconda della complessità del contesto e degli attori coinvolti? 

Già nel 2010, alcune aziende come Intercom hanno sollevato dubbi sull’utilizzo delle User Stories e sul fatto che mettere l’utente di riferimento al centro del requisito non portasse vantaggi concreti.

Sebbene le Personas siano strumenti utili per rappresentare gli utenti, esse creano profili immaginari piuttosto che reali. Ed è qui il punto che vogliamo focalizzare perché questo ci porta a interrogarci sul legame tra le personas e gli utenti reali.

Non sempre le sfumature delle Personas influenzano direttamente i bisogni fondamentali degli utenti. 

L’esempio che abbiamo utilizzato all’inizio era la necessità di proteggere un account. Il bisogno di base rimane costante, ma le modalità di soddisfacimento possono variare. Ma il bisogno è sempre quello, indipendentemente a quale Personas ci rivolgiamo.

Proviamo ora a guardare da un’altra prospettiva, evidenziando un secondo framework: Jobs to Be Done (JTBD), sviluppato da Clayton Christensen e approfondito da Alan Klement. Il JTBD si concentra sul contesto (sul contesto!) in cui si trova l’utente e sulle motivazioni che lo spingono ad utilizzare un prodotto o un servizio per soddisfare un bisogno specifico. In questo modo, il focus si sposta dalla persona all’attività da svolgere.

Quindi, perché non mettere tutti gli ingredienti in pentola per avere una visione molto più pratica dell’utente?

Ed è qui che nascono le Job Stories: una forma alternativa delle User Stories che incorporano elementi chiave del JTBD.  La struttura tipica di una Job Story è: “Quando [situazione], voglio [motivazione], così posso [risultato]”. Questo approccio consente di esplorare le esigenze degli utenti in modo più profondo e contestualizzato.

Quando Utilizzare User Stories o Job Stories

La scelta tra User Stories e Job Stories dipende dal contesto del progetto:

• User Stories: Utili quando gli utenti hanno bisogni distinti e variabili. Queste storie iniziano con “Come utente…” per mettere in risalto chi sta compiendo l’azione.
• Job Stories: Preferibili quando i bisogni degli utenti non differiscono significativamente. Qui, il focus è sul compito da svolgere piuttosto che sull’identità dell’utente.

E quindi, che approccio mi conviene utilizzare?

Immagina di mescolare User Stories e Job Stories all’interno dello stesso backlog di prodotto. Questo ti permette di avere una visione più completa delle esigenze dei tuoi utenti.

È come avere il meglio di entrambi i mondi.

La cosa bella è che sia le User Stories che le Job Stories sono progettate per migliorare la comunicazione tra i team di sviluppo e gli utenti. Così, puoi essere sicuro che i prodotti finali rispondano davvero ai bisogni di chi li utilizza.

Si crea la possibilità di innovare in modo significativo e rispondere alle esigenze dei clienti in modo efficace. In sintesi, non sottovalutare il potere di queste tecniche, soprattutto quando messe insieme. Lascia che ti sorprendano!

Per visualizzare la presentazione completa, clicca qui.

Lays Felix

Con un background lavorativo in retail (9y), ho maturato diverse esperienze legate al business: dalla vendita alla performance, dall'expertise prodotto allo sviluppo di nuovi servizi. Nel 2023, ho iniziato ad utilizzare tutto il mio background per contribuire al percorso di trasformazione organizzativa. Durante gli anni, ho guidato diversi progetti in Italia ed all’estero, cooperando con team cross funzionali, interni ed esterni all’azienda. Oggi mi occupo di supportare il management strategico e operativo di Leroy Merlin Italia nella definizione e esecuzione della strategia.

More Posts

Follow Me:

L'articolo Quando l’User Story incontra il Job to be Done proviene da Agile Community Torino.

Oltre la definizione tradizionale di leadership

Il 3 ottobre 2024, al Talent Garden Fondazione Agnelli di Torino,  Alma del Campo Vara ci ha aiutato a riflettere su cosa sia davvero la leadership. Abbiamo iniziato sfidando l’idea che un leader sia necessariamente un individuo con potere politico o decisionale. Il dibattito ha toccato le varie forme di leadership che esistono in un’organizzazione, mostrando come un leader possa emergere in qualunque ruolo, non s olo da chi è in cima alla gerarchia. Questa parte ha messo in luce come la leadership possa essere vissuta da chiunque sappia influenzare positivamente il proprio contesto, dimostrando empatia, visione e capacità di ascolto.

Leader e follower: una relazione simbiotica

Uno dei concetti centrali del workshop è stata la relazione tra leader e follower. Alma ci ha chiesto se “un leader senza follower, è davvero un leader?” stimolando riflessioni interessanti. La discussione ha evidenziato l’importanza di saper creare un ambiente di fiducia e motivazione, un terreno fertile dove la collaborazione può crescere. Un leader non è tale se non riesce a ispirare chi lo circonda. Abbiamo esplorato le dinamiche tra leader e follower, mettendo in risalto l’importanza del coraggio e dell’orientamento al risultato.

Un leader di contesto

Infine, il workshop ha offerto strumenti di riflessione su quali stili di leadership siano più efficaci in contesti diversi. Ogni gruppo ha potuto esplorare una situazione diversa e approfondire quale approccio sarebbe stato migliore per il raggiungimento del risultato atteso.
Siamo stati invitati a riflettere sulle nostre esperienze di leadership, condividendo successi e difficoltà e creando un ambiente di apprendimento collettivo.

Abbiamo capito che la leadership non è solo una questione di potere e posizione, ma di responsabilità e influenza. Si tratta di creare un percorso di crescita personale e di lavorare costantemente sulle proprie abilità per ispirare e motivare chi ci circonda.

Stefano

More Posts

Follow Me:

L'articolo Leadership autentica: sviluppo, relazioni e impatto proviene da Agile Community Torino.

Quante volte abbiamo avuto esperienze negative nei team di lavoro e abbiamo faticato a migliorare la situazione?

Da oggi possiamo aggiungere uno strumento in più al nostro cassetto degli attrezzi grazie a CoLabo, il gioco in scatola “serious play” con il quale si possono organizzare workshop che facilitano la comunicazione e promuovono l’ascolto.

Abbiamo giocosamente affrontato problemi reali e molto comuni scoprendo alcune soluzioni vincenti per costruire un ambiente di lavoro sereno e collaborativo.

Si va in trasferta

Per la prima volta, la community ha organizzato un appuntamento “fuori sede” grazie alla preziosa collaborazione di Scrum Agile Milano e Talent Garden, che ha gentilmente messo a disposizione gli spazi di TAG Isola per il workshop.

L’evento si è tenuto il 7 marzo e ad accoglierci abbiamo trovato i creatori di CoLabo: Valerio Acerbis, Matteo Tortelli, Giulia Re e Alessandro Colla, tutti colleghi della Web Agency Evoluzione.

I ragazzi hanno preso le redini del workshop introducendo le meccaniche e l’obiettivo alla base del loro gioco: un’esperienza ludica che favorisca la comunicazione e la collaborazione all’interno di un gruppo di lavoro.

Inizia il gioco

Ci siamo divisi in tavoli da 4-5 giocatori e, dopo una breve introduzione, siamo subito entrati nel vivo e abbiamo iniziato a giocare.

Lo svolgimento è tanto semplice quanto efficace: CoLabo è un gioco collaborativo, ad ogni gruppo è chiesto di portare a termine i Progetti che verranno pescati durante la partita entro un certo numero massimo di round, chiamati Sprint.

Ogni Progetto completato, in base al grado di difficoltà, porterà una diversa quantità di punti al gruppo e l’obiettivo finale del team è raggiungere 20 punti prima della fine degli Sprint.

Come si completano i progetti?

Il gioco prevede due risorse fondamentali: l’Energia e l’Empatia. Ogni gruppo dovrà essere in grado di raccogliere e impiegare le risorse a disposizione collaborando e seguendo una strategia comune.

La strategia viene discussa e affinata al termine di ogni Sprint, dopo che tutti i giocatori hanno giocato il proprio turno, il momento della Retrospettiva.

Durante la Retrospettiva, il team può scambiarsi risorse e progetti per aiutarsi a vicenda e raccogliere più punti possibile.

Terminata la Retrospettiva, ricomincia un nuovo giro e quindi un nuovo Sprint.

Per aggiungere un po’ di pepe alle dinamiche di gioco, CoLabo prevede anche l’incursione di Problemi, atti a mettere i bastoni fra le ruote al team (es. l’impossibilità di parlare durante la Retrospettiva), ma anche delle carte “Comportamento Virtuoso” che i giocatori possono ottenere quando aiutano i compagni, le quali permettono di risolvere i Problemi pescati.

Il gioco si fa serio

CoLabo è divertentissimo, ma il valore che abbiamo tratto da questa esperienza va ben oltre il gioco in sé. Ogni carta da gioco, oltre alla sua funzione primaria, include anche degli esempi, delle situazioni, delle dinamiche che possiamo trovare nel lavoro quotidiano e qualche spunto di riflessione su come poter affrontare una situazione simile. 

Inoltre, le carte spesso includono dei mini giochi di ruolo che ricalcano un po’ le dinamiche raccontate, queste attività sono state importantissime per creare gruppo e anche momenti veramente esilaranti!

Chiusura e raccolta feedback

Dopo un’ora abbondante di divertimento, abbiamo concluso il workshop con una retrospettiva finale.

CoLabo è ancora in fase beta e i feedback raccolti sono stati tantissimi. È stato molto coinvolgente confrontarsi con i creatori sugli aspetti meglio riusciti e quelli da affinare per evolvere il gioco e renderlo ancora migliore.

La serata si è conclusa con un aperitivo in compagnia e un augurio a rivederci presto per altri fantastici appuntamenti!

Stefano

More Posts

Follow Me:

L'articolo CoLabo: coltiva un ambiente aziendale positivo proviene da Agile Community Torino.

• chi vuole qualcosa
• chi lo sa fare

Ma perché focalizzarsi sui requisiti? E’ così importante? Vediamo.

Anche all’interno dello sviluppo basato su metodologie agili non si è al riparo da problemi, errori, anomalie: backlog di 4+ anni, debito tecnico, incomprensione sullo scope e sui deliverable, mancanza di specifiche, numero eccessivo di test postumi allo sviluppo.

Quello che manca è un’attenzione specifica al comportamento (Behaviour!) del sistema: cioè ai suoi requisiti.

BDD è appunto un framework che si focalizza sulla definizione dei requisiti, ma in modo agile, cioè requisiti che cambieranno nel tempo e si adatteranno facilmente e velocemente ai nostri incrementi di prodotto!
E i test? I test sono un side effect, esattamente come il TDD è una tecnica di design e i test sono “solo” un sottoprodotto dell’attività di design. In BDD il requisito diventa un Acceptance Criteria scritto in modo formale. 

BDD si basa su tre principi:

1. Business Value
2. Tutto è un comportamento (requisiti funzionali e non funzionali: everything is a behaviour)
3. Enough is enough (fondamentale!)

e richiede che si lavori per iteration di prodotto: è fondamentale poter “affettare” il prodotto in deliverable distinti, che approfondiscono ed espandono il sistema iterazione dopo iterazione.

BDD ha molti formalismi, tra cui i più diffusi sono Spec e Gherkin.

Per calarci nel vivo della pratica, abbiamo ipotizzato di realizzare un diario alimentare, descritto secondo la tecnica dello User Story Mapping (dai uno sguardo alla sintesi di un nostro incontro sul tema).

Per realizzare il diario abbiamo previsto tre iterazioni (MVP 1, 2, 3). Possediamo già una definizione di enough: dobbiamo fermarci alla realizzazione delle User Stories dell’iterazione “MVP 1”: 1) Pagina di inserimento pasti; 2) Tabella pasti inseriti. Per cui nell’espressione dei requisiti (ovvero: comportamenti, acceptance criteria) in un linguaggio formale (Gherkin!) dobbiamo limitarci a questi due comportamenti, senza andare oltre.

Prima dell’esempio, specifichiamo a quale livello di comportamento stiamo operando. Ci sono infatti diverse profondità a cui si può arrivare a determinare il comportamento. Questo schema dovrebbe chiarire quante e quali sono. 

Nell’esempio parleremo solo di User Behaviour. Cominciamo! Affrontiamo il primo requisito espresso dalla user story “Inserimento nuovo pasto”. Nella formalizzazione BDD (useremo Gherkin) diventerà la funzionalità.

Alla funzionalità potremo associare una descrizione. Dopodiché espliciteremo gli scenari. Ciascuno scenario rappresenta compone un acceptance test scandito dagli step: given, when,  then:

• Dato un determinato fatto/contesto (given)
• Al verificarsi un determinato evento/azione (when)
• Deve succedere che (then)

Given: rappresenta gli step necessari affinché il sistema raggiunga lo status corretto per la verifica del test;

When: l’evento che deve avvenire per mezzo dell’utente per azionare la funzionalità in esame; è sempre un evento, si tratta di un’azione;

Then: descrive cosa avviene nel sistema e quali sono le reazioni apprezzabili da parte dell’applicazione;

Lo step che guida la costruzione dello scenario è il “then”, perché rappresenta il Business Value (uno dei tre principi del BDD) associato al requisito: è il perché del requisito, il suo valore, il suo scopo.

Non ci stupirà quindi leggere quindi una specifica del genere:

Funzionalità: Inserimento nuovo pasto

Descrizione:

come «persona a dieta»
voglio una pagina di inserimento del nuovo pasto
per poter inserire un nuovo pasto al diario alimentare

Scenario: Apertura pagina inserimento dati

data la pagina contenente la lista dei pasti
dato il pulsante «nuovo pasto»
quando il pulsante «nuovo pasto» viene cliccato
allora la modale di inserimento pasto viene mostrata

Scenario: Definizione di un pasto

data la modale di inserimento pasto
allora conterrà la lista degli alimenti
e conterrà il tipo di pasto

Scenario: Tipo di pasto

allora potrà essere colazione, pranzo o cena

Questo tipo di descrizione formale produce un vocabolario accurato, accessibile, descrittivo e consistente, tale da rendere comprensibile il sistema a tecnici e non tecnici. E’ quello che nel Domain-Driven Design viene chiamato ubiquitous language.

Per concludere, se dovessi sintetizzare il BDD dire che è uno sforzo congiunto di catturare il valore attraverso le “parole giuste” in una conversazione tra tutti gli attori, focalizzato sullo scambio continuo tra i diversi membri del team.

Qui le slide proiettate durante l’incontro

Foto del meetup:

Paolo Manca

More Posts

L'articolo BDD – molto più che testing proviene da Agile Community Torino.

Quello che però succede spesso è che quando mi avvicino ai banchi di frutta e verdura e noto che la qualità della merce non è in linea con le mie aspettative mi ritrovo a pensare: “Se fossi andato al mercato di quartiere avrei avuto molte bancarelle con la stessa merce, a prezzi diversi e di qualità diversa. Qui, invece, ho solo due scelte: accettare quello che mi viene offerto o rinunciare all’acquisto”.

Questo è quello che succede quando ci si siede ad un tavolo di negoziazione e non si hanno alternative all’accordo proposto.

“Adesso BATNA!” è anche il titolo di uno dei capitoli del libro “Extreme Contracts” scritto da Jacopo Romei, il nostro amico e relatore del talk che ci ha coinvolti nel meetup da lui organizzato nelle sale del Talent Garden di Torino.

BATNA è un acronimo e significa “Best Alternative To a Negotiated Agreement” (migliore alternativa ad un accordo negoziato).

Il concetto alla base è semplice: nel momento in cui ci sediamo ad un tavolo negoziale ognuno di noi ha un bouquet di scelte, bouquet che può essere più o meno limitato ma ce l’ha, fosse soltanto il fatto di scegliere se rimanere o abbandonare la trattativa.

Come al supermercato se non abbiamo alternative all’accordo proposto dalla controparte non abbiamo possibilità di negoziare: accettiamo oppure rifiutiamo.

Se, però, abbiamo diverse scelte su cui puntare ecco che siamo più forti, possiamo mettere in campo le nostre ragioni e iniziare una negoziazione.

Il suggerimento di Jacopo, dunque, è quello di non fermarsi, di crearsi una propria BATNA e possibilmente di rinnovarla e rafforzarla, perché nel momento in cui iniziamo una contrattazione non sappiamo quanto forte è la nostra BATNA e quanto lo sia quella della controparte.

Diventa, allora, fondamentale anche tener conto di aspetti che possono sembrare esterni al contesto, perché l’innesto di un terzo attore, fino a quel momento ignorato, potrebbe cambiare le nostre prospettive ed ampliare all’improvviso le scelte a disposizione.

Jacopo ci ha spiegato con esempi di vita vissuta quanto è importante poter scegliere, avere “potere contrattuale”, ed è stato tutto molto chiaro e semplice (Specification by Example).

Nel sul libro Jacopo pone tre domande alle quali bisognerebbe dare risposta per essere pronti a poter prendere una decisione:

1. Quali sono le mie priorità? Non mi sarà chiaro come procurarmi ciò che mi serve se non mi sarà chiaro cosa io desideri
2. Qual è la mia BATNA? Non confondere questa domanda con quella simile “Ho una BATNA?” Tutti abbiamo una BATNA ma conoscerla ci dice quanto è potente e qual è il nostro potere contrattuale
3. Qual è la loro BATNA? Chiunque sia seduto dall’altro lato del tavolo avrà una sua BATNA; buona, cattiva, chiara o confusa non importa: per noi sarà importante estrarre e ottenere ogni possibile informazione per preparare la nostra negoziazione al meglio.

A questo punto è chiaro che avere una BATNA ricca e variegata è fondamentale.

Ma come si fa ad ottenerla?

La risposta al prossimo meetup di Jacopo Romei del 28 giugno 2023 o leggendo il suo libro.

Ciao ciao. E buona BATNA a tutti.

Nicola

More Posts

Follow Me:

L'articolo Adesso BATNA!! Risk Management per il Knowledge Worker proviene da Agile Community Torino.

Di seguito un paio di foto e le slide dell’evento per uso futuro!

Clicca qui per visionare le slide

Daniel

Appassionato, volenteroso e super addicted di Lean e Agile, amo credere che cambieremo il mondo con la sola forza del pensiero!

More Posts

Follow Me:

L'articolo Back to the basic: (ri)scopriamo l’agilità! proviene da Agile Community Torino.

[This post contains video, click to play]

La comunicazione nonviolenta è un tema caldo, tutti ne parlano, ma cos’è davvero?

Simona ci ha fatto esplorare il luogo misterioso in cui sboccia la comunicazione, quell’attimo di silenzio-in-presenza in cui lasciamo spazio al nostro interlocutore di raccontare la *sua* storia. Quella storia che poi possiamo e dobbiamo allineare con la nostra, ma dopo averle dato spazio, senza l’urgenza di intervenire.

Simona ci racconta che la comunicazione nonviolenta è fatta di 4 fasi fondanti:

• OSSERVAZIONE: mi attengo ai fatti
• EMOZIONI: cosa vive in me?
• BISOGNI: di cosa ho bisogno ora?
• RICHIESTA: che cosa puoi fare per me?

Passiamo subito alla pratica! 

Primo round: divisi in coppie a turno uno racconta e l’altro lo interrompe con domande, feedback ecc.! Insomma si cerca di esasperare l’”urgenza” dell’intervento dell’ascoltatore. 

Tornati tutti insieme abbiamo condiviso le esperienze: chi è uscito infastidito… chi invece proprio non ce l’ha fatta ad interrompere nonostante lo sforzo! 

Ora passiamo al secondo round: stesse coppie, stessi racconti, ma stavolta lo scopo dell’esercizio è quello di ascoltare senza interrompere. 

Ritorniamo tutti insieme, cosa è cambiato? 

La differenza percepita immediatamente è che la storia l’ha pilotata il narratore, con le interruzioni si aveva avuto un racconto parziale, a volte anche un po’ sconclusionato.
Ma anche le emozioni provate erano molto diverse, maggiore coinvolgimento, più empatia ecc.

Clicca qui per la Miro board

Cosa possiamo fare quindi per migliorare la nostra comunicazione?

• Ancora prima di entrare in relazione con una persona posso decidere con quali sentimenti metterla a contatto: se mi rendo conto che una continua interruzione genera emozioni spiacevoli, cosa posso fare per prevenirlo?
• Per esempio, possiamo lasciare all’altro almeno 2 minuti senza interruzioni per la sua narrazione.

Conclusione se ci mettiamo nella posizione dell’ascolto, se accogliamo la storia che ci viene raccontata senza affrettarci a interrompere, possiamo generare sentimenti piacevoli nei nostri interlocutori.

Facile, no?

Tutt’altro! Ma un passo alla volta e possiamo allenare la nostra capacità di ascolto!

Grazie a Simona Pavesi per questa preziosissima esperienza! 

Sorpresa in allegato trovare il link della registrazione oltre ad un visual della nostra serata di Eleonora Della Bernardina!

Per info su altri eventi di Simona visitate il sito https://simonapavesi.it/

Giada.pallavicini

More Posts

L'articolo Mi ascolti bene? proviene da Agile Community Torino.