# Le club des professionnels en informatique > La taverne du Club : Humour et divers > Humour Informatique >  Coder rapidement ou crire du code de qualit ? Les deux approches ne servent  rien

## Idelways

*Coder rapidement ou crire du code de qualit ?*
*Les deux approches reviennent au mme, selon un clbre web-bdiste*



XKCD est une clbre bande-dessine cre et publie par Randall Munroe, un ancien consultant  la NASA, qui la dfinit comme un webcomic sarcastique qui parle de romance, de maths et de langage.

Une planche publie rcemment sous forme d'organigramme algorithmique n'a d'autre prtention que celle de rsumer, d'une manire extrmement pessimiste, le mtier de dveloppeur.

Les dveloppeurs seraient, selon Munroe, ternellement confront au dilemme : coder rapidement ou coder correctement.

Ceux qui prennent la dcision de "coder correctement" sont selon Munroe toujours dpasss par les vnements, et quand leur travail arrive enfin  terme, les spcifications auront dj chang. Les malheureux doivent donc tout jeter et reprendre depuis le dbut.

Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de  bidouilles et de code spaghetti . Rsultat, leur code subirait le mme triste sort que celui de leurs confrres : tre jet et repris depuis le dbut.



Bien entendu, cette planche exclut toute possibilit de juste milieu entre ces deux extrmes.

Il existe bien entendu des dveloppeurs qui arrivent  produire du bon code dans les dlais, sinon nous ne serions pas l pour en parler.


*Mais d'aprs vous ?*

 ::fleche::  Comment trouver le juste milieu pour dvelopper vite tout en produisant du code correct ? 
 ::fleche::  Comment faire des concessions tout en tant consciencieux ? 
 ::fleche::  Y arrivez-vous plus avec l'exprience ? Ou pas du tout ?


*Source* : XKCD.com

----------


## pseudocode

"Make It Work, Make It Right, Make It Fast", Kent Beck.

1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)

2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)

3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)

 ::D:

----------


## eomer212

simple, faire en sorte que les spcifications de l'appli ne changent pas toutes les 5 minutes..

----------


## kaymak

> simple, faire en sorte que les spcifications de l'appli ne changent pas toutes les 5 minutes..


pure folie ou folie pure ? = )

Sion javais pens au triple D en lisant la news
Do it yourself,
Do it fast,
Do not test

On peut mme rajouter
Do it once again =)

a+

----------


## FR119492

Bonjour  tous!

Mon exprience professionnelle est la suivante: dans l'immense majorit des cas, celui (client, suprieur hirarchique ou autre) qui vous confie une tche de dveloppement informatique n'a aucune ide de ce qu'il veut, et encore moins de ce qu'il est possible de raliser. Il convient donc de procder en deux tapes:
Commencer par crire un programme de manire raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manire, est totalement incohrent.Lorsque c'est termin, faire preuve d'un sens psychologique extrme 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 comptent, mais c'est plutt rare; de plus, dans ce cas, il aurait crit son programme lui-mme.

Jean-Marc Blanc

----------


## kaymak

> Bonjour  tous!
> 
> Mon exprience professionnelle est la suivante: dans l'immense majorit des cas, celui (client, suprieur hirarchique ou autre) qui vous confie une tche de dveloppement informatique n'a aucune ide de ce qu'il veut, et encore moins de ce qu'il est possible de raliser. Il convient donc de procder en deux tapes:
> Commencer par crire un programme de manire raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manire, est totalement incohrent.Lorsque c'est termin, faire preuve d'un sens psychologique extrme 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 comptent, mais c'est plutt rare; de plus, dans ce cas, il aurait crit son programme lui-mme.
> 
> Jean-Marc Blanc


La mthode Grard majax !

Un classique de l'incomptent informaticien, ou du trop expriment,
c'est selon ; )

a+

----------


## pseudocode

> La mthode Grard majax !


 ::mouarf:: 

Une variante du Reality distortion field.  ::P:

----------


## spidermario

> "Make It Work, Make It Right, Make It Fast", Kent Beck.
> 
> 1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)
> 
> 2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)
> 
> 3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)


Il ne me semble pas qu’il soit question du mme "fast", ici : celui de la bande dessine semble plutt s’appliquer au dveloppement qu’au programme rsultant.

----------


## bleporini

Des besoins clients qui n'voluent pas, c'est un voeux pieux, donc autant se dire que cela n'existe pas. Et pas de projets sans clients, donc autant intgrer la fluctuation des besoins comme une contrainte de dpart.

Je vous conseille de passer un peu de temps  tudier les mthodes agiles. Ce n'est pas uniquement parce qu'on est un dveloppeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqus dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.

Il est certain que lorsqu'un donneur d'ordre espre que 100% du travail soit ralis dans 70% du temps imparti avec des exigences fonctionnelles diffrentes encours de projet, il y a peu de chances que la MOE livre du travail de qualit dans les dlais!

----------


## Patriarch24

