« Le Release Train n'est pas Agile » : différence entre les versions

De Wiki Agile
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
 
(3 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
[[Category: Agilité à grande échelle]]
[[Category: Agilité à grande échelle]]
[[Category: SAFe]]
[[Category: SAFe]]
[[Catégorie:Paradoxes]]
[[Catégorie:Comic Agilé.net]]
Auteur : Comic Agilé <br />
Auteur : Comic Agilé <br />
Source : [https://www.comicagile.net/comic/the-unagile-release-train/ #108 – The Unagile Release Train]<br />
Source : [https://www.comicagile.net/comic/the-unagile-release-train/ #108 – The Unagile Release Train]<br />
Ligne 9 : Ligne 11 :
Traduction :<br />
Traduction :<br />
<br />
<br />
[[Fichier:Comic-agilé-agile-release-train FR.png|border|link=|800px]]
[[Fichier:Comic-agilé-agile-release-train FR.png|border|link=|1000px]]


Ne prenez pas d'engagements qui s'étendent trop loin dans le futur. Au contraire, seuls les objectifs du PI suivant doivent être communiqués aux parties prenantes, conformément aux engagements pris par l'ART. Le reste de la feuille de route n'est que notre meilleure estimation actuelle, de sorte que l'ART est en mesure de se tourner vers des opportunités nouvellement découvertes ("être agile", vous savez ?).
Ne prenez pas d'engagements qui s'étendent trop loin dans le futur. Au contraire, seuls les objectifs du PI suivant doivent être communiqués aux parties prenantes, conformément aux engagements pris par l'ART. Le reste de la feuille de route n'est que notre meilleure estimation actuelle, de sorte que l'ART est en mesure de se tourner vers des opportunités nouvellement découvertes ("être agile", vous savez ?).

Dernière version du 11 décembre 2023 à 08:49

Auteur : Comic Agilé
Source : #108 – The Unagile Release Train


Traducteur : Fabrice Aimetti
Date : 13/11/2022


Traduction :

Ne prenez pas d'engagements qui s'étendent trop loin dans le futur. Au contraire, seuls les objectifs du PI suivant doivent être communiqués aux parties prenantes, conformément aux engagements pris par l'ART. Le reste de la feuille de route n'est que notre meilleure estimation actuelle, de sorte que l'ART est en mesure de se tourner vers des opportunités nouvellement découvertes ("être agile", vous savez ?).

En outre, n'oubliez pas que votre feuille de route architecturale doit être indicative et non un plan détaillé de tous les outils à venir pour les deux prochaines années. Alignez plutôt la feuille de route architecturale sur votre feuille de route et encouragez une architecture émergente basée sur le travail continu de découverte de fonctionnalités.

Pour que cela réussisse, il faut que le Product Management et l'Architecte Système s'alignent fréquemment l'un avec l'autre. De plus, demandez au RTE d'apprendre aux BOs à comprendre que le fait d'avoir des pistes qui s'étendent jusqu'à l'horizon n'est probablement pas ce qu'il y a de mieux pour leur entreprise. Ainsi, au lieu de leur donner un sentiment de "contrôle" en leur montrant un planning de livraison ferme, renforcez leur confiance en vous en tant qu'ART en les impliquant souvent dans la direction à prendre - pas seulement lors de la planification et de la démonstration du système PI, mais aussi pendant la découverte, l'affinage et le développement.