Prévenir le syndrôme du client qui en veut toujours plus

27 06 2007

Olivier Azeau, alias l’Agilitateur, fait un parallèle sur son blog entre la quantité d’exigences croissante de la part d’un client le long du projet et la prolifération de cellules cancéreuses pendant un traitement radiothérapique. Si ce parallèle est assez déroutant au premier abord, la conclusion est intéressante : la durée d’un sprint et sa vélocité (à comparer à l’espacement des séances et la puissance du traitement) sont déterminants pour empêcher la prolifération de fonctionnalités du client (ou des cellules cancéreuses). Vélocité trop faible/trop de user stories à réaliser en un sprint, et la prolifération n’est pas amortie. Vélocité trop forte, et la qualité (ou la santé du patient) est détériorée.

L’approche du monde IHM consiste à faire participer le client à la conception du logiciel (plus particulièrement les interactions et fonctionnalités qui en découlent). La phase de conception commence par un brainstorming de génération d’idées en quantité, puis on réalise des prototypes basse fidélité (papier en général) testables et facilement modifiables, tout ça avec les utilisateurs. C’est aussi une façon de réduire cet effet puisque le client “teste” son produit au moment même de la conception, et évite ainsi de passer par 4 chemins pour arriver à la solution la plus satisfaisante. Seulement en IHM, on fait du Big Design UpFront… D’où mon intérêt pour le rapprochement des deux mondes…


Actions

Informations

Une réponse à “Prévenir le syndrôme du client qui en veut toujours plus”

8 08 2008
lapinferoce (11:25:24) :

c’est effectivement une dure réalité, de mon experience, c’est un grand risque avec les méthodes agile. Le client qui en veut toujours plus, est relativement difficile à gérer et peu rapidement devenir une source de blocage.

J’ai récemment expérimenté sur un projet dont j’ai la charge, un cas relativement similaire : un patron jamais satisfaits dans mon cas qui demandait toujours plus et plus en me court-circuitant la plupart du temps. Le résultat a faillie être catastrophique…

J’ai également expérimenté sur un autre projet dans un autre contexte une approche par IHM, ca a plutôt bien fonctionner même si il a été difficile d’expliquer au client que ce n’est pas parce que l’on a l’IHM que le projet est fini (code fonctionnel dans le cadre d’un développement logiciel)

Laisser un commentaire

Vous devez être connecté pour poster un commentaire




Parse error: syntax error, unexpected '/' in /mnt/106/sda/6/e/prog13/wp-content/themes/freshy/footer.php on line 18