Recueillir efficacement les besoins
CHAPITRE 3
91
Est-il plus utile de consacrer du temps à détailler précisément les besoins ou à élaborer des
cas de test ?
La réponse de l’expert Christophe Addinquy, directeur de projets back-office chez Vidal.
La poursuite effrénée du bon niveau de détail garantissant la précision ou la clarté du besoin
pour le transmettre à des équipes de développement nous amène souvent à la surspécification
et à la « paralysie de l’analyse ».
En réalité, on a souvent constaté que les spécifications les plus claires, que ce soit pour les
utilisateurs ou pour les équipes de développement, sont celles qui intègrent des exemples.
Parce que ces derniers clarifient une expression parfois abstraite et permettent de vérifier la
bonne compréhension et la bonne cohérence du besoin exprimé.
Le procédé de tests driven requirement n’est finalement que l’étape supplémentaire faisant
des exemples utilisés au sein de l’expression des besoins un élément essentiel de la spécification : ces exemples deviennent des cas de tests pour vérifier la conformité de la réalisation par
rapport au besoin ; ils permettent également de contrôler tous les cas limite.
Cette approche induit un mode de travail et de dialogue différent par rapport à l’expression de
besoins classiques : tout d’abord, entre l’équipe et l’utilisateur, on dialogue moins sur la base
de la signification des phrases, mais davantage sur la base du résultat attendu et visible. Le
cas de test devient la mesure de la clarté et de l’exhaustivité du besoin. Par ailleurs, par
rapport aux équipes de réalisation, les développeurs ne pensent plus en termes d’interprétation mais en termes de conformité de leurs développements par rapport au résultat ; si de
nouveaux cas de figure apparaissent, non prévus initialement dans la spécification, ils savent
se retourner vers les utilisateurs pour obtenir de nouveaux cas de test.
Finalement, nos clients pourront ainsi modifier en permanence leurs besoins et faire évoluer
le périmètre du projet !
1) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
La sécurité apparente d’un contrat détaillant le périmètre fonctionnel précis avant le démarrage
du projet ne tient pas compte de plusieurs facteurs liés au temps. Dans nos projets, nous
avons observé deux types de causes à l’apparition de nouveaux besoins ou au changement
des priorités :
– un changement dans l’environnement du client (économique, concurrentiel ou stratégique) ;
– les réflexions et commentaires d’utilisateurs, alimentés par l’utilisation (ou au moins la vue)
du produit en cours de développement.
Pourquoi ne pas en tenir compte?
La qualité et la régularité des contacts avec le client sont des éléments essentiels pour réactualiser la vision du produit à réaliser et éviter tout investissement déraisonnable sur une mauvaise
voie. La pratique des livraisons fréquentes offre l’opportunité de profiter des retours d’utilisateurs
qui expriment leurs besoins avec plus d’acuité. Sur notre projet actuel, nous proposons une
nouvelle version livrable toutes les deux semaines à des « utilisateurs de référence », qui peuvent
occasionnellement refuser les lots et nous aident à répondre à des préoccupations du terrain.
☞
GestProjInform Livre Page 91 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
91
Est-il plus utile de consacrer du temps à détailler précisément les besoins ou à élaborer des
cas de test ?
La réponse de l’expert Christophe Addinquy, directeur de projets back-office chez Vidal.
La poursuite effrénée du bon niveau de détail garantissant la précision ou la clarté du besoin
pour le transmettre à des équipes de développement nous amène souvent à la surspécification
et à la « paralysie de l’analyse ».
En réalité, on a souvent constaté que les spécifications les plus claires, que ce soit pour les
utilisateurs ou pour les équipes de développement, sont celles qui intègrent des exemples.
Parce que ces derniers clarifient une expression parfois abstraite et permettent de vérifier la
bonne compréhension et la bonne cohérence du besoin exprimé.
Le procédé de tests driven requirement n’est finalement que l’étape supplémentaire faisant
des exemples utilisés au sein de l’expression des besoins un élément essentiel de la spécification : ces exemples deviennent des cas de tests pour vérifier la conformité de la réalisation par
rapport au besoin ; ils permettent également de contrôler tous les cas limite.
Cette approche induit un mode de travail et de dialogue différent par rapport à l’expression de
besoins classiques : tout d’abord, entre l’équipe et l’utilisateur, on dialogue moins sur la base
de la signification des phrases, mais davantage sur la base du résultat attendu et visible. Le
cas de test devient la mesure de la clarté et de l’exhaustivité du besoin. Par ailleurs, par
rapport aux équipes de réalisation, les développeurs ne pensent plus en termes d’interprétation mais en termes de conformité de leurs développements par rapport au résultat ; si de
nouveaux cas de figure apparaissent, non prévus initialement dans la spécification, ils savent
se retourner vers les utilisateurs pour obtenir de nouveaux cas de test.
Finalement, nos clients pourront ainsi modifier en permanence leurs besoins et faire évoluer
le périmètre du projet !
1) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
La sécurité apparente d’un contrat détaillant le périmètre fonctionnel précis avant le démarrage
du projet ne tient pas compte de plusieurs facteurs liés au temps. Dans nos projets, nous
avons observé deux types de causes à l’apparition de nouveaux besoins ou au changement
des priorités :
– un changement dans l’environnement du client (économique, concurrentiel ou stratégique) ;
– les réflexions et commentaires d’utilisateurs, alimentés par l’utilisation (ou au moins la vue)
du produit en cours de développement.
Pourquoi ne pas en tenir compte?
La qualité et la régularité des contacts avec le client sont des éléments essentiels pour réactualiser la vision du produit à réaliser et éviter tout investissement déraisonnable sur une mauvaise
voie. La pratique des livraisons fréquentes offre l’opportunité de profiter des retours d’utilisateurs
qui expriment leurs besoins avec plus d’acuité. Sur notre projet actuel, nous proposons une
nouvelle version livrable toutes les deux semaines à des « utilisateurs de référence », qui peuvent
occasionnellement refuser les lots et nous aident à répondre à des préoccupations du terrain.
☞
GestProjInform Livre Page 91 Vendredi, 3. avril 2009 12:07 12