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 !

25 signes précurseurs
D'échec d'un projet

Le , par koopajah

23PARTAGES

4  0 
25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec

Malgré tous nos efforts pour faire de chaque développement logiciel en entreprise un succès, certains projets restent maudits depuis leur commencement. Voici 25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec.

- Le projet change de nom pour la troisième fois en autant de mois.

- Le chef de projet décide qu'il vaut mieux écrire une version séparée du logiciel pour les Etats-Unis plutôt que d'internationaliser une version unique.

- Les spécifications ont commencé quatre mois après le début du développement.

- Le nouveau directeur de R&D informe fièrement les dirigeants que le projet sera fini à 99% en avance sur le planning et leur assure que le logiciel peut-être livré directement aux clients sans avoir besoin de phases de tests.

- Vous êtes un développeur web. Vous ouvrez l'archive ZIP qui contient les fichiers HTML produits par votre client pour le site que vous intégrez à votre application web. Vous découvrez que les documents HTML du client sont simplement des fichiers Microsoft Word sauvegardés au format HTML.

- Le mémo dit que vous allez développer une application 64 bits sur une plateforme 16 bits.

- Le développeur ne comprend pas le document de spécifications et continue de coder malgré tout. Et l'équipe de validation ne sait pas comment réaliser ses tests mais "teste" malgré tout.

- Quand vous voyez le budget du projet, vous réalisez que plus de la moitié a été dépensée pour demander à un infographiste de créer une maquette de la page d'accueil du site, sans même s'assurer que le design était réalisable. Ou sans aucune considération pour les milliers de pages de contenus qui existeront en plus de cette page d'accueil.

- L'utilisateur ou le client demandent de nouvelles fonctionnalités au lieu de se focaliser sur la résolution de bugs et l'amélioration des performances.

- Vous trouvez une liste de 16 bonnes pratiques de développement et réalisez qu'aucune d'entre elles n'est suivie.

- Les rapports d'avancement sont vus comme une insubordination.

- Le nouveau dirigeant remplace toutes les personnes ayant une connaissance profonde de l'organisation par des externes de son ancienne société.

- C'est un gros projet et son nom est Projet Iceberg. Ou alors c'est la troisième fois que la société essaye de l'arrêter et le projet porte le nom de code Phoénix. Etrangement, vous ne croyez pas que celui ci renaîtra de ses cendres.

- Même les clients qui ont eu la version gratuite sont énervés.

- Le manager de votre projet critique (rapportant 80% des revenus de votre société) a appris la technologie choisie depuis moins de trois mois et il forme 4 nouveaux développeurs en même temps. Le manager a eu droit a une durée de trois mois pour réaliser le projet.

- Ils ont changé le chef de projet et relocalisé le projet entier dans une autre ville. (Vous vous considérez comme chanceux que les deux villes soient sur le même continent.)

- Le chef de projet décide d'appliquer la méthode Agile pour "gagner du temps".

- L'équipe de management décide de dépenser un million d'euros sur un projet en valant 20 000. Ensuite les managers décident en accord avec l'équipe achat de la société que le logiciel d'un million d'euros demande un matériel valant 2 millions d'euros. Pendant ce temps, une secrétaire achète un PC d'occasion et un CD-Rom contenant de nouveaux logiciels d'automatisation. Elle code le projet pendant sa pause déjeuner. (On pourrait en fait considérer celui-ci comme un succès).

- Le chef de projet vous informe que maintenir un historique complet de toutes les bases de données est une fonctionnalité obligatoire de l'application, mais il n'a pas eu le temps de (lire : ne sait pas) réaliser un modèle de données pour ça. Alors il a décidé de prendre de l'avance en commençant l'interface web et de s'en inquiéter plus tard. Et c'est le Le chef de projet !

- Le chef de projet dit : "soyez créatifs". Cela se produit après que l'équipe de management ait diminué l'effectif sur le projet de 20%. Et après que l'équipe informatique ait récupéré du matériel prévu pour le recyclage, indiquant que c'était votre environnement de développement.

- Quand vous êtes embauché comme l'architecte principal et qu'après 4 semaines dans le projet vous ne comprenez toujours pas ce qu'ils veulent que vous fassiez. Finalement vous découvrez qu'ils ne savent pas non plus.

- Quand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà.

