Gestion de projet – Vers les méthodes agiles
164
En complément des tests, des actions doivent être planifiées pour contrôler la qualité du
produit et la qualité du processus : ce seront des revues ou des audits, dans le but de
détecter des écarts par rapport à un standard ou un objectif défini au départ.
Une revue, menée à la fin d’une itération ou d’une phase, vise à vérifier que les objectifs
fixés en début de période sont atteints, respectant la cohérence d’ensemble du produit ;
on vérifie également la conformité aux standards et aux normes retenus.
L’audit est l’examen du produit ou d’un processus, généralement confié à une entité indépendante, en vue de vérifier sa conformité avec l’objectif recherché ou d’analyser les
causes d’un dysfonctionnement.
On pourra organiser une revue de code, relecture croisée du code par les développeurs
eux-mêmes, ou un audit de la sécurité de l’application, par exemple.
Suivre les risques
Quelles sont les activités autour de la gestion des risques ?
• Recenser et caractériser les risques : cette activité doit être menée collectivement et de
façon itérative, car la liste des risques n’est pas définitive au cours du projet : certains
risques peuvent apparaître, d’autres disparaître.
• Analyser et valoriser les risques : il s’agit de qualifier et hiérarchiser les risques en
fonction de leur probabilité d’occurrence et de leur impact sur les projets s’ils se
concrétisent ; on établit ainsi une liste hiérarchisée selon la criticité de chaque risque :
la criticité est fonction de la probabilité d’occurrence et de la gravité du risque. Une
fois analysés, les effets de chacun de ces risques sur le budget (dépassement), sur le
délai (retard), sur le niveau de qualité (dysfonctionnement ou taux élevé d’anomalies)
ou sur le périmètre (exigence non satisfaite) doivent être évalués.
• Formaliser les risques : une liste de risques est dressée à partir d’une fiche individuelle
élaborée pour chaque risque rappelant tous les éléments des étapes d’identification et
d’analyse.
Y a-t-il un rôle dédié à la qualité dans une équipe agile ?
La réponse de l’expert Jean Tabaka, coach et agile mentor chez Rally Software Development.
Le développement logiciel agile tire certaines de ses pratiques des valeurs du lean thinking.
Tant la recherche de création de valeur qu’un engagement vers l’innovation et la perfection
reposent fortement sur un rôle dédié à la qualité.
Les équipes agiles s’appuient sur un « tabouret à trois pieds » pour définir la qualité et la recette
dans chaque itération. Le développeur, le client et le testeur déterminent, en tant qu’équipe de trois,
quels sont les critères d’acceptation pour chaque item réalisé dans l’itération. Le rôle du testeur est
très important dans cette conversation ; cet échange orienté vers les tests peut faire apparaître
la complexité du travail de développement. Un testeur peut aussi guider le client vers ce qui est
réellement utile pour définir de vrais critères d’acceptation. Enfin, le testeur peut aider à découvrir des hypothèses sous-jacentes aux spécifications.
GestProjInform Livre Page 164 Vendredi, 3. avril 2009 12:07 12
164
En complément des tests, des actions doivent être planifiées pour contrôler la qualité du
produit et la qualité du processus : ce seront des revues ou des audits, dans le but de
détecter des écarts par rapport à un standard ou un objectif défini au départ.
Une revue, menée à la fin d’une itération ou d’une phase, vise à vérifier que les objectifs
fixés en début de période sont atteints, respectant la cohérence d’ensemble du produit ;
on vérifie également la conformité aux standards et aux normes retenus.
L’audit est l’examen du produit ou d’un processus, généralement confié à une entité indépendante, en vue de vérifier sa conformité avec l’objectif recherché ou d’analyser les
causes d’un dysfonctionnement.
On pourra organiser une revue de code, relecture croisée du code par les développeurs
eux-mêmes, ou un audit de la sécurité de l’application, par exemple.
Suivre les risques
Quelles sont les activités autour de la gestion des risques ?
• Recenser et caractériser les risques : cette activité doit être menée collectivement et de
façon itérative, car la liste des risques n’est pas définitive au cours du projet : certains
risques peuvent apparaître, d’autres disparaître.
• Analyser et valoriser les risques : il s’agit de qualifier et hiérarchiser les risques en
fonction de leur probabilité d’occurrence et de leur impact sur les projets s’ils se
concrétisent ; on établit ainsi une liste hiérarchisée selon la criticité de chaque risque :
la criticité est fonction de la probabilité d’occurrence et de la gravité du risque. Une
fois analysés, les effets de chacun de ces risques sur le budget (dépassement), sur le
délai (retard), sur le niveau de qualité (dysfonctionnement ou taux élevé d’anomalies)
ou sur le périmètre (exigence non satisfaite) doivent être évalués.
• Formaliser les risques : une liste de risques est dressée à partir d’une fiche individuelle
élaborée pour chaque risque rappelant tous les éléments des étapes d’identification et
d’analyse.
Y a-t-il un rôle dédié à la qualité dans une équipe agile ?
La réponse de l’expert Jean Tabaka, coach et agile mentor chez Rally Software Development.
Le développement logiciel agile tire certaines de ses pratiques des valeurs du lean thinking.
Tant la recherche de création de valeur qu’un engagement vers l’innovation et la perfection
reposent fortement sur un rôle dédié à la qualité.
Les équipes agiles s’appuient sur un « tabouret à trois pieds » pour définir la qualité et la recette
dans chaque itération. Le développeur, le client et le testeur déterminent, en tant qu’équipe de trois,
quels sont les critères d’acceptation pour chaque item réalisé dans l’itération. Le rôle du testeur est
très important dans cette conversation ; cet échange orienté vers les tests peut faire apparaître
la complexité du travail de développement. Un testeur peut aussi guider le client vers ce qui est
réellement utile pour définir de vrais critères d’acceptation. Enfin, le testeur peut aider à découvrir des hypothèses sous-jacentes aux spécifications.
GestProjInform Livre Page 164 Vendredi, 3. avril 2009 12:07 12