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 :-)