- L'équipe dirigeante demande une date de livraison de l'application avant même que vous ayez reçu une seule information concernant les fonctionnalités demandées.

- Quand le tout nouveau chef de projet crée un planning sans consulter personne de l'équipe technique et alloue pour chaque élément 2 semaines dans le planning (y compris les éléments comme "architecturer la base de données" et "écrire le code".

- On vous donne de nouvelles fonctionnalités à développer le jour de la livraison. Souvent.

C'est une liste basée sur des témoignages de nombreux professionnels de l'informatique. Mais, au final, c'est peut être encore incomplet ? Avez-vous des anecdotes à partager avec nous ?

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

Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 08/07/2009 à 14:34
Pour rappel : Le projet "Cauchemar"

Tout commence le 2 janvier, et votre tête souffre encore de vos derniers excès.

Vous êtes assis dans une salle de conférence avec plusieurs managers et quelques uns de vos collègues. Vous êtes un chef d'équipe. Votre patron (Chef de Projet) est là et il a amené avec lui tous ses chefs d'équipe. Son patron (un chef de service ou de département) a décidé de cette réunion.

« Nous avons un nouveau projet à développer! », dit le patron de votre patron. Appelons-le BB (pour BigBoss). BB décrit l'essentiel du nouveau marché identifié et du produit à développer pour l'exploiter.

« Nous devons avoir ce produit sur le marché pour le 4ème trimestre : le 1er octobre! », exige BB. « Comment cela vous prendre-t-il de temps pour faire l'analyse ? ».

Vous levez votre main. Votre patron essaie de vous arrêter, mais vous n'êtes pas conscient de ses efforts.

« Monsieur, nous ne pouvons pas vous dire combien de temps prendra l'analyse tant que nous n'avons pas un cahier des charges

« Le cahier des charges ne sera pas prêt avant 3 ou 4 semaines », dit BB. « Alors, imaginez que vous avez déjà le cahier des charges devant vous maintenant. Combien de temps avez-vous besoin pour l'analyser ? »

Personne ne respire. Tout le monde se regarde pour voir si quelqu'un a une idée.

« Si l'analyse dépasse le 1er avril, alors on a un problème. Pouvez-vous finir l'analyse d'ici-là ? »

Votre patron rassemble son courage et déclare : « On trouvera un moyen, Monsieur! ». Votre mal de tête augmente de 2 aspirines.

« Bien. ». BB sourit. « Maintenant, combien de temps pour la conception ? »

« Monsieur, » dites-vous. Votre patron pâlit visiblement. Il est clairement inquiet quant à sa prime annuelle. « Sans une analyse, il n'est pas possible de vous dire combien de temps prendra la conception. »

L'expression de BB se durcit. « IMAGINEZ que vous avez déjà l'analyse! », dit-il, tout en vous fixant de ses petits yeux ronds. « Combien de temps cela vous prendra pour la phase de conception ? »

2 aspirines ne suffiront pas... Votre patron, dans une tentative désespérée de sauver sa future prime : « Hé bien, Monsieur, dans la mesure où il ne reste plus que 6 mois pour finir le projet, la conception ne devrait pas dépasser 3 mois. »

« Je suis heureux que vous approuviez ce choix », affirme BB, rayonnant. Votre patron se détend. Il sait que sa prime est assurée.

