Gestion de projet – Vers les méthodes agiles
90
Enfin, lorsqu’on aborde l’étape de description détaillée, il est essentiel d’observer les
pratiques existantes pour mieux « coller » au besoin.
• L’analyse de l’existant : il s’agit, ici, d’examiner les applications existantes pour en
évaluer les forces et les faiblesses, et de mettre au point la stratégie d’évolution : doiton réutiliser certaines fonctions ? Dans quelle proportion doit-on remplacer des fonctions existantes ? Comment les améliorer ? On parle souvent de gap analysis.
• L’observation du comportement de l’utilisateur « en situation » : souvent utilisée
par les ergonomes, cette technique est efficace pour bien comprendre le comportement des utilisateurs sur leur poste de travail ou autour du poste de travail. En notant
toutes les astuces qu’un utilisateur trouve pour compenser les manques d’une application (Post-it, carnets, notes…), on prend la mesure de ses limites et de ses failles
qu’il faudra combler. On peut apprécier l’application rigoureuse de telle procédure ou,
au contraire, comprendre pourquoi elle est partiellement appliquée voire totalement
contournée.
Le questionnaire est une autre technique encore utilisée mais dont on a peut-être un peu
abusé à une certaine époque, notamment lorsqu’on sondait la satisfaction des utilisateurs
pour faire évoluer une application. Il permet de recueillir rapidement les avis de plusieurs
personnes sur un certain nombre de points. Combinant questions fermées, ciblées, et
questions ouvertes, le questionnaire doit envisager toutes les alternatives et ne pas induire
les réponses. Anonyme ou non, il reste cependant restrictif, même avec des questions
ouvertes.
Dans une approche agile, l’équipe de réalisation privilégie le contact direct, en face à
face, avec le client ou les utilisateurs, qui expriment eux-mêmes leurs besoins. Le temps
non consommé à la longue description des besoins est utilement consacré au dialogue, à
la levée des ambiguïtés, à la rédaction des scénarios de tests, au développement et à la
validation avec le client. Les longues descriptions sont aussi volontiers troquées contre
des exemples, repris pour les scénarios de tests. Une autre façon de dire : le temps économisé est consacré à l’élaboration des tests qui deviennent des livrables complémentaires
des spécifications ; on parle de tests driven requirements. Le recueil des besoins n’est
plus une étape formelle limitée dans le temps au début du projet, mais fait partie intégrante du processus de réalisation.
Attention !
En outre, à la charge liée au traitement des réponses, surtout si l’on veut atteindre un échantillon représentatif des utilisateurs !
GestProjInform Livre Page 90 Vendredi, 3. avril 2009 12:07 12
90
Enfin, lorsqu’on aborde l’étape de description détaillée, il est essentiel d’observer les
pratiques existantes pour mieux « coller » au besoin.
• L’analyse de l’existant : il s’agit, ici, d’examiner les applications existantes pour en
évaluer les forces et les faiblesses, et de mettre au point la stratégie d’évolution : doiton réutiliser certaines fonctions ? Dans quelle proportion doit-on remplacer des fonctions existantes ? Comment les améliorer ? On parle souvent de gap analysis.
• L’observation du comportement de l’utilisateur « en situation » : souvent utilisée
par les ergonomes, cette technique est efficace pour bien comprendre le comportement des utilisateurs sur leur poste de travail ou autour du poste de travail. En notant
toutes les astuces qu’un utilisateur trouve pour compenser les manques d’une application (Post-it, carnets, notes…), on prend la mesure de ses limites et de ses failles
qu’il faudra combler. On peut apprécier l’application rigoureuse de telle procédure ou,
au contraire, comprendre pourquoi elle est partiellement appliquée voire totalement
contournée.
Le questionnaire est une autre technique encore utilisée mais dont on a peut-être un peu
abusé à une certaine époque, notamment lorsqu’on sondait la satisfaction des utilisateurs
pour faire évoluer une application. Il permet de recueillir rapidement les avis de plusieurs
personnes sur un certain nombre de points. Combinant questions fermées, ciblées, et
questions ouvertes, le questionnaire doit envisager toutes les alternatives et ne pas induire
les réponses. Anonyme ou non, il reste cependant restrictif, même avec des questions
ouvertes.
Dans une approche agile, l’équipe de réalisation privilégie le contact direct, en face à
face, avec le client ou les utilisateurs, qui expriment eux-mêmes leurs besoins. Le temps
non consommé à la longue description des besoins est utilement consacré au dialogue, à
la levée des ambiguïtés, à la rédaction des scénarios de tests, au développement et à la
validation avec le client. Les longues descriptions sont aussi volontiers troquées contre
des exemples, repris pour les scénarios de tests. Une autre façon de dire : le temps économisé est consacré à l’élaboration des tests qui deviennent des livrables complémentaires
des spécifications ; on parle de tests driven requirements. Le recueil des besoins n’est
plus une étape formelle limitée dans le temps au début du projet, mais fait partie intégrante du processus de réalisation.
Attention !
En outre, à la charge liée au traitement des réponses, surtout si l’on veut atteindre un échantillon représentatif des utilisateurs !
GestProjInform Livre Page 90 Vendredi, 3. avril 2009 12:07 12