Siamo finalmente arrivati alla fase di delivery anche per il nostro esempio.

Quindi abbiamo detto abbiamo visto tutta la strategy che ci dà l'idea di dove vogliamo arrivare in futuro.

Abbiamo seguito tutta la fase di Discovery, identificando quelli che sono gli esperimenti e le soluzioni da mettere in pro backlog, perché li abbiamo priori durante l'ultima fase della pro Discovery, quella di deliver.

E adesso andremo a seguire il flusso Scrum Non andrò a spiegarlo nei minimi dettagli, in quanto ci vorrebbe un corso ad hoc.

Vi farò vedere nella maniera più semplice possibile come si svolge Scrum.

Poi sarà necessario un corso ad hoc per spiegare tutti i tutto nel minimo dettaglio, dalle stime a come funziona un una retrospettiva.

Va bene, allora, come abbiamo visto prima, siamo arrivati dalla nostra fase di Discovery con due problemi contenuti troppo teorici e mancanza di tempo contenuti troppo teorici perché alcuni professionisti che hanno maggiore esperienza ritengono che vorrebbero avere accesso a dei contenuti più approfonditi con esercizi e use case, mentre la mancanza di tempo riguarda molti professionisti che, ahimè, tra impegni di lavoro e impegni di famiglia non possono, non riescono a dedicare il proprio tempo alla formazione per risolvere questi due problemi abbiamo identificato due opportunità una migliorare i corsi suggeriti.

Quindi sono presenti già tantissimi corsi pratici e approfonditi sulle ERN.

Probabilmente gli utenti fanno fatica ad individuarli, quindi devo trovare un modo per far trovare far trovare a questi utenti più facilmente il contenuto.

Invece, per quanto riguarda il problema della mancanza di tempo l'opportunità che l'idea che ci è venuta è stata la space, questa tecnica che permette di ripetere ciò che abbiamo studiato in modo da renderlo nostro.

E con questa integrazione possiamo aiutare gli utenti a non dimenticare ciò che hanno imparato durante le lezioni precedenti durante i moduli precedenti, in modo che poi possano proseguire le lezioni in maniera più più veloce senza dover tornare indietro.

Come l'esempio che facevo è immagina di guardare una serie T V e di doverti fermare per un mese.

Probabilmente farai fatica a riprendere senza guardare le puntate precedenti.

Um questo perché ti sei dimenticato cosa è successo? Stessa cosa potrebbe succedere per gli utenti che a causa di impegni lavorativi fanno fatica a con a seguire le lezioni in maniera costante.

Quindi sulla base di queste opportunità abbiamo definito due esperimenti uno in fase di un chiedere quale tipologia di contenuto cerca l'utente mostrare contenuti filtrati, così da far vedere agli utenti che esistono effettivamente questi corsi pratici e approfonditi e due intanto inviare una mail con una domanda relativa alle lezioni appena concluse al segmento di utenti che è più propenso a non continuare un corso che abbiamo visto essere più propenso a non continuare un corso prima Abbiamo cliccato, se ricordi su saint to backlog e ci siamo trovati di conseguenza all'interno del G.

Questi due esperimenti che ho appena che ho appena detto questi due esperimenti li abbiamo esplosi in user stories.

Una user story è sostanzialmente la più piccola unità di lavoro e può rappresentare una piccola funzionalità che deve essere sviluppata.

Si struttura in questo modo s a persona, in quanto come persona vorrei far questo in modo da ottenere un beneficio.

Per il primo esperimento abbiamo identificato tre user stories Come Maria vorrei ricevere una mail con una domanda relativa alle elezioni concluse nei sette giorni precedenti, in modo da far da far miei concetti condivisi come Maria.

Quando rispondo alla domanda vorrei vedere se la risposta è quella corretta e avere accesso ad una spiegazione in modo da potermi correggere una volta inviata la inviata la risposta Come Maria vorrei ricevere una mail che mi suggerisca cosa ripassare e quali prossime elezioni seguire invece per il secondo esperimento è quello del dei contenuti approfonditi.