BB poursuit : « Donc, l'analyse sera prête pour le 1er avril, la conception pour le 1er juillet, et cela vous donne 3 mois pour coder le projet. Cette réunion est un excellent exemple du bon fonctionnement de notre nouvelle politique d'accords et de délégation ("consensus and empowerment". Maintenant, dégagez et commencez à bosser. Je veux les plans-qualité et le plan projet sur mon bureau pour la semaine prochaine. Oh, et n'oubliez pas votre réunion d'équipe multi-projets et les rapports qui seront nécessaires pour les audits-qualité des mois à venir. »

« Oublions l’aspirine », pensez-vous alors que vous vous en retournez vers votre open-space. « J'ai besoin de bourbon ».

Visiblement excité, votre patron vient vers vous et dit : « Quelle fantastique réunion! Je pense que l'on va vraiment faire quelque chose de révolutionnaire avec ce projet! ».
Vous approuvez d'un hochement de tête, trop dégoutté pour faire quoique ce soit d'autre...

« Au fait, » continue votre patron, « j'ai failli oublier. » il vous tend un document d'une trentaine de pages. « Vous vous souvenez que l’ISO vient faire une évaluation la semaine prochaine. Voici le guide d'évaluation. Vous devez le lire entièrement, le mémoriser puis le détruire. Il vous indique comment répondre à n'importe quelle question que l’ISO pourrait vous poser, il vous indique également quels endroits du bâtiment vous pouvez leur montrer et ceux que vous devez éviter. Nous devons obtenir l’accréditation pour juin! »

Vous et vos collègues commencez à travailler sur l'analyse du nouveau projet. C'est difficile dans la mesure où vous ne possédez aucun cahier des charges. Mais, avec les 10 minutes d'introductions données par BB en ce matin fatal, vous avez quelques idées de ce que le logiciel est supposé faire.

Le cahier des charges arrive le 15 février, soit 1 mois et demi après le démarrage du projet.

Puis une nouvelle révision arrive le 20, le 25 et toutes les semaines suivantes. Chaque nouvelle révision contredit la précédente. Visiblement, les gars du marketing qui l'écrivent, bien qu'ils aient toute la délégation de pouvoir nécessaire, ne trouvent pas d'accord.

En dépit de tout cela, vous et vos collègues poursuivez votre travail d'analyse.

Et un miracle se produit!!!

Le 1er avril, vous avez fini l'analyse!! Vous allez trouver votre patron et gémissez :
« Comment avez-vous pu dire à BB que nous avions fini l'analyse ??? »
« Avez-vous regardé un calendrier dernièrement ? c'est le 1er avril! »
L'ironie de la date ne vous échappe pas.
« Mais nous avons encore tant de points à éclaircir et analyser! »
« Qu'est-ce qui vous prouve que vous n'avez pas fini ? » demande impatiemment votre patron.
« Quuuooiiii ???? ...»
Mais il vous coupe par un : « L'analyse ne peut pas continuer indéfiniment, elle doit s'arrêter à un moment donné. Et puisque c'est la date à laquelle elle devait s'arrêter, elle est donc finie. Maintenant, retournez à votre bureau et commencez la conception. »

Alors que vous vous traîner vers votre bureau, vous commencez à considérer les avantages de garder une bouteille de bourbon dans le tiroir à dossier de votre bureau.

Ils ont organisé un pot pour célébrer la fin dans les temps de l'analyse. BB a prononcé un interminable discourt sur la délégation. Et votre patron a félicité sa troupe pour sa cohésion et son exceptionnel esprit d'équipe. Finalement, le grand directeur du département monte sur l'estrade et annonce que l'audit ISO s'est très bien passé et a remercié tout le monde pour avoir bien étudié puis détruit le guide d'évaluation.

Alors que les semaines s'écoulent, vous et votre équipe commencez la conception du logiciel.
Bien sûr, vous découvrez que l'analyse sur laquelle la conception est censée se baser n'est pas sans défauts. Mais lorsque vous annoncez à votre patron que vous avez besoin de renforcer l'analyse sur ses points faibles, il déclare simplement : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! »

Alors, vous et votre équipe dégrossissez la conception du mieux que vous le pouvez, sans vraiment savoir si le cahier des charges a été correctement analysé ou non. Bien sûr, cela n'a pas grande importance dans la mesure où de nouvelles versions du cahier des charges continuent de s'amonceler semaine après semaine.

A mi-chemin en plein dans la phase de conception, le département marketing annonce qu'il a repensé le cœur du système. Leur nouveau cahier des charges est complètement restructuré. Ils ont éliminé quelques domaines fonctionnels majeurs, et les ont remplacés par des fonctionnalités que des études de marchés auprès de clients potentiels ont montrées plus en adéquation avec les attentes de ces-dits clients.

Vous annoncez à votre patron que ces changements signifient que vous devez re-analyser et re-concevoir la plus grande partie du logiciel. Mais il vous répète : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! » Et vous y retournez...

Dégrossir, hacher, trancher, couper... vous essayez de créer une sorte de document de conception qui reflète vaguement le nouveau cahier des charges. Toutefois, les évolutions de ce document ont simplement augmenté en fréquence et amplitude.

Vous tracez votre chemin avec obstination au travers de ce cahier des charges.

Et le 1er Juillet, un nouveau miracle fut!

Vous avez fini la phase de conception! Plutôt que d'aller trouver votre patron pour vous plaindre, vous commencer à stocker dans le tiroir-dossier de votre bureau des bouteilles de vodka.

Ils ont organisé un pot pour célébrer la fin dans les temps de la conception, et leur accréditation ISO. Cette fois, le discourt de BB est si interminable que vous devez aller plusieurs fois aux toilettes.

Il y a des nouvelles bannières et de nouvelles affiches sur les murs de tous les bureaux. Ils montrent des aigles et des alpinistes, et ils parlent d'esprit d'équipe et de délégation. Elles se regardent mieux après quelques scotches. Cela vous rappelle que vous devez faire de la place dans votre bureau pour le brandy.

Vous et votre équipe commencez à coder. Mais vous découvrez rapidement que la conception est inexistante dans plusieurs domaines importants. Vous convoquez une session de conception dans une des salles de conférence afin de résoudre les points les plus critiques. Mais votre patron vous surprend et disperse la réunion par un : « La phase de conception est terminée. La seule activité autorisée est le codage. Maintenant, retournez-y ! »

Votre patron engage un consultant afin de construire des outils permettant de calculer le pourcentage d’avancement du projet en se basant sur les tâches du planning prévisionnel. Il affiche sur le mur un graphique en forme de thermomètre géant, avec le nombre 100% au sommet. Chaque jour, il allonge la ligne rouge en fonction des tâches terminées.

Trois jours après l'apparition du graphique, votre patron vous arrête dans le couloir : « Le graphique ne progresse pas suffisamment vite. Nous devons atteindre les 100% pour le 1er octobre. »

« M... Mais nous n'sommes mêm'pas sûr k... kk... ke'le planning pr..présivio…prévisionnel soit complet » prononcez-vous péniblement.
« Nous devons atteindre les 100% pour le 1er octobre. », répète votre patron. « Êtes-vous sûr que vos rapports d’activités sont à jour ? »
Puis, dans un flash de génie du management, il déclare : « Ca y est, je sais! Je veux que vous instituiez une nouvelle politique de reporting dans votre équipe d'ingénieurs. Vos rapports d’activités devront indiquer le pourcentage d’avancement de chaque tâche. Voilà qui devrait augmenter le pourcentage d’avancement global ! »

Vous décidez de ne pas lui dire que cela va requérir deux mois/homme non planifiés. Vous décidez de ne rien lui dire du tout. Vous décidez que des injections sous-cutanées d'éthanol pure représentent la seule solution. Vous faites les arrangements nécessaires.

Dégrossir, hacher, trancher, couper... vous et votre équipe codez comme des fous. Au 1er août, votre patron, regardant d'un air soucieux son graphique, impose une semaine obligatoire de 50 heures.

Dégrossir, hacher, trancher, couper... au 1er septembre, le thermomètre géant indique 112% et votre patron vous demande d'écrire un rapport expliquant pourquoi vous avez dépassé le nombre de tâches prévues initialement. Il impose les samedi obligatoires.

Dégrossir, hacher, trancher, couper... Les esprits s'échauffent, les gens démissionnent, le département qualité fait pleuvoir les rapports d'anomalies chez vous, les clients demandent des guides d'installation et d'utilisation, les vendeurs demandent des previews pour des clients particuliers, le cahier des charges continue d'évoluer et le magasin d'alcools n'accepte plus votre carte de crédit. Quelque chose doit se passer.

Le 15 septembre, BB convoque tout le monde.

Alors qu'il entre dans la salle, ses yeux sont injectés de sang. Lorsqu'il parle, les tons graves de sa voix soigneusement posée vous causent des problèmes gastriques immédiats. « Le directeur qualité m'a informé que ce projet implémente moins de 50% des fonctionnalités requises! Il m'a également informé que le système se plante tout le temps, affiche des résultats erronés et se traîne lamentablement. Il s'est également plain de ne pouvoir suivre le rythme avec toutes ces livraisons quotidiennes que vous lui faites. »

Il s'arrête quelques secondes, visiblement en train de se calmer : « Le directeur qualité estime qu'à ce taux de développement, nous ne seront pas capable de sortir un produit avant décembre! ». En fait, vous pensez plutôt "mars", mais vous n'en dites rien.

« Décembre!!! », hurle BB. Les personnes baissent leur tête comme s'il leur pointait un fusil d'assaut vers eux. « Décembre est absolument hors de question. Chefs d'équipe, je veux de nouvelles estimations sur mon bureau pour demain matin. Je déclare dorénavant les semaines de 65 heures obligatoires tant que ce projet n'est pas fini. Et il a intérêt à finir pour le 1er novembre! »

En quittant la réunion, on peut l'entendre murmurer : « accords... délégations, ... pfff, à ch...! »

Votre patron est tout blanc. Sa prime annuelle vient de s’envoler. « Avez-vous quelque chose à boire ? » Ayant tout juste fini votre dernière bouteille de Bone's Farm, vous extrayez une bouteille de Thunderbird de votre étagère et en versez dans son reste de café. « combien cela va prendre pour finir le projet ? »
« On a b'soin de figer l'cahier des charges, de l'analyser, de concevoir et de l'implémenter. », dites-vous d'une voix plus que pâteuse.
« Pour le 1er novembre ??? », dit votre patron, « Impossible! Retournez juste coder ce p... de logiciel! », hurle-t-il.

Quelques jours plus tard, vous apprenez que votre patron à été transféré au département de Test. Le taux de turn-over a atteint des sommets. Les clients, informés à la dernière minute que leurs commandes ne pourront être honorées, ont commencé à les annuler. Le Marketing réévalue si, oui ou non, ce logiciel doit faire parti des objectifs généraux de la société, etc., etc.. Les mémos volent, les têtes tombent, les politiques changent, et le cours des choses est, en général, bien sombre...

Finalement, en mars, après bien trop de semaines à 65 heures, une version très instable du logiciel est prête. Sur le terrain, le taux de découverte des bugs est élevé, et les équipes de support technique voient leur volonté poussée à l'extrême pour traiter les plaintes et demandes diverses de clients en colère.
9  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 11/07/2009 à 8:19
Citation Envoyé par mister3957 Voir le message
Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
Il existe des entreprises où :

Les clients savent ce qu'ils veulent et font un cahier des charges très exhaustif.

Les chefs de projets estiment correctement les ressources nécessaires pour le périmètre fonctionnel à accomplir ...

Les chefs de projets arrivent à convaincre le client de restreindre son périmètre, d'augmenter les délai et/ou son budget

Les développeurs peuvent choisir les technologies qu'ils veulent car ils ont le temps de faire de la veille, de recevoir les formations qu'ils souhaitent

Les clients testent sérieusement l'application durant la phase de recette et exprime clairement les petits problèmes rencontrés

Les clients ayant clairement défini ce qu'ils voulaient, il n'y a pas de mauvaise surprise.
Et lorsqu'ils ont oublié un petit truc qui paraît plus grave à leurs yeux qu'à ceux des développeurs qui n'en auront que pour quelques secondes à le corriger, ils ont tellement honte qu'ils vous amènent des croissants chauds ...

....

et là, je me réveille !
4  0 
Avatar de Patriarch24
Membre expérimenté https://www.developpez.com
Le 11/07/2009 à 13:44
Quand le client n'a pas de culture de projet ça veut dire quand tu lui envoie les specs pour validation, il t'appelle et te dis bah moi je valide pas ça, ce que je veux c'est voir une 1ere version dans laquelle je peux valider le fonctionnelement de l'appli.
Ce n'est pas complètement stupide. Le client, ce qu'il souhaite au final, ce n'est pas un bout de papier lui expliquant comment fonctionne le logiciel, mais un logiciel fonctionnel.

Je commencerai par dire que je reconnais ma situation dans tous ces témoignages, en affirmant que malheureusement, c'est une terrible fatalité. La (trop) faible percée des méthodes agiles ces dernières années ne permet pas de changer les mentalités en profondeur. Trop de gens sont encore persuadés qu'un projet logiciel se construit comme une maison, avec d'abord des plans, des fondations, le terrassement, etc. Il n'en est (presque toujours) rien. Le malheur, c'est que beaucoup de gens le savent (beaucoup d'autres l'ignorent aussi), mais ne veulent pas changer les habitudes de travail, et de son côté le "client" ne veut pas faire l'effort de s'intégrer dans le déroulement du projet, dans lequel il tient pourtant un rôle central.

Je ne prendrais qu'une sous-partie d'un projet comme exemple : celui du cahier des charges, considéré comme l'élément indispensable par tous, et quasiment toujours responsable des échecs. Dans le déroulement d'un projet "construction de maison", les développeurs ont besoin du cahier des charges pour analyser d'abord, puis concevoir et enfin développer... Le problème c'est que : le client ne sait pas exactement ce qu'il veut, et même s'il le sait, est-il en mesure de le coucher sur papier ? EN admettant même qu'il soit suffisamment explicite, l'équipe de développement sera-t-elle à même de le comprendre ? D'implémenter exactement les bonnes fonctionnalités ? De décrypter la vision du client ?

Tellement d'études démontrent que cette approche de projet est erronée dans 99% des cas. Ces études mettent en corrélation ces évidences (vos témoignages apportent encore des preuves !), à savoir que le taux d'échec est très élevé dans les projets gérés "en cascade" (mode construction de maison). Un jour, j'ai expliqué à mon boulot comment les méthodes agiles permettaient de résoudre une grande partie de ces problèmes, bien que n'étant pas la panacée. On m'a répondu : "commençons par travailler en mode projet" (extrait texto des bouches des décideurs). Au secours. Désarroi. Le mode projet, ça veut dire quoi exactement ?

Le jour où les décideurs, mais aussi les équipes de développeurs/architectes/chef de projets, prendront conscience que les échecs ne sont pas dus à l'incompétence de leurs équipes de développement ou au client qui fait des caprices du genre "je veux voir un logiciel fonctionnel pour valider" (ce qui est parfaitement légitime, c'est ce pour quoi il paie !), et que le principe de base de réussite d'un projet, la COMMUNICATION, sera l'élément central de tout projet, alors on (tout le monde d'ailleurs) vivra des jours meilleurs.

Je finirai en citant Alistair Cockburn : "Le développement de logiciel est un 'jeu collaboratif' dans lequel les participants utilisent des marqueurs pour se souvenir, se stimuler et s’informer mutuellement au cours de chaque mouvement du jeu. La fin du jeu est la 'production' et le 'déploiement' d’un système ; le résidu de ce jeu est un ensemble de marqueurs destinés à informer et assister les joueurs dans la partie suivante qui consiste à modifier le système existant ou à produire un système similaire." Le titre d'un de ses livres est : "Agile software development : the cooperative game", livre dans lequel il décrit cette activité comme "a cooperative game of invention and communication". Je conseille à de nombreuses personnes de méditer sur cet aspect (j'y médite toujours moi-même...).