> "Make It Work, Make It Right, Make It Fast", Kent Beck.


+1.




> Les dveloppeurs seraient, selon Munroe, ternellement confront au dilemme : coder rapidement ou coder correctement.
> 
> Ceux qui prennent la dcision de "coder correctement" sont selon Munroe toujours dpasss par les vnements, et quand leur travail arrive enfin  terme, les spcifications auront dj chang. Les malheureux doivent donc tout jeter et reprendre depuis le dbut.
> 
> Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de  bidouilles et de code spaghetti . Rsultat, leur code subirait le mme triste sort que celui de leurs confrres : tre jet et repris depuis le dbut.


Il existe des mthodes de gestion de projet pour viter ces dsagrments. XP (Scrum, etc) permettent de significativement rduire le risque que ce genre de msaventures se produisent (mme si elles ne l'annihilent pas). Pour moi, c'est une nerie.

----------


## Barsy

Je pense que la meilleure mthode reste celle l :



C'est la mthodologie de la RACHE  dcouvrir ici : http://www.risacher.com/la-rache/ et qui est utilise dans de trs nombreux projets.

----------


## rawsrc

Bonjour




> dans l'immense majorit des cas, celui (client, suprieur hirarchique ou autre) qui vous confie une tche de dveloppement informatique n'a aucune ide de ce qu'il veut


je dirais +1000. A tel point parfois qu'il arrive que cela soit le prestatire qui doive crire le cahier des charges qu'il devra respecter. Vridique, cela a t le cas de mon dernier contrat. Enfin comme il me l'a dit : "c'est pas mon problme" et que "c'tait  moi de faire mon boulot en lui dtaillant ses besoins". 
A la question pose je dirais qu'il faut juste coder proprement en prvision des futures modifications, de manire  ce que la reprise du code soit la moins fastidieuse possible.

----------


## martopioche

> "Make It Work, Make It Right, Make It Fast", Kent Beck.
> 
> 1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)
> 
> 2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)
> 
> 3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)


a, c'est une jolie thorie, mais elle a le dfaut que si elle n'est pas applique par le gestionnaire de projet (peu importe  quel niveau) plus accroch  ses graphs, elle ne dpasse pas l'tape 1. Aprs tout, pourquoi continuer  imputer sur quelque chose qui est fonctionnel. C'est fonctionnel, bien, c'est pli et on passe  la tache suivante. Au niveau du gestionnaire, a avance (fast), au niveau du code, on gnre du spaghetti  la bolognaise qui tche...

----------


## pseudocode

> Aprs tout, pourquoi continuer  imputer sur quelque chose qui est fonctionnel. C'est fonctionnel, bien, c'est pli et on passe  la tache suivante. Au niveau du gestionnaire, a avance (fast), au niveau du code, on gnre du spaghetti  la bolognaise qui tche...


Ca avance vite... au  debut seulement. Ca s'enlise au fur et  mesure, et les itrations deviennent de plus en plus longues et risques. 

Au point souvent d'tablir comme rgle de "toucher au minimum" le code existant... et finir par n'avoir que deux choix possibles : "Ne plus rien toucher" ou "Tout jeter et refaire".

----------


## kaymak

> Une variante du Reality distortion field.


ouaw excellent !

Mythe ou ralit ?
A en juger par les records d'apple, ralit :O

....





> Je pense que la meilleure mthode reste celle l :
> 
> 
> 
> C'est la mthodologie de la RACHE  dcouvrir ici : http://www.risacher.com/la-rache/ et qui est utilise dans de trs nombreux projets.


Muhahahahahah Il est toujours aussi tordant ce schma !!





> Ca avance vite... au debut seulement. Ca s'enlise au fur et  mesure, et les itrations deviennent de plus en plus longues et risques. 
> 
> Au point souvent d'tablir comme rgle de "toucher au minimum" le code existant... et finir par n'avoir que deux choix possibles : "Ne plus rien toucher" ou "Tout jeter et refaire".


Oui je confirme. Je rajouterais un truc qui n'est pas mentionn jusqu'ici, la documentation.
Avec le turn over, la rapidit des dveloppements mal contrls, on ne fait pas de doc, ou de test, du coup lorsqu'il s'agit de corriger un bug en phase de TMA, on ne sait plus quel tait l'objectif de dpart du dveloppement, le dveloppeur fais des modifs mais n'est pas capable de s'assurer,
- que c'est toujours concordant avec le dv initial
- qu'il n' pas introduit d'effet de bord

Et lorsqu'il s'agit d'expliquer  un nouveau collgue le "but de ce truc",
bah tu prends tes spaghettis et t'organises une partie de mikado avec lui pour dnouer le bordel =)



A +

----------


## martopioche

> Oui je confirme. Je rajouterais un truc qui n'est pas mentionn jusqu'ici, la documentation.
> Avec le turn over, la rapidit des dveloppements mal contrls, on ne fait pas de doc,


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 mme. Alors la doc...

...

 ::dehors::

----------


## ymajoros

> "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"


