« Enablers (SAFe) » : différence entre les versions
De Wiki Agile
| Ligne 62 : | Ligne 62 : | ||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
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. | 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.<br/> | ||
===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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
==En savoir plus== | ==En savoir plus== | ||