Pour terminer, je précise qu'il n'y a aucune forme d'arrogance, de mépris ou de complexe de supériorité dans me propos. Je tiens juste à ouvrir un champ de réflexion nouveau, fort intéressant (je conseille la lecture du manifeste agile - agile manifesto -) à ceux qui ignorent de quoi je parle. En référence, documentez-vous sur des méthodes telles q'Unified process, Scrum, XP, Crystal. Je vous garantis que vous y trouverez des solutions à tous ces problèmes. Après, et c'est la tâches sans aucun doute la plus difficile, il vous reviens de convaincre et de changer les mentalités. Après avoir vous-mêmes été convaincus (ce qui, je l'avoue d'expérience, est franchement pas simple).
4  0 
Avatar de bartoumi
Membre actif https://www.developpez.com
Le 13/07/2009 à 15:29
Salut tout le monde

Jusque la, tout le monde parlait de relation entre Client, Commerciaux , Managers et développeur et les incompréhensions entre ses personnes la

Je vous ajoute un petit point :
Votre responsable vous demande d'estimer une charge ou faire une petite étude sur une fonctionnalité a ajoutée (comprenez "Fait moi ça pour Hier".
Ok, vous jouer le jeu. Vous allez faire de votre mieux (surtout en temps de crise)
Vous donnez la réponse suivante : (par exemple) ça prend 10 jours à faire en faisant comme ça.
Le responsable vous répond : 10 jours !!! non vous allez le faire en deux jours (tests y compris).
Que faites vous ?
Vous allez le faire a l'arrache en cinq jour (donc trois jours de retard et de remontrance - et c'est pas facile-)

