Gestion de projet – Vers les méthodes agiles
78
« Mes clients ne savent jamais ce qu’ils veulent ! » ou bien « C’est exactement ce que j’ai
demandé, mais ce n’est pas ce que je veux ! ».
La réponse de l’expert Marc Dumonte, responsable Qualité chez NDS France.
Pour toute personne travaillant ou ayant travaillé chez un fournisseur de solution logicielle, ces
phrases sonnent comme une tautologie.
Le premier symptôme de cette incompréhension réside dans la qualité du dialogue entre le
client et son fournisseur.
Le second motif usuel d’incompréhension est la gestion des évolutions. On assiste à un
fréquent dialogue de sourds entre un client qui a du mal à stabiliser son besoin et un fournisseur de solution qui voit les modifications comme un véritable poison dans son processus de
développement : le premier se représente une évolution comme une opportunité alors que le
second y voit un risque voire une catastrophe pour son projet de développement.
Dans un modèle de développement classique, la « bonne » réponse consistera à définir différents niveaux de spécifications et un processus de gestion des évolutions avec différentes
instances de gestion des évolutions (les fameux CCB, Change Control Board). Cela devrait
fonctionner, mais si le système est trop complexe pour leur compétence collective, les entreprises tombent la plupart du temps sur l’un des deux écueils de ce problème : la bureaucratie ou
le chaos. La bureaucratie se produira si le client affiche des exigences en matière de qualité
des processus, ce qui se traduira par un besoin de preuves et enregistrements divers. Le
chaos sera plus fréquent, en particulier si l’entreprise affiche la volonté d’être réactive.
Les méthodes agiles proposent une alternative efficace à ce problème, que j’ai pu expérimenter sur des projets de complexité moyenne. Par la taille des équipes (20-30 personnes), par la
dimension du logiciel (1 million de lignes de code, réutilisées par parties et successivement) et
par la longueur du projet (6 mois à 1 an). Cette alternative repose sur 4 piliers :
– Le premier est le développement itératif : livrer souvent, et ce le plus vite possible dans le
projet, au travers de petits lots de développement qui permettront de corriger le tir rapidement
si l’une des deux parties s’est trompée : le client dans sa vision ou son expression du besoin,
le fournisseur dans sa compréhension ou l’implémentation de celui-ci.
– Le deuxième est la focalisation sur la valeur capitalisée par le client. Il s’agit de maximiser la
valeur engrangée par le client en fin d’itération, essentiellement en s’assurant que les fonctionnalités et propriétés du logiciel livré correspondent le plus possible au cœur des préoccupations du client.
– Le troisième est la visibilité donnée au client : il s’agit de mettre en œuvre une transparence
maîtrisée, en s’appuyant en particulier sur les revues de fin d’itération. Elles permettent au
client de réduire le risque, réel ou perçu, que représente pour lui le développement logiciel.
– Le quatrième et dernier pilier est une règle de base : une modification est la bienvenue mais
dans l’itération suivante. Si la pression est trop forte, il faut raccourcir la durée d’une itération mais
aussi faire comprendre au client qu’il n’est pas dans son intérêt de modifier le périmètre de l’itération courante. Cette discipline permet, sur le long terme, de garantir une véritable réactivité. Ne
pas confondre vitesse (oui pour la modification mais dans l’itération suivante) et précipitation
(changer en cours d’itération). C’est une question de maturité des organisations agiles.
L’enjeu est énorme car ces quatre piliers sont le socle d’une relation client rénovée. La visibilité
sur les développements en cours et l’assurance d’être écouté ramènent la confiance du client,
renforcée aussi par la vision d’un processus souple mais rigoureux et convergent. Ce jeu
« gagnant-gagnant » est une valeur essentielle du développement agile. Il s’agit d’aller au-delà
de la simple relation contractuelle pour mettre en œuvre un véritable partenariat avec le client.
GestProjInform Livre Page 78 Vendredi, 3. avril 2009 12:07 12
78
« Mes clients ne savent jamais ce qu’ils veulent ! » ou bien « C’est exactement ce que j’ai
demandé, mais ce n’est pas ce que je veux ! ».
La réponse de l’expert Marc Dumonte, responsable Qualité chez NDS France.
Pour toute personne travaillant ou ayant travaillé chez un fournisseur de solution logicielle, ces
phrases sonnent comme une tautologie.
Le premier symptôme de cette incompréhension réside dans la qualité du dialogue entre le
client et son fournisseur.
Le second motif usuel d’incompréhension est la gestion des évolutions. On assiste à un
fréquent dialogue de sourds entre un client qui a du mal à stabiliser son besoin et un fournisseur de solution qui voit les modifications comme un véritable poison dans son processus de
développement : le premier se représente une évolution comme une opportunité alors que le
second y voit un risque voire une catastrophe pour son projet de développement.
Dans un modèle de développement classique, la « bonne » réponse consistera à définir différents niveaux de spécifications et un processus de gestion des évolutions avec différentes
instances de gestion des évolutions (les fameux CCB, Change Control Board). Cela devrait
fonctionner, mais si le système est trop complexe pour leur compétence collective, les entreprises tombent la plupart du temps sur l’un des deux écueils de ce problème : la bureaucratie ou
le chaos. La bureaucratie se produira si le client affiche des exigences en matière de qualité
des processus, ce qui se traduira par un besoin de preuves et enregistrements divers. Le
chaos sera plus fréquent, en particulier si l’entreprise affiche la volonté d’être réactive.
Les méthodes agiles proposent une alternative efficace à ce problème, que j’ai pu expérimenter sur des projets de complexité moyenne. Par la taille des équipes (20-30 personnes), par la
dimension du logiciel (1 million de lignes de code, réutilisées par parties et successivement) et
par la longueur du projet (6 mois à 1 an). Cette alternative repose sur 4 piliers :
– Le premier est le développement itératif : livrer souvent, et ce le plus vite possible dans le
projet, au travers de petits lots de développement qui permettront de corriger le tir rapidement
si l’une des deux parties s’est trompée : le client dans sa vision ou son expression du besoin,
le fournisseur dans sa compréhension ou l’implémentation de celui-ci.
– Le deuxième est la focalisation sur la valeur capitalisée par le client. Il s’agit de maximiser la
valeur engrangée par le client en fin d’itération, essentiellement en s’assurant que les fonctionnalités et propriétés du logiciel livré correspondent le plus possible au cœur des préoccupations du client.
– Le troisième est la visibilité donnée au client : il s’agit de mettre en œuvre une transparence
maîtrisée, en s’appuyant en particulier sur les revues de fin d’itération. Elles permettent au
client de réduire le risque, réel ou perçu, que représente pour lui le développement logiciel.
– Le quatrième et dernier pilier est une règle de base : une modification est la bienvenue mais
dans l’itération suivante. Si la pression est trop forte, il faut raccourcir la durée d’une itération mais
aussi faire comprendre au client qu’il n’est pas dans son intérêt de modifier le périmètre de l’itération courante. Cette discipline permet, sur le long terme, de garantir une véritable réactivité. Ne
pas confondre vitesse (oui pour la modification mais dans l’itération suivante) et précipitation
(changer en cours d’itération). C’est une question de maturité des organisations agiles.
L’enjeu est énorme car ces quatre piliers sont le socle d’une relation client rénovée. La visibilité
sur les développements en cours et l’assurance d’être écouté ramènent la confiance du client,
renforcée aussi par la vision d’un processus souple mais rigoureux et convergent. Ce jeu
« gagnant-gagnant » est une valeur essentielle du développement agile. Il s’agit d’aller au-delà
de la simple relation contractuelle pour mettre en œuvre un véritable partenariat avec le client.
GestProjInform Livre Page 78 Vendredi, 3. avril 2009 12:07 12