Dans cet article, vous allez retrouver tous les acronymes et abréviations de SAFe ainsi que les termes et définitions.
Les termes du glossaire qui se trouvent sur la grande image de SAFe restent en anglais pour maintenir une terminologie commune.
Guide des acronymes et abréviations
ART : Agile Release Train
BO : Business Owner
BV : Business Value
BVIR : Big Visual Information Radiator
CapEx : Capital Expenses
CD : Continuous Delivery
CE : Continuous Exploration
CI : Continuous Integration
CFD : Cumulative Flow Diagram
CoD : Cost of Delay
CoP : Community of Practice
DoD : Definition of Done
DSU : Daily Stand-up
EA : Enterprise Architect
EO : Epic Owner
FW : Firmware
HW : Hardware
I&A : Inspect and Adapt
IP : Innovation and Planning (iteration)
KPI : Key Performance Indicator
LPM : Lean Portfolio Management
MBSE : Model-Based Systems Engineering
MMF : Minimum Marketable Feature
MVP : Minimum Viable Product
NFR : Non-functional Requirements
OE : Opportunity Enablement
OpEx : Operating Expenses
PDCA : Plan, Do, Check, Adjust
PI : Program Increment
PM : Product Management
PO/PM : Product Owner / Product Manager
PO : Product Owner
ROAM : Resolved, Owned, Accepted, Mitigated
RR : Risk Reduction
RTE : Release Train Engineer
S4T : SAFe® for Teams
SAFe® : Scaled Agile Framework
SA : SAFe®Agilist
SBD : Set-Based Design
SM : Scrum Master
SMART : Specific, Measurable, Achievable, Realistic, Time-bound
SoS : Scrum of Scrums
SP : SAFe® Practitioner
SPC : SAFe® Program Consultant
STE : Solution Train Enginee
SW : Software
UX : User Experience
VS : Value Stream
VSE : Value Stream Engineer
WIP : Work in Process
WSJF : Weighted Shortest Job First
XP : Extreme Programming
PI : Program Increment
PM : Product Management
PO/PM : Product Owner / Product Manager
PO : Product Owner
ROAM : Resolved, Owned, Accepted, Mitigated
RR : Risk Reduction
RTE : Release Train Engineer
S4T : SAFe® for Teams
SAFe® : Scaled Agile Framework
SA : SAFe®Agilist
SBD : Set-Based Design
SM : Scrum Master
SMART : Specific, Measurable, Achievable, Realistic, Time-bound
SoS : Scrum of Scrums
SP : SAFe® Practitioner
SPC : SAFe® Program Consultant
STE : Solution Train Enginee
SW : Software
UX : User Experience
VS : Value Stream
VSE : Value Stream Engineer
WIP : Work in Process
WSJF : Weighted Shortest Job First
XP : Extreme Programming
Termes et définitions
Agile Architecture
L’Agile Architecture est un ensemble de valeurs et de pratiques qui prennent en charge l’évolution active de la conception et de l’architecture d’un système tout en mettant en œuvre des nouvelles Capabilities du système.
Agile Release Train (ART)
L’Agile Release Train (ART) est une équipe d’équipes Agile de longue durée, qui, avec d’autres parties prenantes, développe et délivre des solutions de façon incrémentale en utilisant une série d’Iterations de longueur fixe au sein d’une boîte temporelle d’un Program Increment (PI). L’ART aligne les équipes sur une mission métier et technologique commune.
Agile Team
Le SAFe Agile Team est un groupe pluridisciplinaire de 5 à 10 personnes qui ont la capacité et l’autorité de définir, construire et tester certains éléments de la valeur de solution, le tout au cours d’une brève boîte temporelle d’Iteration. En particulier, le SAFe Agile Team intègre les rôles Dev Team, Scrum Master et Product Owner.
Architectural Runway
L’Architectural Runway est constitué par le code, les composants, l’infrastructure technique existants, qui sont nécessaires pour implémenter les prochaines Features les plus prioritaires, sans retard ni refonte excessifs.
Built-In Quality
Les pratiques Built-In Quality permettent que chaque élément de la solution réponde à des normes de qualité adaptées tout au long du développement, à chaque incrément.
Business Owners
Les Business Owners sont un petit groupe de parties prenantes ayant la responsabilité métier et technique principales de la gouvernance, de la conformité et du Return on Investment (ROI) d’une solution développée par un Agile Release Train (ART). Il s’agit de parties prenantes de l’ART qui doivent évaluer l’usage adapté et participer activement dans certains événements de l’ART.
CapEx and OpEx
Les dépenses en capital (CapEx) et les coûts d’exploitation (OpEx) décrivent les pratiques comptables financières Lean-Agile dans un budget par Value Stream. Dans certains cas, le CapEx peut inclure le travail capitalisé associé au développement d’actifs immatériels tels que les logiciels, la propriété intellectuelle et les brevets.
Capabilities
Une Capability est un comportement global de la solution qui couvre généralement plusieurs ART. Les Capabilities sont dimensionnées et divisées en plusieurs Features pour faciliter leur implémentation en un unique PI.
Communities of Practice (CoPs)
Les Communities of Practice (CoPs) sont des groupes organisés de personnes ayant un intérêt commun dans un domaine technique ou métier spécifique. Ces personnes collaborent régulièrement pour échanger des informations, renforcer leurs compétences et travailler activement pour développer les connaissances générales de leur domaine.
Compliance
La Compliance se résume par une stratégie et un ensemble d’activités et d’artefacts qui permettent aux équipes d’appliquer les méthodes de développement Lean-Agile pour construire des systèmes ayant la qualité plus élevée possible, tout en assurant leur conformité en matière légale, technique ou relative à d’autres normes.
Continuous Delivery Pipeline
Le Continuous Delivery Pipeline (ou tout simplement pipeline) représente les flux de travail, les activités et l’automatisation nécessaires pour fournir une valeur continue à l’utilisateur final.
Continuous Deployment (CD)
Continuous Deployment (CD) est le processus qui consiste à prendre des Features validées de Continuous Integration et à les déployer dans l’environnement de production, où elles sont testées et préparées pour la Release. Il s’agit du troisième élément des quatre de Continuous Delivery Pipeline, à savoir Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment et Release on Demand.
Continuous Exploration (CE)
Continuous Exploration (CE) est le processus d’exploration continue du marché et des exigences des utilisateurs, et de définition d’une vision, d’une Roadmap, et d’un ensemble de Features qui répondent à ces exigences. Il s’agit du premier élément des quatre de Continuous Delivery Pipeline, et précède Continuous Integration (CI), Continuous Deployment (CD) et Release on Demand.
Continuous Integration (CI)
Continuous Integration (CI) est le processus qui consiste à prendre des Features de Program Backlog puis de les développer, tester, intégrer et les valider dans un environnement intermédiaire pour les préparer au déploiement et à la Release.
Core Values
Les quatre valeurs fondamentales (Core Values), à savoir l’alignement, le built-in quality, la transparence et l’exécution du programme, représentent les convictions essentielles à la base de l’efficacité de SAFe. Ces principes guides contribuent à imposer le comportement et l’action pour chaque individu qui participe à un portefeuille SAFe.
Customers
Les Customers sont les acheteurs finaux de chaque solution. Ils font partie intégrante du processus de développement Lean-Agile et du Value Stream, et ont des responsabilités spécifiques dans SAFe.
Dev Team
Le Dev Team est un sous-ensemble de l’Agile Team. Il s’agit de professionnels dédiés qui peuvent développer et tester une Story, Feature ou un composant. Généralement le Dev Team inclut des développeurs et testeurs de logiciels, des ingénieurs et autres experts dédiés requis pour compléter une tranche verticale de fonctionnalité.
DevOps
DevOps est un état d’esprit, une mentalité et un ensemble de pratiques techniques. DevOps fournit la communication, l’intégration, l’automatisation et l’étroite coopération entre tous les professionnels nécessaires pour planifier, développer, tester, déployer, faire la Release et mettre
à jour une solution.
Develop on Cadence
Le Develop on Cadence est une méthode essentielle permettant de gérer la variabilité inhérente au développement de systèmes dans un système basé sur les flux, qui consiste à veiller à ce que les événements et les activités soient gérés selon un calendrier régulier et prévisible.
Economic Framework
L’Economic Framework est un ensemble de règles décisionnelles visant à aligner tout le monde sur les objectifs financiers de la solution et qui définit le processus de prise de décision économique. Il inclut quatre concepts principaux : budgets Lean, financement et gouvernance Epic, prise de décision décentralisée et séquencement du travail selon le Cost of Delay (CoD).
Enablers
Les Enablers prennent en charge les activités nécessaires pour étendre l’Architectural Runway pour fournir les futures fonctionnalités métier. Ces activités incluent le développement de l’exploration, de l’infrastructure, de la conformité et de l’architecture. Les Enablers se retrouvent dans tous les Backlogs et se positionnent à tous les niveaux du framework.
Enterprise
L’Enterprise représente l’entité métier à laquelle chaque portefeuille SAFe appartient.
Enterprise Architect
L’Enterprise Architect promeut des pratiques de conception et d’ingénierie adaptatives, et pilote les initiatives architecturales pour le portefeuille. L’Enterprise Architect facilite également la réutilisation des idées, des composants, des services et des modèles éprouvés à travers les différentes solutions d’un portefeuille.
Epic
Une Epic est un conteneur pour le développement d’une solution suffisamment grand pour nécessiter une analyse, la définition d’un Minimum Viable Product (MVP) et l’approbation financière avant son implémentation. L’implémentation a lieu sur plusieurs Program Increments (PI) et suit le cycle de lancement Lean « construire-mesurer-apprendre ».
Epic Owners
Les Epic Owners sont en charge de faire progresser les epics dans le système du Portfolio Kanban. Ils définissent l’epic, son Minimum Viable Product (MVP) et le business case Lean, et une fois approuvés, facilitent la mise en œuvre.
Essential SAFe configuration
L’Essential SAFe configuration est le cœur du Framework et est le point de départ le plus simple de l’implémentation. Il s’agit du constituant de base pour toutes les autres configurations de SAFe et décrit les éléments plus critiques requis pour réaliser la plupart des avantages du Framework.
Features
Une Feature est un service qui répond à l’exigence d’une partie prenante. Chaque Feature comprend une hypothèse d’avantage et des critères d’acceptation, et est dimensionnée ou divisée selon le besoin pour être fournie par un unique Agile Release Train (ART) au sein d’un Program Increment (PI).
Foundation
La Foundation contient les principes fondamentaux, les valeurs, l’état d’esprit, les consignes de mise en œuvre et les rôles de leadership nécessaire pour fournir des valeurs précieuses sur grande échelle.
Full SAFe configuration
La Full SAFe configuration est la version la plus complète du Framework. Elle prend en charge les entreprises qui construisent et mettent à jour des grandes solutions intégrées qui requièrent des centaines d’individus ou plus et incluent tous les niveaux de SAFe : équipe, programme, grande solution et portefeuille. Dans les plus grandes entreprises, il est possible que plusieurs instances de différentes configurations de SAFe soient requises.
Innovation and Planning Iteration
L’Innovation and Planning (IP) Iteration se produit à chaque Program Increment (PI) et sert plusieurs objectifs. Elle joue un rôle de marge pour l’atteinte des objectifs de PI et réserve du temps pour l’innovation, la formation continue, la planification du PI et les ateliers Inspect and Adapt (I&A).
Inspect & Adapt (I&A)
L’Inspect and Adapt (I&A) est un atelier important organisé à la fin de chaque Program Increment (PI) au cours duquel l’état courant de la solution est démontré et évalué par le train. Ensuite, les équipes réfléchissent et identifient des éléments intégrés dans le Backlog via un atelier structuré destiné à résoudre les problèmes.
Iteration
Les Iterations sont les constituants de base du développement Agile. Chaque Iteration est une boîte temporelle standard de longueur au cours de laquelle les Agile Teams délivrent une valeur incrémentale sous la forme de logiciels et de systèmes fonctionnels et testés. La durée recommandée de la boîte temporelle est de deux semaines. Toutefois, une durée d’une à quatre semaines est acceptable, selon le contexte métier.
Iteration Execution
L’Iteration Execution est la façon dont les Agile Teams gèrent leur travail durant la boîte temporelle de l’Iteration, et qui conduit à un incrément système testé, fonctionnel et de haute qualité.
Iteration Goals
Les Iteration Goals sont des résumés de haut niveau des objectifs métier et techniques que l’Agile Team s’engage à atteindre dans une Iteration. Ils sont essentiels pour coordonner un Agile Release Train (ART) en tant qu’équipe auto-organisée et autogérée d’équipes.
Iteration Planning
L’Iteration Planning est un événement au cours duquel tous les membres de l’équipe déterminent le nombre d’éléments du Team Backlog qu’ils peuvent s’engager à délivrer dans l’Iteration à venir. L’équipe cumule le travail comme un ensemble des Iteration Goals pour lesquels elle s’est engagée.
Iteration Retrospective
L’Iteration Retrospective est une réunion périodique au cours de laquelle les membres de l’Agile Team discutent les résultats de l’Iteration, examinent leurs pratiques et identifient des moyens de s’améliorer.
Iteration Review
L’Iteration Review est un événement basé sur la cadence, où chaque équipe inspecte l’incrément à la fin de chaque Iteration pour évaluer le progrès, puis ajuster son Backlog pour l’Iteration suivante.
Large Solution Level
Le Large Solution Level contient les rôles, les artefacts et les processus nécessaires pour construire des solutions grandes et complexes. Ceci inclut un effort plus important pour capturer les exigences dans la Solution Intent, la coordination de plusieurs Agile Release Trains (ART) et Suppliers, et la nécessité de garantir la conformité aux réglementations et aux normes.
Large Solution SAFe configuration
La Large Solution SAFe configuration est conçue pour le développement des solutions plus grandes et complexes qui normalement requièrent plusieurs Agile Release Trains et Suppliers, mais qui ne nécessitent pas de considérations de portefeuille. Ceci est plutôt courant dans les domaines aérospatial et défense, automobile et fonction publique où la solution à grande échelle – non pas la gouvernance du portefeuille – est la préoccupation majeure.
Lean Budgets
Lean Budgets est un ensemble de pratiques qui permettent de réduire les frais supplémentaires en déléguant
la responsabilité financière aux Value Streams et non aux projets, tout en maintenant une gouvernance financière adaptée. Ceci est réalisé à travers l’évaluation objective des systèmes en cours, la gestion active des investissements Epic et les ajustements de budget dynamiques.
Lean Portfolio Management (LPM)
La fonction Lean Portfolio Management (LPM) possède le niveau le plus élevé de prise de décisions et de comptabilité financière pour les produits et les solutions dans un portefeuille SAFe.
Lean User Experience (Lean UX)
La conception Lean User Experience (Lean UX) est un état d’esprit, une mentalité et un processus qui comprend les méthodes Lean-Agile. Elle met en œuvre les fonctionnalités par incréments minimums viables et détermine la réussite en comparant résultats et hypothèses d’avantages.
Lean and Agile Principles
SAFe est basé sur neuf principes immuables et sous-jacents. Ces dogmes et concepts économiques inspirent et informent les rôles et les pratiques de SAFe.
Lean-Agile Leaders
Les Lean-Agile Leaders apprennent en permanence. Ils sont chargés de l’adoption de SAFe et sont responsables de ses résultats. Ils aident et assistent les équipes à construire de meilleurs systèmes par le biais de l’apprentissage, de la présentation, de l’enseignement et du soutien des principes et pratiques Lean-Agile de SAFe.
Lean-Agile Mindset
Le Lean-Agile Mindset est la combinaison de croyances, hypothèses et actions des leaders et experts SAFe qui diffusent les concepts de l’Agile Manifesto et de la pensée Lean. Il s’agit des fondements personnels, intellectuels et de leadership qui sont à la base de l’adoption et de l’application des principes et pratiques SAFe.
Metrics
Les Metrics sont des mesures convenues et utilisées pour évaluer la façon dont l’entreprise et évolue dans la mise en place du portfolio, de la solution sur grande échelle, du programme et des objectifs métier et techniques des teams.
Milestones
Les Milestones sont utilisés pour suivre l’avancement en direction d’un objectif ou d’un événement spécifique. Il existe trois types de Milestones SAFe : les Milestones Program Increment (PI), les Milestones à date fixe et les Milestones d’apprentissage.
Model-Based Systems Engineering (MBSE)
Model-Based Systems Engineering (MBSE) est la pratique qui vise le développement d’un ensemble de modèles de système pour définir, concevoir et documenter un système en cours de développement. Ces modèles constituent un moyen efficace d’explorer, de mettre à jour et de communiquer les aspects du système aux parties prenantes tout en réduisant ou en éliminant de façon significative la dépendance à des documents traditionnels.
Nonfunctional Requirements (NFRs)
Les Nonfunctional Requirements (NFRs) définissent les attributs du système tels que la sécurité, la fiabilité, la performance, la maintenabilité, l’évolutivité et l’accessibilité. Elles constituent des contraintes ou des restrictions à la conception du système sur les différents Backlogs.
Portfolio Backlog
Le Portfolio Backlog est une liste prioritaire de commandes au sein de SAFe. Il représente une zone d’attente des commandes et des epics Enabler futurs dans le but de créer un ensemble complet de solutions destiné à fournir la différentiation concurrentielle et les améliorations opérationnelles nécessaires pour faire face aux Strategic Themes et faciliter la réussite métier.
Portfolio Kanban
Le Portfolio Kanban est une méthode utilisée pour visualiser, gérer et analyser la priorisation et le flux des portfolios epics, de la conception à la complétion en passant par la réalisation.
Portfolio Level
Le Portfolio Level contient les principes, pratiques et rôles nécessaires pour démarrer et gérer un ensemble de Value Streams de développement. C’est ici que la stratégie et la budgétisation sont définies pour les Value Streams et leurs solutions. Ce niveau fournit également les opérations du portfolio Agile et la gouvernance Lean pour les individus et les ressources nécessaires pour livrer les solutions.
Portfolio SAFe configuration
La Portfolio SAFe configuration vise à aligner l’exécution du portfolio sur la stratégie de l’entreprise en organisant le développement Agile autour du flux de valeurs, par le biais d’un ou de plusieurs Value Streams. Elle assure la souplesse métier via principes et pratiques à : stratégie du portfolio et budgétisation, opérations du Portfolio Agile et gouvernance Lean.
Pre- and Post-PI Planning
Les événements Pre- and Post-Program Increment (PI) Planning sont utilisés pour préparer et assurer le suivi du PI Planning des Agile Release Trains (ART) et Suppliers dans un Solution Train.
Product Management
Le Product Management possède l’autorité sur le contenu au niveau du Program Backlog. Il est responsable de l’identification des besoins du Customer, de la priorisation des Features, de la gestion du travail par le Program Kanban et du développement de la Vision du programme et de la Roadmap du programme.
Product Owner (PO)
Le Product Owner (PO) est un membre de l’Agile Team responsable de la définition des Stories et de la priorisation du Team Backlog pour aider l’équipe à optimiser l’exécution des priorités du programme tout en conservant l’intégrité conceptuelle et technique des Features ou des composants.
Program Backlog
Le Program Backlog est la zone d’attente des Features futures destinées à répondre aux exigences des utilisateurs et fournir les avantages métiers d’un unique Agile Release Train (ART). Il comprend aussi les Enabler Features nécessaires pour construire l’Architectural Runway.
Program Increment (PI)
Un Program Increment (PI) est une boîte temporelle pendant laquelle un Agile Release Train (ART) délivre un incrément de valeur sous la forme de logiciels et systèmes fonctionnels et testés. Les PI durent normalement de 8 à 12 semaines. En général, un PI comprend quatre Iterations de développement, suivies d’une Innovation and Planning (PI) Iteration.
Program Increment (PI) Planning
La Program Increment (PI) Planning est un événement de planification récurrent et en face à face qui module le rythme de l’Agile Release Train (ART) et fixe une mission et une vision communes à toutes les équipes de l’ART.
Program Kanban
Les systèmes Program Kanban et Solution Kanban sont des méthodes pour visualiser et gérer le flux de Features et Capabilities de la conception à la Release en passant par analyse et mise en œuvre, via le Continuous Delivery Pipeline.
Program Level
Le Program Level contient les rôles et les activités nécessaires pour délivrer en continu des solutions à l’aide d’un Agile Release Train (ART).
Refactoring
Le Refactoring est l’activité d’amélioration de la structure interne ou du fonctionnement d’un code ou d’un composant sans pour autant modifier son comportement externe.
Release Train Engineer (RTE)
Le Release Train Engineer (RTE) est un responsable-serviteur et coach pour l’Agile Release Train (ART). Les responsabilités principales du RTE consistent à faciliter les processus et les événements ART et à assister les équipes pour fournir de la valeur. Les RTE communiquent avec les parties prenantes, font remonter les obstacles, aident à gérer les risques et poussent à une amélioration sans relâche.
Release on Demand
Release on Demand est le processus à travers lequel les Features déployées en production sont distribuées de manière incrémentale ou immédiatement aux Customers selon la demande du marché.
Roadmap
La Roadmap est un calendrier des événements et des Milestones qui informe des dates de livraison de la solution. Il comprend des engagements pour le Program Increment (PI) planifié et donne de la visibilité sur les livrables prévus pour quelques PI à venir.
SAFe Implementation Roadmap
La SAFe Implementation Roadmap est un diagramme général et une série de 12 éléments qui décrivent une stratégie et un ensemble organisé d’activités ayant fait preuve d’efficacité dans la mise en œuvre réussie de SAFe.
SAFe Program Consultants (SPC)
Les SAFe Program Consultants (SPC) sont des agents de changement qui unissent leurs connaissances techniques de SAFe à une motivation intrinsèque pour améliorer les processus de développement des logiciels et des systèmes de l’entreprise. Ils jouent un rôle essentiel dans la mise en œuvre de SAFe. Les SPC proviennent de plusieurs rôles internes ou externes, y compris des leaders métiers et techniques, responsables de portfolio/programme/projet, leaders de processus, architectes, analystes, et consultants.
Scrum Master
Un Scrum Master est un responsable-serviteur et coach d’un Agile Team. Il contribue à former l’équipe à Scrum, à l’Extreme Programming (XP), au Kanban et à SAFe, et veille à ce que le processus Agile convenu soit suivi. De plus, il participe à la résolution des problèmes et à la création d’un environnement favorisant la dynamique de groupe performant, le flux permanent de livraison et l’amélioration sans relâche.
ScrumXP
ScrumXP est un processus simplifié de livraison de valeur conçu pour les équipes pluridisciplinaires et auto-organisées au sein de SAFe. Il combine la puissance des pratiques de la gestion de projet Scrum et celle des pratiques de l’Extreme Programming (XP).
Set-Based Design
La Set-Based Design (SBD) est une pratique qui conserve la souplesse des exigences et des options de conception le plus longtemps possible au cours du processus de développement. Au lieu de choisir une unique piste de solution en amont, la SBD identifie et explore simultanément plusieurs options, et élimine peu à peu les choix moins judicieux. Ceci favorise la flexibilité du processus de conception en confirmant les solutions techniques uniquement après validation des hypothèses, ce qui conduit à de meilleurs résultats économiques.
Shared Services
Les Shared Services sont les rôles, personnes et services spécialisés nécessaires à la réussite d’un Agile Release Train (ART) ou d’un Solution Train mais qui ne peuvent pas être dédiés à temps plein.
Solution
Chaque Value Stream produit une ou plusieurs Solutions représentées par des produits, services ou systèmes fournis au Customer, qu’il soit interne ou externe à l’entreprise.
Solution Architect/Engineer
Le rôle Solution Architect/Engineer représente un individu ou une petite équipe qui définissent une vision technique et architecturale partagée de la solution en développement. Ils participent à la définition des systèmes, des sous-systèmes, des interfaces. Ils valident les hypothèses technologiques et évaluent les alternatives en travaillant étroitement avec les Agile Release Trains (ART) et le Solution Train.
Solution Backlog
Le Solution Backlog est la zone d’attente des futurs Capabilities et Enablers, qui peuvent s’étaler sur plusieurs ART. Il est utilisé pour faire progresser la solution et construire son Architectural Runway.
Solution Context
Le Solution Context identifie les aspects critiques de l’environnement opérationnel de la solution. Il fournit une compréhension essentielle des exigences, usage, installation, exploitation et support de la solution. Le Solution Context a un impact significatif sur les possibilités et les contraintes d’effectuer une Release sur demande.
Solution Demo
La Solution Demo est le point où les résultats de tous les efforts de développement d’un Solution Train sont intégrés, évalués et présentés aux Customers et autres parties prenantes.
Solution Management
La Solution Management possède l’autorité sur le contenu pour la Solution Backlog. Ils travaillent avec les Customers pour comprendre leurs besoins, prioriser les Capabilities, définir la Vision et la Roadmap de la solution, définir les exigences et guider le travail via la Solution Kanban.
Solution Train
Le Solution Train est le concept organisationnel utilisé pour construire des solutions grandes et complexes qui requièrent la coordination de plusieurs Agile Release Trains (ART), ainsi que les contributions de Suppliers. Sa fonction est d’aligner les ART à une mission métier et technologique partagée en utilisant la vision de la solution, la solution Backlog et la solution Roadmap, le tout selon le Program Increment (PI).
Spanning Palette
La Spanning Palette contient les divers rôles et artefacts qui peuvent être applicables à une équipe, programme, solution à grande échelle ou contexte de portfolios spécifiques. Élément clé de la flexibilité et configurabilité de SAFe, la spanning palette permet aux entreprises d’appliquer uniquement les éléments nécessaires à leur configuration.
Spikes
Les Spikes sont un type d’Enabler Story d’exploration dans SAFe. Définis initialement dans Extreme Programming (XP), ils représentent les activités telles que recherche, conception, exploration et prototypage. Leur but est d’acquérir les connaissances nécessaires pour réduire le risque d’une approche technique, pour analyser une exigence ou pour augmenter la fiabilité de l’évaluation d’une Story.
Stories
Les Stories sont des descriptions courtes des fonctionnalités souhaitées, écrites dans la langue de l’utilisateur. Les Agile Teams implémentent des petites tranches verticales des fonctionnalités d’un système et sont dimensionnés de manière à les compléter au cours d’une unique Iteration.
Supplier
Un Supplier est une organisation interne ou externe qui développe et fournit des composants, sous-systèmes ou services qui aident les Solution Trains à fournir des solutions à leurs Customers.
System Architect/Engineering
Le rôle System Architect/Engineering représente une personne ou une petite équipe qui définit une vision technique et architecturale partagée pour la Solution en cours de développement. Ils participent à la détermination du système, des sous-systèmes et des interfaces, à la validation des hypothèses technologiques et à l’évaluation des alternatives, tout en travaillant en étroite collaboration avec l’Agile Release Train (ART) et le Solution Train.
+ d’infos System Architect/Engineering
System Demo
La System Demo est un événement important qui fournit une vue intégrée des nouvelles Features de la plus récente Iteration livrées par toutes les équipes de l’Agile Release Train (ART). Chaque Demo fournit aux parties prenantes de l’ART une mesure objective de l’avancement durant un Program Increment (PI).
System Team
La System Team est une Agile Team spécialisée qui fournit une assistance pour la construction et l’utilisation de l’environnement de développement Agile, y compris pour la Continuous Integration, la Test Automation et le Continuous Deployment. Le System Team prend en charge l’intégration des actifs des Agile Teams, et réalise des tests de bout en bout de la solution lorsque cela est nécessaire et participe au déploiement à la Release.
Team Backlog
Le Team Backlog contient les Stories liées à l’utilisateur et aux Enablers qui proviennent du Program Backlog, ainsi que les Stories découlant, au niveau local, du contexte local de l’équipe. Il peut inclure également d’autres éléments de travail, tels que tout ce dont une équipe a besoin de savoir pour faire avancer sa partie du système.
Team Kanban
La Team kanban est une méthode qui assiste les équipes dans l’optimisation du flux de valeur ; elle prévoit de visualiser le flux de travail, de définir les limites du Work In Process (WIP), de mesurer les débits et d’améliorer continuellement leurs processus.
Team Level
Le Team Level contient les rôles, les activités, les événements et les processus construits par les Agile Teams, et fournit de la valeur dans le contexte de l’Agile Release Train (ART).
Test-First
Test-First est une pratique de built-in quality dérivée d’Extreme Programming (XP) qui recommande de construire des tests avant d’écrire du code pour améliorer la fourniture en ciblant les résultats attendus.
Value Stream Coordination
La Value Stream Coordination fournit des orientations pour la gestion des dépendances et exploite les opportunités d’un portfolio.
Value Streams
Des Value Streams sont une série d’étapes qu’une entreprise utilise pour élaborer une solution et offrir un flux de valeur continu à un Customer. Les Value Streams de SAFe sont utilisées pour définir et réaliser des objectifs métier pour le portfolio et pour organiser les Agile Release Trains (ART) pour fournir plus rapidement de la valeur.
Vision
La Vision est une description de l’état futur de la solution en cours de développement. Elle reflète les exigences des Customers et des parties prenantes, ainsi que celles des Features et des Capabilities, proposées pour répondre à ces exigences.
Weighted Shortest Job First (WSJF)
Le Weighted Shortest Job First (WSJF) est un modèle de priorisation utilisé pour séquencer les tâches (par ex. Features, Capabilities et epics) afin de produire le profit économique maximum. Dans SAFe, le WSJF est calculé comme suit : Cost of Delay (CoD) divisé par la taille de la tâche.
© Scaled Agile, Inc.
