Les méthodes agiles ont encore gagné du terrain en 2012. Un nombre croissant d’entreprises lancent un processus de transformation de leurs systèmes d’information en agile.
Et en tant que praticien agile, cette nouvelle accélération n’est pas pour me déplaire.étant un grand adepte des méthodes agiles, je trouve ce genre de décisions très intéressant :). mais malheureusement (ou heureusement) nous (les humains) ne sommes pas des êtres complètement rationnels. Notre processus de prise de décision est entaché parfois de préjugés et de faux raisonnements (nos fameux biais cognitifs).

Ce sont ces préjugés qui augmentent en quelques sorte le fossé qui existe entre les partisans des pratiques agiles et ceux des méthodes traditionnelles. Un fossé et une rupture qui étaient déjà renforcés par le fait que les 4 principes fondateurs des méthodes agiles sont des contre-pieds vis à vis de l’approche classique: (cf. le Manifeste Agile, site officiel: http://agilemanifesto.org/).

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Le but de cet article est de présenter quelques-uns de ces préjugés et fausses idées qui existent toujours sur l’agilité; des idées auxquelles j’étais confrontées à chaque fois que je parlais des méthodes agiles chez des clients ou avec des amis.

  • L’agilité est pour les petits projets
  • Binomage
  • Chiffrage
  • Le pouvoir des équipes de développement
  • Auto-organisation
  • Bye bye la documentation

1. Les Méthodes Agiles sont réservées aux « petits » projets

Une des idées les plus répandues quand on parle agilité est qu’elle est réservée uniquement pour les petits projets et les prototypages. C’est totalement faux, et le 4 ème principe du manifest agile (Responding to change) le prouve.
Les méthodes agiles ont été crées pour permettre aux projets de s’adapter facilement aux changements. Cela n’a de sens que pour les projets de durée plutôt longue, car le risque de changement est d’autant plus fort que le projet s’éternise. De plus, il est parfois coûteux de mettre en place quelques pratiques agiles (automatisation de tests, livraison continue…), ce qui nécessite du temps pour avoir un retour sur investissement.

Cette idée fausse a peut-être été inspirée par la brièveté des cycles de développement. Or un développement itératif a pour but d’éviter le risque d’effet tunnel, qui est d’autant plus important que le projet est long.

Mais ceci ne signifie pas que les méthodes agiles excluent les petits projets. Les pratiques agiles sont adaptées aussi à ce type de projet, parce qu’elles mettent en premier plan la livraison d’un produit de qualité, quelque soit la taille ou le temps exigés par le projet.

2. Les Méthodes Agiles dupliquent les coûts: à quoi bon sert le binomage ?


Le binomage ou “Pair Programming” est la pratique agile la plus utilisée par les détracteurs de l’agilité pour la dénigrer, on trouve cela stupide de dépenser deux fois le temps nécessaire pour faire la même chose.
Le pair programming est, certes, une des pratiques agiles présentées par la méthode eXtreme Programming (XP) mais il n’est, en aucun cas, un synonyme de l’agilité (d’ailleurs il ne figure pas dans le manifest).

Pour moi, la pratique du binomage souffre essentiellement de 2 facteurs:

  • Vision économique: les managers pensent qu’avec le binomage, on dépense le double (voir plus) pour exercer un travail qui doit être fait par une seule personne. Certes c’est légitime de penser aux coûts quand on est manager d’un projet ou équipe, mais penser ainsi réduit le status d’un membre de l’équipe de développement en une machine ou un robot. Il faut au contraire considérer cette collaboration des 2 développeurs comme une collaboration de 2 cerveaux qui se complètent pour le bien du projet.
  • mauvaise pratique du binomage: plusieurs détracteurs de méthodes agiles dénigrent le binomage parce qu’ils ont eu de mauvaises expériences avec des gens qui pratiquent mal le binomage. Il ne suffit pas d’être assis à 2 devant un seul clavier pour dire qu’on fait du pair programming. Il faut que le pilote et co-pilote soient tous les 2 actifs et positifs, chacun dans son rôle bien définit par XP, et que les conditions (espace de travail, outillage,…) soient réunis pour que ce binomage ne soit pas effectivement une perte de temps et d’argent.

Ceci dit le binomage reste une des pratiques agiles et plus spécifiquement de XP, et c’est un grand amalgame de le rendre (et c’est souvent de gré) synonyme à l’agilité. Bien sûr si on veut lister tous les bénifices qu’apporte le binomage dans un projet, il faudra consacrer un billet de blog; mais en général voici ce que je réponds aux personnes qui me disent que cette pratique ne sert à rien:

  • combien ça peut vous coûter l’absence (arrêt maladie, congé…) d’une personne qui travaillait seule sur une partie du projet et que elle seule en maitrise les détails ?
  • ce que je leur propose est de prendre 10 à 20% de ce coût et de l’investir en binomage dès le début du projet.

3. Les Méthodes Agiles ne chiffrent pas en euros !

Le chiffrage en pratiques agiles est toujours sujet de débat et source de beaucoup de mésententes entre développeurs et chefs de projet. Une des fausses idées sur l’agilité est que les méthodes agiles exigent de ne pas chiffrer en Jour/homme mais plutôt en story point. C’est FAUX. Dans toutes les méthodes agiles, on ne trouvera jamais le chiffrage en story point (ou équivalent) comme la seule et unique façon de chiffrer, au contraire, les méthodes agiles laissent les équipes de projets libres de choisir le mode de chiffrage qui leur convient au mieux (J/H, points, taille de T-shirt…).

L’idée que les méthodes agiles chiffrent mal est peut être due au fait que la majorité des équipes qui travaillent en agilité penchent plutôt vers les chiffrages en story point ou équivalent plutôt qu’en J/H. Ce choix traduit le fait qu’on chiffre un duo complexité-temps de traitement.
Peu importe la méthode de chiffrage, ce qu’oublie en général les détracteurs des méthodes agiles, est que le chiffrage est une “estimation” de la charge de travail, et malheureusement on oublie souvent le sens d’estimation.

4. Les Méthodes Agiles donnent beaucoup plus de pouvoir aux développeurs !

mais de quel pouvoir parle-t-on?
La réponse est que les développeurs refusent, via l’agilité, d’intégrer les demandes urgentes des business managers, que c’est l’équipe qui décident de tout (quoi développer), que l’équipe gaspille beaucoup de temps pour des taches annexes (TDD, ATDD, automatisation des tests),…
Mais est-ce vraiment un abus de pouvoir si l’équipe fait de son mieux pour livrer un produit de qualité en incluant tout un socle fortifié de tests ? les développeurs sont-ils abusifs s’ils refusent les demandes urgentes pour éviter toute perturbation et pour se concentrer sur le contenu de leur itération ?

Parler de pouvoir avec l’agilité reste quelque chose d’absurde surtout si on lit bien le 3ème principe du manifest agile: favoriser la collaboration avec le client plutôt qu’une négociation de contrat.

Le sentiment du pouvoir dans un projet est, à mon sens, dû principalement aux méthodes traditionnelles de gestion d’équipe et de projet (waterfall,V…) qui font qu’une hiérarchisation est imposée:

    • Les fonctionnelles font leurs spécifications et s’attendent à que toutes les fonctionnalités soient développées (sans marge de négociation)
    • Les architectes font leurs spécifications techniques et imposent aux développeurs leurs choix
    • Les développeurs doivent respecter à la lettre ce que leur disent les architectes et leur chef d’équipe (qui fait quoi, comment le faire…)
    • Les testeurs et équipe de qualification n’ont aucun mot à dire pendant le cycle de développement (qui peut s’étirer sur des mois voir des années); leur boulot arrive en bout de chaîne uniquement.
    • Bref, tout est contractualisé et chacun cherche à se protéger en exerçant du pouvoir sur l’entité en dessous (comprendre « les suivants »).

Avec un tel état d’esprit, quand une méthode dit qu’il faut favoriser la collaboration, que les fonctionnelles doivent coopérer avec les architectes et/ou développeurs pour spécifier, que ce sont le développeurs qui prennent en charge l’architecture technique en collaboration avec les architectes agiles ( http://blog.neoxia.com/agilite-et-architecture/), que c’est l’équipe qui décide du nombre de taches à prendre lors d’un sprint selon leur vélocité, que les testeurs interviennent dès le début du projet pour élaborer un plan de tests et participer à l’ATDD/BDD… Bien sûr avec tout ceci, il y’a des gens qui ne vont pas se sentir dans leur assiette et que les méthodes agiles constituent pour eux une menace de leur status (ou du moins le pense t-il à tord).

Avec les Méthodes Agiles, on passe plus de temps en réunion qu’en développement, c’est l’anarchie totale!

Le mot anarchie arrive souvent quand on parle de l’agilité. Ce sentiment, à mon avis, est favorisé par 2 facteurs: le fait que l’agilité préconise d’avoir une équipe auto-organisée et la multitude de rites dans une méthode agile comme scrum (sprint planning, sprint review, planning poker…)

Le probleme de l’équipe auto-organisée est que ce principe est souvent mal compris, même dans des équipes novices en agilité. Une équipe auto-organisée ne veut pas dire que pour prendre une décision sur une petite implémentation d’une classe il faut organiser une réunion avec toute l’équipe pour prendre cette décision!! Elle ne veut non plus dire que Monsieur X, qui est spécialiste des service web prend la responsabilité de toutes les taches de développement de webservice, que Madame Y, qui connait bien Hibernate, s’auto-proprie tous les mapping et les classes objet pour la base de données …

Une équipe auto-organisé veut, avant tout dire, que l’équipe est solidaire, qu’il y’a une responsabilité collective du produit, que c’est l’équipe qui décident du mode de travail tout en ayant comme pré-requis la recherche de l’amélioration continue.

Concernant les réunions à répétition sur une méthode comme scrum, il faut juste savoir qu’en scrum tout est timeboxé, çàd qu’aucune réunion ne peut durer indéfiniment et que normalement les 4 heures (voir 6h) de réunions qui sont faite lors de chaque sprint sont censé remplacer des jours et des mois de spécifications (détaillées) pour quelques choses qui deviendra probablement obsolète au moment du développement :)

6. Avec les Méthodes Agiles, bye bye la documentation, comment maintenir alors les livrables ?

Une des craintes pour les managers par rapport aux méthodes agiles est que la maintenance de livrables devient très compliquée à faire vu que les méthodes agiles “ne recommandent pas” de faire des documentations.

D’une part, c’est très légitime de se poser la question de maintenance des produits logiciels quand la documentation est insuffisante. Cependant dire que les méthodes agiles ne produisent pas de documentation est totalement FAUX. Et comme pour tous les points évoqués avant, il suffit de bien lire un des principes du manifest Agile: Priviligier un produit qui fonctionne plutôt qu’une documentation exhaustive. Ceci ne veut absolument pas dire qu’il ne faut pas faire de documentation. au contraire, il faut faire de la documentation mais qui sera maintenable et utile pour le produit. ça sert à quoi de prendre 2 à 3 semaines pour faire tout un document, le plus exhaustif qui peut l’être, pour qu’en fin de compte il ne correspondra plus à la réalité ?

Dans un développement agile, la documentation a son importance comme pour les méthodes classiques. La différence, à mon sens, est dans la démarche. Si dans une méthode classique, il faut faire un bon document de spécifications fonctionnelles, le plus détaillé qu’il soit, et qu’il faut aussi faire un bon document de spécifications techniques, le plus détaillé qu’il soit aussi, et en plus un cahier de tests, le plus détaillé qu’il soit; tout ceci avant même de se lancer dans les développements, vous comprenez bien qu’entre le moment d’avoir la petite idée pour lancer le produit et son lancement (time to market), il va se passer beaucoup de temps.

Avec les méthodes agiles, on agit différemment. On prépare les user stories (façon macro ou épics) avec juste le nécessaire pour que les équipes de développement puissent commencer à développer. Après grâce aux bonnes pratiques préconisées par les méthodes agiles (TDD, ATDD, voyager leger, refactoring, métaphores…), c’est le code source qui fait office de spécifications fonctionnelles et techniques détaillés. En plus avec les tests d’acceptation (ATDD, BDD), à la fois les personnes du fonctionnel et les testeurs sont impliqués dans cette démarche de documentation. Ceci est donc une garantie que la documentation deviendra vivante tout au long du projet : et après tout, si on demande au gens qui critique la documentation façon agile, je leur dirai tout simplement: “Que préfére-t-on, une documentation complète pour un produit qui ne marche pas, ou un bon produit qui marche, avec un code source qui s’explique tout seul ?”