© 2021 Scaled Agile, Inc. All rights reserved.

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

Learn more

Clear explanations and actionable guidance

SAFe Distilled 5.0

SAVE 35% WITH CODE SCALEDAGILE

ORDER NOW

Remote-Enabled SAFe: Tools & Resources

Learn More

SAFe Glossary

Author

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.

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 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

  • 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.

  • 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).

  • Foundation

    Le fondamenta contengono gli elementi portanti quali principi, valori, mentalità, guida all’implementazione e ruoli di leadership necessari a fornire efficacemente valore in modalità scalare.

  • Full SAFe

    Il Full SAFe è la configurazione più completa, che include tutte e sette le competenze di base necessarie per la Business Agility.

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 Execution

    L’esecuzione dell’iterazione rappresenta le modalità utilizzate dagli Agile team per la gestione del proprio lavoro nell’intervallo di tempo definito, che si traduce in un incremento di alta qualità, funzionante e collaudato del sistema.

  • 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.

  • 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.

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.

  • Metrics (Metriche)

    Le metriche sono le misure condivise utilizzate per valutare come l’organizzazione procede verso il raggiungimento degli obiettivi di business e tecnici a livello di portfolio, large solution, programma e team.

  • 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

  • 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

  • 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).

  • 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.

  • Pre- and Post-PI Planning

    Gli eventi di Pre– e Post–Program Increment (PI) Planning servono a preparare e a effettuare il successivo follow-up del PI planning per gli Agile Release Train (ART) e i fornitori in un Solution Train.

  • 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.

  • 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 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).

  • 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 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.

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 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 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 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.

  • 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.

  • 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.

  • 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).

  • 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 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 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 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.

  • 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.

V

  • Value Stream Coordination (coordinamento dei flussi di valore)

    Il coordinamento dei flussi di valore definisce come gestire le dipendenze e come sfruttare le opportunità che esistono soltanto nelle interconnessioni fra i flussi di valore.

  • 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.

  • Value Stream (flusso di valore)

    I flussi di valore rappresentano la sequenza di azioni che un’organizzazione usa per realizzare le Soluzioni che forniscono un flusso di valore continuo per il cliente.

  • 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.

© 2021 Scaled Agile, Inc. All rights reserved.