Gestion de projet – Vers les méthodes agiles
230
la planification, sont organisées avec le client ; on y parle son langage métier ou on utilise
des métaphores pour qu’il comprenne certaines contraintes techniques. En aucun cas, les
utilisateurs n’interviennent dans les réunions techniques. Et leur représentant, en la personne
du product owner (Scrum), joue justement le rôle d’interface entre les utilisateurs et
l’équipe de réalisation, qui est à leur service. Le temps qu’ils consacrent à l’équipe de
réalisation est un gage pour obtenir ce qu’ils souhaitent vraiment à l’arrivée.
• Ce n’est pas adapté à nos projets.
Argumentation : tous les clients pensent que leurs problématiques sont uniques. C’est
partiellement vrai, d’où la nécessité de dresser un état des lieux pour prendre connaissance de l’existant dans chaque contexte. Mais les méthodes agiles adressent une large
typologie de projets. Et le projet idéal n’existe pas : celui où l’on commencerait tout à
zéro, avec des clients disponibles qui savent définir leurs besoins, avec des développeurs
motivés et expérimentés, avec des moyens extraordinaires pour explorer la nouvelle
démarche… n’est qu’utopie. Si l’on est convaincu de faire évoluer sa méthodologie, rien
ne vaut une première expérimentation.
Certains types de projet se prêtent moins aux approches agiles : projet d’intégration de
progiciel, projets peu exploratoires (logiciel de paie ou de comptabilité), refontes
isofonctionnelles ou projets cost cutter pour faire du « pas cher ». Mais il n’y a aucune
contre-indication !
Et ceux qui sont le mieux adaptés, c’est lorsque tout va mal, qu’on a tout essayé (voir le
projet Chrysler de Kent Beck) !
• On ne pourra jamais persuader nos clients ou notre hiérarchie.
Argumentation : prévoir un séminaire d’information et de sensibilisation d’une demijournée, avec de vrais retours d’expérience, illustrant non seulement les bénéfices mais
aussi les difficultés rencontrées, pour être plus crédible ; les parties seront interpellées,
même si elles ne sont pas totalement convaincues. Ensuite, proposer une expérimentation,
même courte, sur un projet pilote, avec des objectifs et un bilan qualitatif et quantitatif.
Utiliser les nombreux exemples d’expériences réussies dans les différents secteurs d’activités, types de projet, environnements… comme références.
• Nos utilisateurs ne sont pas disponibles sur site.
Argumentation : idéalement, l’utilisateur final est le meilleur interlocuteur. À défaut de
cet utilisateur, la solution est de choisir un représentant (un customer proxy 1 ) qui connaît
le métier, les exigences. Il est important, toutefois, que les « vrais » utilisateurs valident
le produit final et, si possible, soient présents aux réunions de planification.
1. Voir Craig Larman, Agile and iterative Development, a Manager’s Guide, Addison Wesley, 2003.
GestProjInform Livre Page 230 Vendredi, 3. avril 2009 12:07 12
230
la planification, sont organisées avec le client ; on y parle son langage métier ou on utilise
des métaphores pour qu’il comprenne certaines contraintes techniques. En aucun cas, les
utilisateurs n’interviennent dans les réunions techniques. Et leur représentant, en la personne
du product owner (Scrum), joue justement le rôle d’interface entre les utilisateurs et
l’équipe de réalisation, qui est à leur service. Le temps qu’ils consacrent à l’équipe de
réalisation est un gage pour obtenir ce qu’ils souhaitent vraiment à l’arrivée.
• Ce n’est pas adapté à nos projets.
Argumentation : tous les clients pensent que leurs problématiques sont uniques. C’est
partiellement vrai, d’où la nécessité de dresser un état des lieux pour prendre connaissance de l’existant dans chaque contexte. Mais les méthodes agiles adressent une large
typologie de projets. Et le projet idéal n’existe pas : celui où l’on commencerait tout à
zéro, avec des clients disponibles qui savent définir leurs besoins, avec des développeurs
motivés et expérimentés, avec des moyens extraordinaires pour explorer la nouvelle
démarche… n’est qu’utopie. Si l’on est convaincu de faire évoluer sa méthodologie, rien
ne vaut une première expérimentation.
Certains types de projet se prêtent moins aux approches agiles : projet d’intégration de
progiciel, projets peu exploratoires (logiciel de paie ou de comptabilité), refontes
isofonctionnelles ou projets cost cutter pour faire du « pas cher ». Mais il n’y a aucune
contre-indication !
Et ceux qui sont le mieux adaptés, c’est lorsque tout va mal, qu’on a tout essayé (voir le
projet Chrysler de Kent Beck) !
• On ne pourra jamais persuader nos clients ou notre hiérarchie.
Argumentation : prévoir un séminaire d’information et de sensibilisation d’une demijournée, avec de vrais retours d’expérience, illustrant non seulement les bénéfices mais
aussi les difficultés rencontrées, pour être plus crédible ; les parties seront interpellées,
même si elles ne sont pas totalement convaincues. Ensuite, proposer une expérimentation,
même courte, sur un projet pilote, avec des objectifs et un bilan qualitatif et quantitatif.
Utiliser les nombreux exemples d’expériences réussies dans les différents secteurs d’activités, types de projet, environnements… comme références.
• Nos utilisateurs ne sont pas disponibles sur site.
Argumentation : idéalement, l’utilisateur final est le meilleur interlocuteur. À défaut de
cet utilisateur, la solution est de choisir un représentant (un customer proxy 1 ) qui connaît
le métier, les exigences. Il est important, toutefois, que les « vrais » utilisateurs valident
le produit final et, si possible, soient présents aux réunions de planification.
1. Voir Craig Larman, Agile and iterative Development, a Manager’s Guide, Addison Wesley, 2003.
GestProjInform Livre Page 230 Vendredi, 3. avril 2009 12:07 12