Come utente vorrei specificare la tipologia di contenuto che cerco per ricevere suggerimenti più adatti alle mie esigenze.

E, come Luca, vorrei visualizzare in Word le lezioni che rispondono alle mie esigenze, esigenze di contenuto e di tipologia di spiegazione.

Quindi esercizi use case okay, come abbiamo visto durante le la scorsa lezione e all'interno delle user stories, possono essere definiti degli che indicano i dettagli di una funzionalità.

Nel nostro caso.

Prendendo una una di queste user stories vediamo che gli fanno riferimento alla funzionalità della pagina di destinazione.

Quindi, quando clicco sulla risposta dalla mail, arrivo ad una pagina che mi mostra se la risposta è corretta o sbagliata e nel caso in cui la risposta fosse sbagliata E la tipologia di messaggio che devo includere.

Quindi la spiegazione dettagliata del perché la risposta è errata e la lezione da cui è stata tratta la domanda in modo che l'utente possa guardarla nuovamente.

Poi ci sono dei requisiti generali da rispettare la pagina deve essere semplicemente responsabile, quindi deve visualizza su tablet e mobile e deve essere comunque in ogni caso performante.

Okay, abbiamo di conseguenza definito gli elementi che sono nel nostro backlog.

Li abbiamo visti, li abbiamo esplosi, abbiamo fatto quello che viene definito, ovvero la pratica in cui gli elementi presenti nel backlog vengono discussi, esaminati e priori utilizzati in base alle nuove scoperte fatte fatte in fase di discovery.

Ci sono arrivati gli esperimenti, abbiamo esploso gli esperimenti in user user story che poi possiamo priori possiamo stimare con le con gli story poi su cui possiamo fare diverse iterazioni ma che non andiamo ad approfondire in questo corso prima di continuare il flusso ti ricordo cos'è uno sprint uno sprint è un ciclo di lavoro iterativo di una durata fissa solitamente due settimane o un mese e questo ti serve perché subito dopo aver sistemato il prodotto backlog andiamo a fare lo sprint planning lo sprint in quel momento in cui il team definisce la lista di attività da portare a termine durante lo sprint e queste attività vengono inserite nello sprint backlog che è la nostra lista di elementi su cui lavorare durante lo sprint anche questo è presente nel nostro notion, quindi, um abbiamo identificato gli elementi e li abbiamo messi nel nostro backlog.

Ora quello che succederà durante lo sprint è che il team di prodotto, il team di sviluppo prodotto, andrà a prendere ognuna di queste stories andrà a svilupparle se necessario, mettendo mano alla facendo no code prototipi utilizzando questo dipende un po' da che tipo di storie? Che tipo di tasche abbiamo in mano durante lo sprint? Ti ricordo che ci sono degli incontri quotidiani chiamati degli stand up.

Sono incontri di allineamento in cui rispondiamo a tre domande su cosa ho lavorato ieri su cosa lavorerò oggi e cosa mi sta bloccando.

Serve creare allineamento e poi alla fine di tutto ci sono dei momenti in cui andiamo a quello che è l'incremento rilasciato dal team di prodotto durante lo sprint demo e andiamo ad organizzare quella che viene chiamata una sprint retrospective.

Quindi un momento di allineamento in cui il team riflette su cosa è andato bene, su cosa è andato meno bene e quali sono le azioni da compiere per migliorare le dichiarazioni successive.

E e questo è il flusso di eh il flusso di scrub, il flusso di prodotto delivery alla fine di questo flusso.

Anzi, ti direi meglio imperativamente durante questo flusso durante il flusso di Discovery.

L'obiettivo è continuare a mantenere un occhio sul sui dati sulle metriche che abbiamo deciso di mi di misurare per valutare se un esperimento effettivamente risulterà valido e tutti questi dati che raccogliamo serviranno come input alla nostra fase di Discovery, diventando di conseguenza un ciclo totalmente iterativo, come visto nell'ultima lezione prima di di questa.