SAFe Glossary
The SAFe glossary is a set of definitions for all SAFe Big Picture elements. The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.
Select language
Print Glossary5
-
5 Whys (I 5 perché)
5 Whys è una tecnica di problem solving usata nell'ambito dell'evento di Inspect & Adapt (I&A) per esplorare la relazione di causa-effetto sottostante un particolare problema.
A
-
Acceptance Criteria (Criteri di accettazione)
Gli Acceptance Criteria forniscono le informazioni necessarie per garantire che una User Story, una Feature o una Capability sia realizzata correttamente e nel rispetto dei requisiti funzionali e non funzionali (NFR).
-
Acceptance Test-Driven Development
L'Acceptance Test-Driven Development è una pratica di sviluppo Agile che conferisce priorità ai test ed è sinonimo Behavior-Driven Development (BDD).
-
Agile
Agile è un insieme di valori, principi e pratiche per lo sviluppo iterativo, descritto nel dettaglio dal Manifesto Agile.
-
Agile Manifesto (Manifesto Agile)
L'Agile Manifesto è il principale documento Agile che descrive i quattro valori e i dodici principi che guidano lo sviluppo di software Agile.
-
Agile Product Delivery
L'Agile Product Delivery è un approccio incentrato sul cliente rivolto a definire, costruire e rilasciare un flusso continuo di prodotti e servizi di valore per i clienti e gli utenti.
-
Agile Program Management Office, APMO
L'Agile Program Management Office (APMO) è una funzione organizzativa incaricata di facilitare il processo di Lean Portfolio Management, nonché di promuovere l'eccellenza operativa e la lean governance nell'ambito di una trasformazione Lean-Agile.
-
Agile Release Train, ART
Un ART è un team stabile formato da team agili, che, insieme ad altri stakeholder, applica una logica incrementale per sviluppare, consegnare e, quando opportuno, mettere in opera una o più Solutions di un Value Stream.
-
Agile Team (team Agile)
In SAFe, un team Agile è un gruppo interfunzionale di 5-11 persone che definiscono, realizzano, testano e consegnano un incremento di valore in un breve lasso di tempo.
-
Architect Sync
L'Architect Sync è un evento di Solution Train volto a garantire la coerenza nella gestione dei nuovi design e compromessi all'interno del Solution Train. L'evento permette di creare opportunità frequenti per riallineare gli approcci di implementazione senza causare ritardi.
-
Architectural Runway
L'Architectural Runway è composta dal codice, dai componenti e dall'infrastruttura tecnologica richiesti per implementare funzionalità nel breve termine, evitando riprogettazioni e ritardi eccessivi.
-
ART Sync
L'ART Sync è un evento ART che combina il Product Owner (PO) Sync e lo Scrum of Scrums (SoS).
B
-
Backlog Refinement (Affinamento del backlog)
Il Backlog Refinement è un'attività svolta una o due volte nel corso dell'iterazione per discutere, stimare e stabilire un consenso preliminare sui criteri di accettazione per le storie nei backlog dei team.
-
Baseline Solution Investments, BSI
Il Baseline Solution Investment (BSI) sono costi sostenuti da ogni flusso di valore durante lo sviluppo, il supporto e l'uso delle soluzioni che forniscono le attuali capability di business.
-
Batch Size (Dimensioni del lotto)
La Batch Size è una misura di quanto lavoro (requisiti, modelli, codici, test e altri elementi di lavoro) viene svolto all'interno di un sistema nel corso di una qualsiasi finestra temporale.
-
Behavior-Driven Development (Sviluppo basato sul comportamento)
Il Behavior-Driven Development (BDD) è una pratica di test Agile che conferisce priorità al test e favorisce la qualità intrinseca di un sistema tramite la definizione (e potenzialmente l'automazione) dei test prima (o come parte) della specifica del comportamento del sistema stesso.
-
Benefit Hypothesis (Ipotesi dei benefici)
La Benefit Hypothesis è il beneficio ipotizzato per l'utente finale o l'impresa come risultato misurabile di una Feature o di una Capability.
-
Big Visible Information Radiator, BVIR
Un Big Visible Information Radiator, BVIR è una rappresentazione grafica che traccia e visualizza dati essenziali in forma sintetica (es. Burn-Down Chart, Program Board, Build Status Board)
-
Built-in Quality
Le pratiche di Built-In Quality assicurano che ogni elemento della Solution, ad ogni incremento, soddisfi gli standard di qualità appropriati durante lo sviluppo.
-
Burn-Down (Burn-Up) Chart
I Burn-Down e Burn-Up Chart sono rappresentazioni grafiche che mostrano l'avanzamento del lavoro rispetto al tempo trascorso.
-
Business Agility
La Business Agility è la capacità di competere e prosperare nell'era digitale, rispondendo rapidamente ai cambiamenti del mercato e alle nuove opportunità con soluzioni aziendali innovative e digitali.
-
Business and Technology
Business and Technology in SAFe rappresenta il modo con cui i domini funzionali dell'intera enterprise abilitano la Business Agility attraverso la continua esplorazione rispetto a come applicare i principi e le pratiche Lean-Agile in un contesto specifico.
-
Business Context (Contesto di business)
Il Business Context è un punto all'ordine del giorno del PI Planning, presentato da un Business Owner, il quale descrive lo stato attuale dell'impresa, condivide la Portfolio Vision e presenta una panoramica su come le soluzioni proposte possano dare una risposta alle esigenze attuali dei clienti.
-
Business Owner
I Business Owner sono un piccolo gruppo di stakeholder respopnsabili , sia a livello di business che tecnico, per la governance, la conformità e il ritorno sull'investimento (ROI) di una Solution sviluppata da un Agile Release Train (ART). Sono gli stakeholder principali dell'ART, che devono valutare l'idoneità allo scopo e partecipare attivamente a determinati eventi dell'ART.
C
-
CALMR
L'approccio CALMR alle pratiche DevOps proposto da SAFe, promuove l'erogazione di valore continuo, gestendo al contempo i progressi a livello di cultura, automazione, flusso lean, misurazioni continue e recovery all'interno di un ART.
-
Capability
Una Capability è un comportamento della Solution che in genere si estende su più ART. Le Capability vengono dimensionate e suddivise in più Feature per facilitarne l’implementazione nel corso di un singolo Program Increment (PI).
-
Capacity Allocation (Allocazione di capacità)
L'allocazione di capacità rappresenta uno dei Lean Budget Guardrail per i vari Backlog, che aiuta a bilanciare il carico di lavoro tra Feature, Enabler e debito tecnico nell'ambito della PI.
-
Committed PI Objectives
I Committed PI Objectives sono un insieme di obiettivi SMART che vengono formulati da ogni team per ciascun PI, con un valore di business assegnato dai Business Owner.
-
Community of Practice, CoP
Le comunità di pratica (CoP) sono gruppi organizzati di persone che hanno un interesse comune in uno specifico dominio tecnico o di business. Collaborano regolarmente per condividere informazioni, migliorare le proprie competenze e lavorare attivamente per far progredire la conoscenza generale del dominio.
-
Compliance (conformità)
La conformità si riferisce non solo all'aspetto strategico ma anche alle attività ed agli artefatti che consentano ai team di poter applicare i metodi di sviluppo Lean-Agile per creare sistemi caratterizzati da un elevato livello di qualità, assicurando, al contempo, il rispetto di eventuali standard qualitativi normativi e specifici di settore.
-
Confidence Vote (Voto di confidenza)
Il Confidence Vote ha luogo verso la fine del PI Planning, quando i team votano in merito al livello di confidenza nel portare a termine i PI Objectives.
-
Continuous Delivery Pipeline, CDP
La CDP rappresenta i flussi di lavoro, le attività e l'automazione necessari per guidare una nuova funzionalità dall'ideazione al release on-demand di valore per l'utente finale.
-
Continuous Deployment, CD
Il Continuous Deployment è il processo che permette di distribuire le Features approvate da un ambiente di staging ad uno di produzione, pronte per essere rilasciate.
-
Continuous Exploration, CE
Continuous Exploration (CE) è il processo che guida l’innovazione e promuove l’allineamento su cosa si dovrebbe realizzare in risposta ad una determinata esigenza, esplorando continuamente le esigenze dei clienti e del mercato, e definendo una Vision, una Roadmap ed una serie di Feature per realizzare una soluzione che sia in grado di soddisfare tali esigenze.
-
Continuous Integration, CI
Continuous Integration (CI) è il processo mediante il quale vengono prese delle Feature dal Program Backlog per svilupparle, testarle, integrarle e convalidarle in un ambiente di staging dove saranno pronte per essere portate in produzione e quindi rilasciate.
-
Continuous Learning Culture, CLC
La Continuous Learning Culture rappresenta una delle competenze per la Business Agility e descrive un insieme di valori e pratiche che incoraggiano i singoli individui – e l’intera organizzazione – ad accrescere continuativamente la conoscenza, le competenze, la performance e l’innovazione.
-
Core Values (Valori Fondanti)
I Core Values di SAFe sono quattro: Alignment, Built-in Quality, Transparency, Program Execution. Essi rappresentano i valori fondanti per l'efficace adozione del framework SAFe e guidano i comportamenti e le azioni per chiunque sia coinvolto in un SAFe Portfolio.
-
Cost of Delay, CoD (Costo del ritardo)
Il Cost of Delay (CoD) costituisce il denaro o il valore perso del ritardare o non fare un lavoro in un certo periodo di tempo e viene usato nella prioritizzazione con il metodo WSJF.
-
Customer (Cliente)
I Clienti sono coloro che consumano il valore delle soluzioni di business create e gestite dai Value Stream all'interno del Portfolio
-
Customer Centricity, CC (Centralità del cliente)
La Customer Centricity è una mentalità e un modo di fare business che si focalizza sulla creazione di valore per il Cliente attraverso l'intera gamma di prodotti e servizi offerti dall'impresa.
-
Customer Journey Map
La Customer Journey Map illustra l'esperienza dell'utente nell'interazione con gli Operational Value Stream, i prodotti e i servizi di un'azienda.
D
-
Daily Stand-Up, DSU
Il Daily Stand-Up (DSU) è un evento giornaliero in cui ogni membro dell'Agile Team descrive le attività svolte il giorno precedente e quelle a cui intende dedicarsi nella giornata corrente per raggiungere gli obiettivi dell'iterazione, nonché qualsiasi ostacolo riscontrato per il raggiungimento di tali obiettivi.
-
Decision-making decentralizzato
Il Decision Making decentralizzato conferisce l'autorità decisionale a coloro che sono più vicini al problema ed hanno le informazioni, in modo da ridurre i ritardi, aumentare il flusso di sviluppo del prodotto e migliorare la qualità delle decisioni.
-
Definition of Done
La Definition of Done determina il completamento di un incremento di valore e favorisce una comprensione condivisa di quali attività debbano essere completate nel contesto di un incremento.
-
-
Design Thinking
Il Design Thinking è un processo di sviluppo incentrato sul cliente, che aiuta a creare prodotti appetibili, redditizi e sostenibili durante l'intero ciclo di vita.
-
Develop on Cadence
Il Develop on Cadence è un insieme coordinato di pratiche che supportano gli Agile Team fornendo una serie di eventi e attività secondo tempistiche regolari e prevedibili.
-
Development Value Stream
Un Development Value Stream è una sequenza di attività necessarie per trasformare un'ipotesi di business in una soluzione. Alcuni esempi possono essere la progettazione di un dispositivo medico o di un satellite metereologico oppure lo sviluppo e la distribuzione di un'applicazione software, di un sistema SaaS o di un sito Web di e-commerce.
-
DevOps
Il DevOps è una mentalità, una cultura ed un insieme di pratiche tecniche. Consente la comunicazione, l’integrazione, l’automazione e la stretta collaborazione tra tutte le persone coinvolte nella gestione, nella pianificazione, nello sviluppo, nel collaudo, nell’implementazione, nel rilascio e nella manutenzione di una Solution.
E
-
Empathy Map (Mappa dell'empatia)
L'Empathy Map è uno strumento di Design Thinking che aiuta i team a sviluppare una comprensione profonda e condivisa dei propri clienti.
-
Enabler
Un Enabler rappresenta le attività necessarie all'estensione della Architectural Runway per supportare le future funzionalità di business. Tra queste attività vi sono l’esplorazione, l’architettura, l’infrastruttura e la compliance. Gli Enabler vengono utilizzati nei diversi Backlog e sono presenti in tutto il framework.
-
Enterprise (impresa)
L’Enterprise rappresenta l'entità organizzativa alla quale appartiene ciascun portfolio SAFe.
-
Enterprise Architect
L'Enterprise Architect ha il compito di stabilire una strategia tecnologica e una roadmap che consenta ad un Portfolio di supportare le capacità di business attuali e future.
-
Enterprise Solution Delivery
La Enterprise Solution Delivery è una competenza che descrive come applicare i principi e le pratiche Lean-Agile alla definizione, allo sviluppo, alla distribuzione, al funzionamento e all’evoluzione delle applicazioni, delle reti e dei sistemi cyber-fisici più grandi al mondo.
-
Epic Hypothesis Statement (Dichiarazione di ipotesi di epica)
La Epic Hypothesis Statement comprende, organizza e trasmette informazioni cruciali relative a un'epica.
-
Epic Owner
Gli Epic Owner sono i responsabili del coordinamento delle Portfolio Epic attraverso il Portfolio Kanban. Gli Epic Owner definiscono collaborativamente l'Epic, inclusi il Minimum Viable Product (MVP) e il Lean Business Case e una volta approvata, ne facilitano l’implementazione.
-
Epic (Epica)
L'Epic è un contenitore per un’iniziativa rilevante, volta allo sviluppo di una soluzione e che rappresenta gli investimenti più sostanziali che si verificano all’interno di un portfolio. Vista la dimensione e l'impatto, l'Epic richiede la definizione di un Minimum Viable Product (MVP) e l’approvazione da parte del Lean Portfolio Management (LPM) prima di passare alla fase di implementazione.
-
Essential SAFe
La configurazione Essential SAFe contiene il set minimo di ruoli, eventi e artefatti necessari a rilasciare soluzioni in forma continua attraverso un singolo ART.
-
Estimating Poker
L'Estimating Poker è la tecnica collaborativa che viene usata in SAFe per stimare relativamente le Story, le Feature e nel WSJF.
-
Extreme Programming, XP
L'Extreme Programming (XP) è un insieme di pratiche Agile sviluppato principalmente da Kent Beck, che contribuiscono a migliorare la qualità del software e ad aumentarne l'adattabilità ai cambiamenti dei requisiti dei clienti.
F
-
Feature (Funzionalità)
Una Feature è un servizio che soddisfa le esigenze di uno o più stakeholder. Ogni Feature include un’ipotesi sui benefici, dei criteri di accettazione ed è dimensionata o suddivisa in modo da poter essere completata da un singolo ART nell'arco di un Incremento di Programma (PI).
-
Final Plan Review (Revisione del piano definitivo)
Durante la Final Plan Review, che si svolge nell'ambito del PI Planning, gli Agile Team presentano i piani definitivi (i PI Objective, carico e rischi) affinché vengano comunicati all'ART e approvati dai Business Owner.
-
Foundation (fondamenta)
Le fondamenta di SAFe contengono i principi, i valori, il mindset, la guida all’implementazione e i ruoli di leadership necessari per fornire efficacemente valore.
-
Full SAFe
Full SAFe è la configurazione più completa ed include tutte le 7 competenze necessarie per la Business Agility.
G
-
Gemba
Il Gemba è il luogo dove viene eseguito il lavoro e dove gli Agile Team possono osservare come gli stakeholder eseguono gli step e le attività specifiche nell'Operational Value Stream, per identificare al meglio le opportunità di miglioramento continuo.
H
-
Hackathon
Gli Hackathon sono eventi di innovazione dove i membri del team possono lavorare su qualsiasi cosa vogliano, con chiunque vogliano, a patto che il lavoro sia in linea con la missione dell'azienda e che il lavoro venga presentato ai colleghi al termine dell'Hackathon.
I
-
IP Iteration, Innovation and Planning Iteration
L'Innovation and Planning Iteration (IP) ha luogo in corrispondenza della fine di ogni Incremento di Programma (PI) e soddisfa una pluralità di scopi. Funziona da buffer per il raggiungimento dei PI Objectives, fornisce tempo specificamente dedicato all'innovazione ed alla formazione continua e permette di organizzare gli eventi di PI Planning e Inspect and Adapt (I&A).
-
Inspect & Adapt, I&A
L'Inspect and Adapt (I&A) è un importante evento che ha luogo al termine di ogni Incremento di Programma (PI), durante il quale un ART presenta e valuta lo stato attuale della Solution. Inoltre, applicando un processo di problem solving strutturato, i team e gli stakeholder dell'ART riflettono su quanto accaduto durante il PI appena trascorso ed individuano le azioni di miglioramento da inseire nel backlog.
-
Integration Point (Punto di integrazione)
L' Integration Point crea un "evento pull" che concentra i diversi elementi della Solution in un insieme integrato, utile per aiutare gli stakeholder a garantire che la soluzione in fase di sviluppo risponda a esigenze aziendali reali e future.
-
Orizzonti di investimento
Gli orizzonti di investimento evidenziano gli stanziamenti per le Solution create dai Value Stream, che aiutano i Business Owner e gli stakeholder del flusso di valore a prendere decisioni di investimento più consapevoli, allineando il portafoglio con i temi strategici, promuovendo al contempo la salute e la crescita generali.
-
Iteration (iterazione)
L'Iteration è l'elemento portante dello sviluppo Agile. Ogni iterazione è un intervallo di tempo prestabilito e di durata fissa, durante il quale gli Agile Team rilasciano valore sotto forma di incrementi funzionanti e collaudati della soluzione. La durata consigliata per l’iterazione è di due settimane. Tuttavia, è accettabile un periodo compreso tra una e quattro settimane, in base al contesto.
-
Iteration Execution
Iteration Execution è la modalità con cui i team Agile eseguono il proprio lavoro durante l'Iterazione, risultando in un incremento della soluzione funzionante, collaudata e caratterizzata da un alto livello di qualità.
-
Iteration Goal
Gli Iteration Goal rappresentano descrizioni di alto livello degli obiettivi tecnici e di business che gli Agile Team si prefiggono di perseguire nell'ambito di una iterazione. Questi sono fondamentali per il coordinamento di un ART che è costituito da team auto-organizzati ed auto-gestiti.
-
Iteration Planning
L’Iteration Planning è l'evento durante il quale tutti i membri dei team stabiliscono la porzione di Team Backlog che il team si impegna a realizzare nella prossima iterazione. Il team sintetizza il lavoro da svolgere attraverso una serie di Iteration Goal.
-
Iteration Retrospective (Retrospettiva dell’iterazione)
La Iteration Retrospective è un evento a cadenza regolare dove i membri dell'Agile Team discutono dei risultati dell'iterazione, riesaminano le loro pratiche e identificano modi per migliorare.
-
Iteration Review
L’Iteration Review è un evento cadenzato alla fine di ogni Iteration, durante il quale ciascun team ispeziona l’incremento di valore realizzato dal team stesso, per valutarne i progressi e quindi adattare il backlog per l’iterazione successiva.
K
-
Knowledge Worker
Il Knowledge Worker è una persona dotata di competenze, capacità e formazione necessarie per risolvere problemi complessi nel rispettivo ambito di competenza.
L
-
Large Solution SAFe
Il Large Solution SAFe è una configurazione che descrive gli ulteriori ruoli, pratiche e linee guida necessari per creare e sviluppare le applicazioni, le reti ed i sistemi cyber-fisici più grandi al mondo.
-
Lead Time (Tempo di esecuzione)
Il Lead Time è il tempo che intercorre tra la conclusione del lavoro nella fase precedente e la conclusione del lavoro nella fase attuale.
-
Lean
Il Lean è un insieme di conoscenze e pratiche per migliorare l'efficienza e l'efficacia, riducendo i ritardi ed eliminando le attività prive di valore aggiunto.
-
Lean Budget Guardrails
I Lean Budget Guardrail stabiliscono le politiche e le pratiche di budget, di spesa e di governo all'interno di uno specifico portfolio.
-
Lean Budget
Il Lean Budget è un approccio Lean Agile per ottenere una governance finanziaria efficace, in grado di aumentare la produzione e la produttività attraverso la riduzione dell'overhead e dei costi di gestione contabile del progetto.
-
Lean Business Case, LBC
Il Lean Business Case (LBC) è un approccio snello alla descrizione delle epiche, inclusi i rispettivi MVP e il valore di business previsto.
-
Lean Governance
La Lean Governance è una dimensione del Lean Portfolio Management che supporta la supervisione e il processo decisionale per quanto riguarda le spese, la revisione, la compliance, le previsioni di spesa e le misurazioni.
-
Lean Portfolio Management
Il Lean Portfolio Management è una delle 7 competenze essenziali per la Business Agility e si occupa di allineare la strategia con l'esecuzione, applicando i principi Lean Agile a strategia e investimenti, operazioni di portfolio agile e governance.
-
Lean Quality Management System, QMS (Sistema di gestione della qualità)
Il Lean Quality Management System (QMS) definisce le pratiche, le politiche e le procedure necessarie per confermare la sicurezza e l'efficacia di una soluzione. In un'organizzazione SAFe si promuove il passaggio da una logica di gestione della qualità di tipo tradizionale ad una fondata sui principi Lean-Agile.
-
Lean User Experience, Lean UX
Il Lean User Experience (Lean UX) è allo stesso tempo un mindset, una cultura e un processo che adotta i metodi Lean-Agile. Il Lean UX implementa le funzionalità attraverso un approccio incrementale di fattibilità minima e ne determina il successo misurando i risultati rispetto ai benefici attesi.
-
Lean-Agile Center of Excellence (Centro di eccellenza Lean-Agile)
Il Lean-Agile Center of Excellence (LACE) è un piccolo team di persone dedicato all'implementazione delle modalità di lavoro Lean-Agile SAFe.
-
Lean-Agile Leadership
La competenza Leadership Lean-Agile descrive come i Leader guidino e sostengano il cambiamento organizzativo oltre all'eccellenza operativa, mettendo le persone e i team in condizione di dare il meglio di sé.
-
Lean-Agile Mindset
Il mindset Lean-Agile è la combinazione delle convinzioni, delle ipotesi, degli atteggiamenti e delle azioni dei leader e di coloro che praticano SAFe e che adottano i principi del Manifesto Agile e del pensiero Lean. È il fondamento personale, intellettuale e di leadership per l'adozione e l'applicazione delle pratiche e dei principi di SAFe.
-
Lean-Agile Principles
SAFe si basa su dieci principi Lean-Agile fondamentali ed immutabili. Questi fondamenti e concetti economici ispirano e plasmano i ruoli e le pratiche di SAFe.
-
Legge di Little
La legge di Little è un teorema sulla teoria delle code che afferma come Il tempo di risposta di un sistema è uguale al rapporto tra la lunghezza media degli elementi presenti nel sistema e il tempo medio di elaborazione di una singola richiesta.
M
-
Measure and Grow
Measure & Grow è la modalità con cui i portfolio valutano i progressi compiuti in termini di Business Agility e ne determinano i passi successivi di miglioramento.
-
Metric (Metriche)
Le metriche sono misure condivise utilizzate per valutare con che efficacia l’organizzazione stia procedendo verso il raggiungimento degli obiettivi (di business e tecnici) a livello di Portfolio, Large Solution, ART e team.
-
Milestone
Le Milestone vengono utilizzate per monitorare i progressi realizzati rispetto a uno specifico obiettivo o evento. Esistono tre tipi di milestone in SAFe: Program Increment (PI), fixed-date e milestone di apprendimento.
-
Minimum Marketable Feature, MMF
La Minimum Marketable Feature (MMF) è la funzionalità minima che i team possono realizzare per valutare se la Benefit Hypotesis della Feature è valida o meno.
-
Minimum Viable Product, MVP
In SAFe, un Minimum Viable Product (MVP) è una versione preliminare e minima di un nuovo prodotto o soluzione di business utilizzata per provare o smentire l'Hypotesis dell'Epic. Rispetto ad altre tecniche di esplorazione quali storyboard, prototipi, mock-up o wireframe, l'MVP è un vero e proprio prodotto utilizzato da clienti reali per generare un apprendimento basato sui fatti.
-
Model-Based Systems Engineering, MBSE
Il Model-Based Systems Engineering (MBSE) è la pratica che sviluppa un insieme di modelli di sistema correlati con cui definire, progettare e documentare un sistema in fase di realizzazione. Questi modelli offrono un metodo efficiente di indagine, aggiornamento e comunicazione delle caratteristiche del sistema, consentendo al contempo di ridurre significativamente o eliminare l'utilizzo di documentazione di tipo tradizionale.
-
Sequenza di Fibonacci normalizzata
La sequenza di Fibonacci Normalizzata (1, 2, 3, 5, 8, 13, 20, 40, 100) viene utilizzata in SAFe per rappresentare l'incertezza intrinseca all'aumentare delle dimensioni del lavoro da stimare.
N
-
Nonfunctional Requirement, NFR
I requisiti non funzionali (NFR) definiscono gli attributi di sistema quali sicurezza, affidabilità, prestazione, manutenibilità, scalabilità e usabilità. Essi fungono da vincoli o restrizioni alla progettazione e sviluppo delle soluzioni nei diversi backlog.
O
-
Objectives and Key Results, OKR
In SAFe, gli OKR possono essere utilizzati per definire, organizzare e comunicare informazioni essenziali relative a temi strategici e monitorarne il progresso attraverso azioni concrete, specifiche e misurabili.
-
Operational Value Stream, OVS
Un Operational Value Stream (OVS) è una sequenza di attività necessarie per fornire un prodotto o un servizio ad un cliente. Alcuni esempi possono essere la creazione di un prodotto, l'evasione di un ordine, l'ospedalizzazione ed il trattamento di un paziente, la concessione di un prestito oppure la fornitura di un servizio professionale.
-
Organizational Agility
La competenza Organizational Agility descrive come le persone che applicano il pensiero Lean e i team Agili ottimizzano i propri processi di business, evolvono la strategia con impegni chiari e decisivi e adattano rapidamente l'organizzazione secondo necessità per sfruttare al meglio le nuove opportunità nel mercato.
-
Organizational Change Management (Gestione del cambiamento organizzativo)
L'Organizational Change Management è un termine che si riferisce a tutti gli approcci per preparare, aiutare e sostenere le persone, i team e l'azienda per affrontare i cambiamenti organizzativi.
P
-
Analisi di Pareto
L'analisi di Pareto è una tecnica utilizzata durante un evento di Inspect & Adapt per identificare il numero minimo di azioni che produca complessivamente il maggior impatto.
-
Participatory Budgeting, PB
il Participatory Budgeting (PB) è il processo utilizzato nel Lean Portfolio Management (LPM) per ripartire l'intero budget di portfolio tra i vari Development Value Stream.
-
Personas
Le Personas sono modelli idealizzati di utente derivanti da ricerche di mercato e che promuovono uno sviluppo del prodotto orientato al cliente.
-
Phase Gate
Il Phase Gate rappresenta una milestone di progetto tradizionale che in SAFe è sostituita da una milestone basata sulla valutazione oggettiva della Soluzione.
-
PI Objective (Obiettivo del PI)
Gli obiettivi di PI sono una sintesi degli obiettivi tecnici e di business che un team Agile o un ART intendono raggiungere nel successivo Incremento di Programma (PI).
-
Plan-Do-Check-Adjust
Il Plan-Do-Check-Adjust (PDCA) è un metodo iterativo a quattro fasi utilizzato per gestire la variabilità ed effettuare adeguamenti in risposta ai feedback ricevuti nel corso dello sviluppo del prodotto.
-
Portfolio
In SAFe, il Portfolio allinea la strategia aziendale all'esecuzione attraverso un insieme di Develpment Value Stream che operano sotto lo stesso modello di governo. Un Development Value Stream realizza una o più Solution necessarie affinché l'organizzazione possa compiere la propria mission aziendale.
-
Portfolio Backlog
Il Portfolio Backlog è il livello di backlog più elevato di SAFe. Esso raccoglie le future Epic ed Enabler destinate a creare e sviluppare un insieme completo di soluzioni.
-
Portfolio Canvas
Il Portfolio Canvas descrive i Development Value Stream inclusi in un portfolio SAFe, l'offerta, le soluzioni proposte, i clienti, i budget allocati e le altre attività necessarie per ottenere la Portfolio Vision.
-
Portfolio Kanban
Il Portfolio Kanban è un metodo utilizzato per visualizzare e gestire il flusso delle Epics di Portfolio, partendo dalla loro ideazione, passando per la fase di analisi, di implementazione e di completamento.
-
Portfolio SAFe
Il Portfolio SAFe allinea la strategie all’esecuzione, e organizza lo sviluppo di soluzioni intorno al flusso di valore all'interno di uno o più value stream.
-
Portfolio Vision
La Portfolio Vision è una descrizione proiettata nel futuro dei flussi di valore e delle soluzioni all'interno di uno stesso portfolio; essa descrive come questi dovranno collaborare al raggiungimento degli obiettivi del portfolio e dell’azienda nel suo insieme.
-
Pre- & Post-PI Planning
Gli eventi di Pre- e Post-PI Planning servono a preparare le PI Planning e, una volta terminate, come follow-up e allineamento per l'intero Solution Train, inclusi gli ART e i fornitori esterni.
-
Problem-Solving Workshop
Il Problem-Solving Workshop è una tecnica strutturata per trovare la causa radice dei problemi sistemici e viene svolto nell'ambito di un evento Inspect & Adapt.
-
Product Management
Il Product Management ha il compito di definire e supportare la creazione di prodotti e soluzioni desiderabili, fattibili, realizzabili e sostenibili, che soddisfino le esigenze dei clienti durante tutto il ciclo di vita del prodotto nel mercato.
-
Product Owner, PO
Il Product Owner (PO) è un membro del team Agile ed è responsabile della definizione delle Storie e della prioritizzazione del Team Backlog relativo alle attività di programma, mantenendone l’integrità concettuale e tecnica.
-
Product Owner (PO) Sync
Il PO Sync è un evento dell'ART che consente di avere una visione dei progressi rispetto al raggiungimento dei PI Objective, discutere dei problemi o opportunità e valutare eventuali adeguamenti di ambito.
-
Program Backlog
Il Program Backlog raccoglie le prossime Feature, pensate per soddisfare i bisogni del cliente ed introdurre vantaggi di business in un singolo ART; contiene inoltre le "Enabler Feature", funzionalità abilitanti, necessarie alla costruzione dell’Architectural Runway.
-
Program Board
La Program Board evidenzia le date di consegna delle Feature, le dipendenze tra i team e le milestone più rilevanti.
-
Program Increment, PI
Un incremento di programma (PI) è un intervallo di tempo fisso durante il quale un ART genera valore incrementale sotto forma di software funzionante e sistemi. I PI hanno una durata compresa tra le 8 e le 12 settimane. Lo schema più comune per un PI è di quattro iterazioni di sviluppo, seguite da una iterazione di Innovazione e Pianificazione (IP).
-
PI Planning, Program Increment Planning
Il PI Planning è un evento cadenzato, organizzato in presenza, che rappresenta il ritmo vitale dell’ART, allineando tutti i team verso una missione ed una vision condivisa.
-
Program Kanban
Le Kanban a livello di Program e di Large Solution sono metodi di visualizzazione e gestione del flusso di Feature e Capability, dalla loro ideazione, passando per la fase di analisi, di implementazione e di rilascio attraverso la Continuous Delivery Pipeline.
-
Program Predictability Measure
La Program Predictability Measure riporta i Business Value reali rispetto a quelli pianificati per tutti i team all'interno dell'ART e costituisce un indicatore fondamentale della performance e della predicibilità dell'ART.
-
Program Risks
I Program Risk vengono identificati dai team durante la PI Planning e rappresentano i rischi e gli impedimenti che potrebbero impattare sulla loro capacità di raggiungere gli obiettivi.
R
-
Refactoring
ll Refactoring è l'attività di miglioramento della struttura o del funzionamento di un codice o di un componente senza modificarne il comportamento funzionale.
-
Relative Estimation (Stima relativa)
La stima relativa mette a confronto Work Package diversi tra loro per stimarne rapidamente le dimensioni ed il valore.
-
-
Release on Demand
La Release on Demand è il processo che predispone le nuove funzionalità in produzione e le rende disponibili ai clienti, immediatamente o in modo incrementale, in base alle necessità.
-
Release Train Engineer, RTE
Il Release Train Engineer (RTE) è il servant leader e coach dell’ART. Le principali responsabilità dell’RTE sono facilitare gli eventi e supportare i processi dell'ART, nonché sostenere i team nel generare valore. L'RTE si confronta con gli stakeholder, gestisce l'escalation degli impedimenti, contribuisce alla gestione del rischio e guida il processo di miglioramento continuo.
-
Relentless Improvement
La Relentless Improvement è il quarto pilastro della SAFe House of Lean ed incoraggia l'apprendimento e l'evoluzione attraverso una continua riflessione ed un incessante miglioramento dei processi.
-
Roadmap
La Roadmap è una schedulazione di eventi e milestone volta a comunicare i principali deliverable di una soluzione rispetto ad un orizzonte temporale concordato.
-
ROAMing Risks
Il Risk ROAMing è un'attività che si svolge in occasione della PI Planning in cui i rischi a livello di ART, sollevati dai team, vengono discussi e classificati in 4 categorie differenti (Resolved, Owned, Accepted e Mitigated).
-
Root Cause Analysis
La Root Cause Analysis è una pratica di risoluzione dei problemi per identificarne le cause radice e viene svolta nell'ambito di un evento Inspect & Adapt.
S
-
SAFe Big Picture, BP
La SAFe Big Picture (BP) è una rappresentazione grafica dei principali ruoli, attività e artefatti del framework SAFe, che permette di accedere ai vari contenuti presenti su scaledagileframework.com attraverso un click sulle relative icone.
-
SAFe for Government
SAFe for Government è un insieme di modelli di comprovato successo che aiutano le organizzazioni del settore pubblico a implementare pratiche Lean-Agile in un contesto governativo.
-
SAFe for Lean Enterprise
SAFe for Lean Enterprise è il framework più affermato a livello globale per la Business Agility. SAFe integra il potenziale di Lean, Agile e DevOps in un sistema operativo completo, che aiuta le imprese a prosperare nell'era digitale fornendo prodotti e servizi innovativi più rapidamente, con maggiore prevedibilità e con una qualità più elevata.
-
SAFe Implementation Roadmap
La roadmap di implementazione di SAFe consiste in una rappresentazione grafica ed una serie di 12 articoli che descrivono una strategia ed un insieme ordinato di attività che si sono dimostrate efficaci nell’implementazione ottimale di SAFe.
-
SAFe Lean Startup Cycle
Il SAFe Lean Startup Cycle è un ciclo fortemente iterativo di costruzione-misurazione-apprendimento per l'innovazione del prodotto e gli investimenti strategici. Questa strategia di implementazione delle epiche fornisce i vantaggi economici e strategici di una start-up Lean grazie alla gestione incrementale degli investimenti e del rischio, sfruttando allo stesso tempo i benefici SAFe relativi al flusso e alla visibilità.
-
SAFe Program Consultant, SPC
Il SAFe Program Consultant (SPC) è un agente del cambiamento che combina la conoscenza tecnica di SAFe con una naturale propensione al miglioramento dei processi di sviluppo software e dei sistemi dell'azienda. Ricopre un ruolo essenziale nell’implementazione efficace di SAFe. Gli SPC sono normalmente figure interne o esterne all'organizzazione, sia legati al business e sia all'area tecnica, tra cui portfolio manager, program e project manager, process lead, architetti, analisti e consulenti.
-
Scrum Master
Lo Scrum Master è il servant leader ed il coach di un team Agile. Gli Scrum Master contribuiscono a educare il team sui temi che riguardano Scrum, eXtreme Programming (XP), Kanban e SAFe, assicurando che il processo Agile concordato venga applicato. Essi aiutano inoltre a rimuovere eventuali ostacoli e promuovono un ambiente adatto a dinamiche di team performanti, con un flusso di valore ed un processo di miglioramento continuo.
-
Scrum of Scrums
Lo Scrum of Scrums (SoS) è un evento a livello ART per gestire le dipendenze tra i vari team all'interno di un ART e fornire visibilità sullo stato di avanzamento delle Feature e sugli impedimenti.
-
ScrumXP
Lo ScrumXP è un processo che consente ai team cross-funzionali e auto-organizzati di rilasciare valore all'interno di SAFe. ScrumXP combina la potenza delle pratiche Scrum con le pratiche dell’eXtreme programming (XP).
-
Set-Based Design
Set-Based Design (SBD) è una pratica che consente di mantenere il più a lungo possibile la flessibilità dei requisiti e delle opzioni di design durante il processo di sviluppo. Invece di scegliere in anticipo un’unica soluzione, SBD individua e contemporaneamente esplora le diverse opzioni, eliminando nel tempo le scelte meno efficaci. Esso promuove la flessibilità nell’ambito del processo di progettazione dedicandosi alle soluzioni tecniche solo dopo aver convalidato le ipotesi sottostanti, che producono i migliori risultati economici.
-
Shared Service
Gli Shared Service rappresentano gli specialisti, le persone, e i servizi che sono necessari al successo di un ART o un Solution Train, ma che non possono esservi dedicati a tempo pieno.
-
Silos
Il silo è una struttura organizzata per funzione, che comprende specialisti, politiche e procedure e garantisce l'efficienza e la ripetibilità delle attività, senza però considerare come il valore fluisce tra silo diversi.
-
Solution
Ogni Development Value Stream realizza una o più Solution, ovvero prodotti, servizi o sistemi resi disponibili per il cliente, sia interno che esterno all’impresa.
-
Solution Architect/Engineer
Il Solution Architect/Engineer ha il compito di definire e comunicare una visione tecnica e architetturale condivisa all'interno del Solution Train, contribuendo a garantire che il sistema o la Solution in sviluppo sia allineata allo scopo prefissato.
-
Solution Backlog
Il Solution Backlog raccoglie le Capability e gli Enabler in entrata, ognuno dei quali può interessare uno o più ART, ed è pensato per far progredire la Solution e predisporre l'Architectural Runway.
-
Solution Context
Il Solution Context descrive gli aspetti rilevanti dell'ambiente in cui opera la Solution. Fornisce una comprensione essenziale dei requisiti, dell’utilizzo, dell’installazione, della gestione operativa e del supporto alla soluzione stessa. Il Solution Context influenza significativamente le opportunità e i vincoli per il release on-demand.
-
Solution Demo
La Solution Demo integra il lavoro di sviluppo di tutti gli ART e dei fornitori realizzati da un Solution Train durante ciascun incremento di programma e lo rende visibile ai clienti e ad altri stakeholder per ottenerne valutazioni e feedback.
-
Solution Intent
Il Solution Intent è il repository per l'archiviazione, la gestione e la comunicazione di ciò che si conosce dei comportamenti attuali e previsti della Solution. Quando richiesto, comprende le specifiche e la progettazione sia fissa sia variabile, i riferimenti agli standard applicabili, ai modelli di sistema, ai test funzionali e non funzionali e alla tracciabilità.
-
Solution Management
Il Solution Management ha il compito di definire e supportare la creazione di soluzioni di business auspicabili, fattibili, praticabili e sostenibili su larga scala, che siano in grado di soddisfare nel tempo le esigenze del cliente.
-
Solution Train
Il Solution Train è il costrutto organizzativo utilizzato per la creazione di Solution grandi e complesse che richiede il coordinamento di più ART, nonché il contributo di Supplier esterni. Gli ART all'interno del Solution Train vengono allineati intorno ad una mission tecnologica e di business condivisa grazie alla Vision, al Backlog, alla Roadmap di prodotto e ad un PI allineato.
-
Solution Train Engineer, STE
Il Solution Train Engineer (STE) agisce da servant leader e coach per un singolo Solution Train, facilita e guida il lavoro di ART e Supplier all'interno di un Development Value Stream.
-
Spanning Palette
La Spanning Palette contiene diversi ruoli ed artefatti applicabili a un particolare contesto di team, program, large solution o portfolio.
-
Spike
Lo Spike è un tipo di Enabler Story della categoria Exploration che permette di acquisire informazioni necessarie a ridurre il rischio relativo ad una scelta tecnica, comprendere meglio un requisito o aumentare l'affidabilità della stima di una determinata User Story funzionale.
-
Sprint
Lo Sprint è un termine del framework Scrum ed è sinonimo di Iteration in SAFe.
-
Stories (storie)
Una Story è una breve descrizione di una piccola porzione di funzionalità desiderata, scritta utilizzando il linguaggio dell’utente. I team Agili implementano piccole sezioni verticali di una funzionalità, che vengono dimensionate in modo da essere completate in una singola iterazione.
-
Story Map
La Story Map è una delle tecniche usate nel Design Thinking che permette di organizzare User Story in sequenza sulla base delle attività e delle necessità di un utente per il raggiungimento dell'obiettivo.
-
Story Point
Lo Story Point è un numero intero utilizzato nella stima relativa che rappresenta un insieme di quantità: volume, complessità, conoscenza ed incertezza.
-
Strategic Theme (Temi Strategici)
I Temi Strategici sono obiettivi di business, che collegano il Portfolio alla strategia dell’impresa. Forniscono un contesto di business al processo decisionale all'interno del Portfolio e ne influenzano la strategia.
-
Sunk Costs
I Sunk Cost si riferiscono alle spese già sostenute, che dovrebbero essere ignorate nel prendere decisioni di investimento per il futuro quando si vuole cambiare rotta.
-
Supplier (Fornitore)
Un Fornitore è un'organizzazione interna o esterna che sviluppa e fornisce componenti, sottosistemi o servizi che consentono ai Solution Train e agli di realizzare le Solution per i propri clienti.
-
SWOT Analysis
La SWOT Analysis è una tecnica di pianificazione strategica per identificare i punti di forza, le debolezze, le opportunità e le minacce relative alla situazione aziendale e viene utilizzata per definire la Portfolio Vision.
-
System Architect/Engineering
Il System Architect/Engineer ha la responsabilità di definire e comunicare una visione tecnica e architetturale condivisa all'interno dell'ART, contribuendo a garantire che il sistema o la soluzione in fase di sviluppo sia idonea allo scopo previsto.
-
System Demo
La System Demo è un evento cardine, che fornisce una visione integrata delle nuove Feature realizzate da tutti i team all'interno dell'ART durante l'ultima iterazione. Ciascuna Demo fornisce agli stakeholder una misura oggettiva dei progressi compiuti dall'ART durante un PI.
-
System Team
Il System Team è un team Agile specializzato che partecipa a costruire e dare supporto all'ambiente di sviluppo agile, includendo di solito lo sviluppo e la manutenzione degli strumenti a supporto della Continuous Delivery Pipeline. Il System Team può anche dare assistenza all’integrazione degli asset dei team Agili, eseguire quando necessario i test end-to-end della Solution e fornire assistenza per il deployment e la release on-demand.
-
Systems Thinking
Il Systems Thinking è un approccio olistico allo sviluppo di soluzioni, che tiene conto di tutti gli aspetti relativi alla progettazione, sviluppo, implementazione e manutenzione di un sistema complesso.
T
-
Team and Technical Agility
La competenza "Team e Technical Agility" descrive le competenze chiave, i principi e le pratiche Lean-Agile che i team Agili altamente performanti e gli ART utilizzano per creare soluzioni di qualità per i propri clienti.
-
Team Backlog
Il Team Backlog contiene le User Story e le Enabler Story che hanno origine dal Program Backlog; inoltre contiene le story che hanno origine nel contesto locale in cui il team opera. Il Team Backlog può includere anche altre tipologie di lavoro, rappresentando tutto quello che un team deve realizzare per fare avanzare la propria parte del sistema.
-
Team Kanban
Il Team Kanban è un metodo che aiuta i team ad agevolare il flusso di valore, visualizzando il workflow, fissando dei limiti per il work-in-progress (WIP), misurando la quantità di lavoro svolto e migliorando continuamente il processo dei team stessi.
-
Team Topologies (Tipologie di team)
Le Team Topologies definiscono quattro tipologie di organizzazione che forniscono un modello chiaro per strutturare i team Agile e gli ART.
-
Debito tecnico
Il debito tecnico è il costo comprensivo di interessi da ripagare per le future lavorazioni. E' comunemente causato dalla scelta più o meno consapevole di rilasciare una soluzione non ottimizzata o solo parzialmente completa.
-
Test-Driven Development, TDD
Il Test-Driven Development (TDD) è un mindset e una pratica che prevede la definizione e l'esecuzione di test prima di implementare il codice o un componente di un sistema.
-
TOWS Analysis
L'analisi TOWS viene utilizzata insieme all'analisi SWOT per identificare le diverse opzioni strategiche al fine di creare un migliore stato futuro nel contesto della Portfolio Vision in SAFe.
U
-
U-Curve Optimization
L'ottimizzazione della curva a U per le batch size determina la dimensione ottimale del batch bilanciando tra di loro i costi di transazione e i costi di mantenimento.
-
Uncommitted Objectives
Gli Uncommitted Objectives contribuiscono a migliorare la prevedibilità nel generare valore, perché non sono inclusi negli impegni del team o calcolati tra i risultati dei team nella misura di prevedibilità del programma. I team possono formalizzare un Uncommitted Objective nel caso in cui non sono sufficientemente confidenti nel raggiungimento dell'obiettivo.
V
-
Value (Valore)
Il valore rappresenta i benefici che un'impresa offre ai propri clienti e stakeholder. Questo termine viene utilizzato in diversi contesti in SAFe.
-
Value Stream Coordination
La coordinazione del Value Stream definisce come gestire le dipendenze e come sfruttare quelle opportunità che nascono dalle interconnessioni fra diversi flussi di valore.
-
Value Stream Identification
La Value Stream Identification è una pratica utilizzata all'interno di un Portfolio SAFe per identificare gli Operational Value Stream e i Development Value Stream a supporto.
-
Value Stream KPI
I KPI di Value Stream sono le metriche quantificabili che si usano per valutare le prestazioni di un Value Stream rispetto ai risultati di business attesi.
-
-
Value Stream Mapping
Il Value Stream Mapping è uno strumento essenziale per migliorare il flusso di valore attraverso la Continuous Delivery Pipeline, rendendo visibili i colli di bottiglia e le aree problematiche che causano ritardi all'interno del flusso.
-
Value Stream (flusso di valore)
Un Value Stream rappresenta la serie di passaggi che un'organizzazione segue per implementare una Solution che fornisce un flusso continuo di valore ad un cliente.
-
Velocity
La Velocity è pari alla somma degli Story Points di tutte le Story completate che soddisfano la Definition of Done (DoD).
-
Vision
La Vision descrive lo stato futuro della Solution in corso di sviluppo. Riflette le esigenze dei clienti e degli stakeholder nonché le Feature e le Capability formulate per soddisfare tali esigenze.
W
-
Weighted Shortest Job First, WSJF
Il WSJF è un modello di prioritizzazione con cui si determina l'ordine di esecuzione dei lavori (per esempio Feature, Capability o Epiche), in modo da garantire il massimo beneficio economico. In SAFe, il WSJF viene stimato dividendo il Cost of Delay (CoD) per la dimensione del lavoro (Job Size).
-
Work in Process, WIP
Il Work in Process (WIP) rappresenta il lavoro parzialmente completato. Una quantità eccessiva di WIP confonde le priorità, provoca cambi di contesto frequenti e favorisce il sovraccarico di lavoro.
