In questa esaustiva serie di interviste e importanti contributi, presentata in collaborazione con Mauro Murru, Founder del podcast GitBar, approfondiamo i concetti fondamentali per i dev, sia senior che junior, che quindi tutti dovrebbero conoscere per rimanere aggiornati sull’attuale industria tecnologica.
Sviluppatori di alto livello hanno condiviso tecnologie chiave, termini e approcci che oggi stanno plasmando i rispettivi settori: dall’AI e ML all’Open Source, Microservizi e metodologie Scrum.
Ecco le loro intuizioni per la community Codemotion da apprezzare!
AI, Machine learning e deep learning
Alberto Massidda, Production Engineer @Meta
AI, ML e DL
AI: è uno dei concetti fondamentali per i dev, nonché un concetto generale che comprende tutto ciò che riguarda il rendere un computer, o un software, “intelligente”. L’IA si può basare su regole (preprogrammate) o sull’apprendimento (capacità di imparare da dati e esperienze).
Machine Learning: “lasciare che i computer imparino da soli” dandogli accesso a un grande set di dati e lasciandogli stabilire regole e pattern. L’output è generato da modelli costruiti attraverso l’apprendimento da dati di addestramento.
Deep Learning (DL): sottocampo del machine learning che imita il principio di funzionamento del cervello biologico. Si basa sul processare un’informazione attraverso più “strati di profondità”. Ogni strato di una rete neurale processa un diverso aspetto dei dati e poi passa ciò che ha appreso al prossimo strato. L’uscita riflette il “punto di vista” di tutti gli strati.
Modello
Modelli Discriminativi in AI: imparano i confini decisionali dai dati di addestramento e usano questi confini per classificare i nuovi input. Applicabili a problemi di decisione e previsione, come generazione di prezzi immobiliari, riconoscimento di immagini, filtraggio dello spam.
Modelli Generativi in AI: stimano la distribuzione dei dati di addestramento, imparando così a generare esempi che appartengano ai più sottogruppi. Sono utilizzati in diverse applicazioni, come la generazione di immagini, la sintesi vocale e la traduzione automatica.
Apprendimento
Apprendimento Supervisionato: gli algoritmi apprendono da un insieme di dati etichettati. Ogni esempio di dati è una coppia composta da un input e il corrispondente output desiderato (etichetta). L’obiettivo è creare un modello che, dato un nuovo input, possa predire l’output corretto.
Apprendimento Non Supervisionato: si basa su dati non etichettati e cerca di trovare strutture o pattern nascosti nei dati. Questo può essere utilizzato per raggruppare dati simili (clustering), ridurre la dimensionalità dei dati, o scoprire regole associative tra le loro caratteristiche.
Apprendimento Semi-Supervisionato: si trova a metà strada tra l’apprendimento supervisionato e quello non supervisionato. Utilizza un grande insieme di dati non etichettati per indurre delle etichette automatiche che verranno poi utilizzate per addestrare un modello supervisionato. Utile quando le etichette dei dati sono costose o difficili da ottenere.
Lettura consigliata: Rilasciato Vite 5: quali sono le novità e i miglioramenti?
Training e inferenza
Training in AI: è la fase in cui un modello “impara” dai dati. L’algoritmo usa un set di dati di addestramento per regolare i suoi parametri interni e ottimizzare la sua performance.
Inferenza in AI: è la fase in cui un modello già addestrato viene utilizzato per fare previsioni su nuovi dati sconosciuti. L’inferenza è l’applicazione pratica del modello.
Licenze Software
Carlo Piana, Founder & Partner @Array Law
Licenza software: è una dichiarazione legale che definisce i termini e le condizioni per l’utilizzo di un software. Quando acquisti, scarichi o installi del software, il produttore o il detentore dei diritti ti concede una licenza che stabilisce i diritti e gli obblighi relativi all’uso di quel software, in aggiunta ai diritti e ai doveri stabiliti dalla legge.
Licenza open-source:
Accesso al codice sorgente: gli utenti possono ottenere, modificare e distribuire il codice sorgente in modo libero e trasparente.
Libertà di utilizzo e distribuzione: offrono la libertà di utilizzare, copiare, distribuire, modificare e ridistribuire il software senza restrizioni. Questa caratteristica promuove l’innovazione e la condivisione della tecnologia.
Attribuzione dell’autore: possono richiedere che venga attribuito il credito all’autore originale del software quando il codice sorgente viene utilizzato o distribuito.
Licenza copyleft: Alcune licenze includono clausole copyleft, come la GPL (GNU General Public License), che impongono che il software derivato o modificato debba essere distribuito con la stessa licenza Open Source del codice originale. Questo garantisce che le versioni derivate continueranno a essere Open Source. Una delle condizioni copyleft è quella di condividere il completo codice sorgente corrispondente alle versioni modificate.
Licenza proprietaria:
Accesso limitato al codice sorgente: non fornisce l’accesso al codice sorgente del software. Gli utenti ricevono solo il prodotto finale compilato, e non possono accedere, visualizzare o modificare il codice sorgente. Non è Open Source, è software proprietario, anche se gratuito.
Licenza a pagamento: richiedono spesso il pagamento di una licenza. Esistono diverse modalità di licenza, come licenze per singolo utente, licenze aziendali o licenze a tempo limitato.
Quando si crea software, la legge riserva tutti i diritti all’autore. Pertanto, se si intende concedere i permessi per renderlo Open Source, occorre effettuare una dichiarazione pubblica ed espressa, altrimenti tutti i diritti rimangono riservati. Ciò non significa che il software diviene di pubblico dominio: infatti il titolare dei diritti può consentire il libero utilizzo solo a determinate condizioni, tra le quali quelle copyleft. Tali condizioni debbono rispettare la Open Source Definition per essere considerati “Open Source”.
Microservizi
Mattia Tommasone, Senior Developer Relations Engineer, Ads @Google
Modularità: sono componenti indipendenti che eseguono funzioni specifiche all’interno di un’applicazione. Ognuno può essere sviluppato, implementato e scalato separatamente dagli altri.
Indipendenza: ogni microservizio è autonomo e può essere sviluppato utilizzando linguaggi di programmazione, tecnologie e strumenti diversi.
Comunicazione tramite API: i microservizi comunicano tra loro attraverso API ben definite.
Scalabilità: consentono di scalare in modo indipendente le singole componenti dell’applicazione in base alle esigenze di carico.
Isolamento dei fallimenti: grazie alla loro natura modulare, se uno dei microservizi fallisce, gli altri possono continuare a funzionare normalmente.
Sviluppo e distribuzione rapida: la modularità dei microservizi facilita lo sviluppo parallelo e l’implementazione continua. Ogni microservizio può essere sviluppato, testato e distribuito in modo indipendente, accelerando il processo di sviluppo dell’applicazione.
Facilità di sostituzione e aggiornamento: grazie alla separazione dei microservizi, è possibile sostituirne uno con un’implementazione migliore o aggiornarlo senza dover toccare gli altri. Ciò semplifica l’evoluzione e l’aggiornamento delle singole componenti dell’applicazione.
Scalabilità orizzontale: i microservizi possono essere replicati e distribuiti su più server in modo da distribuire il carico e aumentare le prestazioni dell’applicazione.
DevOps-friendly: l’architettura dei microservizi si presta bene all’approccio DevOps, in quanto facilita l’integrazione continua, il rilascio continuo e l’automazione dei processi di sviluppo, test e distribuzione.
Lettura consigliata: Come creare un Console Emulator in Python
Divisione in microservizi
Funzionalità coese: identificare le funzionalità del sistema che possono essere isolate e suddivise in microservizi separati. I microservizi dovrebbero essere coesi, cioè contenere logiche di business correlate e fornire un’unità funzionale distinta.
Granularità adeguata: trovare un equilibrio nella dimensione dei microservizi. Devono essere sufficientemente piccoli da garantire la modularità e l’indipendenza, ma anche abbastanza grandi da poter gestire autonomamente una parte significativa della logica di business.
Limiti del dominio: identificare i limiti del dominio, cioè i confini concettuali tra le diverse responsabilità dell’applicazione.
Comunicazione e interfacce: definire le modalità di comunicazione tra i microservizi. Solitamente si utilizzano API RESTful, messaggistica asincrona o eventi per consentire l’interazione tra i diversi servizi. È importante stabilire chiaramente le interfacce e le contrattazioni delle API per garantire una comunicazione corretta e coerente.
Isolamento dei dati: considerare come gestire l’accesso ai dati da parte dei microservizi. Possono essere adottate diverse strategie, come il possesso esclusivo dei dati da parte di un microservizio, la replica dei dati tra i servizi o l’adozione di un modello di consistenza eventualmente consistente.
Gestione delle transazioni: valutare come gestire le transazioni tra i microservizi. Le transazioni distribuite possono essere complesse da implementare e gestire. Si possono adottare approcci come la compensazione dei processi o l’uso di event sourcing e CQRS (Command Query Responsibility Segregation) per garantire la consistenza dei dati.
Monitoraggio e tracciamento: pianificare come monitorare e tracciare le richieste e le risposte tra i microservizi. È importante avere visibilità sulle prestazioni e sulle interazioni tra i servizi per diagnosticare e risolvere eventuali problemi.
Conway’s Law
Un altro tra i concetti fondamentali per i dev da tenere a mente è inerente alle organizzazioni che progettano sistemi: esse sono vincolate a produrre progettazioni che sono copie delle strutture di comunicazione delle loro organizzazioni.
Kubernetes
Serena Sensini, Enterprise Architect @Dedalus spa e Founder @TheRedCode
Kubernetes
E’ un sistema open-source per l’automazione del deployment, la scalabilità e la gestione di applicazioni containerizzate. Il suo scopo principale è fornire un framework per distribuire, mantenere e scalare applicazioni in modo efficiente e affidabile in diversi ambienti di hosting.
Master Node: Il nodo principale che controlla e gestisce il cluster Kubernetes.
Worker Node: È responsabile dell’esecuzione dei container (applicazioni) nel cluster Kubernetes.
Kubelet: Agente che si esegue su ogni nodo e si assicura che i container siano in esecuzione in uno stato desiderato.
Kube-proxy: Mantieni le regole di rete sui nodi per consentire la gestione tra i diversi Services.
Pod: La più piccola e semplice unità in Kubernetes, che rappresenta un singolo processo in un cluster composto da uno o più container.
Service: Un’astrazione che definisce un set logico di pod per consentirne la comunicazione attraverso le componente di networking
Deployment: Fornisce aggiornamenti dichiarativi per i pod e i Replicaset.
ReplicaSet: Garantisce che un numero specificato di copie di un pod siano in esecuzione in qualsiasi momento.
ConfigMap e Secret: Meccanismi per fornire file di configurazione e/o dati sensibili ai pod.
Namespace: consente la separazione logica e la definizione di una naming convention tra le risorse all’interno di un cluster.
Etcd: Conserva in modo affidabile la configurazione di stato del cluster.
Lettura consigliata: I 5 migliori siti di coding challenge
Big data
Antonio Murgia, Data Architect @Agile Labs
I dati hanno una loro gravità.
Il termine “big data” si riferisce a un volume eccezionalmente grande di dati che può essere analizzato per rivelare schemi, tendenze e associazioni. Questo concetto, che è senza dubbio tra i concetti fondamentali per i dev, è in continua evoluzione e generalmente si riferisce a dati che sono così vasti o complessi che i metodi di elaborazione dei dati tradizionali sono inadeguati per gestirli.
Volume: quantità di dati.
Velocità: velocità con cui i nuovi dati vengono generati e con cui i dati si spostano intorno.
Varietà: diverse tipologie di dati strutturati e non
Veridicità: correttezza e affidabilità dei dati
Valore: l’abilità e la possibilità di trasformare i dati in valore.
Tipologie di dati
I dati strutturati sono organizzati in un formato predefinito e facilmente analizzabile (es. database relazionale) mentre i dati non strutturati sono disorganizzati e non seguono una struttura specifica, rendendo più complesso il loro processamento e analisi, come nel caso di testi, immagini o video.
ETL e ELT
Gli ETL (Extract, Transform, Load) sono processi che estraggono dati da varie fonti, li trasformano in un formato compatibile e poi li caricano in un data warehouse per l’analisi. Gli ELT (Extract, Load, Transform) invece, estraggono i dati, li caricano prima nel data warehouse e poi li trasformano all’interno dello storage stesso, spesso offrendo una maggiore efficienza per grandi volumi di dati.
Un data warehouse è un sistema centralizzato che archivia dati strutturati e raramente semi-strutturati, ottimizzati per l’analisi veloce e l’interrogazione.
Un data lake è un sistema che può archiviare grandi volumi di dati strutturati e non strutturati, mantenendoli nel loro formato grezzo fino a quando non sono necessari per l’uso, offrendo maggiore flessibilità.
Bronze, silver e gold data
I termini bronze, silver e gold si riferiscono a fasi di raffinazione dei dati: i bronze data sono dati grezzi e non elaborati, i silver data sono dati puliti e trasformati ma non pronti per il consumo finale, e i gold data sono dati raffinati, affidabili e pronti per l’analisi e il reporting
Cloud
Andrea Saltarello, CTO @Managed Designs e Founder @UGIdotNET
Public Cloud: Servizi di cloud offerti su Internet da fornitori terzi, accessibili a chiunque desideri sottoscrivere o acquistarli.
Private Cloud: Infrastruttura di cloud computing dedicata a un’organizzazione specifica, offrendo maggiore controllo e privacy.
Hybrid Cloud: Combinazione di cloud pubblici e privati, permettendo lo scambio e la condivisione di dati e applicazioni tra di essi, per ottenere una maggiore flessibilità e ottimizzazione dell’infrastruttura esistente.
Private cloud vs On-premises
Le soluzioni on-premises sono fisicamente collocate e gestite all’interno delle strutture dell’organizzazione, richiedendo hardware e software dedicati, nonché personale IT per la manutenzione.
Il private cloud, invece, offre un ambiente di cloud computing dedicato che è ospitato in remoto, gestito dal fornitore di servizi, ma riservato esclusivamente all’organizzazione, fornendo maggiore scalabilità e flessibilità rispetto a un’implementazione on-premises.
Vendor Lock-in
Il “vendor lock-in” nel cloud si riferisce alla situazione in cui un’organizzazione diventa eccessivamente dipendente da un singolo fornitore di servizi cloud, rendendo difficile o costoso migrare a un altro fornitore.
Prima di attuare azioni correttive è necessario fare una stima del rischio, sia dal punto di vista della probabilità sia da quello del costo risultante nel caso si materializzasse. Ove tali fattori risultassero predominanti, occorre attuare una strategia per limitarne l’impatto, strategia che include l’utilizzo di standard aperti e la progettazione di sistemi con la portabilità in mente, anche rinunciando a funzionalità rese disponibili out of the box dalla piattaforma cloud ed accettando il costo di realizzarle in casa o sostituirle con ulteriori prodotti/servizi.
Cloud governance
U altro tra i concetti fondamentali per i dev, è l’insieme di regole, politiche e procedure che un’organizzazione implementa per gestire, monitorare e ottimizzare l’uso delle risorse cloud. Include la definizione di linee guida su come vengono selezionati, implementati e gestiti i servizi cloud all’interno dell’organizzazione.
Politiche e Linee Guida: Definizione di regole e procedure chiare per l’utilizzo dei servizi cloud.
Sicurezza e Conformità: Assicurare che i servizi cloud siano conformi alle normative legali e ai requisiti di sicurezza dell’organizzazione.
Gestione dei Costi: Monitoraggio e controllo dei costi associati all’uso del cloud per evitare sprechi e sovraccarichi inaspettati.
Ottimizzazione delle Prestazioni: Garantire che le risorse cloud siano utilizzate in modo efficiente per fornire le prestazioni desiderate.
Gestione del Rischio: Valutazione e mitigazione dei rischi associati all’adozione del cloud, come la disponibilità e la resilienza.
Integrazione e Interoperabilità: Assicurare che i servizi cloud siano integrati in modo uniforme con gli altri sistemi e tecnologie dell’organizzazione.
Monitoraggio e Reporting: Utilizzo di strumenti per monitorare l’uso, le prestazioni e la conformità dei servizi cloud, e creare report regolari per la leadership dell’organizzazione.
Responsabilità e Ruoli: Definizione chiara dei ruoli e delle responsabilità all’interno dell’organizzazione per la gestione e la governance dei servizi cloud.
Lettura consigliata: Ottimizzazione avanzata delle prestazioni web
User stories e product ownership
Matteo Guidotto, Senior Growth Product Manager @DaVinci Salute
Product owner e Product manager
Il Product Owner tende ad avere un focus più tattico e squadra-specifico, mentre il Product Manager tende ad avere un focus più strategico e orientato al mercato. Tuttavia, in alcune organizzazioni, i ruoli possono essere fusi insieme o avere sovrapposizioni significative.
Ruolo guidato dall’ascolto
- Ascoltando attentamente il business, il Product Owner può capire le loro esigenze, i loro problemi, e le loro aspettative, indispensabili per definire e prioritizzare i requisiti del prodotto.
- L’ascolto attivo è essenziale per lavorare efficacemente con il team di sviluppo, per comprendere le loro sfide, le loro preoccupazioni, e i loro suggerimenti, oltre che per garantire che siano sulla giusta strada per raggiungere gli obiettivi del sprint.
- Ascoltando altri stakeholder (manager, marketing, …), il Product Owner può assicurarsi che il prodotto sia allineato con gli obiettivi aziendali e le strategie di mercato.
- Un buon ascolto è essenziale per gestire e risolvere i conflitti che possono sorgere tra gli stakeholder o all’interno del team di sviluppo, facilitando la mediazione e la ricerca di soluzioni condivise.
- L’ascolto costruisce fiducia tra il Product Owner e gli stakeholder. Mostrare empatia e considerazione può contribuire a creare relazioni di lavoro positive e produttive.
Definition of Ready (DoR):
La Definition of Ready stabilisce i criteri che un elemento del product backlog deve soddisfare prima che possa essere considerato pronto per essere incluso in un sprint.
- Chiarezza dei Requisiti, Accordo sullo Scopo, Stime (quando presenti), soluzione di tutte le dipendenze
La DoR aiuta a prevenire malintesi e ritardi nel lavoro dello sprint, garantendo che il team inizi con aspettative e informazioni chiare.
Definition of Done (DoD):
La Definition of Done, d’altra parte, stabilisce i criteri che un elemento del product backlog deve soddisfare per essere considerato completato, es: Codice Scritto e Testato, Codice Revisato, Documentazione Completa, Clienti e Utenti Finali Soddisfatti
La DoD garantisce che ogni elemento completato soddisfi uno standard di qualità concordato e che sia realmente pronto per essere rilasciato, se necessario.
I rischi della Definition of Ready (DoR):
Una DoR troppo rigida o dettagliata può ridurre la flessibilità e la capacità del team di adattarsi ai cambiamenti. Può essere interpretata in modo tale che solo il Product Owner è responsabile della preparazione degli elementi del backlog, potenzialmente riducendo la collaborazione e la discussione all’interno del team su questi elementi. Può dare un senso di falsa sicurezza, facendo credere che, se tutti i criteri sono soddisfatti, non ci saranno problemi durante lo sviluppo, il che non è sempre vero.
UI e UX design
Davide Di Pumpo, Design Technologist @Amazon, e Paul Romero, UX & Service Designer e Product Manager
Design:
- Processo Globale: è un processo più ampio che va oltre il semplice disegno. Include la pianificazione, la definizione degli obiettivi, la risoluzione dei problemi, la considerazione delle esigenze dell’utente e l’implementazione pratica di un concetto o di un prodotto.
- Orientato agli Obiettivi: si concentra sull’ottenimento di risultati specifici o sull’adempimento di un obiettivo. Può includere il pensiero strategico, la ricerca utente, l’ottimizzazione funzionale e la valutazione delle prestazioni.
- Coinvolge Diverse Competenze: richiede spesso una gamma più ampia di competenze, tra cui l’ingegneria, l’architettura, la psicologia dell’utente, la sostenibilità e molto altro.
Il processo
- Ricerca di mercato e dell’utente:
- Analisi e Definizione dei Requisiti:
- Definizione dei casi d’uso, Creazione di user personas
- Ideazione e Progettazione Concettuale:
- Brainstorming, Prototipazione, Testing
- Progettazione dell’Interfaccia Utente (UI):
- Creazione di wireframe, Progettazione visuale, Creazione di prototipi interattivi
- Test Utente e Iterazione:
- User testing, Analisi dei risultati e iterazioni
- Sviluppo e Implementazione:
- Collaborazione con il team di sviluppo, Test e controllo di qualita
- Lancio e Monitoraggio:.
- Lancio del prodotto, Monitoraggio dell’esperienza utente
Nota bene: a seconda del progetto alcune di queste fasi possono essere omesse
Atomic Design:
- Atomi: sono gli elementi di base dell’interfaccia utente, come bottoni, campi di testo, icone o colori. Sono componenti semplici e riutilizzabili che fungono da mattoni fondamentali nella creazione di elementi più complessi.
- Molecole: sono gruppi di atomi che lavorano insieme per formare componenti più avanzati. Un modulo di inserimento dati potrebbe essere una molecola composta da un campo di input, un pulsante e una label.
- Organismi: Gli organismi sono componenti dell’interfaccia utente più grandi e autosufficienti. Rappresentano sezioni complesse dell’interfaccia come barre di navigazione, intestazioni o card contenenti diverse molecole e atomi che cooperano insieme.
- Template: I template forniscono una struttura di base per le pagine dell’interfaccia utente. Definiscono la disposizione generale degli organismi e delle molecole su una pagina, ma non contengono contenuti specifici.
- Pagine: Le pagine rappresentano le istanze concrete delle interfacce utente complete, dove vengono inseriti i contenuti specifici. Sono la manifestazione finale del design e incorporano tutti gli altri elementi, dai template agli organismi, alle molecole e agli atomi.
Scrum
Fabio Panzavolta, Founder @Collective Genius e Independent Scrum Master
Fondazioni – Scrum si basa sull’empirismo e il Lean Thinking.
- Empirismo: la conoscenza deriva dall’esperienza e le decisioni sono prese sulla base di fatti. Trasparenza, ispezione e adattamento sono i tre pilastri dell’empirismo.
- Lean Thinking: creazione di valore il più velocemente possibile e riduzione dello spreco.
Valori – Scrum Professionale opera in un ambiente di Psychological Safety.
- Coraggio: affermare le proprie idee, non nascondere fatti o informazioni relative al prodotto, rispettare i principi e gli elementi di Scrum.
- Focus: concentrarsi a fare solo ciò che è utile alla creazione di valore, nel momento più opportuno. Essere presente pienamente in ogni evento Scrum.
- Apertura: abbracciare tutte le idee, di qualsiasi persona, senza giudizio e resistendo a ciò che la propria esperienza potrebbe suggerire. Provare cose che non si sarebbero altrimenti provate.
- Rispetto: di tutte le persone che ci circondano, come persone competenti e per tutte le idee e le proposte utili al miglioramento del prodotto.
- Impegno: dare sempre il massimo per raggiungere gli obiettivi prefissati, impegnarsi a rispettare gli eventi Scrum.
Le Responsabilità
- Product Owner: Responsabile della massimizzazione del valore del prodotto. Gestisce il Product Backlog.
- Developers: Composto dai professionisti che effettivamente creano il prodotto o il servizio, sono auto-organizzati e multidisciplinari, il che significa che hanno tutte le competenze necessarie per completare il lavoro, dalla progettazione allo sviluppo, al testing, marketing, ecc. Si impegnano a consegnare incrementi di prodotto completi e pronti per il rilascio al più tardi alla fine di ogni Sprint.
- Scrum Master: Responsabile dell’efficacia dello Scrum Team attraverso la corretta comprensione e il corretto utilizzo di Scrum Facilita il processo Scrum, assicurando che vengano rispettate le regole e le pratiche del framework, aiuta il team Scrum a rimuovere ostacoli e a risolvere problemi che potrebbero impedire il raggiungimento degli obiettivi dello Sprint, promuove il miglioramento continuo e favorisce la crescita e la maturità del team.
- Scrum Team: Composto da Product Owner, Developers e Scrum Master, è auto-gestito e cross-funzionale.
Artefatti
- Product Backlog: riflette la strategia del Product Owner ed è un elenco emergente del lavoro da fare sul prodotto, Contiene il Product Goal.
- Sprint Backlog: un sottoinsieme del Product Backlog che rappresenta le attività e gli elementi selezionati dai Developers per uno specifico Sprint. Contiene lo Sprint Goal.
- Incremento: uno step in avanti verso il raggiungimento del Product Goal. Deve soddisfare la Definition of Done, ossia essere completo, testato e pronto per il rilascio in produzione.
Gli Eventi
- Sprint: è il cuore pulsante di Scrum, l’evento che contiene tutti gli altri eventi e che fornisce la frequenza regolare di ispezione e adattamento.
- Sprint Planning: evento nel quale lo Scrum Team collabora per fissare lo Sprint Goal, fare le previsioni degli elementi più importanti dal Product Backlog e definire. I Developers forniscono il dettaglio del lavoro necessario per completare almeno i primi elementi del Product Backlog selezionati.
- Daily Scrum: È un evento giornaliero dei Developers, che permette di pianificare le prossime 24 ore e capire se il lavoro fatto aumenta le probabilità di raggiungere lo Sprint Goal.
- Sprint Review: evento informale e collaborativo durante il quale lo Scrum Team e gli Stakeholders ispezionano l’incremento e forniscono feedback utile all’adattamento del Product Backlog
- Sprint Retrospective: Lo Scrum Team riflette sull’ultimo Sprint, identifica cosa è andato bene e cosa può essere migliorato, e pianifica le azioni correttive per il prossimo Sprint.
