Discussion :

[jmguiche]

Non, quand il s'agit de demande d'évolutions, celles-ci sont chiffrées et ajoutées au coût du projet. Ce sont les anomalies qui sont à la charge de la SSII. Évidemment, les commerciaux s'arrangent avec le client (faudrait pas le braquer non plus) et intègrent au projet une certaine partie des évolutions si leur coût est raisonnable par rapport à l'ensemble du projet.

Dans le cadre d'une régie, ces questions ne se posent pas...

Ca, c'est dans le meilleurs des monde. mais nous vivons quand même dans un monde ou des trucs comme la régie forfaitisée existe ! Alors, les cahiers des charges qui bougent...

D'autre part, il ne faut pas que se situer dans un rapport "contractuel" ssii<> client.

Nous sommes en général dans un rapport à 3 :
- la MOA (la partie visible du client)
- La MOE (l'équipe de dev)
- Celui qui tient les cordons de la bourse... (partie invisible du client)

Une bonne partie des couleuvres qu'avalent les équipes de dev sont en général due à une MOA qui n'a pas trop envie de dire "ca va couter le double parce que je n'ai pas pensé à la moitié des problèmes" à celui qui tient les cordons de la bourse...

[el_slapper]

(.../...)
Une bonne partie des couleuvres qu'avalent les équipes de dev sont en général due à une MOA qui n'a pas trop envie de dire "ca va couter le double parce que je n'ai pas pensé à la moitié des problèmes" à celui qui tient les cordons de la bourse...

Vu pas mal de fois. J'ai même vu une MOA qui refusait de corriger une spec fausse parceque la spec fausse avait été tamponnée et validée, par peur de déplaire aux grands chefs. Résultat : 18 mois de travail à 60 à la poubelle. Soit c'était conforme, mais ça ne parchait pas, soit ça marchait, mais ça n'était pas conforme. Alors que la spec était vraiment pas mal, et qu'il ne manquait pas grand chose pour qu'elle marche.....

[OWickerman]

C'est quand même rare que le commercial valide une évolution sans en faire part au préalable à l'équipe technique (enfin, j'imagine qu'il doit bien y en avoir qui le font... ).
Dans le cadre d'un forfait, tout dépassement est la charge de la SSII. Accepter de prendre en charge des évolutions sans les chiffrer, c'est aller droit dans le mur.

Vu et revu en SSII, le boss faisait quelques fois office de commercial et ne savait pas dire non. Les clients l'avaient compris et abusaient de lui. J'ai du, plusieurs fois, remettre des clients à leur place alors qu'ils demandaient des "petites" fonctionnalités qui auraient demandé de tout redévelopper. Bon, j'ai quitté cette boite

[olsimare]

Bonjour.

Pour ma part, je trouve l'analyse initiale par trop simpliste.

On ne code pas à partir du besoin, on commence d'abord par l'analyser !

Est-il si loin le temps ou avant toute chose, on réalisait un analyse fonctionnelle pour mettre en évidence les concepts et les invariants métiers qui permettaient au moins de batir sur un socle stable ?

D'autre part, pour qu'un périmétre soit stable, il faut limiter au plus le nombre d'interlocuteurs susceptibles de le modifier... cela pose la question de qui est responsable de quoi, et c'est là où tout ce complique !

Cdt

[pseudocode]

Est-il si loin le temps ou avant toute chose, on réalisait un analyse fonctionnelle pour mettre en évidence les concepts et les invariants métiers qui permettaient au moins de batir sur un socle stable ?Cdt

Depuis l'apparition des environnements RAD/WYSIWYG, cette pratique semble s'être un peu perdue en effet. En particulier pour les applications possédant une interface graphique.

[souviron34]

A la question posée je suis entièrement d'accord avec :

A la question posée je dirais qu'il faut juste coder proprement en prévision des futures modifications, de manière à ce que la reprise du code soit la moins fastidieuse possible.

Maintenant, dans le débat qui suit, je note que le principal problème est (comme ila toujours été) la gestion de projet (et des hommes) :

On en revient toujours au même : le problème, ce n'est pas la méthode, c'est la manière de gérer l'équipe.

D'autre part, pour qu'un périmétre soit stable, il faut limiter au plus le nombre d'interlocuteurs susceptibles de le modifier... cela pose la question de qui est responsable de quoi, et c'est là où tout ce complique !

Le second facteur est la méthologie employée :

Dans une méthode de travail stricte toutes les évolutions sont refusées sous prétexte qu'elles n'étaient pas prévues dans les specs, même si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une méthode Agile, cette question et cette réponse n'a plus lieu d'être (bien entendu si l'évolution reste dans le périmètre du projet initial).

La méthode Agile selon moi ne sert qu'à ça, cela ne change pas la façon d'architecturer et de développer le projet. La méthode Agile ne doit pas converger vers la méthode à l'arrache.

Par contre, la mode des méthodes dites "agiles" accentuent peut être le phénomène. Beaucoup considèrent qu'une vue d'ensemble n'est pas utile : on fonce dans le développement à partir d'un besoin exprimé en 20 lignes dans un mail.
Je pense que c'est une erreur, une très mauvaise mise en oeuvre de ces approches qui necessitent, au contraire, une maitrise d'ouvrage à l'esprit clair, structuré, avec une immense capacité d'abstraction et d'anticipation.

Depuis l'apparition des environnements RAD/WYSIWYG, cette pratique semble s'être un peu perdue en effet. En particulier pour les applications possédant une interface graphique.

Oui mais aujourd'hui, c'est normal. On fait de l'Agile, on favorise la communication orale afin que les équipes communiquent plus vite, et le code parle de lui même. Alors la doc...

Et le troisième problème (qui a aussi toujours existé) est la séparation bien trop grande entre "industrie informatique" et "clients", exprimée très bien par :

D'après mon expérience, de presque 30 ans, il y a deux types de "clients".

Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.

Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...

Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.

Je pense effectivement (et je l'ai dit de très nombreuses fois dans les débats concernés) que les méthologies (et leurs modes), qu'elles soient agiles ou non, sont MAL employées, TOUJOURS, car prises au pied de la lettre, alors que cela ne doit être qu'un guide...

Que la mode des méthodologies dites "agiles" favorisent effectivement le développement de type brouillon, et l'émergence de nouveaux-venus dans le métier qui pensent qu'il suffit de réfléchir 5 minutes...

Que l'échec des méthodes style Waterfall est de ne pas autoriser du tout de modifications en cours de route, et de penser que l'on peut tout modéliser de tête au départ...


Et que fondamentalement il y a une erreur de fond sur les ressources humaines, comme mentionné ci-dessus...

il y a eu (et c'est de plus en plus le cas) une formation universitaire déficiente, qui néglige presque totalement une approche "multi-disicplinaire" en spécialisant sur les langages ou la théorie, alors qu'il devrait y avoir à mon avis, ce qui est (un peu plus) le cas pour les développements scientifiques, plus des "utilisateurs généralistes très bien formés" que des "machines à coder".. (en gros des ingénieurs avec une culture générale grande).

Ce qui entraîne les difficultés de rapport avec les clients (et les mauvaises perceptions de part et d'autre)..


Et enfin maintenant il y a des formations diplomantes de "chefs de projet", ce qui est absurde, et que encore une fois le fait que la méthode employée soit agile ne change rien.. (alors que le contraire est bien précisé dans le Manifeste)


En résumé pour moi le problème des ressources humaines dans l'industrie informatique est le pricnipal problème...

[_Xavier_]

Les quatre valeurs fondamentales Agiles sont de valoriser2 :

• l’interaction avec les personnes plus que les processus et les outils.
• un produit opérationnel plus qu'une documentation pléthorique.
• la collaboration avec le client plus que la négociation de contrat.
• la réactivité face au changement plus que le suivi d'un plan

Qu'est ce qu'il y a de rigide ici ?

L'usage de "c'est la mode" à toute les sauces est aussi passé à la mode. On l'entend maintenant partout, tout comme critiquer des choses dont on n'a que des notions superficielles.

La manière la plus objective de critiquer une méthode (les méthodes agiles en particulier) est de la pratiquer au moins une fois, dans un cadre approprié, avec des gens qui la maîtrisent bien.

Le syndrome de la vieillesse fait parfois qu'on déteste tout ce qui est nouveau, et qu'on a tendance à se réfugier dans un passé mythique où tout était beau.

[souviron34]

Quand on ne sait pas lire, on n'essaye pas de donner des leçons... Le syndrôme de la jeunesse ne serait-il pas de parler sans avoir compris ??

Où as-tu vu que quelqu'un disait que les méthodes agiles étaient rigides ????

[zeavan]

Bonjour à tous!

Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:

1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.

Jean-Marc Blanc

+100
Je suis totalement d'accord avec cet avis, en tant que developpeurs nous sommes des super utilisateurs ou super client, il n'a rien de choquant de remetrre en question les exigences du client, apres un apprentissage approfondie de son domain.

[zaventem]

Je suis totalement d'accord avec cet avis, en tant que developpeurs nous sommes des super utilisateurs ou super client, il n'a rien de choquant de remetrre en question les exigences du client, apres un apprentissage approfondie de son domain.

Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

Ce genre de réflexion me fait vraiment peur
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.


PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"

[Barsy]

Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

Ce genre de réflexion me fait vraiment peur
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.


PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"

Sauf que si le client demande au plombier d'installer une douche en lui disant qu'il veut prendre des bains, je doute que le plombier ne lui fasse pas part de conseils dans ce cas.

Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.
C'est un problème récurrent d'ailleurs en informatique, beaucoup de clients demande au développeur de réaliser une solution sans lui faire part des besoins initiaux. Et résultat, ce sont souvent des projets qui se plantent car le client n'a malheureusement pas pensé à tout.

C'est comme si j'allais chez le garagiste pour une panne et, plutôt que de lui expliquer la panne, je lui dis juste quelles pièces il doit changer.

[Nebulix]

d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée

Si le développeur discute directement avec l'utilisateur final, il est probable qu'ils arrivent rapidement à une solution simple, rapide efficace et bon marché.
Heureusement qu'il existe des managers, chefs de projet, commerciaux, etc. pour valoriser la profession.

[zaventem]

Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.

C'est ce que je disais, un mission de conseil, pas définir lui-même les besoins.

Disons qu'après réflexion, ce qui m'a surtout fait réagir serait cette partie là, partie appuyée par le message auquel j'ai répondu.

1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

[gangsoleil]

Bonjour,

Si le développeur discute directement avec l'utilisateur final, il est probable qu'ils arrivent rapidement à une solution simple, rapide efficace et bon marché.
Heureusement qu'il existe des managers, chefs de projet, commerciaux, etc. pour valoriser la profession.

Il ne faut pas faire peur aux jeunes comme ca : il croiseront, tot ou tard, un manager correct, technique, qui comprend ce que fait son equipe, qui valorise le travail de ses ouailles, ...
Pareil pour le chef de projet, mais plus dur pour le commercial

Sinon, je trouve que simplement, il faut discuter, encore et toujours : expliquer au client que prendre des bains dans une douche sera difficile, lui montrer pourquoi, et voir avec lui s'il desire reellement prendre des bains, ou bien s'il a besoin d'un lavabo pour se brosser les dents.

[Barsy]

Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.

[MigouW]

Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.

La "baignoire-douche-lavabo" étant installé dans la cuisine pour couronner le tout...

[pseudocode]

Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.

Je ne sais pas d'où vient ce penchant des développeurs pour les analogies de plomberie...

Une overdose de Mario étant jeune, peut-être ?

[zaventem]

Je ne sais pas d'où vient se penchant des développeurs pour les analogies de plomberie...

Une overdose de Mario étant jeune, peut-être ?

C'est moi qui l'ai lancée et je n'ai jamais joué à Mario de ma vie, ça doit donc pas être ça. (ben oui, des comme moi, c'est peut-être rare mais ça existe)

Bien tenté quand même

[Nebulix]

Les architectes savent aussi vous vendre une douche comme "salle de bains" http://www.maisonapart.com/edito/con...2-p10-5112.php

[BugFactory]

Non, quand il s'agit de demande d'évolutions, celles-ci sont chiffrées et ajoutées au coût du projet. Ce sont les anomalies qui sont à la charge de la SSII. Évidemment, les commerciaux s'arrangent avec le client (faudrait pas le braquer non plus) et intègrent au projet une certaine partie des évolutions si leur coût est raisonnable par rapport à l'ensemble du projet.

Dans le cadre d'une régie, ces questions ne se posent pas...

Ca, faut vraiment être informaticien pour avoir des idées pareilles!

En pratique, quand les délais s'allongent et que les coûts augmentent, le client ne se montre pas toujours raisonnable et fait preuve de mauvaise foi, arguant n'importe quoi pour que ce soit le prestataire qui assume les coût, même si la responsabilité est entièrement celle du client (genre envoyer le cahier des charges quinze jours APRES la date de fin du projet).

Evidemment, tous les clients ne sont pas à ce point cauchemardesques.