ImposerAgile - Historique des versions

Fabrice Aimetti le 16 février 2021 à 06:33

Fabrice Aimetti — Tue, 16 Feb 2021 06:33:45 GMT

← Version précédente		Version du 16 février 2021 à 06:33
Ligne 25 :		Ligne 25 :
	J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile 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.<br/>		J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile 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.<br/>
	<br/>		<br/>
	Un exemple est celui de l'apprentissage. L'introduction de méthodes Agile 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 [https://www.martinfowler.com/articles/xpVariation.html écrit à ce sujet (en)] sur XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de [https://www.martinfowler.com/bliki/ShuHaRi.html ShuHaRi (en)] 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).		Un exemple est celui de l'apprentissage. L'introduction de méthodes Agile 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 [https://www.martinfowler.com/articles/xpVariation.html écrit à ce sujet (en)] sur XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de [https://www.martinfowler.com/bliki/ShuHaRi.html ShuHaRi (en)] et doit donc suivre les pratiques de manière assez rigide jusqu'à ce qu'elle comprenne comment elle fonctionne. Dans cette situation, le dogmatisme et l'inflexibilité sont un outil d'apprentissage (temporaire).<br/>
			<br/>
	~~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.		Un autre exemple dans lequel nous nous trouvons habituellement chez ThoughtWorks est celui 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 l'équipe du client afin d'assurer un bon transfert et pour que l'équipe du client puisse 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 frontière très mince entre une adaptation raisonnable et l'abandon des pratiques qui ont fait notre succès.<br/>
			<br/>
	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 Agile ~~introduit~~ un conflit avec les valeurs et les principes qui sous-tendent les méthodes Agile.		Ce genre de situations montre qu'imposer l'Agile n'est pas aussi tranché qu'il n'y paraît, néanmoins le point fondamental reste le suivant : imposer des méthodes Agile provoque un conflit avec les valeurs et les principes qui sous-tendent les méthodes Agile.<br/>
			<br/>
	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 Agile - 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.		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é objet 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 Agile, il n'y a pas de police Agile qui applique l'[https://www.martinfowler.com/bliki/RigorousAgile.html AgileAvecRigueur]. 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.<br/>
			<br/>
	(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~~).		(Il y a une [http://tech.groups.yahoo.com/group/extremeprogramming/message/123257 discussion intéressante] à ce sujet sur la [http://tech.groups.yahoo.com/group/extremeprogramming/ liste de diffusion XP] ; en particulier, cela vaut le coup de lire [http://tech.groups.yahoo.com/group/extremeprogramming/message/123271 la réponse de Kent] qui fait avancer la conversation dans une direction pertinente).

Fabrice Aimetti le 16 février 2021 à 06:21

Fabrice Aimetti — Tue, 16 Feb 2021 06:21:18 GMT

← Version précédente		Version du 16 février 2021 à 06:21
Ligne 10 :		Ligne 10 :
	Traduction :<br/>		Traduction :<br/>
	<br/>		<br/>
	Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes Agile [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, ils se concentrent sur la mode plutôt que sur les véritables particularités. Cela peut entraîner des témoignages sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.<br/>		Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes Agile [https://www.infoq.com/articles/agile-alliance-survey-2006/ ont "franchi le gouffre" (en)], 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, ils se concentrent sur la mode plutôt que sur les véritables particularités. Cela peut entraîner des témoignages sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.<br/>
	<br/>		<br/>
	En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile 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.<br/>		En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile 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.<br/>

Fabrice Aimetti le 16 février 2021 à 06:21

Fabrice Aimetti — Tue, 16 Feb 2021 06:21:08 GMT

← Version précédente		Version du 16 février 2021 à 06:21
Ligne 14 :		Ligne 14 :
	En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile 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.<br/>		En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile 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.<br/>
	<br/>		<br/>
	Pour moi, l'une des principales caractéristiques des méthodes Agile est qu'elles sont [https://www.martinfowler.com/bliki/PeopleOriented.html CentréesSurLesPersonnes]. 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 [http://agilemanifesto.org/ Manifeste Agile] ''"Les individus et les interactions plus que les processus et les outils"'' et est renforcé par deux [http://agilemanifesto.org/principles.html principes] du manifeste :		Pour moi, l'une des principales caractéristiques des méthodes Agile est qu'elles sont [https://www.martinfowler.com/bliki/PeopleOriented.html CentréesSurLesPersonnes (en)]. 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 [http://agilemanifesto.org/ Manifeste Agile] ''"Les individus et les interactions plus que les processus et les outils"'' et est renforcé par deux [http://agilemanifesto.org/iso/fr/principles.html principes (fr)] du manifeste :
	* Réalisez les projets avec des personnes motivées.		* Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
	Fournissez-leur l’environnement et le soutien dont ils		* Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
	ont besoin et faites-leur confiance pour atteindre les
	objectifs fixés.
	* Les meilleures architectures, spécifications et
	conceptions émergent d'équipes autoorganisées.
	Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus... un processus qui convienne 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 coeur de la pensée Agile.<br/>		Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus... un processus qui convienne 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 coeur de la pensée Agile.<br/>
	<br/>		<br/>
	Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit aux moyens		Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie 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.<br/>
	de devenir plus efficace, puis règle et modifie 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.<br/>
	<br/>		<br/>
	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 Agile 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 Agile préférées.<br/>		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 Agile 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 Agile préférées.<br/>
Ligne 31 :		Ligne 25 :
	J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile 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.<br/>		J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile 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.<br/>
	<br/>		<br/>
	Un ~~cas~~ est celui de l'apprentissage. L'introduction de méthodes Agile 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).		Un exemple est celui de l'apprentissage. L'introduction de méthodes Agile 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 [https://www.martinfowler.com/articles/xpVariation.html écrit à ce sujet (en)] sur XP il y a plusieurs années). À ce stade, une équipe se trouve dans la phase Shu de [https://www.martinfowler.com/bliki/ShuHaRi.html ShuHaRi (en)] 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.		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.

Fabrice Aimetti le 16 février 2021 à 06:17

Fabrice Aimetti — Tue, 16 Feb 2021 06:17:19 GMT

← Version précédente		Version du 16 février 2021 à 06:17
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.		Selon l'actuel conseil d'administration de l'Agile Alliance, les méthodes Agile [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, ils se concentrent sur la mode plutôt que sur les véritables particularités. Cela peut entraîner des témoignages sur des choses faites au nom de l'agilité qui sont à l'opposé des principes des fondateurs du mouvement.<br/>
			<br/>
	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.		En parcourant le web, j'ai entendu quelques commentaires sur les méthodes Agile 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.<br/>
			<br/>
	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 :		Pour moi, l'une des principales caractéristiques des méthodes Agile est qu'elles sont [https://www.martinfowler.com/bliki/PeopleOriented.html CentréesSurLesPersonnes]. 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 [http://agilemanifesto.org/ Manifeste Agile] ''"Les individus et les interactions plus que les processus et les outils"'' et est renforcé par deux [http://agilemanifesto.org/principles.html principes] du manifeste :
			* Réalisez les projets avec des personnes motivées.
	~~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~~.		Fournissez-leur l’environnement et le soutien dont ils
	Les meilleures architectures, ~~exigences~~ et conceptions émergent d'équipes ~~auto-organisées~~.		ont besoin et faites-leur confiance pour atteindre les
	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~~.		objectifs fixés.
			* Les meilleures architectures, spécifications et
	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.		conceptions émergent d'équipes autoorganisées.
			Une conséquence importante de ces valeurs et principes est qu'une équipe doit choisir son propre processus... un processus qui convienne 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 coeur de la pensée Agile.<br/>
	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.		<br/>
			Cette notion va plus loin avec un autre principe du manifeste : "À intervalles réguliers, l'équipe réfléchit aux moyens
	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.		de devenir plus efficace, puis règle et modifie 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.<br/>
	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).		<br/>
			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 Agile 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 Agile préférées.<br/>
			<br/>
			J'espère donc avoir bien fait comprendre que l'imposition de méthodes Agile 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.<br/>
			<br/>
			Un cas est celui de l'apprentissage. L'introduction de méthodes Agile 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.		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 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 Agile introduit un conflit avec les valeurs et les principes qui sous-tendent les méthodes Agile.

	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.		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 Agile - 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).		(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).

Fabrice Aimetti le 16 février 2021 à 06:04

Fabrice Aimetti — Tue, 16 Feb 2021 06:04:58 GMT

← Version précédente		Version du 16 février 2021 à 06:04
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).

Fabrice Aimetti : Page créée avec « Category: Portail Coach'Agile Category: Martin Fowler Auteur : Martin Fowler
Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition... »

Fabrice Aimetti — Tue, 16 Feb 2021 06:02:58 GMT

Page créée avec « Category: Portail Coach'Agile Category: Martin Fowler Auteur : Martin Fowler Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition... »

Nouvelle page

[[Category: Portail Coach'Agile]]
[[Category: Martin Fowler]]
Auteur : Martin Fowler 
Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition] 
Date : 02/10/2006 
----
Traducteur : Fabrice Aimetti 
Date : 16/02/2021 
----
Traduction :

ImposerAgile - Historique des versions

Fabrice Aimetti le 16 février 2021 à 06:33

Fabrice Aimetti le 16 février 2021 à 06:21

Fabrice Aimetti le 16 février 2021 à 06:21

Fabrice Aimetti le 16 février 2021 à 06:17

Fabrice Aimetti le 16 février 2021 à 06:04

Fabrice Aimetti : Page créée avec « Category: Portail Coach'Agile Category: Martin Fowler Auteur : Martin Fowler Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition... »

Fabrice Aimetti : Page créée avec « Category: Portail Coach'Agile Category: Martin Fowler Auteur : Martin Fowler
Source : [https://www.martinfowler.com/bliki/AgileImposition.html AgileImposition... »