Les développeurs sont-ils condamnés à ne jamais respecter les cahiers des charges ?
Un entrepreneur recommande de multiplier les délais prévus par 3

Le , par Stéphane le calme, Chroniqueur Actualités
Dans une ère où le numérique occupe une place de choix dans les cultures du monde entier, les métiers du génie logiciel bénéficient de la forte demande en applications de toutes sortes.

Les jeux vidéo et autres applications sont le résultat d’un dur travail en interne qui nécessite rigueur et discipline. Avant de se lancer dans la tâche, les ingénieurs doivent procéder à une analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes.

Michael Wolfe, un investisseur américain dans de nombreuses start-ups (Vontu, Kana, I/PRO, Pipewise), pense que les développements logiciels prennent régulièrement deux ou trois fois plus de temps que prévu.



Avec une analogie assez amusante, il prend l’exemple d’une randonnée sur la côte de San Francisco à Los Angeles pour rendre visite à ses amis à Newport Beach. Tout est méticuleusement préparé sur la carte, les horaires sont déjà prévus d’avance ; la distance totale faisant 400 miles, le nombre d’heure de marche par jour est estimé à 10 à raison de 4 miles par heure soit 10 jours de marche au total.

Mais voilà que sur le terrain il y a plein de contours imprévus qui rallongent encore la route de 100 miles. Un coup de fil est passé aux amis pour repousser un peu le jour d’arrivée. À cause du sable, de la fatigue, la vitesse est plus lente que prévue ; 2 miles par heure, la moitié de la performance envisagée. Un autre coup de fil pour repousser. Une tempête s’abat le lendemain rendant toute marche impossible. Un enchaînement d’évènements qui rendent le voyage plus long et plus pénible que « sur le papier ».

Source : Quora

Et vous ?

Qu’en pensez-vous ? Les délais doivent-ils systématiquement être repoussés ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de moldavi moldavi
http://www.developpez.com
Expert Confirmé
le 21/07/2013 23:34
Bonjour.

J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...
Avatar de martopioche martopioche
http://www.developpez.com
Membre éprouvé
le 21/07/2013 23:34
2 remarques :
- l'analogie avec la côte de SF et la rando a déjà été utilisée, intéressant de la ressortir...
- Dans cette ordre de Grandeur, Kirk a eu la puce à l'oreille que Scotty devait sa réputation de faiseur de miracles en multipliant systématiquement ses évaluations par 4.

Sinon, tout développeur rebondit là dessus sur les thèmes "Méthodes Agiles", "Scrum", tout ça... Moi je rebondirai sur le TedxUCSD talk de Guy Kawazaki sur ce qu'il a appris de Steve Jobs et tout particulièrement le point "Real enterpreneurs ship" et son observation de comment ça se passe à la Sillicon Valley : on livre, puis on débeug... Et ça converge avec le point de vue de développeur. On a beau avoir le projet final, on prendra du retard, mais l'objectif devrait être d'avoir quelque chose de livrable à une date T et d'arrêter de se focaliser sur un projet complet, de toutes façons, il est mal définit.
Avatar de sympasteve sympasteve
http://www.developpez.com
Membre régulier
le 22/07/2013 7:53
S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !
Avatar de Paul TOTH Paul TOTH
http://www.developpez.com
Expert Confirmé Sénior
le 22/07/2013 8:16
Citation Envoyé par moldavi  Voir le message
Bonjour.

J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...

Citation Envoyé par sympasteve  Voir le message
S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !

tout est dit
Avatar de arnolem arnolem
http://www.developpez.com
Rédacteur
le 22/07/2013 8:43
On peut s'engager sur un périmètre ou sur un délai mais pas sur les deux a la fois.
De plus, je rencontre systématiquement le problème inverse ou les porteurs de projets me demandent d'avoir le projet toujours plus tôt. Au delà de 2 mois de délai, c'est difficile de signer un projet web.
Avatar de el_slapper el_slapper
http://www.developpez.com
Expert Confirmé Sénior
le 22/07/2013 9:07
C'est un peu toujours le même débat, avec les mêmes arguments, qui portent juste sur un aspect différent. Mais, fondamentalement, un projet informatique est un projet tordu. Une "analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes" n'est donc pas possible, en tous cas pas sans trou, erreurs ou décalages.

