La méthode, un frein au numérique ? Soyons Agiles !

Un vrai projet numérique doit être mené rapidement : il est fait pour révolutionner les processus, le rapport avec les clients,… L’informatique et l’organisation ou les opérations (en tant que « directions ») doivent montrer l’exemple. Néanmoins, les méthodes utilisées dans les DSI ne permettent pas cette célérité car elles répondent à d’autres besoins : couverture du projet, maintenabilité, exploitabilité, cohérence de l’architecture technique et de l’architecture applicative. En outre, de nombreux acteurs interviennent à différents stades et prendre en compte leur disponibilité n’est pas compatible.

En phase de développement, on choisira des méthodes de type agiles. Je ne vais pas faire une thèse sur le sujet, seulement un aparté. Les DSI ne sont pas nécessairement adaptées à ces méthodes et j’ignorais leurs existences jusqu’à il y a quelques mois quand un fournisseur nous a proposé de travailler ainsi car un de nos projets n’avançait pas. Ce qu’il nous a présenté collait parfaitement à ma vision du travail et j’étais enthousiasmé. Pour vous dire, j’ai repris une bière. Me documentant rapidement sur le sujet (il ne m’intéresse pas beaucoup et je suis tenu de respecter les méthodes de ma boite), j’ai découvert que pour mon boulot je pratiquais toujours cette méthode sans m’en rendre compte.  D’ailleurs, la page Wikipedia m’a fait rigoler. Par exemple : « Un responsable fonctionnel définit et ordonne la production des composants de l'application. »  Je me suis découvert comme étant « responsable fonctionnel » faisant la chose.

D’une manière générale, je me suis rendu compte que, dans la boite, on pratiquait beaucoup un dérivé des méthodes agiles sans le savoir. Je vais donc citer une large partie de cette page.

« Pratiques communes à l'ensemble des méthodes agiles

·         Les pratiques communes liées aux ressources humaines :

o   Participation de l’utilisateur final aux groupes de travail.

o   Groupes de travail disposant du pouvoir de décision.

o   Autonomie et organisation centralisée de l’équipe (motivation).

o   Spécification et validation permanente des Exigences.

·         Les pratiques communes liées au pilotage du projet

o   Niveau méthodologique variable en fonction des enjeux du projet.

o   Pilotage par les enjeux et les risques.

o   Planification stratégique globale basée sur des itérations rapides.

o   Réalisation en jalons par prototypage actif itératif et incrémental.

o   Recherche continue d’amélioration des pratiques.

·         Les pratiques communes liées à la qualité de la production

o   Recherche d’excellence technique de la conception.

o   Vision graphique d’une modélisation nécessaire et suffisante.

o   Vision de la documentation nécessaire et suffisante.

o   Normes et techniques raisonnables de qualité du code (métrique).

o   Architecture à base de composants.

o   Gestion des changements automatisés. »

Nous y sommes presque ! Je vais en parler à mes chefs. Je vais néanmoins faire deux ou trois critiques. Par exemple, les groupes de travail ne doivent pas avoir de pouvoir de décision : le responsable fonctionnel doit pouvoir s’y opposer et faire remonter les désaccords aux instances dirigeantes, pour des raisons que j’exposais récemment dans mon blog (les braves gens ont tendance à prendre des décisions inutiles qui coûtent cher, notamment parce que dans le feu de l’action, ils perdent le recul nécessaire). Mais de tous ces points, c’est le premier qui est le plus important : l’utilisateur final doit participer aux groupes de travail, ou, plus exactement, celui qui le représente.

A cette liste, j’ajouterais bien qu’il faut un PMO (bureau de gestion de projet), éventuellement externe à l’équipe et indépendante du responsable fonctionnel pour gérer tout le bordel, les plannings, les actions, le reporting,… En plus d’un chef, également.

Supprimer les vieilles méthodes

Comme je le disais, il ne s'agit pas pour moi de faire la critique des méthodes utilisées mais de rappeler le constat : elles ne sont pas adaptées à des projets numériques. Il faut donc en utiliser d'autres, plus souples,... Il faut en finir avec les "dossiers d'architecture technique" et autres "documents de conception détaillée". Tant pis !

Mais pour que cela fonctionne, que le numérique s'applique à certains projets, tous les projets doivent prendre les nouvelles méthodes. C'est une révolution qui doit se faire dans les DSI.

Avant-projet

Je parlais récemment de Moneo et d'une des raisons de l'échec : les PME ne sont pas rechargeables sur les distributeurs automatiques.

Aussi, on ne répétera jamais que dans tout projet informatique (numérique ou pas), la phase la plus importante est la conception initiale, le cadrage. Il ne suffit pas dire : on veut ça, mettez-vous autour d'une table pour le faire. Il faut que l'avant-projet définisse toutes les briques impactées et que le responsable fonctionnel puisse distribuer les copies dès le lancement.

Pensez-y bien !