Et voila le pire : Y'en auras tirs un collègue à vous pour dire (quand vous n'êtes pas la bien sur) qu'il pouvait le faire en une demis journée (c'est du vécu) .
Il passera trois jours à chercher des irrégularité dans votre code pour les montrer aux responsable. Du coup le chef vous demande un compte-rendu avec argumentaire pourquoi vous avez passez cinq jour dessus.
le compte rendu me prendra 1/2 journée a faire + une réunion de deux heure.

Votre collègue ne l'a pas fait contre vous , il veut juste se faire recruter chez le client final (du coup il est prêt a tout)

si on fait le compte j'ai mis 6 jours a le faire (dev+ test + compte rendu et réunion) je reconnais un peu a l'arrache avec des horaire pas possible.

après cela, une ambiance de "lourdeur" vas s'installer dans l'équipe et un nouveau système de management vas s'installer que j'appellerai: MRMF
Management par la Recherche du Meilleur Fayot

Sachant que ce que je viens de décrire se produit a tout les échelons d'une hiérarchie dans une entreprise, je vous laisse imaginer une des grande cause intrinsèque a l'échec de nos projet en gle.

Pour finir, j'ai vu quand même des projet réussir , c'était des projet de moins de trois mois à deux personne Max.
4  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 13/07/2009 à 17:45
Citation Envoyé par cherkaoui.j.e Voir le message
Quel est le problème avec la méthode Agile?
Personnellement je n'ai pas de problème particulier avec les méthodes agiles en tant que telle. Bien au contraire.

