Suivre et piloter son projet
CHAPITRE 5
171
comme tels. À la différence d’une approche classique, l’ensemble de l’équipe détermine,
beaucoup plus fréquemment, les actions à mener pour réduire les menaces. Le suivi des
risques est intégré dans l’agenda des réunions de bilan de fin d’itération ; la liste est alors
actualisée, et les modifications qui en résultent sont prises en compte dans la planification
de l’itération suivante.
Si, comme Thierry Cros 1 , on considère que la cause principale des facteurs de risques est
l’absence de communication entre les acteurs du projet, on comprend aisément l’intérêt
d’une gestion « agile » des risques : tests automatisés systématiques, démonstrations au
client et feedbacks permanents, différents niveaux de planification avec participation de
l’ensemble de l’équipe aux différentes réunions…
Et la documentation dans tout ça ?
L’une des quatre valeurs du Manifeste agile préconise de privilégier la livraison de fonctionnalités opérationnelles par rapport à la documentation trop volumineuse.
En la matière, la première question est de savoir pour quelles raisons on veut produire des
documents. Est-ce pour satisfaire un processus ? Ou bien est-ce parce que l’on ressent un
besoin d’illustration ou de formalisation ?
La seconde question, c’est de savoir si l’on veut rédiger de la documentation en amont,
pour préparer les travaux, ou a posteriori pour enregistrer et capitaliser.
Simple ! Il faut faire simple, être pragmatique, et surtout ne pas allonger les délais pour
la production de documents ; ceux-ci peuvent se révéler utiles pour l’utilisateur, pour
l’exploitation, pour la maintenance ; mais la batterie de tests qui sont exécutés chaque
jour constitue une large part de la documentation du produit.
1. Thierry Cros, Être agile face aux risques, http://agile.thierrycros.net, mars 2006.
Comment s’intègrent les rédacteurs techniques dans le cycle de vie et l’organisation de
l’équipe ?
La réponse de l’expert Dominic Williams, coach XP.
Ma meilleure expérience dans ce domaine a consisté à intégrer un rédacteur technique (et une
femme ingénieur qualité) dans l’équipe au titre de « Clients XP » (représentants du chef de
produit). Leur expérience respective leur donnait d’excellentes connaissances métier et
surtout un point de vue très proche des utilisateurs. Leurs compétences informatiques leur ont
rapidement permis de définir eux-mêmes une grande partie des tests fonctionnels automatisés. Non seulement la documentation et les tests étaient toujours parfaitement à jour des
développements, mais ces personnes étaient beaucoup plus valorisées et motivées qu’avant.
Il faut en tout cas éviter que la rédaction technique diminue la fréquence des livraisons ou
augmente le temps qui s’écoule entre la planification d’une fonctionnalité et sa livraison aux
utilisateurs.
Au minimum, il faut que les rédacteurs techniques soient à proximité des développeurs et
travaillent en phase avec les développements : ils rédigent la documentation relative aux développements en cours. Ainsi, ils profitent de toutes les discussions, et eux-mêmes au travers des
questions ou précisions qu’ils demanderont, contribueront à la réflexion du reste de l’équipe.
GestProjInform Livre Page 171 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 5
171
comme tels. À la différence d’une approche classique, l’ensemble de l’équipe détermine,
beaucoup plus fréquemment, les actions à mener pour réduire les menaces. Le suivi des
risques est intégré dans l’agenda des réunions de bilan de fin d’itération ; la liste est alors
actualisée, et les modifications qui en résultent sont prises en compte dans la planification
de l’itération suivante.
Si, comme Thierry Cros 1 , on considère que la cause principale des facteurs de risques est
l’absence de communication entre les acteurs du projet, on comprend aisément l’intérêt
d’une gestion « agile » des risques : tests automatisés systématiques, démonstrations au
client et feedbacks permanents, différents niveaux de planification avec participation de
l’ensemble de l’équipe aux différentes réunions…
Et la documentation dans tout ça ?
L’une des quatre valeurs du Manifeste agile préconise de privilégier la livraison de fonctionnalités opérationnelles par rapport à la documentation trop volumineuse.
En la matière, la première question est de savoir pour quelles raisons on veut produire des
documents. Est-ce pour satisfaire un processus ? Ou bien est-ce parce que l’on ressent un
besoin d’illustration ou de formalisation ?
La seconde question, c’est de savoir si l’on veut rédiger de la documentation en amont,
pour préparer les travaux, ou a posteriori pour enregistrer et capitaliser.
Simple ! Il faut faire simple, être pragmatique, et surtout ne pas allonger les délais pour
la production de documents ; ceux-ci peuvent se révéler utiles pour l’utilisateur, pour
l’exploitation, pour la maintenance ; mais la batterie de tests qui sont exécutés chaque
jour constitue une large part de la documentation du produit.
1. Thierry Cros, Être agile face aux risques, http://agile.thierrycros.net, mars 2006.
Comment s’intègrent les rédacteurs techniques dans le cycle de vie et l’organisation de
l’équipe ?
La réponse de l’expert Dominic Williams, coach XP.
Ma meilleure expérience dans ce domaine a consisté à intégrer un rédacteur technique (et une
femme ingénieur qualité) dans l’équipe au titre de « Clients XP » (représentants du chef de
produit). Leur expérience respective leur donnait d’excellentes connaissances métier et
surtout un point de vue très proche des utilisateurs. Leurs compétences informatiques leur ont
rapidement permis de définir eux-mêmes une grande partie des tests fonctionnels automatisés. Non seulement la documentation et les tests étaient toujours parfaitement à jour des
développements, mais ces personnes étaient beaucoup plus valorisées et motivées qu’avant.
Il faut en tout cas éviter que la rédaction technique diminue la fréquence des livraisons ou
augmente le temps qui s’écoule entre la planification d’une fonctionnalité et sa livraison aux
utilisateurs.
Au minimum, il faut que les rédacteurs techniques soient à proximité des développeurs et
travaillent en phase avec les développements : ils rédigent la documentation relative aux développements en cours. Ainsi, ils profitent de toutes les discussions, et eux-mêmes au travers des
questions ou précisions qu’ils demanderont, contribueront à la réflexion du reste de l’équipe.
GestProjInform Livre Page 171 Vendredi, 3. avril 2009 12:07 12