Enablers (SAFe)

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.

Faciliter la conformité

En construisant de manière incrémentale les artefacts nécessaires dans l'intention de la solution au cours d'une série de PI, SAFe permet une vérification et une validation continues. Les activités de vérification sont menées dans le cadre du processus de développement et sont souvent imposées dans la définition des tâches (DoD). Bien que les artefacts satisfassent les preuves objectives nécessaires à la fin du développement, ils sont créés de manière itérative tout au long du cycle de vie. La validation a lieu lorsque les Product Owners, les clients et les utilisateurs finaux participent à la planification de l'ART et aux démonstrations du système, validant ainsi l'adéquation à l'objectif.

Les Enablers sont utilisés pour soutenir ces activités. Prenons l'exemple d'une réglementation qui exige des revues de conception et qui stipule que toutes les actions découlant de ces revues doivent être documentées lorsqu'elles sont terminées. Un élément du backlog intitulé "Design Review Enabler" (enabler de revue de conception) apporterait la preuve de la revue, et son DoD garantirait que les actions sont enregistrées et résolues conformément au système de gestion de la qualité (QMS) Lean. Si nécessaire, les activités elles-mêmes pourraient être suivies en tant qu'enabler stories.

Mise en œuvre incrémentale des Enablers

Les enablers fournissent des technologies et des informations essentielles et fondamentales pour la chaîne de valeur. Par conséquent, ils méritent une attention particulière dans le portefeuille, depuis la budgétisation et l'allocation des capacités jusqu'à la livraison et l'amélioration continue. Mais comme la valeur réelle des enablers est liée à la réalisation des futurs objectifs métier, il faut veiller à mettre en œuvre les enablers rapidement et de manière itérative. Dans le cas contraire, la fourniture de valeur aux clients peut être considérablement retardée, ce qui compromet l'objectif fondamental des enablers.

Tous les types d'enablers doivent être mis en œuvre de manière incrémentale. Cependant, comme les enablers d'architecture et d'infrastructure influencent souvent la fourniture et le fonctionnement de solutions critiques, ils méritent une mention spéciale ici.

L'ampleur et les exigences du travail des enablers d'architecture et d'infrastructure peuvent être énormes. Il est donc important de se rappeler qu'ils doivent être divisés en features et en stories qui peuvent être livrées de manière incrémentale. Cela peut toutefois s'avérer difficile, car les modifications de l'architecture et de l'infrastructure peuvent potentiellement empêcher le système existant de fonctionner jusqu'à ce que les changements soient mis en place.

Le travail doit être séquencé de manière à ce que le système puisse continuer à fonctionner dans l'environnement actuel pendant que les enablers sont mis en œuvre. De cette façon, les équipes peuvent continuer à travailler, à intégrer, à faire des démonstrations et même à livrer de nouvelles fonctionnalités.

Il existe trois façons d'aborder cette question [1] :

• Cas A - L'enabler est gros, mais l'approche de la mise en œuvre est incrémentale. Le système fonctionne toujours et est exploité.
• Cas B - L'enabler est gros, mais il ne peut pas être mis en œuvre de manière incrémentale. Le système devra occasionnellement être interrompu.
• Cas C - L'enabler est très gros et ne peut pas être mis en œuvre de manière incrémentale. Le système fonctionne lorsque c'est nécessaire.

Des exemples de patterns incrémentaux sont également décrits dans [2], où les sous-systèmes patrimoniaux sont progressivement "étranglés" au fil du temps, en utilisant des patterns éprouvés tels que la capture d'assets ou l'interception d'événements.

En créant les plates-formes technologiques qui fournissent les fonctionnalités métier, les enablers améliorent la situation économique. Mais le développement de produits innovants ne peut se faire sans prise de risque. C'est pourquoi les décisions initiales liées à la technologie ne peuvent pas toujours être correctes, et c'est pourquoi l'entreprise Lean doit être prête à changer de cap de temps en temps. Dans ce cas, le principe des coûts irrécupérables [3] (sunk costs) fournit une indication essentielle : ne pas tenir compte de l'argent déjà dépensé. La mise en œuvre incrémentale permet de prendre des mesures correctives avant que l'investissement ne devienne trop important.

Mise en œuvre des Enablers à travers les ART et les flux de valeur

Les enabler epics et capabilities peuvent traverser plusieurs flux de valeur ou ART. Au cours de la phase d'analyse du système Kanban approprié, il est important de déterminer s'il faut mettre en œuvre l'enabler dans toutes les ART simultanément ou incrémentalement (figure 2).


Figure 2. Deux approches pour la mise en œuvre des enablers transversaux.

Dans le scénario A, l'enabler est d'abord mis en œuvre dans l'ART 1, puis par les autres ART dans les PI suivants. Cela peut atténuer l'impact du changement sur l'ensemble du portefeuille, mais peut retarder la réalisation des bénéfices d'une mise en œuvre complète de l'enabler. En revanche, le scénario B prévoit que toutes les ART mettent en œuvre l'enabler en même temps. Ce scénario est préférable si le coût du retard de l'ensemble de la mise en œuvre est inacceptable.

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