Par contre avec le discours qui consiste à dire "utilisons les méthodes agiles pour gagner du temps", j'aurais plusieurs reproches à formuler.
  • Tout d'abord, même utilisée correctement, les méthodes agiles ne représente pas toujours un gain de temps de développement (généralement, c'est plutôt un gain de réactivité et un gain lors des phases de maintenance et d'évolution) et rarement (pour ne pas dire jamais) un gain de temps à court terme s'il faut tout mettre en place.
  • Généralement ce type de discours est tenu par des gens qui ont vaguement entendu parler des méthodes agiles et surtout qui n'ont pas pesé toutes les conséquences de leur mise en place. Utiliser une méthode aussi bonne soit elle là où elle n'est pas adaptée n'est clairement pas une bonne idée.


Pour résumer, les méthodes agiles ne sont pas des "silver bullet". Elles ne vont pas résoudre tous les problèmes possibles et imaginables, elles ne sont pas applicables dans tous les contextes et elles ne se mettent pas en place du jour au lendemain en un claquement de doigt.
En particulier, dans un environnement particulièrement "bordélique" et sans qualité, elles ne seront probablement que peu efficaces (et généralement mal appliquées) et ont pour effet pervers de donner bonne conscience aux personnes qui continuent pourtant à aller droit dans le mur.
4  0 
Avatar de jabbounet
Membre expert https://www.developpez.com
Le 22/01/2010 à 15:07
Citation Envoyé par lepinekong Voir le message
Ca c'est pour les p'tits joueurs. Pour les gros, ils le confient à des cabinets de conseil hyper cheros et le prix grimpe avec le niveau de l'abstraction
L'avantage d'avoir une coquille vide c'est qu'on peut faire ce qu'on veut au moins.
j'ai souvenir d'un "on dit" d'un ancien collègue a propos de certaines personnes.

