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

Affichage des résultats du sondage: Que pensez vous de la qualité de vos projets ?

Votants
24. Vous ne pouvez pas participer à ce sondage.
  • Tous les projets informatique sont gérés avec les pieds, il faut faire avec.

    11 45,83%
  • Les projets web (surtout PHP) sont particulierement mal menés.

    5 20,83%
  • Globalement, les projets se déroulent bien, malgres quelques patches un peu violents.

    5 20,83%
  • Tout est merveilleux, c'est toi qui doit être mauvais.

    3 12,50%
  1. #1
    Nee
    Nee est déconnecté
    Membre du Club
    Profil pro
    Inscrit en
    mai 2002
    Messages
    50
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 50
    Points : 55
    Points
    55
    Par défaut Avez vous déja travailler sur des projets de bonne qualité ?
    Bonjour à tous;

    En quelques mots, j'ai une expérience de quelques années dans le développement web (PHP, AS, JS).
    Au fur et a mesur de mon expérience, j'ai amélioré mes compétences techniques (bonnes pratiques OO, design patterns, tests unitaires, ...).

    Malheureusement, les projets sur lesquels j'ai travaillé dans différentes boites - et surtout la manière dont ils ont été gérés - sont toujours basés sur des choix technologiques tres discutables, des spécifications inéxistantes, une absence presque totale de documentation, et peu de recomandations sur la qualité du code, sans parler de l'absence de communication entre les différents projets qui pourrait permettre de mutualiser certains éléments.

    Bien sûr, je connais les contraintes économiques d'un projet, mais je parle des choix qui vont faire gagner quelques jours à court termes, et en faire perdre des dizaines a plus long terme.

    J'avoue que je désespere un peu de travailler dans de bonnes conditions.
    Je vous demande donc votre retour d'expérience sur cette question : avez vous déja travaillé dans de bonnes conditions ?


    merci.
    we are the knights who said nee !

  2. #2
    Membre confirmé Avatar de MetalGeek
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : octobre 2008
    Messages : 412
    Points : 513
    Points
    513
    Par défaut
    Si par bonnes conditions tu entends faire les choses "dans les règles de l'art", comme on l'apprend à l'école, pour moi la réponse est non, jamais.
    Le problème numéro un là ou je bosse est toujours le même, quel que soit le projet : un calendrier est défini avec le client, et ce calendrier comporte des jalons auxquels je dois présenter l'avancement du travail.
    Et inutile d'espérer montrer au client un schéma UML, Merise ou quoi que ce soit, il veut un aperçu du logiciel un point c'est tout. Donc je me retrouve à coder des parties de l'interface avant de faire l'analyse de composants très importants.
    Au final, dans 9 projets sur 10, la partie UML & co se résume à un diagramme de packages + quelques diagrammes de classe réalisés APRES avoir codé, histoire de dire qu'on est des pros, on fait de l'UML...
    Et je ne parle pas des phases de testing qui sont réalisées à l'arrache par manque de temps et qui ne sont même pas prévues dans le calendrier...

  3. #3
    Nee
    Nee est déconnecté
    Membre du Club
    Profil pro
    Inscrit en
    mai 2002
    Messages
    50
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 50
    Points : 55
    Points
    55
    Par défaut
    C'est plus une question de court et de moyen termes que de "règles de l'art".

    Je n'ai encore jamais vu un projet ou l'on prévoit quelques heures de plus pour la rédaction de documentation, ou encore quelques heures pour des vrais tests, avec des cas d'utilisations bien définis. Tout le monde le sait : les quelques heures investient dans ces pratiques seront rentabilisés rapidement (nouvel arrivant, pause dans le projet, ...).

    Je parle bien de bonnes pratiques de gestion de projet, et non pas de bonnes pratiques "théoriques" (:p).

    En fait, j'ai l'impression de travailler en mode "extreme programming" (conception a la volée, nombreuses releases, ...), mais sans les garde-fou (tests unitaires, documentation, communication, ... ).

    Malgrès tout, les projets fonctionnent, mais leur cout de maintenance est délirant par rapport aux fonctionnalités ajoutées et aux bugs corrigés.
    we are the knights who said nee !

  4. #4
    Membre émérite
    Homme Profil pro
    Développeur Java/Scala
    Inscrit en
    octobre 2007
    Messages
    1 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Scala

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 085
    Points : 2 306
    Points
    2 306
    Par défaut
    Je vois ce que tu veux dire et j'ai également pu effectuer un stage ou c'etait un peu comme tu dis...


    Actuellement je suis sur un projet sympa et on prend bien le temps pour faire de la doc, des tests unitaires, de charge et http.

    Sur chaque projet il devrait y avoir une plateforme d'intégration continue + batterie de tests lancés a chaque commit.


    Bon on a pas un cahier des charges de 100 pages mais d'un autre coté je crois que c'est assez rare... En général la spec évolue toujours un peu en cours de route, et je pense que c'est également a toi de savoir poser les bonnes questions (si tu es en contact direct), tirer un peu les vers du nez de la moa et de bien t'imprégner de la problématique pour pouvoir anticiper les éventuels besoins...


    En tout cas a mon avis une chose est fort probable: c'est pas dans les projets PHP que tu as le plus de chance de trouver des projets cleans a mon avis... rien que le langage n'invite pas forcement a la rigueur je trouve
    Développeur certifié: Java 6 - Scala - Machine Learning

    Liste verte des SSII humaines, pour passionnés de technique, essentiellement Java mais aussi C#, NoSQL, Scala, JS: Octo, Zenika, Xebia, So@t, Arolla, Excilys...
    Allez la bas plutôt que chez Altruc!
    Détails en MP.

  5. #5
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 110
    Points
    3 110
    Par défaut
    personellement j'ai connu les deux modes

    mes 4 premières années d'expériences étaient dans l'informatique industrielle et dans la sureté de fonctionnement dans les systèmes embarqués ferroviaire.

    Dans ces 4 années j'étais entouré de process normatif et on ne pouvais pas coder une ligne avant d'avoir fait des specs qui avaient été relue plusieurs fois par d'autres personnes, les cycles de développement d'un soft était assez long mais l'optique des soft était d'être robuste et fiable (j'ai eu notamment a travailler sur un soft dont l'une des contraintes était de fonctionner en 24/7 pendant 10 ans).

    Ensuite je suis passé dans l'univers telecom, les méthodes et les outils étaient les mêmes, mais les cycles de vie etaient plus court donc forcement la doc le code était moins soigné, le but étant de livrer le soft dans les temps avec les fonctionnalité demandé (même si tout n'était pas complètement verrouillé avant)

    bref deux univers totalement différent.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  6. #6
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 895
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 895
    Points : 26 946
    Points
    26 946
    Par défaut
    bossé juste en banque/assurance, en tant que dev mais aussi en tant qu'homologateur. J'ai vu du meilleur et du pire.

    Le meilleur : un projet ou le chef de projet connait le sujet, ou les specs sont rédigées par une personne qui connait son affaire, ou le dialogue avec les utilisateurs est permanent, ou l'architecte(un sale con très compétent) vérifiait régulièrement la bonne conformité du code, ou les développeurs sont motivés, et ou ils ne prennent pas pour une insulte personelle chaque anomalie que j'ai pu leur lever. Et en plus, une spec qui s'adapte quand on voit des trous ou des erreurs dedans. Avec malgré tout des points faibles : lot 1 rachitique en raison d'une exigence de délai délirante, livraisons en homologation une seule fois par semaine(livré le lundi matin, homologué dans la journée, anomalies corrigées le mardi, et ensuite on attend), environnement de travail plombé 3 semaines, utilisateurs qui se rendent compte devant l'outil développé suivant leurs désirs qu'en fait ça ne va pas du tout, etc.....mais c'était faisable, et on l'a fait. Proprement.

    Le pire : projet ou les specs sont rachitiques, fausses, obsolètes, et rachitiques, mais validées donc intouchables. Ou les développeurs errent dans les couloirs sans savoir ce qu'ils doivent faire. Ou le client et le fournisseur "n'arrivent même pas à se mettre d'accord sur l'étendue de leur désaccords". Ou les choix technologiques sont aberrants. Ou les DP & CP se font virer à la queue leu leu. J'ai eu la chance de pouvoir me barrer avant le feu d'artifice final, d'après les survivants, ça a été sanguinaire.

    Le plus démotivant : un projet ou les spécifications fournies au développeur étaient du niveau organique. Y'avait plus qu'à transformer "alimenter le numéro de contrat destinataire par celui de l'origine" en un "MOVE N-CTRT OF ORGN TO MOVE N-CTRT OF DSTR". Le niveau zéro de la programmation.

    Le plus motivant : une chaine existante gère les éditions au client. On change de logiciel d'édition. On en profite pour refaire toute la chaine, car l'existante est un vieux nanar illisible. Tout le monde considère que c'est impossible, ou au moins délirant. "el_slapper, tu as carte blanche". J'en ai chié, les gens des métiers m'ont fort peu aidé, le cahiers des charges était rachitique, mais ça tourne nickel.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Membre émérite
    Homme Profil pro
    Développeur Java/Scala
    Inscrit en
    octobre 2007
    Messages
    1 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Scala

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 085
    Points : 2 306
    Points
    2 306
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Le pire : projet ou les specs sont rachitiques, fausses, obsolètes, et rachitiques, mais validées donc intouchables. Ou les développeurs errent dans les couloirs sans savoir ce qu'ils doivent faire. Ou le client et le fournisseur "n'arrivent même pas à se mettre d'accord sur l'étendue de leur désaccords". Ou les choix technologiques sont aberrants. Ou les DP & CP se font virer à la queue leu leu. J'ai eu la chance de pouvoir me barrer avant le feu d'artifice final, d'après les survivants, ça a été sanguinaire.

    L'entreprise commence par un P ?
    Développeur certifié: Java 6 - Scala - Machine Learning

    Liste verte des SSII humaines, pour passionnés de technique, essentiellement Java mais aussi C#, NoSQL, Scala, JS: Octo, Zenika, Xebia, So@t, Arolla, Excilys...
    Allez la bas plutôt que chez Altruc!
    Détails en MP.

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 895
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 895
    Points : 26 946
    Points
    26 946
    Par défaut
    Citation Envoyé par HerQuLe Voir le message
    L'entreprise commence par un P ?
    Non. Mais je ne devrais même pas donner cet indice, hein..... Ca veut juste dire que ça existe à pas mal d'endroits, hélas.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 110
    Points
    3 110
    Par défaut
    non les deux mode de fonctionnement existe il faut juste savoir ou tu met les pieds.
    ,
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

Discussions similaires

  1. Travailler sur des projets à distance
    Par moha1984 dans le forum Emploi
    Réponses: 0
    Dernier message: 01/12/2009, 00h20
  2. Travailler sur des projets à distance
    Par moha1984 dans le forum CV
    Réponses: 0
    Dernier message: 01/12/2009, 00h18
  3. Débutant travailler sur des images
    Par doud dans le forum Bibliothèques
    Réponses: 1
    Dernier message: 15/08/2005, 16h47
  4. Travailler sur des sources distantes avec Eclipse
    Par El Saigneur dans le forum Eclipse Java
    Réponses: 5
    Dernier message: 12/07/2004, 10h40
  5. Travailler sur des données qui doivent être triées
    Par haypo dans le forum XML/XSL et SOAP
    Réponses: 2
    Dernier message: 19/07/2003, 18h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo