ImposerAgile : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
(Page créée avec « Category: Portail Coach'Agile Category: Martin Fowler Auteur : Martin Fowler<br/> Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition... »)
 
Ligne 10 : Ligne 10 :
 
Traduction :<br/>
 
Traduction :<br/>
 
<br/>
 
<br/>
 +
Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes agiles [https://www.infoq.com/articles/agile-alliance-survey-2006/ ont "franchi le gouffre"], ce qui signifie, je pense, qu'elles se répandent de plus en plus. Si cela a ses avantages, cela pose aussi des problèmes. Lorsqu'une méthodologie ou une approche de conception devient à la mode, nous voyons beaucoup de gens l'utiliser ou l'enseigner, qui se concentrent sur la mode plutôt que sur les vrais détails. Cela peut conduire à des rapports sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.
 +
 +
En parcourant le web, j'ai entendu quelques commentaires sur les méthodes agiles imposées à une équipe de développement par la haute direction. Imposer un processus à une équipe est totalement contraire aux principes du logiciel agile, et ce depuis sa création.
 +
 +
Pour moi, l'une des principales caractéristiques des méthodes agiles est qu'elles sont orientées vers les personnes. Elles reconnaissent que les personnes et leur façon de travailler ensemble sont le facteur principal dans le développement de logiciels, et que les processus sont un facteur secondaire. Cela se reflète dans la première valeur du manifeste agile "Les individus et les interactions sur les processus et les outils" et est renforcé par deux principes du manifeste :
 +
 +
Construire des projets autour d'individus motivés. Donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance pour qu'ils accomplissent leur travail.
 +
Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées.
 +
Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus - un processus qui convient aux personnes et au contexte dans lequel elles travaillent. Imposer un processus agile de l'extérieur prive l'équipe de l'autodétermination qui est au cœur de la pensée agile.
 +
 +
Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace, puis ajuste son comportement en conséquence". Une équipe ne doit pas seulement choisir son propre processus, elle doit aussi contrôler la façon dont ce processus évolue.
 +
 +
Cette notion de processus adapté à l'équipe (et non l'inverse) est une condition nécessaire aux méthodes agiles, mais elle n'est clairement pas suffisante. Une équipe peut choisir un processus totalement en cascade et non agile. Dans ce cas, il est clair que le processus n'est pas plus agile que le goût des pommes ou des fraises. Mais les méthodes agiles ne sont pas les meilleures pour toutes les situations, et personnellement, je préfère qu'une équipe travaille d'une manière non agile qu'elle a elle-même choisie plutôt que de se voir imposer mes pratiques agiles préférées.
 +
 +
J'espère donc avoir bien fait comprendre que l'imposition de méthodes agiles est un signal d'alarme. Mais quand j'en entends parler, je ne comprends généralement pas toute l'histoire. Il y a des situations qui peuvent sembler similaires de l'extérieur, mais qui ne sont pas vraiment identiques.
 +
 +
Un cas est celui de l'apprentissage. L'introduction de méthodes agiles implique souvent l'apprentissage de tout un tas de nouvelles choses en même temps, dont beaucoup sont contre-intuitives. C'est particulièrement vrai pour l'Extreme Programming. Dans cette situation, il est très difficile d'adapter un processus tant que vous ne l'avez pas utilisé pendant un certain temps (j'ai écrit à ce sujet à propos d'XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de ShuHaRi et doit donc suivre les pratiques de manière assez servile jusqu'à ce qu'elle comprenne comment elles fonctionnent. Dans cette situation, le dogmatisme et l'inflexibilité sont un outil d'apprentissage (temporaire).
 +
 +
Une autre situation dans laquelle nous nous trouvons habituellement chez ThoughtWorks est celle d'un projet co-sourcé avec une équipe cliente. Dans la plupart de ces situations, nous sommes responsables de la livraison du logiciel, mais nous devons travailler avec le personnel du client afin d'assurer un bon transfert et pour que les personnes du client puissent apprendre comment nous travaillons. Dans cette situation, nous sommes payés pour être aussi efficaces que possible, donc nous utiliserons un processus qui fonctionne pour nous. Cela ne signifie pas que nous n'adaptons pas le processus à l'environnement du client, c'est toujours nécessaire, mais il y a une ligne délicate entre une adaptation raisonnable et l'abandon des pratiques qui font notre succès.
 +
 +
Ce genre de situation montre que l'imposition n'est pas aussi claire qu'elle peut paraître, mais le point fondamental reste le suivant : l'imposition de méthodes agiles introduit un conflit avec les valeurs et les principes qui sous-tendent les méthodes agiles.
 +
 +
Ce genre de problème était inévitable. Je me souviens très bien d'une période où il était à la mode d'être orienté vers les objets et où toutes sortes de choses bizarres étaient faites au nom des objets. Tout cela fait partie du processus normal d'adoption. Rien ne peut être fait pour empêcher que le nom agile soit appliqué à des comportements très peu agiles - il n'y a pas de police agile qui applique l'AgilitéRigoureuse. Tout ce que nous pouvons faire, c'est pour ceux d'entre nous qui se soucient de continuer à essayer d'expliquer ce qu'est réellement l'agile. Et je préfère expliquer que convaincre.
 +
 +
(Il y a une discussion utile à ce sujet sur la liste de diffusion XP ; en particulier, il vaut la peine de lire la réponse de Kent qui fait avancer la conversation dans une direction intéressante).

Version du 16 février 2021 à 06:04

Auteur : Martin Fowler
Source : AgileImposition
Date : 02/10/2006


Traducteur : Fabrice Aimetti
Date : 16/02/2021


Traduction :

Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes agiles ont "franchi le gouffre", ce qui signifie, je pense, qu'elles se répandent de plus en plus. Si cela a ses avantages, cela pose aussi des problèmes. Lorsqu'une méthodologie ou une approche de conception devient à la mode, nous voyons beaucoup de gens l'utiliser ou l'enseigner, qui se concentrent sur la mode plutôt que sur les vrais détails. Cela peut conduire à des rapports sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.

En parcourant le web, j'ai entendu quelques commentaires sur les méthodes agiles imposées à une équipe de développement par la haute direction. Imposer un processus à une équipe est totalement contraire aux principes du logiciel agile, et ce depuis sa création.

Pour moi, l'une des principales caractéristiques des méthodes agiles est qu'elles sont orientées vers les personnes. Elles reconnaissent que les personnes et leur façon de travailler ensemble sont le facteur principal dans le développement de logiciels, et que les processus sont un facteur secondaire. Cela se reflète dans la première valeur du manifeste agile "Les individus et les interactions sur les processus et les outils" et est renforcé par deux principes du manifeste :

Construire des projets autour d'individus motivés. Donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance pour qu'ils accomplissent leur travail. Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées. Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus - un processus qui convient aux personnes et au contexte dans lequel elles travaillent. Imposer un processus agile de l'extérieur prive l'équipe de l'autodétermination qui est au cœur de la pensée agile.

Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace, puis ajuste son comportement en conséquence". Une équipe ne doit pas seulement choisir son propre processus, elle doit aussi contrôler la façon dont ce processus évolue.

Cette notion de processus adapté à l'équipe (et non l'inverse) est une condition nécessaire aux méthodes agiles, mais elle n'est clairement pas suffisante. Une équipe peut choisir un processus totalement en cascade et non agile. Dans ce cas, il est clair que le processus n'est pas plus agile que le goût des pommes ou des fraises. Mais les méthodes agiles ne sont pas les meilleures pour toutes les situations, et personnellement, je préfère qu'une équipe travaille d'une manière non agile qu'elle a elle-même choisie plutôt que de se voir imposer mes pratiques agiles préférées.

