Agilité, Scrum, Xtreme programming... Ca fait deux ans que j'en entendais parler, et deux ans que je me disais que c'était vraiment un truc pour les geeks les plus furieux, pas trop fait pour moi.
Et puis j'ai vu la lumière. Le fameux bouquin Getting Real ( toujours lui) n'y est surement pas pour rien...
Pour faire court, il faut retenir que l'approche "agile" est faite pour palier les défauts de la gestion de projet informatique classique : dérapages en coûts et en délais quasi systématiques, et produit final souvent aussi figé qu'éloigné des besoins concrets des utilisateurs.
Avant de rentrer dans le détail ça vaut le coup de décrire l'approche classique de la conduite de projet informatique :
Acte 1 : le Chef de Projet
Un intermédiaire est baptisé Chef de Projet. Il n'est ni expert métier, ni expert informatique. Disons qu'il est interprète.
Acte 2 : les Spécifications
Ce chef de projet fait le tour des popotes dans la mesure de ses possibilités pour savoir qui est l'utilisateur final, et ce qu'il voudrait.
Il en tire un document souvent aussi épais qu'excitant qu'on appelle des Spécifications Fonctionnelles ( les majuscules comptent, comme dans Cahier des Charges).
Le Chef de Projet est brillant, il a tout prévu, il va donc de soi que ces Spécifications sont exhaustives et définitives.
Acte 3 : le tunnel
Il confie cette bible à des développeurs qui jurent sur leurs ancêtres qu'ils réaliseront ces commandements à la virgule prêt, et dans des délais bien entendus respectés 'puisqu'ils savent déjà ce qu'ils ont à faire' (sic).
3 mois plus tard, l'équipe se réunit pour un Comité de Pilotage.
Les développeurs regardent le capuchon de leur stylo en demandant un léger délai supplémentaire, la dernière petite ligne des Spécifications leur demandant malheureusement 15 jours de travail.
Acte 4 : Le dérapage
30% de dérapage plus tard, le chef de projet est donc livré d'un magnifique site ou logiciel. Il s'en estime heureux, la fois précédente, c'était 70% de dérapage...
Il profite quand même de l'occasion pour expliquer à ses développeurs en regardant à son tour le capuchon de son stylo que le besoin exprimé dans les Saintes Spécifications a "un peu" évolué.
Acte 5 : le conflit
Ce à quoi le développeur répond que cette petite évolution coutera en fait 1 mois de boulot de plus, qui n'était évidemment pas budgeté.
... et que ce n'est d'ailleurs pas la première fois que ça se produit.
... et que la prochaine fois ce serait bien que la demande soit ferme et définitive dès le départ.
Acte 5 : le dénouement
Si le projet est vital, les grognements finissent par cesser et les modifications sont faites à grands renforts de "vraiment c'est pas normal".
Si le projet n'est pas si vital, il est mis en production en l'état, c'est-à-dire utile à personne.
Mais pourquoi tout le monde fait comme ça ?
Disons que l'Enteprise s'est mis à gérer des projets informatiques dans les années 80 avec les méthodes qu'elle avait sous la main, c'est-à-dire celles qui servaient à construire des ponts.
...sans bien se rendre compte que la construction d'un pont est assez différente de celle d'un projet informatique :
- tout le monde est bien conscient que ce sera compliqué de le déplacer une fois construit, donc on se met vraiment d'accord avant.
- une fois qu'il sera fait, personne n'aura l'idée saugrenue de le transformer en hotel
- les pratiques séculaires du BTP font que, même comme ça, ça prendra du retard. Mais apparemment un mois de retard sur un pont qui servira 50 ans, ça fait partie du folklore et ce n'est pas si grave.
30 ans ont passé, il est temps de prendre conscience qu'un projet informatique est tout l'inverse :
- je vous promets que vous ne savez pas aujourd'hui ce que vous voudrez en faire demain
- votre site va servir au maximum un an en l'état. Un mois de dérapage dans ces conditions, c'est lourd.
Partant de ces constats, pas mal d'acteurs du milieu se sont mis d'accord petit à petit sur des pratiques un peu plus pragmatiques : les méthodes agiles.
Ca y est, vous êtes mûrs, on en reparle dans un prochain post :-)
Je partage ton constat sur l'inadaptation des méthodes de projet "classiques" à de nombreux projets actuels, et le besoin de faire "bouger les lignes".
Néanmoins, l'agilité a aussi ses contraintes, que tous les acteurs ne sont pas toujours près à accepter :
- il faut que la MOA soit capable de figer le morceau de besoin exprimé à chaque étape (agile n'etant pas le synonyme de mouvant)
- il faut que la MOE soit capable de traiter au fil de l'eau (l'agilité n'est possible qu'avec une organisation adaptée de bout en bout)
Rien d'infaisable, mais une éducation des MOA et nécessaire, ainsi qu'une transformation des DSI car il ne s'agit pas que de méthode, il s'agit aussi d'organisation.
Le plus gros risque à toujours avoir à l'esprit à mon sens est la tendance naturelle des MOA à ne pas vouloir s'engager, qui peut dans le cadre des méthodes agiles se voir "légitimée" du fait d'une mauvaise compréhension et de fait tuer tout l'intérêt de la méthode. Il y a un gros travail pédagogique préalable à entretenir tout du long du projet !
Rédigé par : Fabien Grenet | 05 février 2011 à 08:33
@Fabien : totalement d'accord avec le constat, pas complètement avec les conclusions... ce sera l'objet des prochains posts, je serai ravi de poursuivre la discussion !
Rédigé par : Nicolas Hennion | 09 février 2011 à 10:19
Avec grand plaisir :)
Ma vision est effectivement un peu déformée par mon quotidien, et la confronter avec d'autres points de vue est toujours instructif et enrichissant !
Rédigé par : Fabien Grenet | 07 mars 2011 à 10:41