SFEIR - la voie Agile, le blog

Suite à une première journée très intense, voici la suite des résumés des interventions auxquelles nous avons eu la chance d'assister.

Esther Derby : Keynote Self-organised team

Un constat : les équipes qui échouent le font toutes de manière différentes

Les équipes qui réussisent le font de la même manière. Idéalement une équipe de 5 ou un peu plus.

Une équipe va généralement suivre le cycle suivant :

• Peu de contrôle du manager
  

• Forte auto-organisation
  

• Faible auto-organisation
  

• Fort contrôle du manager
  

1->2 Dans ce shéma, le rôle du manager va être de lacher prise pour laisser l'équipe s'auto-organiser.

2->3 Si l'équipe ne prend pas ses responsabilité, elle retombe dans une certaine anarchie

3->4 Le manager va chercher à reprendre le contrôle

4->1 Retour de la confiance envers l'équipe, Nouveau lacher-prise du manager

L'objectif est de rester à l'étape 2 en continuant à être collectivement responsable

François Wauquier

Eric Mignot : Refactoring d’un legacy par les tests

Présentation d'un code legacy “tout neuf” et mise sous test avec mockito.

Discussions autour des pratiques.

Très interactif.

François Wauquier

Thierry Cros : Accord Toltèques

Thierry nous présente une nouvelle passion: les accord toltèques, originaire du mexique. Ces accord sont une ligne de conduite que l’on s’engage à respecter :

• Ma parole est impeccable
  

• Quoi qu’il arrive, je ne réagis pas de manière personnelle
  

• Je ne fais pas de supposition
  

• Je suis sceptique et j’apprends à écouter
  

• Je fais toujours de mon mieux
  

L’atelier expérimental nous permet ensuite de considérer l’un de nos problèmes, et le voir à travers le prisme de l’un de ces accords.

En suivant cet accord, quelle action puis-je réaliser pour sortir de cette situation ?

Un clé de lecture complémentaire est que la solution se situe sur l’un de ces niveau hiérarchique :

• Rôles
  

• Savoir-Faire
  

• Croyances
  

• Environnement
  

François Wauquier

Gilles Mantel & Jean Claude Grosjean : Transformation agile à grande échelle

Valtech a eu la confiance d’une DSI dans le secteur industriel, désirant une conversion à l’agilité. Ils ont choisi 3 projets pilotes sur 300, (rapides, petite taille, peu critiques, ) afin de la diffuser.

Ils ont éxpérimenté l’Open Space entre coach, les rencontres entre équipes, les interactions avec les entités non-agiles, la transformation des standards, des contrats-cadres, …

François Wauquier

David Gageot : Git

David est maintenant évangeliste de Git, un gestionnaire de source distribué. J'ai retenu ces avantages:

• Rapide
  

• Distribué = backup gratuit
  

• Différents mode/typologie
  

• Gestion des droits par cercle de confiance
  

• Phénomène GitHub
  

• Permet au lieu de contraindre
  

• Intégration continue sans serveur avec un private-build scripté
  

François Wauquier

Bernard Notarianni & Eric Séguier: Réussir ses projets à coût, délais, périmêtre et qualité fixes

Session controversée où Bernard s'attaque à la recherche du graal du contrat au forfait agile.

Il prend un exemple personnel de la réalisation d'un jardin par un paysagiste. Pourquoi ne pourrions nous pas faire cela en informatique ?

• Délai fixe
  

• Coût fixe
  

• Périmètre = backlog, constitué par l'équipe
  

• Qualité XP, constituée par l'équipe
  

Dans la configuration idéale, le client ne donne qu'une description vague de ce qu'il souhaite, et l'équipe détaille, collabore directement avec lui. Cela exige de revoir les organisations traditionnelles. La MOA par exemple si on la conserve, n'est plus un intermédiaire mais un support fonctionnel.

Dans l'ensemble, on rapproche le développeur de celui qui émet son besoin. Ca ne vous rappelle rien ?

Bernard nous propose finalement une organisation de type XP, en respectant les contraintes et en faisant varier le périmêtre.

François Wauquier

