SAFe 5.0 Glossary Scaled Agile Framework Terms and Definitions - Italian
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
SAFe 5.0 Glossary
®
Scaled Agile Framework Terms and Definitions
Italian
PROVIDED BY
www.scaledagileframework.com | www.scaledagile.com
© Scaled Agile, inc.
Hidden Topic Title Text
Guide to acronyms and abbreviations
ART Agile Release Train PDCA Plan, Do, Check, Adjust
BO Business Owner PI Program Increment
BV Business Value PM Product Management
BVIR Big Visual Information Radiator PO/PM Product Owner/Product Manager
CapEx Capital Expenses PO Product Owner
CD Continuous Delivery ROAM Resolved, Owned,
Accepted, Mitigated
CE Continuous Exploration
RR Risk Reduction
CI Continuous Integration
RTE Release Train Engineer
CFD Cumulative Flow Diagram
S4T SAFe® for Teams
CoD Cost of Delay
SAFe® Scaled Agile Framework
CoP Community of Practice
SA SAFe® Agilist
DoD Definition of Done
SBD Set-Based Design
DSU Daily Stand-up
SM Scrum Master
EA Enterprise Architect
SMART Specific, Measurable, Achievable,
EO Epic Owner Realistic, Time-bound
FW Firmware SoS Scrum of Scrums
HW Hardware SP SAFe® Practitioner
I&A Inspect and Adapt SPC SAFe® Program Consultant
IP Innovation and Planning (iteration) STE Solution Train Engineer
KPI Key Performance Indicator SW Software
LPM Lean Portfolio Management UX User Experience
MBSE Model-Based Systems Engineering VS Value Stream
MMF Minimum Marketable Feature VSE Value Stream Engineer
MVP Minimum Viable Product WIP Work in Process
NFR Nonfunctional Requirements WSJF Weighted Shortest Job First
OE Opportunity Enablement XP Extreme Programming
OpEx Operating Expenses
© Scaled Agile, Inc. | www.scaledagileframework.com 3Note: Glossary terms that are on the SAFe Big Picture remain in English in the
definitions to create a common taxonomy alignment.
Glossario SAFe 5.0
Agile Release Train (ART)
L’Agile Release Train (ART) è un team attivo da molto tempo formato da diversi Agile
Team che, insieme ad altre parti interessate, sviluppa, fornisce, e laddove applicabile
gestisce in modo incrementale una o più solution in un value stream.
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 codice, componenti e infrastruttura tecnica già
esistenti, necessari a implementare feature di breve termine, evitando riprogettazioni e
ritardi eccessivi.
Built-in Quality
Le pratiche di built-in quality assicurano che ciascun elemento di una solution, ad ogni
incremento, soddisfi gli standard di qualità appropriati durante tutto il corso dello
sviluppo.
Business Owner
I Business Owner sono un piccolo gruppo di stakeholder a cui sono assegnate le
principali responsabilità aziendali e tecniche riguardanti la governance, la compliance e
il ritorno sull’investimento (ROI), di una solution sviluppata da un Agile Release Train
(ART). Sono stakeholder chiave dell’ART che devono valutare l’idoneità all’uso e
partecipare attivamente a determinati eventi dell'ART.
Capability
Una Capability è un comportamento di alto livello di una solution, che generalmente
coinvolge diversi ART. Le capability sono dimensionate e suddivise in più feature per
facilitarne l’implementazione in un singolo PI.
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 e
operano attivamente per aumentare la conoscenza generale di dominio.
Compliance
La compliance si riferisce a una strategia e a una serie di attività e artefatti che
consentono ai team di applicare i metodi di sviluppo Lean-Agile per creare sistemi
© Scaled Agile, Inc. | www.scaledagileframework.com 4caratterizzati dalla qualità più elevata possibile, assicurando al contempo il rispetto di
eventuali standard normativi e di settore e di altri rilevanti
Continuous Delivery Pipeline
La Continuous Delivery Pipeline (CDP) rappresenta i flussi di lavoro, le attività e
l'automazione necessari a guidare una nuova funzionalità dall'ideazione fino al release
su richiesta di valore all’utente finale.
Continuous Deployment (CD)
Continuous Deployment (CD) è il processo che prende delle Feature convalidate in un
ambiente di staging e le implementa nell'ambiente di produzione, dove vengono
preparate per il release.
Continuous Exploration (CE)
Continuous Exploration (CE) è il processo che guida l’innovazione e stimola
l’allineamento su quello che dovrebbe essere creato, esplorando continuamente le
esigenze dei customer e del mercato, e definendo una Vision, Roadmap e una serie di
Feature per una Solution che affronti 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 l’implementazione e il release.
Core Values
I quattro Core Values sono allineamento, built-in quality, trasparenza ed esecuzione del
programma e rappresentano i punti di riferimento fondamentali, 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.
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 release e la manutenzione di una Solution.
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
L’Enterprise rappresenta l’entità aziendale alla quale appartiene ciascun portfolio SAFe.
© Scaled Agile, Inc. | www.scaledagileframework.com 5Enterprise Solution Delivery
La competenza di Enterprise Solution Delivery descrive come applicare i principi e le
pratiche Lean-Agile alla specifica, 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 epic a livello di portfolio
attraverso il sistema Portfolio Kanban. Collaborando fra di loro, essi definiscono l’epic, il
suo Minimum Viable Product (MVP), e il Lean business case e, una volta approvati,
facilitano l’implementazione.
Epic
Un Epic è un contenitore per un’iniziativa importante di sviluppo di Solution che
acquisisce gli investimenti più sostanziali che si verificano all’interno di un portfolio. A
causa dell’obiettivo e dell’impatto considerevoli, gli epic richiedono la definizione di un
Minimum Viable Product (MVP) e l’approvazione del Lean Portfolio Management (LPM)
prima dell’implementazione.
Essential SAFe
Essential SAFe contiene una serie minima di ruoli, eventi e artefatti necessari a fornire
continuamente delle business solution attraverso un Agile Release Train (ART) sotto
forma di Team degli Agile Team.
Feature
Una Feature è un servizio che soddisfa le esigenze degli stakeholder. Ogni feature
include un’ipotesi dei vantaggi e dei criteri di accettazione ed è dimensionata o
suddivisa in modo da poter essere fornita da un singolo Agile Release Train (ART) in un
Program Increment (PI).
Foundation
La Foundation contiene gli elementi portanti quali principi, valori, mentalità, guida
all’implementazione e ruoli di leadership necessari a fornire efficacemente valore per
scalare.
Full SAFe
Full SAFe è la configurazione più completa, che include tutte e sette le competenze di
base necessarie per l’agilità di business.
Innovation and Planning Iteration
L'iteration di Innovation e Planning (IP) ha luogo in corrispondenza di ogni Program
Increment (PI) e serve una pluralità di scopi. Funziona da buffer per il raggiungimento
dei PI Objectives, e fornisce tempo specificamente dedicato all’innovazione, alla
formazione continua e agli eventi di PI Planning e Inspect and Adapt (I&A).
© Scaled Agile, Inc. | www.scaledagileframework.com 6Inspect & Adapt (I&A)
Un Inspect and Adapt (I&A) è un evento significativo che si tiene al termine di ogni
Program Increment (PI), durante il quale il train dimostra e valuta lo stato attuale della
solution. I team quindi riflettono e individuano nuovi elementi dell'improvement backlog
mediante un workshop strutturato di risoluzione dei problemi.
Iteration
Le iteration (iterazioni) sono l’elemento portante dello sviluppo Agile. Ciascuna iteration
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
La iteration execution rappresenta le modalità utilizzate dagli Agile team per la gestione
del proprio lavoro nell’intervallo di tempo della iteration, che si traduce in un incremento
di sistema di alta qualità, funzionante e collaudato.
Iteration Goal
Gli iteration goal sono riepiloghi di alto livello degli obiettivi tecnici e di business che
l’Agile team decide di perseguire nell’ambito di una iteration. Sono fondamentali per il
coordinamento di un Agile Release Train (ART) come team di team auto-organizzato e
auto-gestito.
Iteration Planning
Un 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
iteration. Il team sintetizza il lavoro mediante una serie di iteration goal preventivati.
Iteration Retrospective
La iteration retrospective è una riunione regolare durante la quale i membri dell’Agile
team discutono dei risultati della iteration, analizzano le pratiche utilizzate e individuano
i percorsi di miglioramento.
Iteration Review
Una Iteration Review è un evento cadenzato durante il quale ciascun team ispeziona
l’incremento alla fine di ogni iterazione per valutare i progressi e quindi rivede il proprio
backlog per l’iterazione successiva.
Large Solution SAFe
Large Solution SAFe descrive gli ulteriori ruoli, pratiche e orientamento per creare e
sviluppare le applicazioni, le reti e i sistemi cyber-fisici più grandi del mondo.
© Scaled Agile, Inc. | www.scaledagileframework.com 7Lean Budget Guardrails
Lean Budget Guardrails descrive le politiche e le pratiche di budget, spesa e
governance per uno specifico portfolio.
Lean Budget
I Lean Budget forniscono un’efficace governance finanziaria in tema di investimenti, con
molte meno spese generali e frizioni e sostenendo un volume molto più alto di lavoro di
sviluppo.
Lean Enterprise
La Lean Enterprise è una fiorente organizzazione dell’era digitale che dimostra agilità di
business, rispondendo rapidamente ai cambiamenti del mercato e alle opportunità
emergenti, fornendo ai customer sistemi e solution innovativi nel minor tempo di
realizzazione sostenibile.
Lean Portfolio Management
La competenza di Lean Portfolio Management allinea la strategia con l’esecuzione
applicando le metodologie del pensiero Lean e dei sistemi alla strategia e al
finanziamento degli investimenti, alle operazioni di Agile portfolio e alla governance.
Lean User Experience (Lean UX)
Il design Lean User Experience (Lean UX) è una mentalità, una cultura e un processo
che adotta i metodi Lean-Agile. Implementa la funzionalità a incrementi minimi e
determina il successo misurando i risultati rispetto alle ipotesi dei vantaggi.
Lean-Agile Leadership
La competenza Lean-Agile Leadership descrive come i Lean-Agile Leader guidano e
sostengono il cambiamento organizzativo e l'eccellenza operativa, consentendo a
individui e team di raggiungere il loro massimo potenziale.
Lean-Agile Mindset
Per Lean-Agile Mindset si intende la combinazione dei punti di riferimento, delle ipotesi
e delle azioni dei leader e dei practitioner 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 dei SAFe principle e pratiche.
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.
Metrics
Per metrics si intendono le misure concordate utilizzate per valutare come
l’organizzazione procede verso il raggiungimento degli obiettivi tecnici e di business a
livello di portfolio, large solution, program e team.
© Scaled Agile, Inc. | www.scaledagileframework.com 8Milestone
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), con data fissa, 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 corso di sviluppo. 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.
Nonfunctional Requirement (NFR)
I Nonfunctional Requirement (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.
PI Objectives
I Program Increment (PI) Objectives sono un sommario degli obiettivi tecnici e di
business che un Agile Team intende raggiungere nel successivo Program Increment
(PI).
Portfolio Backlog
Il Portfolio Backlog è il livello di backlog più elevato di SAFe. Fornisce un’area di
partecipazione per le future attività e enabler di Epic con lo scopo di creare e sviluppare
una serie completa di Solution.
Portfolio Kanban
Il Portfolio Kanban è un metodo utilizzato per visualizzare e gestire il flusso di portfolio
Epic a partire dall'ideazione, fino all’analisi, all'implementazione e al completamento.
Portfolio SAFe
Portfolio SAFe allinea la strategia all’esecuzione e organizza lo sviluppo di solution
intorno al flusso di valore attraverso uno o più value stream.
Portfolio Vision
Portfolio Vision è una descrizione del futuro stato di Value Stream e Solution di un
portfolio e descrive come collaboreranno per raggiungere gli obiettivi del portfolio e lo
scopo più ampio dell’Enterprise.
Pre- and Post-PI Planning
Gli eventi di Pre– and Post–Program Increment (PI) Planning servono a preparare e ad
effettuare il successivo follow-up del PI planning per gli Agile Release Train (ART) e i
supplier in un Solution Train.
© Scaled Agile, Inc. | www.scaledagileframework.com 9Product Management
Product Management ha il compito di definire e supportare la creazione di prodotti
desiderabili, fattibili, attuabili e sostenibili che soddisfano le esigenze dei customer
durante il ciclo di vita del prodotto-mercato.
Product Owner (PO)
The Product Owner (PO) è un membro dell’Agile Team responsabile della definizione
delle Story e della prioritizzazione del Team Backlog per ottimizzare la fase di execution
in linea con le priorità dei programmi mantenendo al contempo l’integrità concettuale e
tecnica delle feature o dei componenti per il team.
Program Backlog
Il Program Backlog è un’area dedicata ad ospitare le feature future e ha lo scopo di
soddisfare le esigenze del cliente e di fornire benefici di business per un singolo Agile
Release Train (ART). Comprende inoltre le Enabler Feature necessarie alla costruzione
della Architectural Runway.
Program Increment (PI)
Un Program Increment (PI) è un intervallo di tempo 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 iteration di sviluppo, seguiti da una iteration di Innovation and Planning (IP).
Program Increment (PI) Planning
Il Program Increment (PI) planning è un evento cadenzato di pianificazione, svolto face-
to-face, che rappresenta il ritmo vitale dell’Agile Release Train (ART), allineando tutti i
team coinvolti nell’ART verso il raggiungimento di una missione e una vision comuni.
Program Kanban
I sistemi Program e Solution Kanban offrono un metodo di visualizzazione e gestione
del flusso di feature e di capability dall’ideazione all’analisi, implementazione e release
attraverso la Continuous Delivery Pipeline.
Release Train Engineer (RTE)
Il Release Train Engineer (RTE) è un servant leader e il coach dell’Agile Release Train
(ART). Le principali responsabilità dell’RTE sono facilitare gli eventi e i processi
dell'ART e fornire assistenza ai team per quanto riguarda la consegna di valore. Gli
RTE comunicano con gli stakeholder, riportano gli impedimenti al livello superiore,
contribuiscono alla gestione del rischio e al miglioramento continuo.
Release on Demand
Release on Demand è il processo che implementa le nuove funzionalità nella
produzione e le rilascia immediatamente o in modo incrementale ai customer in base
alla domanda.
© Scaled Agile, Inc. | www.scaledagileframework.com 10Roadmap
La Roadmap è una lista di eventi e milestone che comunica i risultati attesi per la
Solution, in relazione ad un orizzonte di pianificazione.
SAFe Implementation Roadmap
LaSAFe Implementation Roadmap è una overview grafica e una serie di 12 articoli che
descrive una strategia e un insieme ordinato di attività che si sono dimostrate efficaci
nell’implementazione ottimale di SAFe.
SAFe Program Consultant (SPC)
I Certified SAFe® Program Consultant (SPC) sono agenti di cambiamento che
combinano la propria conoscenza tecnica di SAFe con una motivazione intrinseca verso
il miglioramento dei processi di sviluppo dei sistemi e dei software dell’azienda.
Svolgono un ruolo chiave nell’implementazione efficace di SAFe. Gli SPC provengono
da diversi ruoli interni o esterni, tra cui leader tecnologici e di business, responsabili di
portfolio/programma/progetto, leader di processo, architetti, analisti e consulenti.
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 è una base di conoscenze di principi, pratiche e
competenze comprovati e integrati per ottenere l’agilità di business mediante
l’implementazione di Lean, Agile e DevOps in scala.
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 e assicurano l’osservanza del processo Agile concordato. Aiutano inoltre a
rimuovere eventuali ostacoli e promuovono un ambiente caratterizzato da dinamiche di
team ad alte prestazioni, flusso continuo del lavoro e miglioramento continuo.
ScrumXP
ScrumXP è un processo leggero che consente ai team cross-funzionali e auto-
organizzati di consegnare valore nell’ambito di SAFe. ScrumXP combina il potere delle
pratiche di project management di Scrum, con le pratiche dell’extreme programming
(XP).
Set-Based Design (SBD)
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 anticipatamente una solution "single point", 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
© Scaled Agile, Inc. | www.scaledagileframework.com 11soluzioni tecniche solo dopo aver convalidato le ipotesi, al fine di migliorare i risultati
economici.
Shared Service
Gli Shared Service rappresentano le persone, i servizi e i ruoli di specializzazione
richiesti per il successo di un Agile Release Train (ART) o di un Solution Train, i quali
però non possono essere dedicati a tempo pieno.
Solution
Ogni Value Stream produce una o più Solution, ossia prodotti, servizi o sistemi forniti al
customer, sia internamente che esternamente alla Enterprise.
Solution Architect/Engineer
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
solution e per la creazione della sua Architectural Runway.
Solution Context
Il Solution Context individua gli aspetti critici dell’ambiente operativo per una Solution.
Consente di comprendere le nozioni essenziali sui requisiti, sull’uso, sull’installazione,
sul funzionamento e sul supporto della solution stessa. Il Solution Context influenza
significativamente le opportunità e i vincoli per il release on demand.
Solution Demo
Nella Solution Demo i risultati delle azioni di sviluppo del Solution Train vengono
integrati, valutati e resi visibili ai customer e agli altri stakeholder.
Solution Intent
Solution Intent è il repository per l'archiviazione, la gestione e la comunicazione della
conoscenza del comportamento corrente e previsto della Solution. Ove necessario, ciò
comprende specifiche e progetti sia fissi che variabili, riferimenti a standard, modelli di
sistema e prove funzionali e non funzionali applicabili e la tracciabilità.
Solution Management
Solution Management ha il compito di definire e supportare la creazione di business
solution desiderabili, fattibili, attuabili e sostenibili su larga scala, che soddisfano nel
tempo le esigenze del customer.
© Scaled Agile, Inc. | www.scaledagileframework.com 12Solution Management
Solution Management ha il compito di definire e supportare la creazione di business
solution desiderabili, fattibili, attuabili e sostenibili su larga scala, che soddisfano nel
tempo le esigenze del customer.
Solution Train
Il Solution Train è il costrutto organizzativo utilizzato per creare Solution complesse e di
grandi dimensioni che richiedono coordination di più Agile Release Train (ART), nonché
il contributo di Supplier. Allinea gli ART con una missione di business e tecnologica
comune utilizzando la Vision, il Backlog e la Roadmap della solution e un Program
Increment (PI) allineato.
Solution Train Engineer (STE)
Il Solution Train Engineer (STE) è servant leader e coach per il Solution Train, che
facilita e orienta il lavoro di tutti gli ART e i Supplier del Value Stream.
Spanning Palette
La Spanning Palette contiene diversi ruoli e artefatti che potrebbero essere applicabili a
uno specifico team, a un programma, a una Large Solution o a un Portfolio Context.
Story
Le Story sono brevi descrizioni di una piccola porzione di una funzionalità desiderata,
scritte nel linguaggio dell’utente. Gli Agile team implementano piccole fette (slice)
verticali di funzionalità del sistema e sono dimensionate in modo da consentirne il
completamento in una singola iteration.
Strategic Theme
Gli Strategic Theme sono obiettivi di business dettagliati e differenziati che collegano un
portfolio alla strategia di business della Enterprise. Influenzano la strategia di portfolio e
forniscono un contesto di business per il processo decisionale relativo al portfolio.
Supplier
Un Supplier è un’organizzazione interna o esterna che sviluppa e fornisce componenti,
sottosistemi o servizi che consentono ai Solution Train e agli Agile Release Train di
fornire solution ai propri customer.
System Architect/Engineer
Il System Architect/Engineering ha il compito di definire e comunicare una visione
tecnica e architettonica condivisa per un Agile Release Train (ART) per verificare che il
sistema o la Solution in corso di sviluppo siano adatti allo scopo previsto.
System Demo
La System Demo è un evento importante che fornisce una visione integrata delle nuove
Feature, che sono state realizzate da tutti i team dell’Agile Release Train (ART) nella
iteration più recente. Ciascuna demo fornisce agli stakeholder di un ART un indicatore
oggettivo dei progressi effettuati durante un Program Increment (PI).
© Scaled Agile, Inc. | www.scaledagileframework.com 13System Team
Il System Team è un Agile Team specializzato che assiste nella creazione e nel
supporto dell'ambiente di sviluppo Agile, dove in genere è incluso lo sviluppo e la
manutenzione della toolchain che supporta la Continuous Delivery Pipeline. Il System
Team può anche supportare l’integrazione degli asset degli Agile team, eseguire
laddove necessario test end-to-end delle solution e fornire assistenza per la
distribuzione e la Release on Demand.
Team Backlog
Il Team Backlog contiene le user story e le enabler story che hanno origine dal Program
Backlog, nonché le story che hanno origine a livello locale nel contesto del team. Può
includere anche altri elementi di lavoro e rappresenta tutto ciò di cui un team ha bisogno
per avanzare nello sviluppo della propria parte di sistema.
Team Kanban
Il Team Kanban è un metodo 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.
Value Stream Coordination
La Value Stream Coordination definisce come gestire le dipendenze e sfruttare le
opportunità che esistono soltanto nelle interconnessioni fra i value stream.
Value Stream
I Value Stream rappresentano la sequenza di azioni che un’organizzazione usa per
realizzare le Solution che forniscono un flusso di valore continuo al customer.
Vision
La Vision è una descrizione dello stato futuro della Solution in corso di sviluppo. Riflette
le esigenze dei customer e degli stakeholder nonché le Feature e le Capability proposte
per soddisfare tali esigenze.
Weighted Shortest Job First (WSJF)
Weighted Shortest Job First (WSJF) è un modello di prioritizzazione utilizzato per
ordinare i "lavori" (ad es. feature, capability, ed epic) in modo da produrre il massimo
beneficio economico. In SAFe, il WSJF è calcolato dividendo il Cost of Delay (CoD) per
la dimensione del lavoro.
© Scaled Agile, Inc. | www.scaledagileframework.com 14Puoi anche leggere
