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.
A
-
-
-
-
-
-
-
-
-
Agile Product Delivery
Agile Product Delivery è un approccio incentrato sui clienti per la definizione, la creazione e la realizzazione di un flusso continuo di valore, in termini di prodotti e servizi di valore per clienti e utenti.
-
Agile Release Train, ART
L’Agile Release Train (ART) è un team stabile composto da diversi Agile Team che, insieme ad altri stakeholder, sviluppa, fornisce, e laddove applicabile, gestisce in modo incrementale una o più soluzioni in un flusso di valore.
-
-
Agile Team
In SAFe, un Agile team è un gruppo inter-funzionale di 5-11 individui che definiscono, creano, testano e forniscono un incremento di valore in un breve intervallo temporale.
-
-
-
Architectural Runway
L’Architectural Runway è costituita da software, componenti e infrastruttura tecnica già esistenti, necessari a implementare “feature” di breve termine, evitando riprogettazioni e ritardi eccessivi.
-
Program Backlog (backlog di programma)
Il backlog di programma è un’area dedicata ad ospitare le “feature” future, che hanno lo scopo di soddisfare le esigenze del cliente e di fornire benefici di business per un singolo Agile Release Train (ART). Comprende inoltre gli enabler, funzionalità abilitanti, necessarie alla costruzione dell’Architectural Runway.
-
-
Program Kanban
Le Kanban di Programma e di Soluzione sono un metodo di visualizzazione e gestione del flusso di “feature” e di “capability” dall’ideazione all’analisi, implementazione e rilascio attraverso la Continuous Delivery Pipeline.
-
-
-
-
B
-
-
-
-
-
-
-
Built-in Quality (qualita’ intrinseca)
Le pratiche di built-in quality assicurano che ciascun elemento di una soluzione, ad ogni incremento, soddisfi gli standard di qualità appropriati durante tutto il corso dello sviluppo.
-
-
Business Agility
Business Agility è la capacità di competere e prosperare nell'era digitale rispondendo rapidamente ai cambiamenti del mercato e alle opportunità emergenti con soluzioni di business innovative.
-
Business and Technology (Business e Tecnologia)
L'icona Business e Tecnologia in SAFe descrive il modo in cui i domini funzionali di ciascun ramo aziendale facilitino la Business Agility attraverso un'esplorazione costante sul come applicare i principi e le pratiche Lean-Agile in un contesto specifico.
-
-
Business Owner
I Business Owner sono un piccolo gruppo di stakeholder a cui sono assegnate le principali responsabilità aziendali e tecniche riguardanti il governo, la compliance e il ritorno sull’investimento (ROI), di una soluzione sviluppata da un Agile Release Train (ART). Sono i principali stakeholder dell’ART che devono valutare l’idoneità all’uso e partecipare attivamente a determinati eventi dell'ART.
-
C
-
CALMR
L'approccio CALMR alle pratiche DevOps proposto da SAFe è un mindset che guida gli ART verso l'ottenimento di valore costante gestendo in parallelo i progressi a livello di cultura, automazione, flusso lean, misurazioni continue e recovery.
-
Capability
Una Capability è un bisogno di alto livello di una soluzione. Per soddisfare questo bisogno aziendale occorre generalmente coinvolgere diversi ART. Le capability sono dimensionate e suddivise in più “feature” per facilitarne l’implementazione in un singolo PI (periodo, chiamato Incremento di Programma).
-
-
-
-
-
-
Community of Practice, CoP
Le Community of Practice (CoP) sono gruppi organizzati di persone che hanno un interesse comune in uno specifico dominio tecnico o di business. Collaborano regolarmente allo scopo di condividere informazioni, migliorare le proprie competenze. Le CoP operano attivamente per aumentare la conoscenza generale di dominio.
-
Compliance (conformita’)
La compliance si riferisce ad una strategia e ad una serie di attività e artefatti che consentono ai team di applicare i metodi di sviluppo Lean-Agile per creare sistemi caratterizzati dalla qualità più elevata possibile, assicurando, al contempo, il rispetto di eventuali standard normativi, di settore e altri standard rilevanti.
-
-
Continuous Delivery Pipeline
La Continuous Delivery Pipeline (CDP) rappresenta i flussi di lavoro, le attività e l'automazione necessari per rendere disponibile una nuova funzionalità, dalla ideazione al rilascio on demand di valore per l’utente finale.
-
Continuous Deployment, CD
Continuous Deployment (CD) è il processo che prende delle “feature” (o funzionalità) approvate in un ambiente di staging e le rilascia in produzione.
-
Continuous Exploration, CE
La Continuous Exploration (CE) è il processo che guida l’innovazione e promuove l’allineamento con quello che dovrebbe essere creato, esplorando continuamente le esigenze dei clienti e del mercato, e definendo una Vision, Roadmap ed una serie di “feature” per una soluzione soddisfi tali esigenze.
-
Continuous Integration, CI
La Continuous Integration (CI) è il processo mediante il quale vengono prese delle “feature” dal backlog di programma 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 (cultura dell’apprendimento continuo)
La cultura dell’apprendimento continuo descrive un insieme di valori e pratiche che incoraggiano gli individui – e l’intera impresa – ad incrementare con continuità la conoscenza, le competenze, le performance e l’innovazione.
-
-
Core Values (Valori Fondanti)
I quattro Valori Fondanti sono allineamento, qualita’ intrinseca, trasparenza ed esecuzione del programma. Questi rappresentano i punti di riferimento fondamentali ed essenziali per l’efficacia di SAFe. Questi principi guida indicano il comportamento e le azioni che tutti coloro che partecipano a un portfolio SAFe devono adottare.
-
-
Customer (Cliente)
I clienti sono i beneficiari ultimi del valore delle soluzioni di business create e gestite dai value stream (flussi di valore) del portfolio.
-
Customer Centricity, CC (centralita’ del cliente)
La centralità del cliente è una mentalità e un modo di fare business che si focalizza sulla creazione di esperienze positive per il cliente attraverso l'intera gamma di prodotti e servizi offerti dall'impresa.
-
D
-
-
-
-
Design Thinking
Design Thinking è un processo di sviluppo incentrato sul cliente e che crea prodotti desiderabili, redditizi e sostenibili per tutto il loro ciclo di vita.
-
-
Development Value Streams, DVS (Flussi di valore di sviluppo)
Per flussi di valore di sviluppo (DVS, Development Value Stream) s'intende la sequenza di attività necessarie per trasformare un'ipotesi in una soluzione digitale. Alcuni esempi possono essere la progettazione di un dispositivo medico o di un satellite geofisico oppure lo sviluppo e la distribuzione di un'applicazione software, di un sistema SaaS o di un sito Web di e-commerce.
-
DevOps
DevOps è una mentalità, una cultura e un insieme di pratiche tecniche. Consente la comunicazione, l’integrazione, l’automazione e la stretta cooperazione tra tutte le persone necessarie a gestire la pianificazione, lo sviluppo, il collaudo, l’implementazione, il rilascio e la manutenzione di una soluzione.
E
-
-
Enabler
Un Enabler supporta le attività necessarie all’ampliamento della Architectural Runway per fornire le future funzionalità di business. Tra queste attività vi sono l’esplorazione, l’architettura, l’infrastruttura e la compliance. Gli Enabler vengono acquisiti a livello dei vari backlog e sono presenti in tutto il framework.
-
Enterprise (impresa)
L’impresa rappresenta l’entità aziendale alla quale appartiene ciascun portfolio di SAFe.
-
Enterprise Architect
L'enterprise architect stabilisce una strategia tecnologica e una roadmap che consente a un portfolio, prodotti o servizi, di supportare le capability aziendali attuali e future.
-
Enterprise Solution Delivery
La competenza di Enterprise Solution Delivery descrive come applicare i principi e le pratiche Lean-Agile alla realizzazione delle specifiche, allo sviluppo, alla distribuzione, al funzionamento e all’evoluzione delle applicazioni software, delle reti e dei sistemi cyber-fisici più grandi e sofisticati del mondo.
-
-
Epic Owner
Gli Epic Owner sono responsabili del coordinamento delle epiche a livello di portfolio attraverso il sistema Portfolio Kanban. Collaborativamente, gli epic owner definiscono le epiche, il loro Minimum Viable Product (MVP), e il business case Lean. Una volta approvate, ne facilitano l’implementazione.
-
Epics (Epiche)
Una Epica è un contenitore per un’iniziativa importante di sviluppo di Solution che rappresenta gli investimenti più sostanziali che si verificano all’interno di un portfolio. A causa dell’obiettivo e dell’impatto considerevoli, le epiche richiedono la definizione di un Minimum Viable Product (MVP) e l’approvazione del Lean Portfolio Management (LPM) prima dell’implementazione.
-
Essential SAFe
L’Essential SAFe contiene il set minimo di ruoli, eventi e artefatti necessari a rilasciare soluzioni di business con continuità attraverso un Agile Release Train (ART), ovvero dei Team di Agile Team.
-
-
F
-
Feature (funzionalita’)
Una Feature è un servizio che soddisfa le esigenze degli stakeholder. Ogni feature condivide un’ipotesi dei vantaggi e dei criteri di accettazione ed è dimensionata e suddivisa in modo da poter essere completata in un singolo Agile Release Train (ART) in un Incremento di Programma (PI).
-
-
-
-
-
-
-
-
-
I
-
Innovation and Planning Iteration (iterazione di innovazione e di pianificazione)
L’iterazione di innovazione e di pianificazione (IP) ha luogo in corrispondenza di ogni Incremento di Programma (PI) e soddisfa una pluralità di scopi. Funziona da buffer per il raggiungimento degli obiettivi di PI, e fornisce tempo specificamente dedicato all’innovazione, alla formazione continua e agli eventi di PI Planning e Inspect and Adapt (I&A).
-
Inspect & Adapt, I&A
Un Inspect and Adapt (I&A) è un evento significativo che si tiene al termine di ogni Incremento di Programma (PI), durante il quale il “treno” dimostra e valuta lo stato attuale della soluzione. I team quindi riflettono e individuano nuovi elementi del backlog di miglioramento mediante un workshop strutturato di risoluzione dei problemi.
-
-
-
Iteration (iterazioni)
Le iterazioni sono l’elemento portante dello “sviluppo Agile”. Ciascuna iterazione rappresenta un intervallo di tempo standard di durata fissa, durante il quale gli Agile team rilasciano valore incrementale sotto forma di sistemi e software funzionanti e collaudati. La durata consigliata per l’intervallo di tempo è di due settimane. Tuttavia, è accettabile un periodo compreso tra una e quattro settimane, in base al contesto di business.
-
Iteration Goal (obiettivo dell’iterazione)
Gli obiettivi dell’iterazione sono la raccolta di alto livello degli obiettivi di business e tecnici che l’Agile team decide di perseguire nell’ambito di una iterazione. Sono fondamentali per il coordinamento di un Agile Release Train (ART) come team di team auto-organizzato e auto-gestito.
-
Iteration Planning
L’iteration planning è l’evento durante il quale tutti i membri del team stabiliscono l’entità del team backlog che possono impegnarsi a consegnare durante la successiva iterazione. Il team sintetizza il lavoro mediante una serie di iteration goal preventivati.
-
Iteration Retrospective (retrospettiva dell’iterazione)
La retrospettiva dell’iterazione è un meeting regolare durante il quale i membri dell’Agile team discutono dei risultati dell‘ iterazioni, analizzano le pratiche utilizzate e individuano i percorsi di miglioramento.
-
Iteration Review
L’Iteration Review è un evento cadenzato durante il quale ciascun team ispeziona l’incremento di valore alla fine di ogni iterazione per valutare i progressi e quindi rivede il proprio backlog per l’iterazione successiva.
L
-
Large Solution SAFe
Il Large Solution SAFe è una configurazione che descrive gli ulteriori ruoli, pratiche e l’orientamento per creare e sviluppare le applicazioni, le reti e i sistemi cyber-fisici più grandi del mondo.
-
-
Lean Budget Guardrails
I Lean Budget Guardrail descrivono le politiche e le pratiche di budget, spesa e governo per uno specifico portfolio.
-
Lean Budget
Il Lean Budget è’ un approccio Lean Agile per un’efficace governo finanziario che aumenta la produzione e la produttività attraverso la riduzione delle spese e dei costi associati alla gestione del progetto.
-
-
-
Lean Portfolio Management
Il Lean Portfolio Management allinea la strategia con l’esecuzione applicando gli approcciLean e System Thinking alla strategia e al finanziamento degli investimenti, alle operazioni del portfolio agile e alla governance.
-
-
Lean User Experience, Lean UX
Il Lean User Experience (Lean UX) è un mindset, una cultura e un processo che adotta i metodi Lean-Agile. Il Lean UX implementa le funzionalità in incrementi minimi e determina il successo misurando i risultati rispetto ai benefici attesi.
-
-
Lean-Agile Leadership
La Leadership Lean-Agile descrive come i Leader guidano e sostengono il cambiamento organizzativo e l'eccellenza operativa, motivando individui e team a raggiungere il loro massimo potenziale.
-
Lean-Agile Mindset
Il Lean-Agile Mindset è la combinazione dei punti di riferimento, delle ipotesi, delle attitudini e delle azioni dei leader e dei praticanti SAFe che abbracciano i concetti 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.
-
M
-
Measure And Grow
Measure and Grow è la modalità con cui i portfolio valutano i loro progressi in termini di Business Agility determinano i passi successivi di miglioramento.
-
Milestone
Le milestone vengono utilizzate per monitorare i progressi effettuati verso il raggiungimento di uno specifico obiettivo o evento. Esistono tre tipi di milestone SAFe: Program Increment (PI), date fisse e milestone di apprendimento.
-
-
-
Model-Based Systems Engineering, MBSE
Il Model-Based Systems Engineering (MBSE) è la pratica utilizzata per lo sviluppo di un insieme di modelli di sistema correlati che consentono di definire, progettare e documentare un sistema in fase di realizzazione. Questi modelli offrono un metodo efficiente di analisi, aggiornamento e comunicazione degli aspetti del sistema agli stakeholder, consentendo al contempo di ridurre significativamente o eliminare la dipendenza dai documenti tradizionali.
-
N
-
Nonfunctional Requirement, NFR (requisiti non funzionali)
I requisiti non funzionali (NFR) definiscono attributi di sistema quali sicurezza, affidabilità, prestazioni, manutenibilità, scalabilità e usabilità. Fungono da vincoli o restrizioni alla progettazione del sistema nei diversi backlog.
O
-
-
Operational Value Streams (Flussi di valore operativi)
Per flussi di valore operativi (OVS, Operational Value Stream) s'intende la sequenza di attività necessarie per fornire un prodotto o un servizio al cliente. Alcuni esempi possono essere la creazione di un prodotto, l'evasione di un ordine, l'ospedalizzazione e il trattamento di un paziente, la concessione di un prestito oppure la fornitura di un servizio professionale.
-
Organizational Agility (agilità dell’organizzazione)
L’agilità dell’organizzazione descrive come le persone con pensiero Lean e gli Agile team ottimizzano i loro processi di business, sviluppano la strategia con nuovi impegni chiari e decisi, e adattano rapidamente l'organizzazione secondo necessità per sfruttare al meglio le nuove opportunità.
P
-
-
Participatory Budgeting (Budget partecipativo)
Il budget partecipativo (PB, Partecipatory Budgeting) è il processo utilizzato nel Lean Portfolio Management (LPM) per ripartire l'intero budget di portfolio tra i flussi di valore.
-
-
-
PI Objective (obiettivi di incremento di programma)
Gli obiettivi di incremento di programma sono una sintesi degli obiettivi tecnici e di business che un Agile Team o treno intende raggiungere nel successivo Incremento di Programma (PI).
-
Program Increment (PI) Planning (pianificazione dell’incremento di programma)
La pianificazione dell’incremento di programma è un evento cadenzato e svolto faccia a faccia (se possibile), che rappresenta il ritmo vitale dell’Agile Release Train (ART), allineando tutti i team coinvolti nell’ART verso una missione e una vision condivisa.
-
-
Program Increment, PI (incremento di programma)
Un incremento di programma (PI) è un intervallo di tempo fisso durante il quale un Agile Release Train (ART) genera valore incrementale sotto forma di sistemi e software funzionanti e collaudati. I PI sono generalmente di 8-12 settimane. Lo schema più comune per un PI è di quattro iterazioni di sviluppo, seguiti da una iterazione di Innovazione e Pianificazione (IP).
-
Portfolio
Un portfolio SAFe allinea la strategia all'esecuzione attraverso una serie di flussi di valore di sviluppo (Development Value Stream). Coordinati da un modello di governance comune, ciascun flusso di valore fornisce una o più soluzioni necessarie affinché l'organizzazione possa realizzare la propria mission.
-
Portfolio Backlog
Il Portfolio Backlog è il livello di backlog più elevato di SAFe. Fornisce un’area di raccolta delle future epiche di business e abilitanti con lo scopo di creare e sviluppare un insieme completo di soluzioni.
-
-
-
Portfolio Kanban
Il Portfolio Kanban è un metodo utilizzato per visualizzare e gestire il flusso delle epiche in portfolio a partire dall'ideazione attraverso l’analisi, l'implementazione e il completamento.
-
Portfolio SAFe
Portfolio SAFe allinea la strategia all’esecuzione e organizza lo sviluppo delle soluzioni intorno al flusso di valore attraverso uno o più flussi di valore.
-
Portfolio Vision
Portfolio Vision è una descrizione del futuro stato dei flussi di valore e delle soluzioni di un portfolio e descrive come questi coopereranno per raggiungere gli obiettivi del portfolio e lo scopo più ampio dell’azienda.
-
-
-
Product Management
Product Management ha il compito di definire e supportare la creazione di prodotti desiderabili, fattibili, realizzabili e sostenibili che soddisfano le esigenze dei clienti durante il ciclo di vita del prodotto-mercato.
-
Product Owner, PO
The Product Owner (PO) è un membro dell’Agile Team responsabile della definizione delle Storie e della prioritizzazione del Team Backlog per ottimizzare la fase di esecuzione in linea con le priorità dei programmi mantenendo al contempo l’integrità concettuale e tecnica delle funzionalità o componenti per il team.
-
R
-
-
-
-
Release on Demand
Release on Demand è il processo che implementa le nuove funzionalità in produzione e le rilascia ai clienti, immediatamente o in modo incrementale, in base alla domanda.
-
Release Train Engineer, RTE
Il Release Train Engineer (RTE) è un servant leader e coach dell’Agile Release Train (ART). Le principali responsabilità dell’RTE sono facilitare gli eventi e i processi dell'ART e supporta i team per quanto riguarda la produzione di valore. Gli RTE comunicano con gli stakeholder, riportano gli impedimenti al livello superiore, contribuiscono alla gestione del rischio e guidano il processo di miglioramento continuo.
-
-
Roadmap
La Roadmap è una piano di eventi e milestone che comunica i deliverable pianificati per la soluzione su un orizzonte di pianificazione condiviso.
S
-
SAFe for Lean Enterprise
SAFe for Lean Enterprise è una base di conoscenze di principi integrati e comprovati, pratiche e competenze per raggiungere l'agilità aziendale implementando Lean, Agile e DevOps su larga scala.
-
-
SAFe for Government (SAFe per le Istituzioni Pubbliche)
SAFe per le Istituzioni Pubbliche (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 Implementation Roadmap
La SAFe Implementation Roadmap consiste in una rappresentazione grafica e una serie di 12 articoli che descrivono una strategia e un insieme ordinato di attività che si sono dimostrate efficaci nell’implementazione ottimale di SAFe.
-
-
Principi Lean-Agile
SAFe si basa su dieci principi Lean-Agile fondamentali e immutabili. Questi fondamenti e concetti economici ispirano e danno forma ai ruoli e alle pratiche di SAFe.
-
-
SAFe Program Consultant, SPC
I SAFe® Program Consultant (SPC) certificati sono agenti di cambiamento che combinano la propria conoscenza tecnica di SAFe con una intrinseca motivazione verso il miglioramento dei processi di sviluppo dei software e dei sistemi dell’azienda. Svolgono un ruolo chiave nell’implementazione efficace di SAFe. Gli SPC provengono da diversi ruoli interni o esterni, tra cui leader di business e tecnologici, manager di portfolio/programmi/progetti, leader di processo, architetti, analisti e consulenti.
-
ScrumXP
ScrumXP è un processo minimo che consente ai team cross-funzionali e auto-organizzati di consegnare valore nell’ambito di SAFe. ScrumXP combina il potere delle pratiche Scrum di project management, con le pratiche dell’eXtreme programming (XP).
-
Team Kanban
Il Team Kanban è una tecnica che consente ai team di facilitare il flusso di valore visualizzando il flusso di lavoro, fissando dei limiti per il Work In Process (WIP), misurando la quantità di lavoro svolto e migliorando continuamente il loro processo.
-
Scrum Master
Gli Scrum Master sono i servant leader e i coach di un Agile team. Contribuiscono alla formazione del team per quanto riguarda Scrum, eXtreme Programming (XP), Kanban e SAFe, assicurando che il processo Agile concordato venga applicato. Aiutano inoltre a rimuovere eventuali ostacoli e promuovono un ambiente caratterizzato da dinamiche per team ad alte prestazioni, flusso e processo di miglioramento continuo.
-
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. Promuove la flessibilità nell’ambito del processo di progettazione passando alle soluzioni tecniche, solo dopo aver convalidato le ipotesi, che producono i migliori risultati economici.
-
Shared Service (servizi condivisi)
I servizi condivisi rappresentano gli specialisti, le persone, e i servizi richiesti per il successo di un Agile Release Train (ART) o di un Solution Train, ma che non possono essere dedicati a tempo pieno.
-
Solution (soluzione)
Ogni flusso di valore produce una o più Soluzioni, ossia prodotti, servizi o sistemi forniti al cliente, sia internamente che esternamente all’azienda.
-
Solution Architect/Engineer
Il Solution Architect/Engineering ha il compito di definire e comunicare una visione tecnica e architettonica condivisa in un Solution Train per verificare che il sistema o la Solution in corso di sviluppo siano adatti allo scopo previsto.
-
Solution Context (contesto della soluzione)
Il contesto della soluzione identifica gli aspetti critici dell’ambiente operativo per una soluzione. Fornisce una comprensione essenziale dei requisiti, dell’utilizzo, dell’installazione, della gestione operativa e del supporto alla soluzione stessa. Il contesto della soluzione influenza significativamente le opportunità e i vincoli per il release on demand.
-
Solution Demo
La Solution Demo è dove i risultati delle attività di sviluppo del Solution Train vengono integrati, valutati e resi visibili ai clienti e agli altri stakeholder.
-
Solution Intent
Solution Intent è l’area per l'archiviazione, la gestione e la comunicazione della conoscenza del comportamento corrente e previsto della soluzione. Ove richiesto, comprende le specifiche e la progettazione sia fissa sia variabile, i riferimenti applicabili a standard, modelli di sistema e test funzionali e non funzionali e la tracciabilità.
-
Solution Management
Il Solution Management ha il compito di definire e supportare la creazione di soluzioni di business desiderabili, fattibili, realizzabili e sostenibili su larga scala, che soddisfano nel tempo le esigenze del cliente.
-
Solution Train
Il Solution Train è il costrutto organizzativo utilizzato per creare Soluzioni complesse e di grandi dimensioni che richiedono il coordinamento di più Agile Release Train (ART), nonché il contributo dei fornitori. Allinea gli ART con una missione di business e tecnologica condivisa utilizzando la Vision, il Backlog e la Roadmap della soluzione e un incremento di programma (PI) allineato.
-
Solution Backlog
Il Solution Backlog rappresenta l’area che ospita le Capability e gli Enabler futuri, ciascuno dei quali può interessare più ART ed è utilizzato per l’avanzamento della soluzione e per la creazione del suo Architectural Runway.
-
Solution Train Engineer, STE
Il Solution Train Engineer (STE) è un servant leader e coach per il Solution Train, che facilita e orienta il lavoro di tutti gli ART e i fornitori del flusso di valore.
-
-
Spanning Palette
La “Spanning Palette” contiene diversi ruoli e artefatti che potrebbero essere applicabili a uno specifico team, programma, Large Solution o a un contesto di Portfolio.
-
-
-
Stories (storie)
Le Storie sono brevi descrizioni di una piccola porzione di una funzionalità desiderata, scritte nel linguaggio dell’utente. Gli Agile team implementano piccole parti verticali di funzionalità del sistema e sono dimensionate in modo da consentirne il completamento in una singola iterazione.
-
-
-
Strategic Theme (temi strategici)
I temi strategici sono obiettivi di business dettagliati e differenziati che collegano un portfolio alla strategia dell’impresa. Essi influenzano la strategia di portfolio e forniscono un contesto di business per il processo decisionale relativo al portfolio.
-
-
Supplier (fornitore)
Un fornitore è un’organizzazione interna o esterna che sviluppa e fornisce componenti, sottosistemi o servizi che consentono ai Solution Train e agli Agile Release Train di creare soluzioni per i clienti.
-
-
System Architect/Engineer
Il System Architect/Engineer ha il compito di definire e comunicare una visione tecnica e architettonica condivisa per un Agile Release Train (ART) per supportare la verifica che il sistema o la Soluzione in corso di sviluppo siano allineati allo scopo previsto.
-
System Demo
La System Demo è un evento importante che fornisce una visione integrata delle nuove funzionalità, che sono state realizzate da tutti i team dell’Agile Release Train (ART) nell’iterazione più recente. Ciascuna demo fornisce agli stakeholder di un ART una misura oggettiva dei progressi effettuati durante un incremento di programma (PI).
-
System Team
Il System Team è un Agile Team specializzato che assiste nella creazione e nel supporto dell'ambiente di sviluppo Agile, includendo tipicamente lo sviluppo e la manutenzione dell’ambiente che supporta la Continuous Delivery Pipeline. Il System Team può anche supportare l’integrazione delle risorse (con ampio significato) degli Agile team, eseguire laddove necessario test end-to-end delle soluzioni e fornire assistenza per la distribuzione e il rilascio on demand.
-
T
-
Team and Technical Agility (Team e Technical Agility)
L’agilità tecnica e dei team descrive le competenze critiche, i principi e le pratiche Lean-Agile che i team ad alta prestazione (high-performing) e i team di agile team utilizzano per creare soluzioni di elevata qualità per i loro clienti.
-
Team Backlog
Il Team Backlog contiene le user story e le enabler storie che hanno origine dal Program Backlog, nonché le storie che hanno origine localmente nel contesto del team locale. Può includere anche altri elementi di lavoro, rappresentando tutto ciò di cui un team deve fare per avanzare nello sviluppo della propria porzione di sistema.
-
-
-
-
-
V
-
-
-
-
Value Stream KPIs
I Key Performance Indicator (KPIs) dei flussi di valore sono le misure quantificabili utilizzate per valutare come un flusso di valore sta performando rispetto ai risultati di business attesi.
-
-
-
-
-
Vision
La Vision è una descrizione dello stato futuro della Soluzione in corso di sviluppo. Riflette le esigenze dei clienti e degli stakeholder nonché le “feature” e le “capability” proposte per soddisfare tali esigenze.
W
-
Weighted Shortest Job First, WSJF
Weighted Shortest Job First (WSJF) è un modello di prioritizzazione utilizzato per ordinare i "lavori" (ad es. feature, capability, ed epiche) in modo da produrre il massimo beneficio economico. In SAFe, il WSJF è calcolato dividendo il Cost of Delay (CoD) per la dimensione del lavoro.
-