Méthodes agiles : il faut énormément de préparation en amont pour fabriquer le bon logiciel

Un meilleur alignement avec les métiers

Au final, il constate des bénéfices certains dans l’alignement entre l’application et les besoins métiers. Mais il ne faut pas considérer uniquement les jours hommes des informaticiens, il faut aussi prendre en compte l’impact sur l’activité opérationnelle avant de lancer l’investissement. « C’est un vrai changement d’esprit dans les méthodes de travail. C’est en soi une méthode de conduite de projet car on intervient beaucoup en amont » informe-t-il.

Côté prestataire, « nous avons passé du temps à décrire les mécanismes d’ajustement avec l’intégrateur. L’agilité a un coût et génère de la qualité. Ce qui veut dire qu’il y aura moins de coût à la maintenance. Nous pilotons par la valeur délivrée. La liste des fonctions, on s’en moque un peu » conclut-il.

A l’écoute de ce témoignage, les défauts des méthodes en V classiques sautent aux yeux.  « Il y a un décalage entre ce qui a été imaginé par le client et ce qui est livré, car le client a un rôle limité dans le projet avec des comités de pilotage et stratégique tous les deux à six mois » relate Christophe Delhaise, directeur de programme chez Bull Services et Solutions et qui intervenait lors du séminaire.

Trop de déperdition d’information


Il poursuit : « le client ne voit le logiciel qu’à la fin. Et il y a une déperdition entre les équipes fonctionnelles, celles de développement et celles de recette sur une durée de 1 an à 2 ans. » Il confirme qu’il est également un fervent partisan des méthodes agiles. « On montre des versions du logiciel régulièrement, pour détecter ce qui n’a pas été bien compris ou ce qui a été mal spécifié. »

Il souligne que les méthodes agiles s’adaptent à de gros projets de 20 000 ou 30 000 jours hommes tels qu’il en mène actuellement pour la DCNS, qui gère les chantiers navals militaires, à Toulon. « Le rythme de développement évite les défauts des projets classiques où on mobilise plein de développeurs lorsqu’on on est en retard et qui délivrent du code de mauvaise qualité. » Il prévient toutefois : « Il faut surveiller les architectes et les développeurs qui sont toujours très créatifs. » Il ajoute : « Il faut réutiliser du code, c’est là où se réalise la marge de l’intégrateur. »

Fonctionner en mode trade in – trade out …