J'espère donc avoir bien fait comprendre que l'imposition de méthodes agiles est un signal d'alarme. Mais quand j'en entends parler, je ne comprends généralement pas toute l'histoire. Il y a des situations qui peuvent sembler similaires de l'extérieur, mais qui ne sont pas vraiment identiques.

Un cas est celui de l'apprentissage. L'introduction de méthodes agiles implique souvent l'apprentissage de tout un tas de nouvelles choses en même temps, dont beaucoup sont contre-intuitives. C'est particulièrement vrai pour l'Extreme Programming. Dans cette situation, il est très difficile d'adapter un processus tant que vous ne l'avez pas utilisé pendant un certain temps (j'ai écrit à ce sujet à propos d'XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de ShuHaRi et doit donc suivre les pratiques de manière assez servile jusqu'à ce qu'elle comprenne comment elles fonctionnent. Dans cette situation, le dogmatisme et l'inflexibilité sont un outil d'apprentissage (temporaire).

Une autre situation dans laquelle nous nous trouvons habituellement chez ThoughtWorks est celle d'un projet co-sourcé avec une équipe cliente. Dans la plupart de ces situations, nous sommes responsables de la livraison du logiciel, mais nous devons travailler avec le personnel du client afin d'assurer un bon transfert et pour que les personnes du client puissent apprendre comment nous travaillons. Dans cette situation, nous sommes payés pour être aussi efficaces que possible, donc nous utiliserons un processus qui fonctionne pour nous. Cela ne signifie pas que nous n'adaptons pas le processus à l'environnement du client, c'est toujours nécessaire, mais il y a une ligne délicate entre une adaptation raisonnable et l'abandon des pratiques qui font notre succès.

Ce genre de situation montre que l'imposition n'est pas aussi claire qu'elle peut paraître, mais le point fondamental reste le suivant : l'imposition de méthodes agiles introduit un conflit avec les valeurs et les principes qui sous-tendent les méthodes agiles.

Ce genre de problème était inévitable. Je me souviens très bien d'une période où il était à la mode d'être orienté vers les objets et où toutes sortes de choses bizarres étaient faites au nom des objets. Tout cela fait partie du processus normal d'adoption. Rien ne peut être fait pour empêcher que le nom agile soit appliqué à des comportements très peu agiles - il n'y a pas de police agile qui applique l'AgilitéRigoureuse. Tout ce que nous pouvons faire, c'est pour ceux d'entre nous qui se soucient de continuer à essayer d'expliquer ce qu'est réellement l'agile. Et je préfère expliquer que convaincre.

(Il y a une discussion utile à ce sujet sur la liste de diffusion XP ; en particulier, il vaut la peine de lire la réponse de Kent qui fait avancer la conversation dans une direction intéressante).