Si c'est simple tu dit que c'est compliqué et tu le fait
Si c'est compliqué tu dit que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
4  0 
Avatar de ram-0000
Rédacteur https://www.developpez.com
Le 07/07/2009 à 15:26
Citation Envoyé par pseudocode Voir le message
le code a 6 mois d'avance sur la spec.
Ah ? Vous avez une spec quand même (vieux motard que jamais)
3  0 
Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 11/07/2009 à 13:15
Citation Envoyé par mister3957 Voir le message
Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
Non. Des fois c'est pire. J'ai vu:

La "maquette" présentée aux clients, qui était en fait un fichier PPS, avec des screenshots bricolés avec paint shop pro. Et fait pas une ligne de code n'avait encore été écrite.

Le commercial et le patron qui impose à l'équipe de développement les outils à utiliser (et pas les moindres: l'EDI de développement). Bien sûr, ni l'un ni l'autre n'ont de connaissances en informatique.

Le commercial (le même) qui vend des nouvelle fonctonnalités aux clients avant même que ce soit développé (et avant même de savoir si c'est faisable). Démerde-toi après à développer ça. Il faut que ce soit fini pour vendredi.
3  0 
Avatar de millie
Rédacteur https://www.developpez.com
Le 11/07/2009 à 19:56
Citation Envoyé par 10_GOTO_10 Voir le message

La "maquette" présentée aux clients, qui était en fait un fichier PPS, avec des screenshots bricolés avec paint shop pro. Et fait pas une ligne de code n'avait encore été écrite.
D'où le nom de maquette

EDIT : Ah moins que la maquette était présentée par les commerciaux en tant que produit presque fini et non en tant que maquette ?
3  0 
Avatar de B.AF
Membre chevronné https://www.developpez.com
Le 18/09/2009 à 0:01
Il ne peut pas y avoir d'industrialisation au sens où jusqu'à aujourd'hui et pour encore un moment, à la différence de quasi toutes les industries, la chaine de production ne peut pas être outillée.

Voilà.

On a pu le faire pour des voitures, on a pu le faire pour l'alimentaire. Pas pour l'informatique. Comme tous les process sont basés sur la spécialisation, aucun ne fonctionne, puisque finalement une usine logicielle...
- Ne supporte pas le nombre, plus le nombre de développeur augmente, plus la productivité baisse, voir j'ai déjà vu des projets au point mort, chacun bloquant l'autre; le backdraft de l'offshoring
- Ne supporte pas la spécialisation, malgrè toutes les grandes théories, il est quasi impossible de développer en black box, en china wall et autres conneries de grands stratèges
- Ne peut pas industrialiser sa qualité : la qualité ne peut être garantie que par des personnes à même niveau de compêtence. On ne peut tester intelligement que ce que l'on comprendre, le test idiot par combinatoire est juste un gouffre financier.

Le problème de fond est qu'un développeur est un traducteur d'ambiguités structurelles. La plupart des langages aujourd'hui sont fait par des développeurs pour des développeurs. La plupart des langages sont basés sur une sémantique et une abstraction forte.

Le développement est fondamentalement le seul métier ouvrier du monde qui réussi à infirmer l'idiot et pourtant toujours enseigné modéle de l'usine d'épingle (smith) et qui ne supporte pas la taylorisation.
Pour une raison simple : le développement n'est pas une tâche simple, et n'est pas découpable en une somme de taches simples et répétitives.
Le développement est un métier qui ne demande pas une organisation mécanique mais une organisation organique. Si l'un des organes devient défaillant, toute la chaine est enrayée.

Au regard de cela, on ne peut que constater avec effroi et stupéfaction la capacité infinie des entreprises à forcer le cube à rentrer dans le triangle en embauchant des contremaitres toujours plus chers et des ouvriers toujours moins chers, en se plaignant constamment de la réussite de plus en plus hazardeuse de leurs projets, des dépassements de budgets, et autres.

L'informatique et réussir un projet en informatique de bout en bout, de la première phrase au premier anniversaire en production n'est pas un métier comme un autre : c'est un art. C'est le truc con qui me fait aimer mon job tous les jours, c'est cet acharnement à matérialiser l'abstrait et à rendre la vie des autres plus simple qui me plait.

Tous les jours je parle ici ou ailleurs avec des gens qui ont du génie. Des gens qui manipulent tous les jours des notions et des principes que 98% des gens ne comprennent pas et ne feront pas l'effort de comprendre. Je vois toutes ces personnes qui vent et marée font tout pour faciliter la vie des autres. Parce que si certains disent que la finance est l'économie, que la mondialisation fait tout, pensez tous à une simple chose : et si demain, aucun ordinateur dans le monde n'existait plus. Plus rien. Nada
Plus d'email. De tableur. D'ERP. De paiement Web. De Fix.

Retour au fax, au téléphone, à la feuille de papier. Les comptables faisant leurs comptes en T, calculant les amortissements à la calculatrice.
Le contrôleur de gestion consolidant à la main.
Le vendeur appelant le stock pour se faire faxer un état des stocks sur les docks.
Chaque grande surface obligée de faire ses rayonnages à la main.
Chaque placement financier réalisé par fax, chaque bourse revient à la criée.
Les laboratoires devraient faire leurs simulations à la main.
Chaque entreprise devrait ouvrir une filiale dans le pays concerné pour y vendre.

L'économie aujourd'hui, dans 80% des cas, fonctionne parce que des gens comme moi et vous codons tous les jours. Parce que tous les jours on a envie de faire plus loin, plus haut plus rapide.
3  0