Gestion de projet – Vers les méthodes agiles
212
Quel que soit le modèle de référence ou le modèle personnalisé, il est important de ne pas
négliger les aspects collaboratifs et comportementaux au travers du ressenti des membres
de l’équipe.
Quels sont les symptômes de l’échec de la démarche ?
Peut-être n’atteindrez-vous pas complètement vos objectifs ? L’échec n’est jamais total ;
certains symptômes ont un effet positif pour accroître la vigilance et mener des adaptations.
On ne fait pas systématiquement le bon choix des bonnes pratiques dès le début du projet.
L’expérience montre que l’on constate souvent les mêmes symptômes d’une mauvaise
adoption des pratiques agiles (voir tableau 7-3) :
Tableau 7-3 Symptômes et parades
Symptôme
Parade
Le client n’est pas impliqué dans le déroulement du projet. Il
n’a pas été convaincu par la méthode.
Un effort de communication doit être fourni pour le mobiliser. Si
l’enjeu du projet de développement est réel, son implication doit
être à la mesure de cet enjeu.
Les objectifs ne sont jamais atteints en fin d’itération. Il se
peut que l’équipe soit trop ambitieuse ou qu’elle ne sache pas
calculer sa vélocité.
Mener une rétrospective et analyser pour quelles raisons les
objectifs ne sont pas atteints.
Prévoir un accompagnement spécifique sur les techniques de
planification agiles.
L’équipe n’a pas assez d’autonomie. Ce manque d’autonomie
peut s’expliquer par un chef de projet trop directif ou par une
équipe qui ne veut pas prendre ses responsabilités.
Là encore, prévoir une action d’accompagnement du chef de
projet par un coach agile. Laisser davantage d’autonomie à
l’équipe, même au prix d’erreurs qu’elle analysera et corrigera
elle-même. L’équipe a droit à l’erreur pour s’améliorer.
La confiance qu’on lui accorde doit être manifeste.
Certains membres de l’équipe ne participent pas assidûment
aux réunions, notamment à la réunion quotidienne. Il se peut que
ces membres non assidus n’aient pas encore pris conscience
de l’importance du travail collaboratif et du partage d’information.
Ne les brusquez pas avec autorité en les obligeant à participer.
Lorsqu’ils auront besoin d’une information, on leur fera remarquer que ce point a été discuté lors de la réunion et que, par
conséquent il serait bon qu’ils y participent à l’avenir. Les sensibiliser, aussi, au fait que l’information qu’ils détiennent présente un intérêt général.
L’équipe ne s’entraide pas, le pair-programming ne fonctionne
pas.
Il n’est pas aisé pour tous d’interpréter l’objectif de l’itération
au niveau collectif ; tous se retranchent derrière leur réussite
individuelle.
Il existe des actions de team building pour développer la coopération au sein d’une équipe.
Mais certains peuvent ne pas du tout adhérer à la philosophie
agile et en particulier à la pratique du binômage ; dans ce cas,
ils doivent être affectés à d’autres projets afin de ne pas nuire à
l’équilibre (fragile, au début) de l’équipe.
Une partie des développements est encore testée a posteriori
en dehors de l’itération. Les équipes de test ne sont alors pas
totalement intégrées au projet. Le concept de « done », voulant qu’une fonctionnalité n’est aboutie que si elle a été testée,
validée et documentée, n’est pas appliqué.
Si l’organisation n’a pas procédé à cette restructuration, il est
effectivement difficile d’adopter une démarche agile fondée sur
le contrôle qualité et les tests au fil de l’eau.
Une action de communication doit être menée afin de convaincre la direction ; détacher au moins une personne et l’affecter
au projet pourrait être une première étape, si l’on ne veut pas
désorganiser totalement un département tests.
GestProjInform Livre Page 212 Vendredi, 3. avril 2009 12:07 12
212
Quel que soit le modèle de référence ou le modèle personnalisé, il est important de ne pas
négliger les aspects collaboratifs et comportementaux au travers du ressenti des membres
de l’équipe.
Quels sont les symptômes de l’échec de la démarche ?
Peut-être n’atteindrez-vous pas complètement vos objectifs ? L’échec n’est jamais total ;
certains symptômes ont un effet positif pour accroître la vigilance et mener des adaptations.
On ne fait pas systématiquement le bon choix des bonnes pratiques dès le début du projet.
L’expérience montre que l’on constate souvent les mêmes symptômes d’une mauvaise
adoption des pratiques agiles (voir tableau 7-3) :
Tableau 7-3 Symptômes et parades
Symptôme
Parade
Le client n’est pas impliqué dans le déroulement du projet. Il
n’a pas été convaincu par la méthode.
Un effort de communication doit être fourni pour le mobiliser. Si
l’enjeu du projet de développement est réel, son implication doit
être à la mesure de cet enjeu.
Les objectifs ne sont jamais atteints en fin d’itération. Il se
peut que l’équipe soit trop ambitieuse ou qu’elle ne sache pas
calculer sa vélocité.
Mener une rétrospective et analyser pour quelles raisons les
objectifs ne sont pas atteints.
Prévoir un accompagnement spécifique sur les techniques de
planification agiles.
L’équipe n’a pas assez d’autonomie. Ce manque d’autonomie
peut s’expliquer par un chef de projet trop directif ou par une
équipe qui ne veut pas prendre ses responsabilités.
Là encore, prévoir une action d’accompagnement du chef de
projet par un coach agile. Laisser davantage d’autonomie à
l’équipe, même au prix d’erreurs qu’elle analysera et corrigera
elle-même. L’équipe a droit à l’erreur pour s’améliorer.
La confiance qu’on lui accorde doit être manifeste.
Certains membres de l’équipe ne participent pas assidûment
aux réunions, notamment à la réunion quotidienne. Il se peut que
ces membres non assidus n’aient pas encore pris conscience
de l’importance du travail collaboratif et du partage d’information.
Ne les brusquez pas avec autorité en les obligeant à participer.
Lorsqu’ils auront besoin d’une information, on leur fera remarquer que ce point a été discuté lors de la réunion et que, par
conséquent il serait bon qu’ils y participent à l’avenir. Les sensibiliser, aussi, au fait que l’information qu’ils détiennent présente un intérêt général.
L’équipe ne s’entraide pas, le pair-programming ne fonctionne
pas.
Il n’est pas aisé pour tous d’interpréter l’objectif de l’itération
au niveau collectif ; tous se retranchent derrière leur réussite
individuelle.
Il existe des actions de team building pour développer la coopération au sein d’une équipe.
Mais certains peuvent ne pas du tout adhérer à la philosophie
agile et en particulier à la pratique du binômage ; dans ce cas,
ils doivent être affectés à d’autres projets afin de ne pas nuire à
l’équilibre (fragile, au début) de l’équipe.
Une partie des développements est encore testée a posteriori
en dehors de l’itération. Les équipes de test ne sont alors pas
totalement intégrées au projet. Le concept de « done », voulant qu’une fonctionnalité n’est aboutie que si elle a été testée,
validée et documentée, n’est pas appliqué.
Si l’organisation n’a pas procédé à cette restructuration, il est
effectivement difficile d’adopter une démarche agile fondée sur
le contrôle qualité et les tests au fil de l’eau.
Une action de communication doit être menée afin de convaincre la direction ; détacher au moins une personne et l’affecter
au projet pourrait être une première étape, si l’on ne veut pas
désorganiser totalement un département tests.
GestProjInform Livre Page 212 Vendredi, 3. avril 2009 12:07 12