Indiana Jones ?  ::zoubi::

----------


## Barsy

> Indiana Jones ?


perdu  ::aie::

----------


## Tellen

> Indiana Jones ?



Mais non !!! Mac Gyver. a fait 2 fois (ok pas sur la mme discussion). ::P: 
Y a quant mme l'avatar qui donne un indice. :;):

----------


## Barsy

> Mais non !!! ...


T'aurais pu laisser les gens essayer de deviner un peu...

----------


## el_slapper

> (.../...)
> Je vous conseille de passer un peu de temps  tudier les mthodes agiles. Ce n'est pas uniquement parce qu'on est un dveloppeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqus dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.
> (.../...)


D'accord avec le reste, mais pour les mthodes agiles, je ne suis pas emball(enfin, pas toujours). Tout simplement parceque l'important n'est pas la mthode, mais que le client ET la MOA soient impliqus. Quand le client suit le projet de prs et rpond aux questions(et en pose), a peut tre du waterfall  18 mois, a marche. Ca eut march aussi en agile, mais pas parceque c'est de l'agile. Pour moi, le choix de l'agile est surtout intrssant pour des projets ou on peut tester vite(tout ce qui comporte une interface, tout ce qui est batches quotidiens). Pour les monstres mensuels que je traite actuellement, a n'aurait aucun sens.

----------


## notia

> Je pense que la meilleure mthode reste celle l :
> 
> 
> 
> C'est la mthodologie de la RACHE  dcouvrir ici : http://www.risacher.com/la-rache/ et qui est utilise dans de trs nombreux projets.


 ::ccool::  I like this

----------


## jmguiche

D'aprs mon exprience, 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 diffrence 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 dlais.

Et les autres... Ceux avec qui, quelque soit la mthode de dveloppement, le projet coutera au moins le double de ce qu'il devrait,  force d'incohrences, de voltes faces, d'oublies, d'imprcisions, de y'akafaukon, etc...

Tout cela n'a rien  voir avec la mthode employe. 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 itratives (extrem programming et autres) ne convergent pas mais tournent en rond.

----------


## Nebulix

> Bonjour  tous!
> 
> Mon exprience professionnelle est la suivante: dans l'immense majorit des cas, celui (client, suprieur hirarchique ou autre) qui vous confie une tche de dveloppement informatique n'a aucune ide de ce qu'il veut, et encore moins de ce qu'il est possible de raliser. Il convient donc de procder en deux tapes:
> Commencer par crire un programme de manire raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manire, est totalement incohrent.Lorsque c'est termin, faire preuve d'un sens psychologique extrme 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 comptent, mais c'est plutt rare; de plus, dans ce cas, il aurait crit son programme lui-mme.
> 
> Jean-Marc Blanc


Pour le point 1, la mthode la plus sre et la plus rentable n'est-elle pas de reservir ce qui a convenu  un client prcdent ?  ::mouarf::

----------


## Barsy

> Et les autres... Ceux avec qui, quelque soit la mthode de dveloppement, le projet coutera au moins le double de ce qu'il devrait,  force d'incohrences, de voltes faces, d'oublies, d'imprcisions, de y'akafaukon, etc...


Les commerciaux adorent ce type de client qui, multiplient la dure des projets et transforment les forfaits en rgies.
Bizarrement, les dveloppeurs eux les aiment moins... Allez comprendre...  ::aie::

----------


## BugFactory

> Les commerciaux adorent ce type de client qui, multiplient la dure des projets et transforment les forfaits en rgies.
> Bizarrement, les dveloppeurs eux les aiment moins... Allez comprendre...


Pas vraiment. Au dbut oui. Ensuite les clients rlent parce que le projet n'avance pas, hurlent que les dveloppeurs sont incomptents et exigent que leurs modifications communiques aprs la date thorique de fin du projet soient faites sans supplment de dlai et de prix ou le projet tombent  l'eau. Les commerciaux n'aiment pas les projets dficitaires.

----------


## kaymak

> D'aprs mon exprience, 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 diffrence 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 dlais.
> 
> Et les autres... Ceux avec qui, quelque soit la mthode de dveloppement, le projet coutera au moins le double de ce qu'il devrait,  force d'incohrences, de voltes faces, d'oublies, d'imprcisions, de y'akafaukon, etc...
> 
> Tout cela n'a rien  voir avec la mthode employe. 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 itratives (extrem programming et autres) ne convergent pas mais tournent en rond.


C'est intressant comme retour d'exprience, as tu des informations plus formalises sur le sujet ?

a+

----------


## jmguiche

> C'est intressant comme retour d'exprience, as tu des informations plus formalises sur le sujet ?
> 
> a+


Tu veux des noms? je n'en donnerais pas!
C'est un simple constat. En fait, ce sont deux extrmes, entre ces 2 extrmes, tout se trouve.

