Gestion de projet – Vers les méthodes agiles
206
Facteurs clés de réussite
Risques
La participation volontaire et l’implication du client dans
les décisions sont indispensables.
Une démarche agile est basée sur la livraison de valeur pour
le client, la hiérarchisation des fonctionnalités par le client et
son feedback régulier : le client est un maillon indispensable
de la chaîne. La qualité des échanges entre client et équipe de
réalisation est primordiale.
L’implication du client est insuffisante.
Il est des projets où les utilisateurs sont en trop grand nombre
pour être tous représentés, d’autres où l’entreprise est trop
petite pour permettre à ses utilisateurs une disponibilité suffisante. La culture traditionnelle induit ce mode de fonctionnement, tout comme un développement itératif avec des
itérations trop longues. Le risque doit être remonté au plus tôt,
sur un échantillon représentatif d’utilisateurs sélectionné ;
éventuellement, à défaut, trouver un membre de l’équipe de
réalisation qui « jouera » le rôle du client.
L’équipe de réalisation est stable.
La déperdition d’information et de performance lorsque les
ressources passent d’un projet à l’autre n’est plus à démontrer.
Si un projet est prioritaire, ses ressources doivent l’être également. Le noyau de l’équipe reste le même tout au long du projet.
La délocalisation des développements (au démarrage).
La dispersion géographique des équipes doit être sérieusement prise en considération. Mieux vaut commencer à adopter
les méthodes agiles dans un contexte d’équipes regroupées,
au moins durant les premiers mois de l’expérimentation, pour
développer sa « collaborativité ».
Les collaborateurs sont polyvalents.
L’idée de disposer d’équipes cross-fonctionnelles est un atout
contre la séparation des rôles et la lassitude des collaborateurs, au profit du partage de la connaissance.
Les tests ne sont pas intégrés au cycle de développement.
Comment, dans ce cas, valider la qualité, la conformité, la performance au fil de l’eau sans risquer la mauvaise surprise en
fin de projet… et sans compter la « rupture de charge » dans
la connaissance autour du projet ?
L’application est subdivisible.
Grâce à la vision et à l’architecture, l’application peut être
décomposée en modules, fonctionnels ou techniques, pour
s’adapter à la taille des équipes, au rythme du projet (itérations
courtes), et contourner la complexité en l’isolant.
On ne dispose pas d’une description générale des besoins.
Le risque est de ne pas avoir une vision globale des fonctionnalités à implémenter et de se perdre dans la compréhension
détaillée des attentes. Il est impératif de compartimenter les
besoins et de leur affecter un niveau de priorité et une fenêtre
de temps, avant de les détailler.
Deux ou trois membres de l’équipe sont expérimentés.
Même s’ils sont rôdés aux méthodes traditionnelles, et pas
expérimentés dans la méthodologie choisie, ils doivent avoir
une réelle expérience de la vie d’un projet de développement.
Leur aisance face aux risques améliorera la qualité des décisions… s’ils font preuve d’ouverture d’esprit face à la nouveauté
de la méthode !
L’adoption « big bang » de la méthode sans suppor t à la
démarche.
L’adoption d’une nouvelle méthodologie est un projet : l’adoption doit être itérative et incrémentale, l’apprentissage enrichi
des premiers retours d’expérience. On ne forme pas beaucoup
de développeurs sur une courte période ou on n’applique pas
la nouvelle méthode sur de nombreux projets durant la phase
d’apprentissage.
Le soutien de la direction générale, un budget, de l’accompagnement, des formations… et du temps sont indispensables. Sans
cela, le projet ne pourra rester que confidentiel, limité à un petit
département et particulièrement exposé au risque d’échec.
L’acceptation du changement comme opportunité.
Observer, apprendre, adapter, pour être plus performant et
davantage coller aux besoins du client, grâce au changement
qui ne sera plus perçu comme des remises en question pénalisantes.
Un planning détaillé précisant le nombre d’itérations, leur
durée, leur contenu.
C’est le réflexe ! Comment planifier suffisamment sans trop planifier ? En s’efforçant de se limiter aux deux ou trois itérations à
venir et en actualisant ses plans en fonction des constats
réels. Planifier les dates des itérations, oui, pas le contenu.
Tableau 7-2 Risques et facteurs clés de réussite (suite)
GestProjInform Livre Page 206 Vendredi, 3. avril 2009 12:07 12
206
Facteurs clés de réussite
Risques
La participation volontaire et l’implication du client dans
les décisions sont indispensables.
Une démarche agile est basée sur la livraison de valeur pour
le client, la hiérarchisation des fonctionnalités par le client et
son feedback régulier : le client est un maillon indispensable
de la chaîne. La qualité des échanges entre client et équipe de
réalisation est primordiale.
L’implication du client est insuffisante.
Il est des projets où les utilisateurs sont en trop grand nombre
pour être tous représentés, d’autres où l’entreprise est trop
petite pour permettre à ses utilisateurs une disponibilité suffisante. La culture traditionnelle induit ce mode de fonctionnement, tout comme un développement itératif avec des
itérations trop longues. Le risque doit être remonté au plus tôt,
sur un échantillon représentatif d’utilisateurs sélectionné ;
éventuellement, à défaut, trouver un membre de l’équipe de
réalisation qui « jouera » le rôle du client.
L’équipe de réalisation est stable.
La déperdition d’information et de performance lorsque les
ressources passent d’un projet à l’autre n’est plus à démontrer.
Si un projet est prioritaire, ses ressources doivent l’être également. Le noyau de l’équipe reste le même tout au long du projet.
La délocalisation des développements (au démarrage).
La dispersion géographique des équipes doit être sérieusement prise en considération. Mieux vaut commencer à adopter
les méthodes agiles dans un contexte d’équipes regroupées,
au moins durant les premiers mois de l’expérimentation, pour
développer sa « collaborativité ».
Les collaborateurs sont polyvalents.
L’idée de disposer d’équipes cross-fonctionnelles est un atout
contre la séparation des rôles et la lassitude des collaborateurs, au profit du partage de la connaissance.
Les tests ne sont pas intégrés au cycle de développement.
Comment, dans ce cas, valider la qualité, la conformité, la performance au fil de l’eau sans risquer la mauvaise surprise en
fin de projet… et sans compter la « rupture de charge » dans
la connaissance autour du projet ?
L’application est subdivisible.
Grâce à la vision et à l’architecture, l’application peut être
décomposée en modules, fonctionnels ou techniques, pour
s’adapter à la taille des équipes, au rythme du projet (itérations
courtes), et contourner la complexité en l’isolant.
On ne dispose pas d’une description générale des besoins.
Le risque est de ne pas avoir une vision globale des fonctionnalités à implémenter et de se perdre dans la compréhension
détaillée des attentes. Il est impératif de compartimenter les
besoins et de leur affecter un niveau de priorité et une fenêtre
de temps, avant de les détailler.
Deux ou trois membres de l’équipe sont expérimentés.
Même s’ils sont rôdés aux méthodes traditionnelles, et pas
expérimentés dans la méthodologie choisie, ils doivent avoir
une réelle expérience de la vie d’un projet de développement.
Leur aisance face aux risques améliorera la qualité des décisions… s’ils font preuve d’ouverture d’esprit face à la nouveauté
de la méthode !
L’adoption « big bang » de la méthode sans suppor t à la
démarche.
L’adoption d’une nouvelle méthodologie est un projet : l’adoption doit être itérative et incrémentale, l’apprentissage enrichi
des premiers retours d’expérience. On ne forme pas beaucoup
de développeurs sur une courte période ou on n’applique pas
la nouvelle méthode sur de nombreux projets durant la phase
d’apprentissage.
Le soutien de la direction générale, un budget, de l’accompagnement, des formations… et du temps sont indispensables. Sans
cela, le projet ne pourra rester que confidentiel, limité à un petit
département et particulièrement exposé au risque d’échec.
L’acceptation du changement comme opportunité.
Observer, apprendre, adapter, pour être plus performant et
davantage coller aux besoins du client, grâce au changement
qui ne sera plus perçu comme des remises en question pénalisantes.
Un planning détaillé précisant le nombre d’itérations, leur
durée, leur contenu.
C’est le réflexe ! Comment planifier suffisamment sans trop planifier ? En s’efforçant de se limiter aux deux ou trois itérations à
venir et en actualisant ses plans en fonction des constats
réels. Planifier les dates des itérations, oui, pas le contenu.
Tableau 7-2 Risques et facteurs clés de réussite (suite)
GestProjInform Livre Page 206 Vendredi, 3. avril 2009 12:07 12