Gestion de projet – Vers les méthodes agiles
92
Une fois recueillis, les besoins sont formalisés. Il existe, là encore, différentes techniques, des plus classiques aux plus légères, le degré de formalisme variant avec la taille du
projet ou des équipes, de leur proximité géographique ou de la méthodologie retenue.
Finalement, nos clients pourront ainsi modifier en permanence leurs besoins et faire évoluer
le périmètre du projet ! (suite)
Leurs retours sont traduits sous forme de nouvelles user stories, dont les tailles et les priorités
seront mesurées relativement aux autres. Notre client peut donc faire évoluer le périmètre de
son projet, mais doit alors accepter de réorganiser ses plans en repor tant d’autres fonctionnalités.
2) La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
L’approche est conçue pour mieux s’adapter aux changements en cours de projet, par exemple
lorsque le contexte business du projet oblige le client à changer les priorités, ou bien lorsque le
client revoit ses demandes après que les premières versions du produit lui ont donné de
nouvelles idées sur l’approche fonctionnelle à adopter.
En revanche, il ne faut pas croire que cette flexibilité est un prétexte au laisser-aller. Deux incompréhensions fréquentes méritent en effet d’être dissipées :
– Modifier les besoins ne veut pas dire avancer systématiquement par essai/erreur. On revient
sur des fonctionnalités implémentées, mais dans la grande majorité des cas il s’agit de les
enrichir ou les ajuster légèrement, et non pas de faire de grands retours en arrière parce qu’on
s’est lancé dans le développement sans aucune réflexion sur le fonctionnel. Les erreurs ou
tâtonnements sont parfois inévitables, mais il m’est aussi arrivé assez souvent d’avoir à
repousser l’implémentation de fonctionnalités parce qu’il semblait que la définition de la solution n’était pas suffisamment claire, ou bien parce que les différents représentants côté
maîtrise d’ouvrage n’étaient pas encore d’accord sur la solution choisie.
– Modifier les besoins ne veut pas dire fonctionner à budget variable. Dans une logique XP, on
considère que l’enveloppe finale est fixe, puis on vise à en faire le maximum dans le cadre de
cette enveloppe via un effort de priorisation très fin.
Comment organiser les rôles autour du recueil des besoins ?
À chaque besoin sont associés différents contributeurs et niveaux de responsabilité : celui qui
décrit le besoin, celui qui valide le besoin décrit, celui qui éventuellement contribue à la
description du besoin et enfin celui qui doit être informé d’un besoin. On peut ainsi établir une
matrice de responsabilités, qu’on appelle matrice RACI. La signification de cet acronyme est la
suivante :
– R pour Responsable de la description du besoin ;
– A pour Approbateur, de qui R doit obtenir une approbation pour valider la description du
besoin ;
– C pour Contributeur à qui R peut demander une contribution pour finaliser la description d’un
besoin ;
– I pour Informé de l’existence d’un besoin ou de la description finale d’un besoin..
GestProjInform Livre Page 92 Vendredi, 3. avril 2009 12:07 12
92
Une fois recueillis, les besoins sont formalisés. Il existe, là encore, différentes techniques, des plus classiques aux plus légères, le degré de formalisme variant avec la taille du
projet ou des équipes, de leur proximité géographique ou de la méthodologie retenue.
Finalement, nos clients pourront ainsi modifier en permanence leurs besoins et faire évoluer
le périmètre du projet ! (suite)
Leurs retours sont traduits sous forme de nouvelles user stories, dont les tailles et les priorités
seront mesurées relativement aux autres. Notre client peut donc faire évoluer le périmètre de
son projet, mais doit alors accepter de réorganiser ses plans en repor tant d’autres fonctionnalités.
2) La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
L’approche est conçue pour mieux s’adapter aux changements en cours de projet, par exemple
lorsque le contexte business du projet oblige le client à changer les priorités, ou bien lorsque le
client revoit ses demandes après que les premières versions du produit lui ont donné de
nouvelles idées sur l’approche fonctionnelle à adopter.
En revanche, il ne faut pas croire que cette flexibilité est un prétexte au laisser-aller. Deux incompréhensions fréquentes méritent en effet d’être dissipées :
– Modifier les besoins ne veut pas dire avancer systématiquement par essai/erreur. On revient
sur des fonctionnalités implémentées, mais dans la grande majorité des cas il s’agit de les
enrichir ou les ajuster légèrement, et non pas de faire de grands retours en arrière parce qu’on
s’est lancé dans le développement sans aucune réflexion sur le fonctionnel. Les erreurs ou
tâtonnements sont parfois inévitables, mais il m’est aussi arrivé assez souvent d’avoir à
repousser l’implémentation de fonctionnalités parce qu’il semblait que la définition de la solution n’était pas suffisamment claire, ou bien parce que les différents représentants côté
maîtrise d’ouvrage n’étaient pas encore d’accord sur la solution choisie.
– Modifier les besoins ne veut pas dire fonctionner à budget variable. Dans une logique XP, on
considère que l’enveloppe finale est fixe, puis on vise à en faire le maximum dans le cadre de
cette enveloppe via un effort de priorisation très fin.
Comment organiser les rôles autour du recueil des besoins ?
À chaque besoin sont associés différents contributeurs et niveaux de responsabilité : celui qui
décrit le besoin, celui qui valide le besoin décrit, celui qui éventuellement contribue à la
description du besoin et enfin celui qui doit être informé d’un besoin. On peut ainsi établir une
matrice de responsabilités, qu’on appelle matrice RACI. La signification de cet acronyme est la
suivante :
– R pour Responsable de la description du besoin ;
– A pour Approbateur, de qui R doit obtenir une approbation pour valider la description du
besoin ;
– C pour Contributeur à qui R peut demander une contribution pour finaliser la description d’un
besoin ;
– I pour Informé de l’existence d’un besoin ou de la description finale d’un besoin..
GestProjInform Livre Page 92 Vendredi, 3. avril 2009 12:07 12