La vélocité est en train de tuer l'agilité - Historique des versions

Fabrice Aimetti le 24 mars 2021 à 19:01

2021-03-24T19:01:26Z

← Version précédente		Version du 24 mars 2021 à 19:01
Ligne 14 :		Ligne 14 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	<span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg\|left]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />		<span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg\|left\|link=]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />

	* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>		* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>

Fabrice Aimetti le 24 mars 2021 à 19:00

2021-03-24T19:00:54Z

← Version précédente		Version du 24 mars 2021 à 19:00
Ligne 1 :		Ligne 1 :
	[[Category: Jean-Baptiste Dusseaut]]		[[Category: Jean-Baptiste Dusseaut]]
	[[Category: Jim Highsmith]]		[[Category: Jim Highsmith]]
			[[Catégorie:Kent Beck]]
	[[Category: Vélocité]]		[[Category: Vélocité]]
	[[Catégorie: Coût du retard]]		[[Catégorie: Coût du retard]]

Fabrice Aimetti le 7 mai 2020 à 12:01

2020-05-07T12:01:32Z

← Version précédente		Version du 7 mai 2020 à 12:01
Ligne 1 :		Ligne 1 :
			[[Category: Jean-Baptiste Dusseaut]]
	[[Category: Jim Highsmith]]		[[Category: Jim Highsmith]]
	[[Category: Vélocité]]		[[Category: Vélocité]]

Fabrice Aimetti le 12 août 2018 à 09:39

2018-08-12T09:39:10Z

← Version précédente		Version du 12 août 2018 à 09:39
Ligne 3 :		Ligne 3 :
	[[Catégorie: Coût du retard]]		[[Catégorie: Coût du retard]]
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br /> Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br /> Date : 02/11/2011<br />		Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br />
			Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br />
			Date : 02/11/2011<br />
	----		----
	Traducteur : Jean-Baptiste Dusseaut ([https://twitter.com/BodySplash @BodySplash])<br /> Date : 01/01/2013<br />		Traducteur : Jean-Baptiste Dusseaut ([https://twitter.com/BodySplash @BodySplash])<br />
			Date : 01/01/2013<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg\|left]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg\|left]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />

	* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>		* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>

Fabrice Aimetti le 12 août 2018 à 09:38

2018-08-12T09:38:40Z

← Version précédente		Version du 12 août 2018 à 09:38
Ligne 1 :		Ligne 1 :
	[[Category: Jim Highsmith]]		[[Category: Jim Highsmith]]
	[[Category: Vélocité]]		[[Category: Vélocité]]
			[[Catégorie: Coût du retard]]
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br /> Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br /> Date : 02/11/2011<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br /> Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br /> Date : 02/11/2011<br />

Fabrice Aimetti le 9 août 2018 à 07:53

2018-08-09T07:53:50Z

← Version précédente		Version du 9 août 2018 à 07:53
Ligne 1 :		Ligne 1 :
	[[Category: Jim Highsmith]]		[[Category: Jim Highsmith]]
			[[Category: Vélocité]]
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br /> Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br /> Date : 02/11/2011<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith])<br /> Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility]<br /> Date : 02/11/2011<br />

Fabrice Aimetti le 17 juillet 2018 à 07:29

2018-07-17T07:29:19Z