Ce que je remarque, par contre, c'est que le phnomne du changement d'avis et de l'incohrence s'accentue peut tre (mais ce n'est qu'un ressenti, pas une tude statistique). Comme si les gens ne savaient plus rflchir, ils effleurent, zappent, sans aller au bout des choses.
Qu'on ne me dise pas que c'est parce que "tout change, tout va vite, on ne peut pas figer un besoin...". Ce n'est pas a l'origine du problme. Ce ne sont pas des problmes nouveaux qui apparaissent en cors de projets, ce sont des points qu'on avait oubli d'exprimer.

Par contre, la mode des mthodes dites "agiles" accentuent peut tre le phnomne. Beaucoup considrent qu'une vue d'ensemble n'est pas utile : on fonce dans le dveloppement  partir d'un besoin exprim en 20 lignes dans un mail.
Je pense que c'est une erreur, une trs 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. Bref, rien  voir avec les profils que l'on rencontre quelquefois : zappeurs, brouillon, ractif plutot que dans l'anticipation et, j'exagre  peine, avec quelques difficults avec la logique boolenne !

----------


## jmguiche

> Pas vraiment. Au dbut oui. Ensuite les clients rlent parce que le projet n'avance pas, hurlent que les dveloppeurs sont incomptents et exigent que leurs modifications communiques aprs la date thorique de fin du projet soient faites sans supplment de dlai et de prix ou le projet tombent  l'eau. Les commerciaux n'aiment pas les projets dficitaires.


Pour les marchands de viande en rgie, et ils sont de plus en plus nombreux, c'est jackpot, il faut l'admettre.

----------


## kaymak

hello,




> Tout cela n'a rien  voir avec la mthode employe. 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 itratives (extrem programming et autres) ne convergent pas mais tournent en rond.


J'aurais du prciser, c'est ce point qui m' particulirement interpell. En fait ce que j'y trouvait dintressant c'tait ce retour d'exprience de mauvais utilisation, d'une application de mthode qui n' pas fonctionn.
Car je trouve que c'est aussi le meilleur moyen de savoir si on pratique bien ou pas telle ou telle chose que de savoir en dtecter ces disfonctionnements, et rester clairvoyant face  sa situation.


Sinon  la lecture de ton post, je suis plutt d'accord avec toi.
Mais il est difficile de quantifier de tels choses, par ailleurs chaque situation  des rponses plus ou moins adaptes.
bref, la rponse est difficile, car je suis convaincu que les deux mthodes ont leurs raisons d'tre, malgr tout.

a+

----------


## Fifan31

Il est aussi facile de coder  partir des spcifications que de marcher sur l'eau   :8O: 
A condition que les 2 soient geles  ::aie::

----------


## Mobius

> Je vous conseille de passer un peu de temps  tudier les mthodes agiles. Ce n'est pas uniquement parce qu'on est un dveloppeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqus dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.


Je pensais que les mthodes agiles c'tait le contraire : voir le graal s'loigner en perdant du temps.
Exprience observ : Le client dcide de passer aux mthode agile pour rduire les cycle de dveloppement en ayant une qualit accrue. Il fait venir un expert agile expliquant  tout le monde comment faire. Aprs avoir cout la grande messe,  tout le monde met un maximum de bonne volont, communique chaque matin sur le job de la journe. Il s'est rvl que ce qui devait prendre 5 minute chaque jour pouvait dure plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avanc, peut donner de nouvelles directive (ou changer d'ide) encore plus souvent. Rsultat des courses, on passe plus de temps en runions (donc moins de temps de dveloppement) et le travail est plus rapidement mis  la poubelle.

----------


## pseudocode

> Je pensais que les mthodes agiles c'tait le contraire : voir le graal s'loigner en perdant du temps.
> Exprience observ : Le client dcide de passer aux mthode agile pour rduire les cycle de dveloppement en ayant une qualit accrue. Il fait venir un expert agile expliquant  tout le monde comment faire. Aprs avoir cout la grande messe,  tout le monde met un maximum de bonne volont, communique chaque matin sur le job de la journe. Il s'est rvl que ce qui devait prendre 5 minute chaque jour pouvait dure plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avanc, peut donner de nouvelles directive (ou changer d'ide) encore plus souvent. Rsultat des courses, on passe plus de temps en runions (donc moins de temps de dveloppement) et le travail est plus rapidement mis  la poubelle.


De la bonne volont et un daily meeting n'est pas suffisant pour combler une absence de gestion projet.

Les methodes agiles mettent en oeuvre des cycles de dveloppement complexes, ncessitant une grande rigueur dans la gestion du projet. C'est justement parce que le cadre du projet est trs rigoureux qu'on peut se permettre de modifier le cahier des charges ou le contenu des itrations pendant le dveloppement.

Si dj on a du mal avec un SDLC simple (waterfall, spiral, sawtooth), il faut viter de plonger dans l'agile en esprant que ca va magiquement rsoudre les problmes. Enfin, c'est mon avis.

----------


## billynirvana

La mthode Agile est une trs bonne mthode de travail si l'quipe (manager du projet + architecte + dveloppeurs) ont de nombreuses annes d'exprience avec une mthode plus stricte et rigoureuse.