En outre, l'expérience montre que le principal facteur de succès ou d'echec(hormis la taille brute, qui est un inconvénient) n'est pas la méthodologie, mais le facteur humain.

Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

A celà, on rajoutera les exigences contradictoires des donneurs d'ordre("je veux un site mieux qu'Ebay en moins de deux mois", pour reprendre la situation d'arnolem). Exemple en cours : la recette sur un projet technique important est en retard. Raison immédiate : on a trouvé des anomalies qui ont retardé la recette. Cause profonde : la direction a exigé qu'on fasse un planning "si tout va bien", parceque de toutes façons les programmeurs auront tout bien testé, et que la recette ne trouvera quasiment pas d'anomalies.....

Mon point de vue à moi c'est que l'informatique est un domaine de l'invisible. On ne sait pas ou on va, on a bien quelques techniques, mais il faut sans cesse les adapter, au contexte technique, fonctionnel, ou politique. Dans ces conditions-là, les estimations ne seront jamais plus que des estimations, ayant la même valeur que les pronostics sportifs(scoop : la Colombie va gagner la coupe du monde 1994).
Avatar de phili_b phili_b
http://www.developpez.com
Expert Confirmé Sénior
le 22/07/2013 9:32
Citation Envoyé par el_slapper  Voir le message
Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.
Avatar de xelab xelab
http://www.developpez.com
Membre Expert
le 22/07/2013 9:54
Citation Envoyé par el_slapper  Voir le message
Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

Je pense ceci dit que les méthodes agiles sont souvent comprises comme "pas de conception", ce qui est tout de même un sérieux problème. Et quand on lit le "agile manifesto" que tu as mis en lien, on peut penser que c'est vrai, malheureusement. Et quand je vois la tronche de certains cahiers des charges dans ma boîte, où on applique une certaine idée des méthodes agiles, c'est encore plus vrai... Résultat: aucun projet livré à temps, même les plus petits. Du coup j'aime bien l'article de Reeves que tu cites, qui remet bien les pendules à l'heure:

Nevertheless, people keep insisting that my contention of "the source code is the design" means "don’t do design, just code." I never said anything of the sort. What I did say was:

"In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc.—if it helps, then use it."

Today, I would phrase it differently. I would say we need good architectures (top level design), good abstractions (class design), and good implementations (low level design). I would also say something about using UML diagrams or CRC cards to explore alternatives. Nevertheless, I will not back away from the following statement:

"We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them."

This is fundamental. I am not arguing that we should not "do design." However you want to approach the process, I simply insist that you have not completed the process until you have written and tested the code.

Avatar de pmithrandir pmithrandir
http://www.developpez.com
Expert Confirmé
le 22/07/2013 9:59
Citation Envoyé par phili_b  Voir le message
Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.
Avatar de GPPro GPPro
http://www.developpez.com
Membre chevronné
le 22/07/2013 10:09
Citation Envoyé par pmithrandir  Voir le message
Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

Euh ce n'est pas forcément le développeur qui merde hein... On peut aussi interpréter ça comme étant un moyen de s'assurer et que le client voulait aller à A et non à un B qui serait à 1000 bornes du A ! Sachant qu'en plus si le client sait qu'il veut aller à A (ce qui est déjà un petit miracle en soit) il y ait des chances qu'il ait dit A' voir C...
Offres d'emploi IT
Leader Technique C++ H/F
CDI
Sogeti HT - Région Est - Provence Alpes Côte d'Azur - sophia antipolis (06000)
Parue le 11/10/2014
Chef de projet technique
CDI
Experis Executive - Rhône Alpes - Lyon (69000)
Parue le 09/10/2014
Développeur senior php / symfony h/f
CDI
SENSIOLABS - Ile de France - Clichy (92110)
Parue le 03/10/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula