Ouais. Mais : en SSII, je n'ai jamais rencontré de manager / chef d'équipe / chef d'entreprise assez éclairé ou assez courageux pour prendre sur lui d'autoriser l'équipe à travailler par prototypage. Ils préfèrent passer beaucoup de temps sur des specs abstraites et mal comprises par le client, mais qui génèrent une paperasse bien indigeste qui "prouve" qu'ils ont bien fait le boulot, et donne l'impression au client qu'il y aura beaucoup de temps à passer sur le code pour que ça fonctionne, alors que l'approche par prototype ça donne souvent ça :
"Ah, ben vous l'avez déjà presque terminé en fait, c'est bien, vous avez un peu vu gros pour le devis initial mais me voilà rassuré, vous allez nous développer ça moitié prix *wink*wink* *nudge*nudge*".
Pour que l'utilisation du prototypage fonctionne, il faut alors que les deux équipes client et développeur soient proches pour discuter du bidule fréquemment (sinon c'est difficile de prototyper correctement sans se viander en cours) et pour que le client réalise que le prototype ne peut pas être le machin final ni servir directement de squelette ou de base et réduir le temps de travail prévu (cf plus haut).
Ou alors, si ça bloque, il reste la technique de bâtard (mais elle a déjà fonctionnée) :
- on fait un prototype "dans son garage" sans en avertir le client
- on fait rapidement une spec. fonctionnelle bourrée de captures d'écran du prototype, et on dit que c'est juste une maquette
- on laisse le client faire "ouaou" à la réunion de validation, et on est quand même mieux préparé pour mettre en production
[^] # Re: Rire jaune
Posté par Bastes . En réponse au journal Linuxfr en J2EE. Évalué à 7.
"Ah, ben vous l'avez déjà presque terminé en fait, c'est bien, vous avez un peu vu gros pour le devis initial mais me voilà rassuré, vous allez nous développer ça moitié prix *wink*wink* *nudge*nudge*".
Pour que l'utilisation du prototypage fonctionne, il faut alors que les deux équipes client et développeur soient proches pour discuter du bidule fréquemment (sinon c'est difficile de prototyper correctement sans se viander en cours) et pour que le client réalise que le prototype ne peut pas être le machin final ni servir directement de squelette ou de base et réduir le temps de travail prévu (cf plus haut).
Ou alors, si ça bloque, il reste la technique de bâtard (mais elle a déjà fonctionnée) :
- on fait un prototype "dans son garage" sans en avertir le client
- on fait rapidement une spec. fonctionnelle bourrée de captures d'écran du prototype, et on dit que c'est juste une maquette
- on laisse le client faire "ouaou" à la réunion de validation, et on est quand même mieux préparé pour mettre en production