Cela donne une certaine souplesse au projet, pas besoin d'attendre le feu vert de la hirarchie, pas besoin d'attendre la maj du cahier des charges, des specs, des docs annexes (planning...) pour mettre en place une volution. Tout se ralise en mme temps, la perte de temps est fortement rduite.

Dans une mthode de travail stricte toutes les volutions sont refuses sous prtexte qu'elles n'taient pas prvues dans les specs, mme si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une mthode Agile, cette question et cette rponse n'a plus lieu d'tre (bien entendu si l'volution reste dans le primtre du projet initial).

La mthode Agile selon moi ne sert qu' a, cela ne change pas la faon d'architecturer et de dvelopper le projet. La mthode Agile ne doit pas converger vers la mthode  l'arrache.

Par mon exprience j'ai particip  plusieurs projets o nous avons employ cette mthode Agile, le premier projet tait trs bien j'ai ador mais je sens que de plus en plus on se laisse aller. Peut re faudrait-il alterner les deux mthodes pour garantir dans les deux cas un travail de qualit. Rigueur et souplesse!

----------


## Barsy

> Pas vraiment. Au dbut oui. Ensuite les clients rlent parce que le projet n'avance pas, hurlent que les dveloppeurs sont incomptents et exigent que leurs modifications communiques aprs la date thorique de fin du projet soient faites sans supplment de dlai et de prix ou le projet tombent  l'eau. Les commerciaux n'aiment pas les projets dficitaires.


Non, quand il s'agit de demande d'volutions, celles-ci sont chiffres et ajoutes au cot 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 intgrent au projet une certaine partie des volutions si leur cot est raisonnable par rapport  l'ensemble du projet.

Dans le cadre d'une rgie, ces questions ne se posent pas...

----------


## OWickerman

Le problme survient quand le commercial ne sait pas prcisment quel est le cout en travail de telle ou telle volution ajoute "pour faire plaisir au client".

----------


## kaymak

hello,




> Dans une mthode de travail stricte toutes les volutions sont refuses sous prtexte qu'elles n'taient pas prvues dans les specs, mme si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une mthode Agile, cette question et cette rponse n'a plus lieu d'tre (bien entendu si l'volution reste dans le primtre du projet initial)


.

En mme temps, il me semble que de demander une validation hirarchique pour ce genre de demandes, relativement justifie, ne dnote t'il pas d'un problme dans la mthodologie de gestion du projet et de ces alas ?

Je ne suis pas encore pass  l'agile, mais j'espre que cela m'apportera de meilleures rponses dans des situations plus cruciales.

M'enfin, il y  la gestion du projet d'un point de vue  dfinition des besoins et implmentations, il y  aussi la gestion du projet du point de vue maintenance de l'existant.
Dans le deux cas il y  besoin de border le primtre, de contrler les ajouts et modifications, sans pour autant que cette machinerie ne soit un frein  linnovation du projet.
Sans non plus que se soit dangereux ou pique pour l'quipe de dveloppement.
C'est ce qui est de plus difficile, et malheureusement, je n'ai pas encore trouv, vue, expriment de meilleures solutions que de faire reposer cette logique et ces process sur les paules d'un homme :/

Et a c'est trs mauvais.....

a+

----------


## Barsy

> Le problme survient quand le commercial ne sait pas prcisment quel est le cout en travail de telle ou telle volution ajoute "pour faire plaisir au client".


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

----------


## kaymak

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


Dj vcu. Plusieurs fois.

----------


## Patriarch24

> mais je sens que de plus en plus on se laisse aller. Peut re faudrait-il alterner les deux mthodes pour garantir dans les deux cas un travail de qualit


Normalement, "se laisser aller" ne fait pas partie du droulement d'un projet agile. Cela contredit l'un des principes du manifeste "Btissez le projet autour de personnes *motives*. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacit  faire le travail.". Le rle du coach XP (ou du Scrum Master) est de vrifier que ces rgles sont respectes. Cela tient donc de la gestion de projet, et non de la mthode en elle-mme.





> Exprience observ : Le client dcide de passer aux mthode agile pour rduire les cycle de dveloppement en ayant une qualit accrue. Il fait venir un expert agile expliquant  tout le monde comment faire.


C'est bien d'expliquer aux gens comment faire, mais il faut aussi un accompagnement (coach XP, Scrum Master) qui connaisse la mthode.



> Aprs avoir cout la grande messe, tout le monde met un maximum de bonne volont, communique chaque matin sur le job de la journe. Il s'est rvl que ce qui devait prendre 5 minute chaque jour pouvait dure plusieurs heures.


On en revient toujours au mme : le problme, ce n'est pas la mthode, c'est la manire de grer l'quipe.



> Le client, se rendant compte au fur et a mesure de l'avanc, peut donner de nouvelles directive (ou changer d'ide) encore plus souvent. Rsultat des courses, on passe plus de temps en runions (donc moins de temps de dveloppement) et le travail est plus rapidement mis  la poubelle.


L encore, il ne faut pas croire que mthode agile = chaos. C'est d'ailleurs tout le contraire : il existe des moments pour changer d'ide, demander de nouvelles fonctionnalits, etc. Tout ne se fait pas n'importe quand.

----------


## jmguiche

> Non, quand il s'agit de demande d'volutions, celles-ci sont chiffres et ajoutes au cot 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 intgrent au projet une certaine partie des volutions si leur cot est raisonnable par rapport  l'ensemble du projet.
> 
> Dans le cadre d'une rgie, ces questions ne se posent pas...


Ca, c'est dans le meilleurs des monde. mais nous vivons quand mme dans un monde ou des trucs comme la rgie forfaitise 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 gnral 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 gnral 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 problmes"  celui qui tient les cordons de la bourse...

----------


## el_slapper

> (.../...)
> Une bonne partie des couleuvres qu'avalent les quipes de dev sont en gnral 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 problmes"  celui qui tient les cordons de la bourse...


Vu pas mal de fois. J'ai mme vu une MOA qui refusait de corriger une spec fausse parceque la spec fausse avait t tamponne et valide, par peur de dplaire aux grands chefs. Rsultat : 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..... ::aie::

----------


## OWickerman

> C'est quand mme rare que le commercial valide une volution sans en faire part au pralable  l'quipe technique (enfin, j'imagine qu'il doit bien y en avoir qui le font... ).
> Dans le cadre d'un forfait, tout dpassement 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" fonctionnalits qui auraient demand de tout redvelopper. 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 ralisait un analyse fonctionnelle pour mettre en vidence les concepts et les invariants mtiers qui permettaient au moins de batir sur un socle stable ?

D'autre part, pour qu'un primtre 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 ralisait un analyse fonctionnelle pour mettre en vidence les concepts et les invariants mtiers 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 possdant une interface graphique.  ::calim2::

----------


## souviron34

A la question pose je suis entirement d'accord avec :




> A la question pose je dirais qu'il faut juste coder proprement en prvision des futures modifications, de manire  ce que la reprise du code soit la moins fastidieuse possible.




Maintenant, dans le dbat qui suit, je note que le principal problme est (comme ila toujours t) la gestion de projet (et des hommes) :





> On en revient toujours au mme : le problme, ce n'est pas la mthode, c'est la manire de grer l'quipe.





> D'autre part, pour qu'un primtre 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 mthologie employe :




> Dans une mthode de travail stricte toutes les volutions sont refuses sous prtexte qu'elles n'taient pas prvues dans les specs, mme si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une mthode Agile, cette question et cette rponse n'a plus lieu d'tre (bien entendu si l'volution reste dans le primtre du projet initial).
> 
> La mthode Agile selon moi ne sert qu' a, cela ne change pas la faon d'architecturer et de dvelopper le projet. La mthode Agile ne doit pas converger vers la mthode  l'arrache.






> Par contre, la mode des mthodes dites "agiles" accentuent peut tre le phnomne. Beaucoup considrent qu'une vue d'ensemble n'est pas utile : on fonce dans le dveloppement  partir d'un besoin exprim en 20 lignes dans un mail.
> Je pense que c'est une erreur, une trs 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 possdant 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 mme. Alors la doc...



Et le troisime problme (qui a aussi toujours exist) est la sparation bien trop grande entre "industrie informatique" et "clients", exprime trs bien par :




> D'aprs mon exprience, 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 diffrence 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 dlais.
> 
> Et les autres... Ceux avec qui, quelque soit la mthode de dveloppement, le projet coutera au moins le double de ce qu'il devrait,  force d'incohrences, de voltes faces, d'oublies, d'imprcisions, de y'akafaukon, etc...
> 
> Tout cela n'a rien  voir avec la mthode employe. 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 itratives (extrem programming et autres) ne convergent pas mais tournent en rond.




Je pense effectivement (_et je l'ai dit de trs nombreuses fois dans les dbats concerns_) que les mthologies (_et leurs modes_), qu'elles soient agiles ou non, sont MAL employes, TOUJOURS, car prises au pied de la lettre, alors que cela ne doit tre qu'un guide...

Que la mode des mthodologies dites "agiles" favorisent effectivement le dveloppement de type brouillon, et l'mergence de nouveaux-venus dans le mtier qui pensent qu'il suffit de rflchir 5 minutes...

Que l'chec des mthodes style Waterfall est de ne pas autoriser du tout de modifications en cours de route, et de penser que l'on peut tout modliser de tte au dpart...


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 dficiente, qui nglige presque totalement une approche "multi-disicplinaire" en spcialisant sur les langages ou la thorie, alors qu'il devrait y avoir  mon avis, ce qui est (un peu plus) le cas pour les dveloppements scientifiques, plus des "utilisateurs gnralistes trs bien forms" que des "machines  coder".. (_en gros des ingnieurs avec une culture gnrale grande_).

Ce qui entrane les difficults 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 mthode employe soit agile ne change rien..  (alors que le contraire est bien prcis dans le Manifeste)


En rsum pour moi le problme des ressources humaines dans l'industrie informatique est le pricnipal problme...

----------


## _Xavier_

> Les quatre valeurs fondamentales Agiles sont de valoriser2 :
> *linteraction* avec les personnes plus que les processus et les outils.un produit oprationnel plus qu'une documentation plthorique.la *collaboration* avec le client plus que la ngociation de contrat.la *ractivit* 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 manire la plus objective de critiquer une mthode (les mthodes agiles en particulier) est de la pratiquer au moins une fois, dans un cadre appropri, avec des gens qui la matrisent bien. 

Le syndrome de la vieillesse fait parfois qu'on dteste tout ce qui est nouveau, et qu'on a tendance  se rfugier dans un pass mythique o tout tait beau.

----------


## souviron34

Quand on ne sait pas lire, on n'essaye pas de donner des leons... Le syndrme de la jeunesse ne serait-il pas de parler sans avoir compris ??

O as-tu vu que quelqu'un disait que les mthodes agiles taient rigides ????  ::cfou::

----------


## zeavan

> Bonjour  tous!
> 
> Mon exprience professionnelle est la suivante: dans l'immense majorit des cas, celui (client, suprieur hirarchique ou autre) qui vous confie une tche de dveloppement informatique n'a aucune ide de ce qu'il veut, et encore moins de ce qu'il est possible de raliser. Il convient donc de procder en deux tapes:
> Commencer par crire un programme de manire raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manire, est totalement incohrent.Lorsque c'est termin, faire preuve d'un sens psychologique extrme 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 comptent, mais c'est plutt rare; de plus, dans ce cas, il aurait crit son programme lui-mme.
> 
> 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; aprs tout, c'est lui le pro.

Ce genre de rflexion me fait vraiment peur  :8O:  
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilit que d'tre un support au mtier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse dcider en connaissance de cause, qu'il soit conscient des contraintes engendres par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.


PS: le jour o un dveloppeur sera un "super utilisateur" (hormis le cas rare de logiciel destin spcifiquement aux informaticiens), les entrepreneurs de pompes funbres seront de "super mort"  ::aie::

----------


## Barsy

> Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; aprs tout, c'est lui le pro.
> 
> Ce genre de rflexion me fait vraiment peur  
> Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilit que d'tre un support au mtier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse dcider en connaissance de cause, qu'il soit conscient des contraintes engendres par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.
> 
> 
> PS: le jour o un dveloppeur sera un "super utilisateur" (hormis le cas rare de logiciel destin spcifiquement aux informaticiens), les entrepreneurs de pompes funbres 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 dvelopper des fonctionnalits dans le dos du client, mais plutt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considre la plus adapte (mme si elle peut tre discute ou refuse) plutt que de se lancer aveuglment dans celle qu'il propose.
C'est un problme rcurrent d'ailleurs en informatique, beaucoup de clients demande au dveloppeur de raliser une solution sans lui faire part des besoins initiaux. Et rsultat, 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, plutt que de lui expliquer la panne, je lui dis juste quelles pices il doit changer.

----------


## Nebulix

> d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considre la plus adapte


Si le dveloppeur 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 dvelopper des fonctionnalits dans le dos du client, mais plutt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considre la plus adapte (mme si elle peut tre discute ou refuse) plutt que de se lancer aveuglment dans celle qu'il propose.


C'est ce que je disais, un mission de conseil, pas dfinir lui-mme les besoins.

Disons qu'aprs rflexion, ce qui m'a surtout fait ragir serait cette partie l, partie appuye par le message auquel j'ai rpondu.




> Commencer par crire un programme de manire raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manire, est totalement incohrent.Lorsque c'est termin, faire preuve d'un sens psychologique extrme *pour persuader le client que c'est exactement ce qu'il a command*.

----------


## gangsoleil

Bonjour,




> Si le dveloppeur 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 mme d'essayer de vendre la baignoire mme si le client n'a besoin que d'une douche.

Le but du client par contre est de russir  acheter la douche au prix du lavabo.

Le dfi du dveloppeur sera de russir  raliser la "baignoire-douche-lavabo" qui sera un subtil mlange entre les trois solutions et qui au final ne rpondra  aucun besoin.

----------


## MigouW

> Le but du commercial reste quand mme d'essayer de vendre la baignoire mme si le client n'a besoin que d'une douche.
> 
> Le but du client par contre est de russir  acheter la douche au prix du lavabo.
> 
> Le dfi du dveloppeur sera de russir  raliser la "baignoire-douche-lavabo" qui sera un subtil mlange entre les trois solutions et qui au final ne rpondra  aucun besoin.


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

----------


## pseudocode

> Le but du commercial reste quand mme d'essayer de vendre la baignoire mme si le client n'a besoin que d'une douche.
> 
> Le but du client par contre est de russir  acheter la douche au prix du lavabo.
> 
> Le dfi du dveloppeur sera de russir  raliser la "baignoire-douche-lavabo" qui sera un subtil mlange entre les trois solutions et qui au final ne rpondra  aucun besoin.


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

Une overdose de Mario tant jeune, peut-tre ?

----------


## zaventem

> Je ne sais pas d'o vient se penchant des dveloppeurs pour les analogies de plomberie...
> 
> Une overdose de Mario tant jeune, peut-tre ?


C'est moi qui l'ai lance 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 mme  ::mouarf::

----------


## Nebulix

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

----------


## BugFactory

> Non, quand il s'agit de demande d'volutions, celles-ci sont chiffres et ajoutes au cot 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 intgrent au projet une certaine partie des volutions si leur cot est raisonnable par rapport  l'ensemble du projet.
> 
> Dans le cadre d'une rgie, ces questions ne se posent pas...


Ca, faut vraiment tre informaticien pour avoir des ides pareilles!  :8O: 

En pratique, quand les dlais s'allongent et que les cots 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 cot, mme si la responsabilit est entirement 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.

----------


## Barsy

> le client ne se montre pas toujours raisonnable et fait preuve de mauvaise foi


D'o l'intrt de toujours communiquer par mail et de garder un crit. Quand un client me tlphone en me demandant une volution, je lui renvoie tout de suite un mail dans lequel je dtaille cette volution (en commenant le mail par "suite  note conversation tlphonique..." et en demandant de confirmer et mme s'il ne le fait pas, a laisse une trace).

Des clients de mauvaises foi, il y en a (plutt rarement cela dit). Et souvent, s'ils sont de mauvaise foi avec le presta, ils le sont aussi avec le commercial (en tout cas, ceux que j'ai connu taient comme a). Quand on est prestataire, il faut savoir se protger et conserver des traces reste le meilleur moyen.

----------


## ovh

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


Le chiffrage c'est de la vaste blague... Les dlais sont toujours largement sous-estims... C'est souvent trs alatoire, mme pour un dev expriment qui est  fond dans un projet, estimer le dlai de ralisation d'une nouvelle fonctionalit est trs difficile ( part pour certaines tches simples bien sr). Et on a trs souvent tendance  minimiser.

----------


## el_slapper

> Le chiffrage c'est de la vaste blague... Les dlais sont toujours largement sous-estims... C'est souvent trs alatoire, mme pour un dev expriment qui est  fond dans un projet, estimer le dlai de ralisation d'une nouvelle fonctionalit est trs difficile ( part pour certaines tches simples bien sr). Et on a trs souvent tendance  minimiser.


j'ai vot +1, mais j'ai vu des exceptions. Sur des applis matures, dans des environnements matures, avec un chef de projet prsent depuis 10 ans, on pouvait avoir des chiffrages prcis  quelques pourcent. En 15 secondes, "il faut 420 jours pour passer le code produit de 4  5 caractres, en comptant la recompilation de tout les batchs, la retaille de tous les JCL, mais surtout la refonte de tous les crans CICS, dont certains n'ont pas la place pour, et devront tre chambouls; cel compte galement l'intgration et la recette". A 10 jours prs, il avait tout vu.

Mais c'est une exception. En gnral, on avance dans l'inconnu. Les boites srieuses(pas toujours les plus grosses) parlent de R&D pour le dveloppement, pas de production de code, car elles savent que le cot alatoire(i.e. les mauvaises surprises, les choses qu'on dcouvre en cours de dv) est important.

----------


## gangsoleil

> Le chiffrage c'est de la vaste blague... Les dlais sont toujours largement sous-estims... C'est souvent trs alatoire, mme pour un dev expriment qui est  fond dans un projet, estimer le dlai de ralisation d'une nouvelle fonctionalit est trs difficile ( part pour certaines tches simples bien sr). Et on a trs souvent tendance  minimiser.


Moui. Certaines personnes savent faire de vrais chiffrages, qui sont tres souvent corrects, a quelques pourcents pres bien sur. 
Mais ca ne veut pas dire que les commerciaux accorderont ce chiffrage au projet.

Par ailleurs, il faut tenir compte de la loi de Hofstadter : 



> Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

----------


## souviron34

> Moui. Certaines personnes savent faire de vrais chiffrages, qui sont tres souvent corrects, a quelques pourcents pres bien sur. 
> Mais ca ne veut pas dire que les commerciaux accorderont ce chiffrage au projet.
> 
> Par ailleurs, il faut tenir compte de la loi de Hofstadter :


moui...

D'un autre ct c'est par application de a par , dans l'ordre, le programmeur, puis le Chef d'quipe, puis le Chef de Projet, puis le Directeur Technique, puis le Directeur du Marketing,, puis les commerciaux, qu'on finit par avoir des dlais aberrants...

C'est le principe du parapluie... Chacun ouvre son parapluie .. Du coup, a n'a plus rien de rel, et les dlais et les budgets explosent....

 ::aie::

----------

