Enablers (SAFe)

De Wiki Agile
Aller à la navigation Aller à la recherche

Auteur : © 2010-2023 Scaled Agile, Inc.
Source : Enablers
Date : 13/10/2023 (dernière mise à jour)


Traducteur : Fabrice Aimetti
Date : 28/12/2023


Traduction :

La chance est une question de préparation venant à la rencontre d‘une opportunité.


- Largement attribué à Sénèque, philosophe et dramaturge romain.

Enablers

Les Enablers sont des éléments du backlog qui étendent la piste architecturale (architectural runway) de la solution en cours de développement ou qui améliorent la performance de la chaîne de valeur (value stream) du développement.

Les Enablers sont capturés dans les backlogs comme des types d'Epic (fr), Capability, Feature, ou Story. Ils sont principalement utilisés pour l'exploration, la mise en œuvre de l'architecture, le refactoring, la construction de l'infrastructure et le traitement de la conformité. Bien que leur type soit différent, ils sont gérés de la même manière que les éléments du backlog orientés vers le client.

Description détaillée

Les Enablers apportent de la visibilité à tout le travail nécessaire pour soutenir le développement efficace et la livraison des futures exigences métier. Les Enablers sont utilisés pour explorer des idées, améliorer l'architecture, renforcer l'infrastructure et gérer la conformité. Étant donné que les Enablers aboutissent à la production de résultats tangibles, ils doivent être visibles. Ils sont traités comme tous les autres éléments du backlog, c'est-à-dire qu'ils doivent être visibles, priorisés, livrés de manière incrémentale, mesurés et faire l'objet d'un feedback.

Types d'Enablers

Les Enablers peuvent être utilisés pour définir toute activité qui améliore la chaîne de valeur afin de répondre aux besoins prévisibles du métier. Ces activités entrent généralement dans l'une des quatre catégories suivantes :

  • Exploration - soutien à la recherche, au prototypage et à d'autres activités nécessaires pour comprendre les besoins des clients, y compris l'exploration de Solutions potentielles et l'évaluation d'alternatives.
  • Architectural - utilisé pour construire la piste architecturale (Architectural Runway), qui permet un développement plus fluide et plus rapide par le biais de la chaîne de livraison continue (CDP - Continuous Delivery Pipeline).
  • Infrastructure - soutien à la création et à l'optimisation des environnements de développement et d'exécution qui hébergent les systèmes utilisés pour construire, valider, déployer et exploiter les solutions.
  • Conformité - facilite la gestion des activités de conformité spécifiques, y compris la vérification et la validation (V&V), les audits et les approbations, et l'automatisation des règles.

Création et gestion des Enablers

Les Enablers existent tout au long de SAFe et sont écrits et priorisés selon les mêmes règles que leurs epics, features, capabilities et stories correspondantes.

  • Enabler Epics - Elles sont écrites en utilisant le format "epic hypothesis statement", de la même manière que les epics métier. Les Enabler Epics peuvent s'étendre sur plusieurs trains de versions Agile (ART) et PI et sont gérées via le Portfolio Backlog et le système Kanban qui lui est associé.
  • Enabler Features et Capabilities - Elles sont définies par les ART et les Solution Trains et comprennent une courte phrase, une hypothèse de bénéfice et des critères d'acceptation. Elles doivent être dimensionnées pour tenir dans un seul PI.
  • Enabler Stories - Elles doivent tenir dans les itérations comme n'importe quelle autre story. Bien qu'elles ne nécessitent pas le format de la voix de l'utilisateur, leurs critères d'acceptation clarifient les exigences et favorisent les tests.

Les architectes définissent et pilotent souvent les enabler epics, features et capabilities. Il peut s'agir d'architectes d'entreprise qui contribuent au portefeuille, d'[architectes de systèmes https://scaledagileframework.com/system-architect/] qui contribuent aux ART ou d'architectes de solutions qui contribuent aux Trains de Solution. Les architectes dirigent les enablers à travers le système Kanban et le backlog appropriés, en guidant la mise en œuvre du concept à la livraison. Les équipes agiles utilisent également des enablers ; des enabler stories émergent localement à partir de leurs besoins et sont portées dans le Backlog de l'équipe.

Les exemples suivants illustrent comment les équipes agiles et les architectes créent et gèrent chacun des quatre types d'enablers.

Faciliter l'exploration

Les enablers d'exploration fournissent des éléments de travail que les équipes peuvent utiliser pour découvrir les exigences et les détails de la conception. La nature de l'intention de la solution est que de nombreuses exigences commencent par une intention vague. Au début du développement, on sait peu de choses sur les besoins du client ou sur la manière de les mettre en œuvre. Souvent, les clients eux-mêmes ne comprennent pas précisément ce dont ils ont besoin. Grâce à l'exploration continue, les équipes apprennent progressivement quels aspects de l'intention de la solution doivent passer de vagues à déterminés.

D'un point de vue encore plus large, il existe généralement de nombreuses possibilités techniques pour mettre en œuvre un besoin ou une opportunité identifiés. Ces alternatives doivent être analysées et sont souvent évaluées par le biais de la modélisation, du prototypage, du Set-Based Design ou du Cycle Lean Startup (fr). Les enablers d'exploration formalisent ces activités, assurent la visibilité du travail et contribuent à garantir que le développement de la solution est étroitement aligné sur les besoins des clients et des parties prenantes.

Faciliter l'architecture

En SAFe, les pratiques d'architecture agile produisent une piste architecturale (architectural runway), la technologie sous-jacente qui permet aux équipes agiles et aux ART de fournir rapidement des solutions métier. Mais la piste est constamment occupée par des epics, des features, des capabilities et des stories métiers, et doit donc être étendue à de nouvelles fonctionnalités.

Les enablers d'architecture sont utilisés pour construire, étendre et maintenir la piste. Les enablers d'architecture peuvent également résoudre les problèmes de résilience des solutions déployées. Après la mise en œuvre, ces enablers reflètent souvent les exigences non fonctionnelles (NFR) imposées aux futurs éléments du backlog. Les NFR sont souvent à l'origine des enablers d'architecture et se développent globalement au fil du temps (Figure 1).


Figure 1. De nombreuses NFR apparaissent au fil du temps grâce aux enablers.

Faciliter l'infrastructure

Le développement agile nécessite une intégration fréquente. Les équipes agiles intègrent leur travail et présentent l'incrément de solution lors de la démonstration du système. De même, les ART qui font partie d'un train de solutions intègrent leur travail aussi souvent que possible pendant le PI en préparation des démonstrations de solutions. Les enablers d'infrastructure fournissent la technologie d'intégration continue et de déploiement continu qui soutient cette cadence d'intégration agressive.

L'équipe système joue un rôle essentiel dans la définition et la mise en place des enablers d'infrastructure qui améliorent l'environnement de développement et rationalisent le pipeline de livraison continue (CDP). Les services partagés, les équipes d'exploitation et l'ingénierie de fiabilité des sites (SRE) s'appuient sur les enablers d'infrastructure pour fournir des services Cloud qui accélèrent le développement et la mise à l'échelle des solutions.

En savoir plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.
[2] Fowler, Martin. Strangler Fig Application. MartinFowler.com, June 29, 2004. Retrieved October 13, 2023, from http://martinfowler.com/bliki/StranglerApplication.html
[3] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Autres ressources

Télécharger les posters