« Enablers (SAFe) » : différence entre les versions
| Ligne 36 : | Ligne 36 : | ||
* Enabler Features et Capabilities - Elles sont définies par les ART et les [https://scaledagileframework.com/solution-train/ 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 Features et Capabilities - Elles sont définies par les ART et les [https://scaledagileframework.com/solution-train/ 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 [https://scaledagileframework.com/iterations/ 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. | * Enabler Stories - Elles doivent tenir dans les [https://scaledagileframework.com/iterations/ 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'[https://scaledagileframework.com/enterprise-architect/ architectes d'entreprise] qui contribuent au portefeuille, d'[architectes de systèmes https://scaledagileframework.com/system-architect/] qui contribuent aux ART ou d'[https://scaledagileframework.com/solution-architect/ architectes de solutions] qui contribuent aux [https://scaledagileframework.com/solution-train/ 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 [https://scaledagileframework.com/agile-teams/ équipes agiles] utilisent également des enablers ; des enabler stories émergent localement à partir de leurs besoins et sont portées dans le [https://scaledagileframework.com/team-backlog/ Backlog de l'équipe].<br/> | |||
<br/> | |||
Les exemples suivants illustrent comment les équipes agiles et les architectes créent et gèrent chacun des quatre types d'enablers. | |||
==En savoir plus== | ==En savoir plus== | ||
Version du 28 décembre 2023 à 15:30
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.
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.