« Votre transition n'est pas très agile » : différence entre les versions
Page créée avec « Category: Tim Ottinger Category: Portail Equipe de développement <div id="content_view" class="wiki" style="display: block"> Auteur : Tim Ottinger ([https://twitt... » |
Aucun résumé des modifications |
||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Tim Ottinger]] | [[Category: Tim Ottinger]] | ||
[[Category: Portail Equipe de développement]] | [[Category: Portail Equipe de développement]] | ||
Auteur : Tim Ottinger ([https://twitter.com/tottinge @tottinge])<br /> | |||
Source : [http://agileotter.blogspot.fr/2014/10/your-transition-isnt-very-agile.html Your Transition Isn't Very Agile]<br /> | |||
Date : 17/10/2014<br /> | |||
---- | ---- | ||
Traducteur : Fabrice Aimetti<br /> | |||
Date : 21/10/2014<br /> | |||
---- | ---- | ||
Traduction :<br /> | |||
<br /> | |||
<span style="display: block; text-align: justify">L'enseignement agile sur le fait de "découper en fines tranches verticales" (NdT : sashimi) ne s'applique pas juste aux fonctionnalités (NdT : features).</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Les organisations elles-mêmes progressent également en fines tranches verticales.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le story mapping nous invite à faire de la programmation incrémentale, orientée valeur (NdT : value-first) et à intégrer des "trames de fonctionnalités" tout le temps et de bout-en-bout.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">L'intégration continue nous enseigne qu'intégrer ces fines tranches fréquemment nous évite les cauchemars des préparations de livraison (et des après-livraisons).</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">De même, nous laissons place à l'apprentissage et au développement, parce que ce que nous apprenons au cours de l'itération N peut nous donner différentes options et opportunités pour l'itération N+1 et les suivantes. Nous avons l'idée de l'endroit où nous voulons aller, mais nous cherchons toujours à maximiser la valeur.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Cependant, trop peu de transitions agiles sont réalisées d'une manière agile.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Il est tout à fait raisonnable qu'une société "pré-agile" (NdT : traditionnelle) désire avoir un plan waterfall avec une conception aboutie dès le départ, ainsi que les ressources et les étapes définies à l'avance pour mener sa transition agile. Mais nous, les coachs et les consultants en transition (NdT : moderne), nous en savons bien plus en la matière et sur la façon dont nous sommes censés apporter conseil et soutien.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Et juste au moment où nous sommes en train de construire un logiciel, construire une transition selon une approche ascendante, orientée architecture, en couches horizontales et isolées provoque beaucoup de problèmes d'intégration.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Nous ne devrions pas paraître surpris.</span> | |||
Dernière version du 23 août 2018 à 13:24
Auteur : Tim Ottinger (@tottinge)
Source : Your Transition Isn't Very Agile
Date : 17/10/2014
Traducteur : Fabrice Aimetti
Date : 21/10/2014
Traduction :
L'enseignement agile sur le fait de "découper en fines tranches verticales" (NdT : sashimi) ne s'applique pas juste aux fonctionnalités (NdT : features).
Les organisations elles-mêmes progressent également en fines tranches verticales.
Le story mapping nous invite à faire de la programmation incrémentale, orientée valeur (NdT : value-first) et à intégrer des "trames de fonctionnalités" tout le temps et de bout-en-bout.
L'intégration continue nous enseigne qu'intégrer ces fines tranches fréquemment nous évite les cauchemars des préparations de livraison (et des après-livraisons).
De même, nous laissons place à l'apprentissage et au développement, parce que ce que nous apprenons au cours de l'itération N peut nous donner différentes options et opportunités pour l'itération N+1 et les suivantes. Nous avons l'idée de l'endroit où nous voulons aller, mais nous cherchons toujours à maximiser la valeur.
Cependant, trop peu de transitions agiles sont réalisées d'une manière agile.
Il est tout à fait raisonnable qu'une société "pré-agile" (NdT : traditionnelle) désire avoir un plan waterfall avec une conception aboutie dès le départ, ainsi que les ressources et les étapes définies à l'avance pour mener sa transition agile. Mais nous, les coachs et les consultants en transition (NdT : moderne), nous en savons bien plus en la matière et sur la façon dont nous sommes censés apporter conseil et soutien.
Et juste au moment où nous sommes en train de construire un logiciel, construire une transition selon une approche ascendante, orientée architecture, en couches horizontales et isolées provoque beaucoup de problèmes d'intégration.
Nous ne devrions pas paraître surpris.