Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Expert éminent sénior
    En même temps qui a véritablement le choix d'éluder un tel luxe ? A moins d'être la rock-star de la boite, interne a priori, versus un jeune consultant de chez Altruc ou Choupa-Stevia qui arrive l'air complètement terrorisé et qui veut juste se faire une première expérience...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  2. #42
    Membre émérite
    Bonjour.

    Développeur est un vrai métier qui demande de réelles compétences.

    Cela ne m'étonne pas qu'il faille reprendre à zéro 80% des projets informatiques.

    Selon moi, avec mon expérience actuelle et mes diverses rencontres avec des développeurs, le problème principal est la rigueur.

    Le deuxième problème est la capacité à architecturer un programme.

    Ces deux problèmes suffisent à mettre en péril un projet.

    Je ne parlerai pas des autres problèmes, parce que dépendant du langage et des technos.



    Il est possible aussi de repartir de zéro, tout en usant de l'expérience et des bénéfices du projet antérieur. Rien ne l'empêche.

  3. #43
    Expert éminent sénior
    Citation Envoyé par moldavi Voir le message
    Il est possible aussi de repartir de zéro, tout en usant de l'expérience et des bénéfices du projet antérieur. Rien ne l'empêche.
    Je crois que tu oublies la pierre angulaire : le sponsor.
    Lorsqu'un projet est parti en vrille dès le début, qu'il a fallu rajouter des dizaines et centaines de milliers d'euros alors qu'à la première mise en production c'était une catastrophe, que les utilisateurs ont à peu près ce qu'ils veulent mais ils doivent quand même retraiter des choses à la main derrière... Penses-tu qu'ils seraient chaud pour repayer un an de dev supplémentaire quand on leur dit "on va tout raser, on va tout refaire ?"

    Citation Envoyé par moldavi
    Développeur est un vrai métier qui demande de réelles compétences.
    Non, c'est du charlatanisme.
    Désolé, je ne savais pas trop quoi répondre à ce truisme.

    Citation Envoyé par moldavi
    Selon moi, avec mon expérience actuelle et mes diverses rencontres avec des développeurs, le problème principal est la rigueur.

    Le deuxième problème est la capacité à architecturer un programme.

    Ces deux problèmes suffisent à mettre en péril un projet.
    A chacun ses expériences. Je pense que personnellement le problème principal suit simplement le flot du projet : les CDC sont rarement clairs. L'interview client est souvent limitée. La conception a des manquements. Coté technique, il y a souvent des oublis.
    Dans tous les cas ce n'est pas grave, si on ne mettait pas autant de temps à réagir. Quelqu'un m'a dit un jour : lorsqu'on découvre une anomalie à un point d'un projet, le facteur de résolution est de 10. Grosso modo, si un Business Analyst a mal fait son boulot et aurait pu réparer son erreur en un jour, ça produit quand même 10 jours côté dev.
    Maintenant, va dire à un utilisateur que tu interviews qu'il prenne un jour pour répondre à résoudre une problématique sinon ça en prendre 100 chez le développeur. Sa réaction ? "j'ai pas le temps et/ou c'est pas mon problème. On validera en prod et après je pèterai un câble, et c'est la TMA à Madrid qui va s'en occuper".

    En soit oui, tu n'as pas tort, on manque toujours de rigueur en développement. Que ce soit des gars qui testent à l'arrache ou mal faire l'inventaire des livrables... mais si le projet était déjà mal défini, si le business analyst s'entête à mélanger des choux et des carottes, si le business analyst est pas assez technique ou pas assez fonctionnel et n'arrive pas à décrire le besoin et établir un modèle ou travailler correctement avec l'architecture fonctionnelle... bah rigoureux ou pas le projet ne pourra que se planter et être un pataquès d'ajouts.



    Au passage, le postulat de l'article, à la base, c'est qu'une équipe de développement veut tout raser parce que c'est plus dur d'essayer de comprendre, maintenir, et faire évoluer un code sur lequel ils n'ont pas travaillé. Ton message sous-entend qu'on peut faire un ReX avec d'anciens acteurs du programme. Mais dans un monde lié à la prestation biennale / triennale et à la promotion interne express, nous n'avons plus ces acteurs et nous n'avons plus de ReX. Ou alors ils s'en dédouanent carrément.
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  4. #44
    Membre émérite
    Bonjour.

    Citation Envoyé par Glutinus Voir le message
    Je crois que tu oublies la pierre angulaire : le sponsor.
    Lorsqu'un projet est parti en vrille dès le début, qu'il a fallu rajouter des dizaines et centaines de milliers d'euros alors qu'à la première mise en production c'était une catastrophe, que les utilisateurs ont à peu près ce qu'ils veulent mais ils doivent quand même retraiter des choses à la main derrière... Penses-tu qu'ils seraient chaud pour repayer un an de dev supplémentaire quand on leur dit "on va tout raser, on va tout refaire ?"


    Non, c'est du charlatanisme.
    Désolé, je ne savais pas trop quoi répondre à ce truisme.



    A chacun ses expériences. Je pense que personnellement le problème principal suit simplement le flot du projet : les CDC sont rarement clairs. L'interview client est souvent limitée. La conception a des manquements. Coté technique, il y a souvent des oublis.
    Dans tous les cas ce n'est pas grave, si on ne mettait pas autant de temps à réagir. Quelqu'un m'a dit un jour : lorsqu'on découvre une anomalie à un point d'un projet, le facteur de résolution est de 10. Grosso modo, si un Business Analyst a mal fait son boulot et aurait pu réparer son erreur en un jour, ça produit quand même 10 jours côté dev.
    Maintenant, va dire à un utilisateur que tu interviews qu'il prenne un jour pour répondre à résoudre une problématique sinon ça en prendre 100 chez le développeur. Sa réaction ? "j'ai pas le temps et/ou c'est pas mon problème. On validera en prod et après je pèterai un câble, et c'est la TMA à Madrid qui va s'en occuper".

    En soit oui, tu n'as pas tort, on manque toujours de rigueur en développement. Que ce soit des gars qui testent à l'arrache ou mal faire l'inventaire des livrables... mais si le projet était déjà mal défini, si le business analyst s'entête à mélanger des choux et des carottes, si le business analyst est pas assez technique ou pas assez fonctionnel et n'arrive pas à décrire le besoin et établir un modèle ou travailler correctement avec l'architecture fonctionnelle... bah rigoureux ou pas le projet ne pourra que se planter et être un pataquès d'ajouts.



    Au passage, le postulat de l'article, à la base, c'est qu'une équipe de développement veut tout raser parce que c'est plus dur d'essayer de comprendre, maintenir, et faire évoluer un code sur lequel ils n'ont pas travaillé. Ton message sous-entend qu'on peut faire un ReX avec d'anciens acteurs du programme. Mais dans un monde lié à la prestation biennale / triennale et à la promotion interne express, nous n'avons plus ces acteurs et nous n'avons plus de ReX. Ou alors ils s'en dédouanent carrément.
    Si on lit tout ce que vous racontez, "c'est bancale dès le départ", oui, nous sommes tous d'accord.

###raw>template_hook.ano_emploi###