IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

10PARTAGES

14  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de moldavi
Inactif https://www.developpez.com
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é...
21  0 
Avatar de JackIsJack
Membre éclairé https://www.developpez.com
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 !
15  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
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).
12  0 
Avatar de Frank P
Membre à l'essai https://www.developpez.com
Le 26/07/2013 à 11:28
Les contours, le sable, la tempête... pipeau ! C'est vrai que l'imprévu (le "sable", la "tempête", ça existe, que c'est même inévitable. C'est vrai qu'un système informatique, dès lors qu'il est un peu plus ambitieux que "Hello World", est un peu comme une réalité fractale (les "contours" : plus on s'en approche, et plus on s'aperçoit que chaque module en apparence simple est en fait un système plus ou moins complexe.

Mais ce n'est pas l'essentiel. Ce n'est pas l'imprévu technique ou informatique qui fait perdre l'essentiel du temps dans un projet : c'est l'être humain, avec ses comportements parfaitement habituels, ses habitudes inamovibles, ses méthodes souvent canoniques, son organisation verrouillée et presque intouchable, ses systèmes de management et de décisions inefficaces.

------------------------------------------

La réalité en face, c'est l'incompétence de personnes qui, exécutants ou cadres, côté client/métier, côté spécification/Maîtrise d'Ouvrage ou côté réalisation informatique/Maîtrise d'Oeuvre, sont incapables de faire correctement leur travail, de communiquer correctement avec leurs interlocuteurs, de transmettre des informations correctes au maillon suivant ou de demander correctement les informations nécessaires au maillon précédent dans cette chaîne qu'est la conception d'un logiciel.

Ce sont souvent aussi des méthodes auxquelles on est attaché et qui oui, ne sont pas agiles du tout, en tout cas pas adaptées au projet à réaliser. Ou des méthodes agiles que l'on n'a pas bien compris, ou qu'on ne maîtrise pas, quant ce n'est pas que l'on rejette : car il y a dans les méthodes agiles de nombreux principes qui peuvent déplaire, aux développeurs, mais surtout à toute la hiérarchie habituelle d'un projet qui voit bousculés ses petits pouvoirs et remis en question le contrôle qu'elle exerce habituellement.

Et ne parlons pas de nos organisations, souvent bureaucratiques à l'excès, parfois rigides jusqu'à la sclérose. Un nombre d'échelons hiérarchiques tels (et des relations hiérarchiques telles) qu'une information essentielle que détient un exécutant n'atteint jamais la moitié de la pyramide (surtout si elle dérange, elle peut même s'arrêter à l'échelon immédiatement supérieur). S'ajoutent à cela des cloisonnements horizontaux, des découpages par domaine, secteur, département, service... avec les éventuelles tensions ou conflits qu'il peuvent exister entre, pour rendre la communication des informations encore plus difficile. L'organisation "verticale" et "horizontale" des sociétés les rend rarement efficaces pour gérer les projets informatiques, surtout quand le logiciel doit être prêt pour dans 3 mois, car dans un an la donne aura changé.

Jetons aussi un œil sur le management : quel est l'intérêt pour un développeur de faire son travail vite et bien quand il sait que c'est quelqu'un d'autre qui en tirera les bénéfices (reconnaissance, promotion, augmentation). Dans certains projets, ce sont ceux qui ne font pas grand-chose mais savent se vendre qui réussissent à s'attribuer les mérites de la réussite de leur collaborateurs. Ceci est rarement de nature à faire avancer correctement un projet, cela n'assure pas dans l'équipe la motivation et la cohésion nécessaire justement quand il y a un imprévu, un "coup de bourre", une "charrette". Par contre, cela encourage les abandons de poste, les congés maladie et toutes choses que l'on va rajouter bien sûr à la liste des "imprévus" qui ont entravé la bonne marche du projet. Pour ceux qui voudraient comprendre pourquoi il y a autant d'incompétents à des postes pourtant élevés dans la hiérarchie, il y a le Principe de Peter (un peu simpliste, mais hélas pas assez pour être faux).

Ajoutons à cela aujourd'hui une incapacité croissante des décideurs à prendre une décision, rapidement et de façon stable ("on va quand même pas se mouiller, ça pourrait nous retomber dessus", et comme chaque étape d'un projet est souvent soumise à plusieurs décisions, on comprend pourquoi non seulement on n'arrive pas à la date prévue, mais surtout on ne commence pas à la date prévue !

En plus de cela, il y a un vrai piège : dès qu'on fixe des délais, les différents acteurs fixent leur vitesse de croisière sur ces délais (surtout pas plus tôt, on ne voit aucun intérêt pour soi). Autrement dit, au moindre problème, au moindre impondérable, et un acteur prend 1 ou 2 semaines de retard. Le développement d'un logiciel étant un enchaînement d'étapes, c'est tout le projet qui dérape, entre les aléas des uns et les surprises des autres. Mais là encore, il y a pour cela des méthodes et des formes d'organisation pour éviter ces dérapages.

------------------------------------------

Or tout ceci, ça existe avant le projet, ça se voit, et même dans certains cas ça se sait. Qu'on ne veuille pas en tenir compte pour fixer des délais, planifier, alors oui SURPRISE, JE COMPRENDS PAS, ON PEUT PAS TENIR LES DELAIS !

La communication ça s'apprend. La motivation et l'implication des gens, cela s'encourage, la méthode, ça s'adapte (sinon ce n'est plus une méthode, mais un boulet). Et le management, car plus les projets sont importants, plus c'est là où ça pêche, ça s'apprend aussi et ça devrait s'adapter. L'organisation d'une entreprise, c'est censé s'améliorer aussi pour permettre l'atteinte des objectifs de l'entreprise, et non pour satisfaire les appétits de pouvoir des uns et des autres.

Dans tout cela, il n'y a rien d'imprévisible, rien dont on ne puisse tenir compte pour établir des plannings cohérents, réalistes. Et si l'état des compétences, des motivations, des méthodes, de l'organisation, du management ou du système de décision ne permettent pas de planifier, alors arrêtons de fixer des délais intenables et commençons d'abord par soigner le malade pour qu'il soit en état de marche !

Dans les gros projets, les problèmes informatiques, c'est 80% d'humain et 20% de technique. Les vrais imprévus sont peu nombreux et, à moins d'une destruction des locaux informatiques, jamais susceptibles de repousser notablement la fin de réalisation prévue.

En clair : IL N'Y A AUCUNE LOI QUI FAIT QU'INELUCTABLEMENT, UN PROJET DERAPE. Presque tout est "under control", le tout est de regarder les choses en face, et d'essayer de les changer si besoin pour que les projets puissent enfin suivre un cours normal.

Si nous ne sommes pas capables de regarder en face la réalité, pour voir où sont les vraies sources de dérapage d'un projet, si en plus nous n'avons pas l'envie ou le courage de changer cette réalité pour qu'enfin les projets puissent progresser normalement, alors oui, il faut multiplier par 10 pour être presque certain de ne pas déraper.
8  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 29/07/2013 à 12:40
Citation Envoyé par Matthieu Vergne Voir le message
l'adaptatif c'est de l'agile où on s'assure quand même d'avoir une première phase comme dans un cycle en V (une grosse conception).
Citation Envoyé par foetus Voir le message
Effectivement mais ce n'est pas un "vrai" cahier des charges qui a demandé 2-3 mois, voire plus, à établir.

À mon avis c'est le côté "faux-cul" de la chose.

Méthode Agile == Pas de cahier des charges, mais de la conception continuelle.


Comme le dit Nathaniael....

Où avez-vous lu ça ??????????

C'est ce qu'on vous enseigne ??? C'est ce qui se passe aujourd'hui avec le buzz-word ????

Non seulement ce n'est en rien partie de l'approche agile, mais c'est même le contraire... Je vous en prie, relisez le Manifeste...

Il n'est absolument nulle part mentionné qu'on ne doive pas faire de cahiers des Charges, ni que les étapes identifées lors de l'établissement du Cycle en V ne doivent pas être respectées...

La SEULE chose qui change, c'est primo le caractère non-définitif des architectures / décisions établies au départ, secondo la légerété des documents associés à chaque étape, et tertio un cycle ultra-court et partiel par rapport à un cycle long et total...

ça me déséspère de voir que de telles idées se propagent - ou sont malheureusement appliquées...

Une méthodologie agile n'est qu'une MANIERE SOUPLE de faire un développement standard...

IL FAUT connaître et les étapes et les documents standards du développement global (dont Waterfall et cycle en V sont tirés) et avoir/produire les documents et étapes essentiels..


ça m'énerve, ces trucs de mode qui finalement dénaturent tout le fond de la pensée... .

Il FAUT avoir un Cahier des Charges, une spec, une architecture, des tests, bref tout ce qui est prévu. normalement......
9  1 
Avatar de NaetoH
Membre à l'essai https://www.developpez.com
Le 23/07/2013 à 10:54
C'est un problème qui ne changera jamais, surtout en France.

La direction pense qu'une deadline très courte permet au développeur de coder plus vite, alors qu'en réalité ils codent surtout plus sale.
7  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 29/07/2013 à 18:26
T'as déjà un léger problème :

Citation Envoyé par foetus Voir le message

Mais par exemple dans un cahier des charges tu as de l'UML (diagrammes de classes, diagrammes USE CASES, diagrammes de déploiement), tu as des planning ....
  • Pourquoi y aurait-il un outil paticulier pour un Cahier des Charges ????? Un simple papier et crayon ou un éditeur de texte suffit..
  • Il ne peut pas y avoir de "diagramme de déploiement" dans un CdC
  • Encore moins de planning...


Mais quel foutoir vous avez dans la tête !!!!

Vous mélangez le quoi, le comment, le quand...

  • Le Cahier des Charges c'est quoi, un point c'est tout...
  • Comment, ça devient de la conception...
  • Quand, c'est du planning, et ça dépend des pressions/contraintes/méthodologies/budgets/difficultés, etc etc...


Quant aux méthodes XP et Scrum, et autres, elles sont apparues après.. Et je suis de la génération des gens du Manifeste, merci pour eux

Ce pourquoi eux (et moi) sommes arrivés à ces conclusions c'est par une longue pratique des cycles en V dans de grosses équipes.....
7  0 
Avatar de martopioche
Membre éclairé https://www.developpez.com
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.
8  2 
Avatar de GPPro
Membre éprouvé https://www.developpez.com
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...
6  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 23/07/2013 à 11:27
Citation Envoyé par martopioche Voir le message
Exemple très intéressant car ce type de qualification (point bloquant ou non) devrait être définit par l'Usex... Ou la priorité par le marketing. Finalement, est-ce que les clients (donc les commerciaux) se sont investi dans la réalisation ? Car si ils reviennent avec un NoGo à cause du choix d'avoir une autocompletion, le "dev" a fait son job. Et à mon sens, là c'est une erreur commerciale : en attendant, le site n'est pas en ligne, il ne gagne pas en notoriété, la boite continue de perdre de l'argent (ou de ne pas en gagner) alors que la mise en ligne n'aurai pas empêché d'améliorer et faire un upgrade. We ship, then we test...
Idéalement, une bonne méthode serait de faire exactement l'inverse que ce qui a été fait dans le projet dont je parle : choisir le minimum de fonctionnalité, vraiment juste ce qu'il faut pour que l'appli puisse remplir son rôle et qu'on puisse mettre en prod. Ensuite, on enrichit. Ca a l'avantage supplémentaire de permettre d'avoir du feedback des utilisateurs et de développer moins de fonctionnalités inutiles (vous savez, ces fonctionnalités sur lesquelles vous passez beaucoup de temps, et 6 mois après la mise en prod, on se rend compte que PERSONNE ne s'en sert, parce que ça ne correspond à aucun besoin...)
6  0