← Version précédente		Version du 17 juillet 2018 à 07:29
Ligne 5 :		Ligne 5 :
	Traducteur : Jean-Baptiste Dusseaut ([https://twitter.com/BodySplash @BodySplash])<br /> Date : 01/01/2013<br />		Traducteur : Jean-Baptiste Dusseaut ([https://twitter.com/BodySplash @BodySplash])<br /> Date : 01/01/2013<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">[[Image:Software_engine-300x120.jpg\|Software_engine-300x120.jpg\|left]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons :</span><br />

	* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>		* La vélocité est de plus en plus utilisée en tant qu<span style="display: block; line-height: 1.5; text-align: justify">e mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.</span>

Fabrice Aimetti : Page créée avec « Category: Jim Highsmith Category: Portail Planification
Auteur : Jim Highsmith ([https://twitter.com/ji... »

2018-06-24T15:25:59Z

Page créée avec « Category: Jim Highsmith Category: Portail Planification <div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/ji... »

Nouvelle page

[[Category: Jim Highsmith]]
[[Category: Portail Planification]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Jim Highsmith ([https://twitter.com/jimhighsmith @jimhighsmith]) Source : [http://jimhighsmith.com/velocity-is-killing-agility/ Velocity is Killing Agility] Date : 02/11/2011 
----
Traducteur : Jean-Baptiste Dusseaut ([https://twitter.com/BodySplash @BodySplash]) Date : 01/01/2013 
----
''Traduction :'' [[Image:Software_engine-300x120.jpg|Software_engine-300x120.jpg]]Il est clair qu'une large partie des entreprises que je vois à travers le monde est toujours embourbée dans la fange de la productivité, de l'efficacité et de l'optimisation. Elles sont faciles à repérer, car elles sont souvent des maniaques de la mesure de la vélocité : vélocité de l'équipe, vélocité entre les équipes, déduire une vélocité d'entreprise, ou même une vélocité par développeur (beurk). La vélocité est donc en train de tuer l'agilité. C'est la quintessence de l'application d'un outil intéressant pour de mauvaises raisons : 

* La vélocité est de plus en plus utilisée en tant que mesure de productivité (et non pas comme la mesure de calibration de capacité qu'elle était censée être) qui se concentre trop sur le volume de points de story points livré.
* Se concentrer sur le volume se fait au détriment de la qualité de l'expérience utilisateur, et d'un investissement suffisant dans le moteur de livraison (qualité technique).
* Donner au product owner/manager un contrôle total sur la priorisation aggrave le problème - nous sommes passés d'une approche "faire attention au client" à une approche "contrôle par le client" qui biaise encore plus l'équilibre entre le développement de nouvelles fonctionnalités et le moteur de livraison.
* Particulièrement pour ces domaines métiers où une forte réactivité (un cycle de déploiement de quelques jours ou semaines) est crucial, l'investissement dans le moteur de livraison est aussi critique que celui fait dans les nouvelles fonctionnalités.
* Le management doit allouer des ressources entre les fonctionnalités et le moteur, et créer alors une équipe product owner, composée du product owner et de leaders techniques qui travailleront sur la priorisation des fonctionnalités.
* La valeur et des mesures de temps de cycle aideront à contrebalancer les effets négatifs de la mesure de vélocité.
 Une trop grande insistance sur la vélocité entraîne des problèmes en raison de son large usage en tant que mesure de productivité. L'usage correcte de la vélocité est en tant qu'outil de calibration, une manière d'aider un planning basé sur la capacité, comme Kent Beck le décrit dans [http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_3?s=books&ie=UTF8&qid=1320239118&sr=1-3 Extreme Programming : Embrassez le Changement]. D'une manière générale, la mesure de productivité [http://martinfowler.com/bliki/CannotMeasureProductivity.html a peu de sens dans les emplois intellectuels], mais c'est le sujet d'un autre article. La vélocité est également une mesure séduisante, car elle est facile à calculer. Même si le nombre de story points par itération est calculé sur la base de fonctionnalités livrables, la vélocité parle par essence d'effort. Alors que les équipes agiles tentent de se concentrer sur la livraison de fonctionnalités à haute valeur ajoutée, elles se retrouvent déviées par des rapports de productivité. Régulièrement, j'entend des commentaires venant de managers ou de product owners disant : "Votre vélocité est descendue de 24 à 21 cette fois, qu'est-ce qui ne va pas ? Remontons la à 24, voir un peu plus". Dans ce scénario, la vélocité est passée d'un outil utile de calibration (quelle est notre capacité pour la prochaine itération ?) à une mesure de productivité et de performance. Cela signifie que deux éléments sont ignorés : la qualité de l'expérience utilisateur (la quantité de fonctionnalités plutôt que l'expérience du client) et l'amélioration du moteur de livraison (la qualité technique). L'agilité est la capacité d'à la fois créer et répondre au changement pour prospérer dans un environnement métier turbulent. Cela signifie que nous devons construire et maintenir un moteur de livraison de valeur continue, et non pas un moteur qui crache une grande quantité de fonctionnalités la première fois, puis décline rapidement après. L'expression ultime de l'agilité d'un point de vue logiciel, est la livraison et le déploiement continus. Notre but ne devrait pas être la productivité, mais de "Concevoir et déployer rapidement une expérience utilisateur exceptionnelle, encore et encore au cours du temps". Pour répondre au métier, à la technologie et aux turbulences des concurrents sur le marché, nous devons nous concentrer sur le fait de livrer une meilleure expérience utilisateur, construire de nouvelles fonctionnalités, et améliorer le moteur de livraison nous permettant de déployer rapidement à chaque cycle de livraison. Aggravant le problème, le mouvement agile s'est concentré sur le haut niveau d'engagement du client, qui est plutôt une bonne chose, mais nous sommes allés trop loin. Un grand nombre d'agilistes s'écrient qu'ils ne peuvent obtenir des entreprises qu'elles se concentrent sur les pratiques techniques, mais pourquoi est-ce que cela devrait être une surprise quand nous encourageons les product owners à prendre toutes les décisions de priorisation, et que nous mesurons la performance à travers la vélocité ? Nous avons surcompensé le manque d'attention au client des méthodes traditionnelles, en donnant le contrôle de la priorisation au product owner. La tendance a été de rassembler tout le travail sous la tutelle de stories démontrables au client, et supposer que nous pourrions convaincre le product owner d'accepter tout le travail technique à faire sur le moteur de livraison. C'est une sur-correction d'un problème des méthodes traditionnelles dans lesquelles des mois de travail technique précédaient tout travail présentable au client (ce qui était un problème encore pire). Les products owners/managers comprennent l'importance de prioriser l'expérience utilisateur, mais ils ne sont généralement pas incités ni ne comprennent le travail technique à faire sur le moteur de livraison. Nous devons créer une équipe product owner, composée du product owner et d'un leader technique (ce qui peut inclure une participation de l'assurance qualité). Les product owners sont les clients d'aujourd'hui, alors que les leader techniques sont les clients de demain. Imaginez notre moteur de livraison de logiciel comme un moteur à réaction dans un avion de chasse. Si nous ne faisions pas les maintenances nécessaires sur ce moteur, il s'encrasserait. Que se passerait-il si nous ne reconstruisions pas régulièrement des éléments de ce moteur ? Dans la livraison de logiciel, nous encrassons notre moteur en : ignorant la dette technique, retardant les refactorings, négligeant les tests automatisés, sous-investissant dans les outils d'intégration continue et les processus, et en acceptant des cycles de déploiement longs. Ces éléments sont souvent considérés comme des "subtilités techniques" plutôt que comme des éléments gardant notre moteur opérationnel et en capacité optimale. Dans son livre [http://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?s=books&ie=UTF8&qid=1320238338&sr=1-1 The Principles of Product Development Flow], Don Reinertsen suggère cette formule : Temps de cycle / Valeur ajoutée = 1 / (1 - Utilisation). Par conséquent, lorsque les équipes optimisent leur processus par rapport à la vélocité, elles augmentent le gaspillage dans le processus de livraison, et augmentent le temps de cycle. Inversement, quand les équipes optimisent le temps de cycle, l'utilisation (et donc la vélocité) décroît. Il doit y avoir un équilibre. Le métier a évolué d'un monde où le changement était périodique à un monde où le changement est continu. En parallèle, le développement logiciel est en train de passer d'un travail sur un projet (livré un logiciel en un seul gros lot, puis le maintenir), à un travail sur un produit (fournir un logiciel par livraisons continues). Pour orienter les comportements dans la bonne direction, nous devons inclure des mesures comme la valeur, le temps de cycle de livraison et la qualité technique dans nos critères de performance. Nous devons calculer des points de "valeur" des fonctionnalités ainsi que des points "d'effort" (points de story). Le temps de cycle peut être une excellente mesure car elle dépend du bon fonctionnement du moteur de livraison, et c'est une mesure que les clients comprennent. Quand nous disons : "Voulons-nous de nouvelles fonctionnalités ou de la qualité (ou de la réduction de dette technique, ...) ?", il est facile pour le product owner de répondre"bien sûr que nous voulons de nouvelles fonctionnalités". Nous devons plutôt dire : "Comment devons-nous équilibrer la livraison des nouvelles fonctionnalités avec la réduction du temps de cycle ?". [Note : Le coût du retard, dans le livre de Don Reinertsen, peut aussi être une mesure utile.] Ce billet ne devrait pas être interprété comme étant contre la vélocité ; elle a toujours sa place dans le planning par capacité. Le problème est le poids donné à la vélocité, et sa transformation en mesure de productivité. Comme elle est facile à mesurer, nous le faisons. Mais le plus important est de mesurer des éléments comme la valeur d'une fonctionnalité, le temps de cycle de livraison, et des mesures de qualité (défauts, dette technique, ...). Livrer des fonctionnalités à haute valeur ajoutée devrait être primordial, mais l'attention ne doit pas être sur une livraison en une seule fois, mais sur une livraison continue. Le débat n'est pas fonctionnalité ou qualité; c'est équilibrer la livraison rapide de fonctionnalités aujourd'hui avec l'augmentation de notre capacité à livrer rapidement des fonctionnalités demain, encore et encore. La réactivité pour le métier est une capacité, pas un évènement se produisant une seule fois. Soutenir ce besoin continu de réactivité métier nécessite un moteur de réactivité puissant et bien huilé. Note : je remercie Martin Fowler, Jez Humble et Ken Collier pour m'avoir apporter leurs commentaires et leurs idées sur ce sujet.