Pour complément, beaucoup de questions ont été posées et la verve légendaire de Bernard y a répondu (en partie selon moi car l'usage de la métaphore est peut être poussée à son extrême...) : "comment appeler ça forfait si le périmètre n'est pas fixe (obligation de résultat) ?", "N'est ce pas l'émergence d'un nouveau profil : le super développeur ?", ... Bref, pourquoi si peu de temps pour un sujet si vaste et qui se prête à tant de polémique ?

Thierry TREPIED

Jean Claude Grosjean : Personas - une dose d'expérience utilisateur pour vos projets agiles

Cette présentation n'est pas spécifique à l'Agile et peut très bien être utilisée dans le cadre de projets "cycle en V" ou autre.

Les personas sont des personnages virtuels qui représentent un utilisateur final. Il s'agit de lui donner :

• un nom ou plutôt un prénom afin de créer une proximité
  

• un profil (Age, métier, passions,...).
  

• But dans le cadre de l'utilisation du produit.
  

Attention : ce n'est pas une cible type marketing mais réellement un personnage virtuel.

Ces personas sont créées à la suite d'ateliers et d'interview des clients finaux.

L'établissement de cette fiche persona permet d'avoir toujours en point de mire le but d'utilisation du produit en visualisant par exemple sur le radiateur d'information les personas impactées.

Thierry TREPIED

Guillaume Bodet : Architecture agile et conception émergente - le concept du jardinier

"L'architecture regroupe tout ce qui est difficile à changer" c'est à dire, ce qui va être couteux (argent, temps) dans le cadre d'un projet informatique.

Ce sont donc les langages de développement, les frameworks, ...

Guillaume décrit via cette présentation une vision de l'architecture et de l'architecte qui permet de la simplifier et de la rendre plus flexible.

Par exemple si on a plusieurs projet avec différents architectes, il faut créer la notion de "Architecte Chief" ou encore "Architect Owner" qui a pour but de centraliser les décisions en termes d'architecture commune.

Il est également "facile" de ne pas tomber dans le piège d'une architecture complexe : privilégier l'échange de document (type Rest) au RPC entre différents systèmes.

Le jardinier peut changer l'apparence d'un jardin via quelques modifications à l'inverse d'un bâtisseur de cathédrale par exemple...

Thierry TREPIED

Régis Medina : Satisfaire complètement son client avec le Problem Driven Devlopment

La démarche de Régis est simple : pour satisfaire un client, il faut connaitre ses problèmes, son besoin.

Pour cela rien de mieux que d'aller l'observer.

Se mettre derrière lui et prendre note du cheminement dans l'appli, voir s'il se retrouve dans les menus proposés, ... Sa préconisation : aller sur le terrain et observer.

Egalement ne jamais partir du principe que "c'est une évidence". Pour un informaticien, le placement d'un bouton peut être instinctif, sans discussion, mais une fois l'application donnée à un utilisateur, on se retrouve devant une incompréhension de sa part et un blocage dû à une disposition non conforme à ses attentes de ce qui est mis à sa disposition.

Il faut donc l'observer, établir un cheminement pour aboutir à la fonctionnalité, mettre en évidence les points de douleur, et revenir vers lui. ça peut se résumer en :

• voir le client
  

• voir la performance
  

• voir les problèmes
  

• résoudre les problèmes
  

• en tirer les bonnes leçons
  

Ce discours s'adresse essentiellement au Product Owner qui doit s'imprégner au plus prêt des problèmes de ses utilisateurs finaux.

Thierry TREPIED

Introduction

S’il y a un rôle déterminant dans la méthodologie Agile, c’est celui de Product Owner. Il doit être présent et à disposition de l’Equipe, prioriser, spécifier et valider les stories. Tout ceci dans un laps de temps d’une itération. Son implication et sa capacité à alimenter l’Equipe sont les facteurs majeurs de réussite du projet. Dans ces conditions, doit-il se consacrer à 100 % à son projet ou peut-il être multi projets? Et dans ce cas, comment être multi taches ?

Des contraintes métier fortes

Au cours d’une précédente expérience professionnelle, j’ai appris à pratiquer la méthodologie Agile. Pour débuter, j’étais Product Owner d’une application à développer « from scratch ». Je me suis consacré à ce projet à 100 % pendant une durée de 9 mois environ avant de devoir prendre dans mon escarcelle d’autres projets en cours, orphelins de PO. Le métier évoluant très vite, il n'est pas envisageable de terminer un projet avant d'en commencer un autre.
L'incapacité de faire un choix de priorité, ou tout simplement un sous effectif de PO, se répercute sur le Product owner qui se voit dans l'obligation de mener des projets en parallèle.
Plusieurs projets sont à mener de front. Plusieurs équipes de dév sont constituées; elles sont tout de même dédiée à un projet.

Constituer une équipe de Product Owners

Cette phase d’apprentissage de la fonction de PO a fait ressortir quelques points :
- le PO a au moins une itération d’avance de spécification sur l’Equipe ;
- il doit toujours avoir à l’esprit la vision et la version de son produit à livrer et le partager avec l’Equipe ;
- plus il teste l’application tôt (si possible dès la livraison de la fonctionnalité), moins il a à gérer les retours.
Puis l’augmentation du volume de mon portefeuille projets m’a amené à travailler de la façon suivante :
- constituer une équipe de « Product Owners ». Ce qui induit de les former au métier et à la fonction de PO.
- de ce fait, déléguer un certains nombres de taches normalement attribuées au PO
- au fil de l’eau, se désengager des projets « qui roulent »

Petit Scarabée deviendra PO

Pour ce faire, j’ai recruté un analyste, pour qui le métier était inconnu, mais avec un esprit clair, ouvert et vif. Je l’ai formé sur le « projet qui roule » en méthode Agile :
- Au début de chaque itération, je spécifie les règles de gestion métier, les cas de test à la marge. Il se charge alors d’établir les cas de test ;
- Nous itérons également sur un passage de connaissance métier lié au différentes stories à traiter.
- Il participe aux ateliers de travail utilisateurs afin de s’imprégner de leur vision, de leurs besoins et d’un langage métier.
- Petit à petit, il prend en charge la recette des fonctionnalités livrées par l’Equipe.

"Luke je suis ton père", mais maintenant tu es grand

A ce stade, je reste encore le PO, mais nous entrons dans une phase où nous pouvons être considérés comme backup l’un de l’autre. Les seules différences entre nous deux sont :
- Une connaissance métier plus approfondie due à mon passif (difficile à changer…) ;
- Je suis interne et il est externe. Mais est-ce une condition nécessaire pour être PO ? A priori non dès l’instant où il peut s’appuyer sur une MOA interne à forte disponibilité.
Etant donné cet état de fait, je me positionne désormais en backup et le nomme PO du projet. Il le prend dorénavant en charge de bout en bout, et sait qu’il peut compter sur moi en cas de besoin.

Une équipe PO en place. Oui mais...

Ce cycle de formation à la méthode, passage de connaissances métier et endossement de la cape de PO a pris environ 3 mois. Il est évident qu’il s’agit d’une charge de travail supplémentaire, mais étant donné qu’il a pu monter en compétence rapidement sur la rédaction des cas de test (Fitnesse) et recetter les stories, c’était aussi une charge de travail en moins. La constitution d’une équipe PO s’est avérée comme étant une stratégie payante. Cette équipe PO peut être vue comme une équipe Agile à part entière, fonctionnant en parallèle de l'équipe de dév sur un rythme d'itération en avance d'au moins une phase. Il faut cependant être très claire en termes de communication vis-à-vis de l’Equipe (qui est le PO référent et bien gérer la bascule d'un PO à l'autre) et savoir se coordonner précisément sur les fonctionnalités à embarquer.

Thierry TREPIED- Directeur de projets & Coach Agile
SFEIR Groupe

La méthodologie satisfait très majoritairement tous ceux qui la pratiquent et sa prise d’ampleur le confirme. Peut-on alors parler de succès limité à la conduite/gestion de projet ou étendre ce succès aux clients/sponsors des applications ? En particulier le « client final » (utilisateur de l'application) s’y retrouve-t-il ?

Un point sur la situation Client :

Chaque cas est bien évidemment particulier sachant que la mise en place de la méthodologie peut être soit portée par la gestion de projet (scrum) soit portée par le développement (XP). Même si dans la majorité des cas ce sont les deux qui vont de paire... Je fais donc le choix d'utiliser ma propre expérience afin de mettre en exergue les difficultés rencontrées et les succès majeurs de cette méthode. Tout d'abord, plantons le décor : nous avons appliqué Scrum (AMOA) combiné avec XP (plateau de développement composé de prestataires). Je suis client (chef de projet / product owner) de plusieurs applications :
- 1er cas : un projet de refonte d’une brique du SI,
- 2ième cas : un nouveau projet (application from scratch),
- 3ième cas : un projet « purement technique » (mise en place d’un ESB).
Les utilisateurs concernés sont des populations métiers bien différentes et ont une vision distincte des applications.

1er cas : la refonte applicative :

Dans le 1er cas, l’application souffre d’un comparatif avec l’existant en plus de nouveaux besoins à implémenter. Dans un premier temps, l’application a été découpée en 3 lots distincts afin de pouvoir délivrer en 3 phases l’application complète. Un suivi de projet utilisateur en alternance avec les planning games est mis en place. Les utilisateurs sont porteurs et très enthousiastes quant au fait de voir l’application grossir en emportant leurs besoins. Cette satisfaction va de paire avec la volonté de voir leurs nouveaux besoins apparaître sachant que la refonte (éléments de base) n’est pas encore terminée… Puis vient la date fatidique de mise en production du lot n°1. Et là patatra : « on ne peut pas mettre en production une application qui ne couvre pas tout le périmètre ! ». Est-ce un problème de communication de la part de l’Informatique ? A priori non, car ce découpage et ce lot de livraison sont en permanence rappelés. Il s’avère que l’utilisateur n’est finalement prêt à basculer que si son environnement de travail bascule d’un coup. Il ne conçoit pas de gérer une partie des données dans l’ancien système et l’autre dans le nouveau. La méthodologie a dans ce cas complètement satisfait les utilisateurs, même s’ils n’ont pas eu l’occasion de profiter de mise en production incrémental plutôt qu’une bascule complète vers cette application. L’Equipe quant à elle, est surmotivée par cette application qui leur permet de s’exprimer pleinement avec des interfaces riches, et une méthodologie de développement ultra communicante en accord avec leur façon de voir les choses.

2ième cas : une application toute neuve

Dans le 2ième cas, il s’agit de mettre en place une application, qui par la même occasion, met à plat les interactions entre trois services allant du back au front office. L’application est rapidement développée mais sa mise en place est décalée, ceci à cause d’un point purement business. Une fois en place, elle est vécue dans un premier temps un peu comme une contrainte car chaque service voit alors clairement les dépendances les uns vis-à-vis des autres, puis elle devient enrichissante car facilite les échanges et évolue très rapidement. Cette facilité de l’Agile est exploitée de façon très poussée par les utilisateurs et donc répond très bien à leur besoin. Par contre, l’Equipe le vit beaucoup moins bien car ils ont l’impression de faire et défaire en permanence : « pourquoi se presser puisque de toute façon on va revenir dessus… ». Même si, en tant que Product Owner, je remonte le fait que l’application est très satisfaisante pour les utilisateurs, le moral de l’équipe est difficilement maintenable au beau fixe et la lassitude se fait souvent sentir. De ce fait, la méthodologie est de temps en temps ressentie comme une contrainte (peu de binômage), même si de leur point de vue, aucune autre méthode n’est envisageable.

3ième cas : un client Agile convaincu

Enfin le 3ième cas est plus un projet technique et je suis donc l’utilisateur final est tant que PO et chef de projet. Chacun des deux premiers exemples entrainent un besoin à mettre en place dans cet ESB. De ce fait, la méthodologie Agile répond parfaitement car on ne sait pas réellement ce que l’on doit mettre en place dans cette application et on le « découvre » pour la prochaine itération. La façon de concevoir cet ESB sous forme de scénarios a satisfait d’une part le client dont le besoin émergeant est pris rapidement, et d’autre part l’Equipe qui voit les fruits de ses efforts utilisés peu de temps après leur développement.

En conclusion

Chaque projet a été ressenti de façon différente : - par les utilisateurs finaux selon le périmètre de l’application, l’impact sur les process métier. Le point commun remonté est le fait que, grâce aux livraisons itératives, ils ont à disposition un produit fonctionnel qui leur permet de valider rapidement la conformité avec le business ; - par l’Equipe, selon la variété du produit, l’utilisation du refactoring et le résultat de leur travail qui était utilisé rapidement ou non. La méthodologie a fait l’unanimité, même s’il convient de bien réfléchir à la façon de la vendre auprès des différents intervenants afin de ne pas les frustrer quand à la rapidité avec laquelle sera mise en place la produit.

Thierry TREPIED- Directeur de projets & Coach Agile
SFEIR Groupe

Un passage aux méthodes agiles nécessite un profond changement des pratiques et mentalités. Je souhaite m'attarder particulièrement ici sur la notion de budget.

Beaucoup d'organisations, publiques ou privées utilisent ce principe financier. Cela permet de dire "Oh non, nous ne pouvons pas faire cela, car il n'y a plus de budget" ou "Il faut absolument acheter 200 ramettes de papier pour boucler le budget de cette année".

Pour les projets informatiques, les lignes de budget sont souvent réparties par fonctionnalité ou projet. Mais pour une équipe Agile, cela n'a pas de sens de faire des budgets par fonctionnalité, puisque les fonctionnalités ne sont pas définies à l'avance, ce sont des User Stories qui sont définies et implémentées au fur et à mesure. Si l'ont veut absolument créer un budget, cela a plus de sens de le faire sur la taille de l'équipe. Cela permettrait de dire "Nous avons un fort besoin pour cette période, nous allons progressivement augmenter la taille de l'équipe avec 2 nouvelles personnes" ou bien "Ce projet est stable, les utilisateurs sont contents, et le backlog sera vide dans 2 itérations, nous pouvons retirer une personnes".

La méthode fait en sorte de dégager un maximum de valeur ajouté à partir de cette équipe. Cela devient de la gestion de produit, et non de la gestion de projet.

Le budget d'un produit agile, c'est la taille de l'équipe

Mercredi dernier, j'ai passé la soirée dans les bureaux de Zenika pour assister à la conférence "outils du Product Owner pour maximiser le ROI" animée par Michel Goldenberg.

Malheureusement, car le sujet m'intéresse beaucoup, la discussion a divergé vers l'intérêt des estimations.

Ci-dessous, les exercices que Michel Goldenberg a eu le temps de nous présenter.

Comment arriver à une vision commune et obtenir un consensus ?

1. définir le sujet de questionnement ;
2. demander à chaque participant d'écrire sa réponse sur un post-it ;
3. former des binômes ;
4. demander à chaque binôme d'échanger leurs points de vue ;
5. demander à chaque binôme de noter, d'un commun accord, leurs deux post-its pour arriver à une somme de cinq (cinq étant la meilleure note i.e. la définition remportant l'adhésion des deux membres du binôme) ;
6. demander à chaque binôme d'échanger leurs post-its ;
7. réitérer l'exercice à partir de l'étape trois jusqu'à ce que les post-its aient le même nombre de notes que de participants ;
8. additionner les notes pour donner une note globale à chaque post-it.

La note globale d'un post-it révèle le degré d'adhésion des participants à ce qui est écrit dessus.

Durant cet exercice, nous avons vue se dégager un post-it particulièrement bien noté. Il s'agit du consensus. Puis un peloton de post-its un peu moins bien notés. Il s'agit de la vision commune. Et pour finir, deux post-its avec des notes très faibles. Il s'agit des visions marginales.

Comment déterminer l'intérêt d'une vision marginale ?

Les visions marginales ne sont pas nécessairement inintéressantes. Il est possible qu'elles soient seulement mal comprises. Pour répondre à cette question, nous avons utilisé l'exercice suivant :

1. demander à chaque participant de marquer physiquement son adhésion ou non à la vision marginale, par exemple en divisant la salle de réunion en deux ;
2. demander à une personne du groupe minoritaire, ceux adhérant à la vision marginale, d'expliquer son point de vue ;
3. demander à chaque personne du groupe majoritaire si les éclaircissements apportés lui fait réviser sa position ;
4. réitérer l'exercice à partir de l'étape deux jusqu'à ce que toutes les personnes du groupe minoritaire se soient exprimées ;
5. conclure en fonction des migrations entre le groupe majoritaire et le groupe minoritaire.

Comment interviewer un client ?

L'objectif de l'interview est d'aider le client à définir et prioriser son besoin. Le client doit être acteur de l'interview. L'interviewer n'est là que pour aider le client à structurer son expression de besoin.

1. demander au client d'écrire sur des post-its jusqu'à 5 fonctionnalités essentielles de son produit ;
2. demander au client de prioriser les post-its en répartissant 15 points, une note élevée indiquant une priorité forte ;
3. réitérer l'exercice jusqu'à atteindre la granularité souhaitée.

L'étape deux n'est pas toujours évidente. J'en ai fait l'expérience en mettant cet exercice en pratique le vendredi suivant la conférence. Le rôle de l'interviewer est alors de challenger le client pour qu'il sépare son besoin entre l'essentiel et le facultatif à force de questionnement.

Dernier conseil

Le PO doit également pousser l'équipe de développement à lui expliquer les stories ayant une forte complexité. Il pourra ainsi détecter les tâches ayant une forte complexité à cause d'un détail technique (e.g. : drag and drop, …). Le cas échéant, ils pourront étudier ensemble les alternatives envisageables.

Maximiser le ROI, c'est minimiser le travail inutile !

Le backlog produit est la liste des fonctionnalités du produit à développer. Chaque élément de cette liste est composé au minimum de trois attributs :

• une description sous la forme d'une user story ;
• une valeur métier ;
• un effort ou une complexité.

La finalité du backlog produit est d'avoir de la visibilité sur l'état du projet et de prioriser les développements.

Le backlog produit est de la responsabilité du product owner.

Valeur métier

La valeur métier d'un item est estimée par le product owner.

C'est la valeur métier des items qui doit diriger la priorisation des développements. Pour aider à la mise en perspective entre l'accessoire et le fondamental, il est conseillé d'utiliser la suite de Fibonacci en s'efforçant d'utiliser des valeurs très disparates.

Effort ou complexité

L'effort nécessaire à la réalisation d'un item est estimé par les personnes qui seront en charge de la réalisation. Cette valeur est fixe dans le temps.

Plus un effort est important, plus son estimation est imprécise. C'est pourquoi il est conseillé d'utiliser la suite de Fibonnaci pour estimer les efforts.

Métriques

Les métriques issues des données du backlog produit donnent de la visibilité sur l'état actuel du projet et aide à définir les prochaines étapes.

Le backlog produit est un outil évolutif (ajout, suppression, modification d'items). Par conséquent, il est souvent intéressant de suivre ces métriques en points et en pourcentage.

Ci-dessous, deux exemples de métrique que nous pouvons extraire du backlog produit.

Vélocité

La vélocité est l'effort qu'une équipe peut adresser en un sprint. Cette mesure s'affine au fil des itérations.

La vélocité ne doit pas être utilisé pour assurer le suivi de la productivité d'une équipe mais pour réaliser des projections (e.g. estimer la date de fin du projet). Une mauvaise utilisation de cette métrique entraine une inflation des points d'effort et/ou une "course à la vélocité" au détriment de la qualité.

Il est également déconseillé de comparer les vélocités de deux équipes du fait des estimations réalisées sur des échelles différentes. Les estimations sont relatives, pas absolues.

Par contre, il est intéressant de suivre l'évolution de la vélocité d'une équipe. Une diminution de la vélocité traduit souvent un manque d'évolutivité du produit développé ou l'apparition de nombreux bugs.

Valeur métier acquise

Cette métrique détermine la valeur des développements réalisés.

Si le backlog est correctement priorisé, l'évolution de la valeur métier acquise doit diminuer au cours des itérations car les items de plus grande valeur sont traités en premier.

Quelques liens

Dans SCRUM mon backlog de produit est DEEP
Le backlog produit
Des user stories de qualité
Valeur métier en pratique
Comment mieux prioriser en agile
Suite de Fibonacci

Scott W. Ambler, Chief Agile Methodologist chez IBM, a présenté les résultats des sondages réalisés par Ambysoft et Dr. Dobb's Journal pour faire ressortir les pratiques réelles des équipes agiles à ce jour.

Les conclusions qui ont retenu mon attention :

• les pratiques agiles restent principalement concentrées sur la technique (Continuous Integration) ;
• l'obtention de la certification "SCRUM Master" après seulement deux jours de formation est dépourvue de sens ;
• des équipes de plus de 200 personnes pratiquent l'agilité ;
• les pratiques agiles ne changent pas les besoins de chiffrage, de spécification, de modélisation, d'architecture durant l'initialisation d'un projet ;
• la majorité des développeurs agiles suivent des conventions de codage même s'il reste une marge de progrès dans ce domaine ;
• les équipes agiles et traditionnelles écrivent autant de documentation et cette documentation est de qualité similaire ;
• les projets agiles connaissent plus de succès que les projets classiques.

L'intérêt principal de cette présentation a été de fournir des réponses chiffrées aux questions que peuvent se poser les personnes s'intéressant aux méthodes agiles. Cependant, il convient de considérer ces chiffres dans leur contexte avec les limitations que ça implique. Par exemple, les conditions de succès d'un projet restent sujet à discussion.

Pour la liste complète des "Mythes Agiles" et les résultats des sondages associés, se référer au post de Jevgeni Kabanov.

Pour la liste des sondages, suivre ce lien.

Comparons ce qui est comparable

parallèle avec les référentiels dans la cinématique des corps

La force de chiffres est impressionnante, car elle a l'aura de l'objectivité- la mesure est objective. C'est pour cette raison que les chiffres peuvent devenir un instrument puissant de persuasion., au même titre que les images des films documentaires. Mais il ne faut pas oublier de placer les images (et les chiffres) dans leur contexte. Ou comme il nous était rappelé à l'école aux cours de physique , la vitesse d'un objet dans un système référentiel non galiléen n'est pas celle qu'on mesure si l'observateur est en dehors de ce système.