IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

"Je suis un ingénieur, pas un compilateur"


Sujet :

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

  1. #261
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    Il en va ainsi dans beaucoup de domaines, le notre n'est pas épargné...
    tout à fait.. Et c'est bien dommage en ce qui concerne l"agilité", car c'est à mon avis la seule manière réelle de faire aboutir un projet avec succès aussi bien en termes de budget que de satisfaction de l'équipe et des utilisateurs, et ce, justement contrairement aux remarques précédentes, quelle que soit la taille du projet... (et plus le projet est gros plus le gain est mesurable)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  2. #262
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    tout à fait.. Et c'est bien dommage en ce qui concerne l"agilité", car c'est à mon avis la seule manière réelle de faire aboutir un projet avec succès aussi bien en termes de budget que de satisfaction de l'équipe et des utilisateurs, et ce, justement contrairement aux remarques précédentes, quelle que soit la taille du projet... (et plus le projet est gros plus le gain est mesurable)
    Pour faire le parallèle avec un domaine que je connais assez : on ne manoeuvre pas une division comme on manoeuvre une section, mais c'est quand même avec des divisions qu'on gagne la guerre et pas avec des sections...
    Il est clair que pas mal de DSI souffrent d'une certaine inertie, et que le développemetn Agile peut dans certains cas aider. Mais en faire un mode de fonctionnement me semble dangereux à long terme. Or la grande erreur de nos dirgeants est en général de ne regarder qu'à court (voire très court) terme. Je conçois Agile comme étant un outil utilisable ponctuellement, pas comme un dogme de développement.

    Et pour aller plus loin, Agile me semble (mais c'est mon avis) plus une modèle d'organisation humaine qu'un modèle de développement dans l'esprit... On est aglie ou pas dans un environnement fixe...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  3. #263
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    Pour faire le parallèle avec un domaine que je connais assez : on ne manoeuvre pas une division comme on manoeuvre une section, mais c'est quand même avec des divisions qu'on gagne la guerre et pas avec des sections...
    Il est clair que pas mal de DSI souffrent d'une certaine inertie, et que le développemetn Agile peut dans certains cas aider. Mais en faire un mode de fonctionnement me semble dangereux à long terme. Or la grande erreur de nos dirgeants est en général de ne regarder qu'à court (voire très court) terme. Je conçois Agile comme étant un outil utilisable ponctuellement, pas comme un dogme de développement.

    Et pour aller plus loin, Agile me semble (mais c'est mon avis) plus une modèle d'organisation humaine qu'un modèle de développement dans l'esprit... On est aglie ou pas dans un environnement fixe...
    Je suis certainement d'accord avec ton dernier paragraphe...

    Je pense par contre que le reste provient d'une mauvaise conception (et/ou expérience)..

    Pour reprendre ton analogie, le besoin d'une armée est dans les faits (selon mon expérience) une absurdité dans le développement.

    Je pense que le besoin d'une armée, et donc de divisions, vient de l'analogie beaucoup trop présente (et à la base de l'approche traditionnelle) entre chaîne de production d'une usine et développement logiciel..

    Or cette analogie est fausse : une chaîne de production reproduit un prototype établi en bureau d'études, pour la fabrication duquel l'équipe était petite et le flux absolument non linéaire. Une fois le prototype fait, on l'a découpé en morceaux isolables, et automatisé la production par morceaux, utilisant au passage des ouvriers spécialisés par poste/morceau. Dans le cas d'un logiciel, la reproduction est instantanée, ce qui compte , et ce qu'est une équipe de développement, c'est le Bureau d'Etudes.. Non linéaire, et relativement petit..

    De cette erreur d'appréciation vient le fait d'une part de considérer les hommes comme des pions (compter en homme/jour par exemple), interchangeables (et donc des besoins de docs gigantesques pour que toute la connaissance puisse passer d'un pion à un autre), affectés à des postes fixes, dirigés par des chefs d'équipes, avec plusieurs équipes ayant des objectifs distincts... A cause de cette structure mentale et pratique, des règles de gestion sont obligatoires, et donc des réunions, de la communication, une linéarité des tâches, et de la documentation différente à chaque niveau de décision...

    Si par contre on se base sur une verticalité des tâches, des hommes non interchangeables, et une responsabilité plus étale, même si les besoins de conception et d'analyse restent les mêmes, les besoins de structure de gestion, de communication, et de docs sont bien moindres.. De même, la remise en cause d'une partie pour cause soit d'évolution technologique soit de "découverte" de fonctionalité "oubliée" ou mal analysée/identifiée/hiérarhisée au départ devient beaucoup plus légère, et influe beaucoup moins sur les délais et coûts..

    Par contre, gérer un tel projet et une telle équipe pré-suppose d'être déjà familier avec des developpements et structures traditionnels, afin justement de pointer et éviter les écueuils, d'avoir la doc suffisante, voire d'appuyer les différences de gestion auprès des directions générales..

    Je pense donc que les échecs ou la mauvaise perception/expérience avec l'agilité est plus à mettre sur le compte de l'inexpérience des DSI /CP en cause que de l'agilité.. (que ce soit en termes de devs traditionnels ou de devs tout court)

    Je l'ai appliquée sur d'énormes projets et ça a très bien fonctionné.. Faire avec 12 personnes en 1 an 1/2 le travail (raté) par 60 en 16 ans, ça se fait assez facilement dans ce cadre... ou avec 5 personnes en 4 ans le travail (raté) de 100 en 10 ans..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  4. #264
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    Octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2008
    Messages : 3 615
    Points : 8 080
    Points
    8 080
    Par défaut
    Attention hein, l'agile c'est pas "on avance au fil de l'eau et on voit ce qui se passe". C'est au contraire hyper cadré et a essentiellement un but: éviter l'effet tunnel. Mais dès le départ tu dois savoir ou tu veux arriver. TOUT doit être découpé c'est l'agencement des tâches et l'histoire de cycle court qui fait la chose. Bien souvent, les gens qui se disent "Agiles" ont un tableau blanc, des postits et naviguent un peu à vue. Bah, c'est pas ca. Après, il ne faut pas non plus devenir terroriste de l'agilité et rentrer dans des process à la con totalement inadaptés au points de scléroser l'équipe.

  5. #265
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Aux deux précédents intervenants (souviron34 et Nathanael Marchand) vous avez raison tous les deux.
    Bien souvent, Agile est utilisé par des gens peu au fait des différentes étapes du cycle de développemetn, et leur sert à légitimer leur manque crucial de docs et autres méthodes "propres" de développement.
    Pour autant, je ne compare pas le développement à une chaîne de montage, et d'ailleurs la différence est notoire. Mais comme un architecte doit avoir des plans précis pour que derrière ca tourne, le projet doit être documenté pour qu'on puisse le faire vivre (cycle de vie d'une application), et ça ça manque trop souvent, ce qui fait que certaines applis deviennent des hydres incontrôlables...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  6. #266
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    Mais comme un architecte doit avoir des plans précis pour que derrière ca tourne, le projet doit être documenté pour qu'on puisse le faire vivre (cycle de vie d'une application), et ça ça manque trop souvent, ce qui fait que certaines applis deviennent des hydres incontrôlables...
    C'est également vrai (par excès inverse) des devs Waterfall purs, pour peu quils soient conséquents...

    Qui a vu des docs de specs ou d'analyse, et même de conception, même détaillée, mises à jour réellement ?? Et une remontée au fur et à mesure dans les docs de plus haut niveau lors d'une modification, soit due à un bug d'analyse, soit due à une avancée technologique, soit due à une optmisation d'algo ???

    Trop de docs tue la doc, de même que pas assez est absurde...

    Cependant, l'obligation de documents multiples et variés à chaque étape dans le Waterfall est une source inévitable d'hydre .. Dès que le projet est un tant soit peu conséquent...

    (dans le projet de 60 personnes dont je parlais plus haut, il y avait une pièce de 30m2 entière remplie d'étagères remplies de docs depuis le début du projet.. 16 ans après, d'une part aucune doc n'était à jour, tout le monde (y compris l'Architecte en Chef, là depuis le départ) ne savait plus ce qu'il y avait dedans, et l'état des connaissances et de l'informatique et des utilsateurs avaient complètement changé entre temps, donc la plupart des analyses et conceptions d'origine étaient devenues obsolètes)


    NB: enfin, petite note pratique... Si demain matin tu étais mis dans un tel projet, ayant environ au minimum 100 000 pages de docs, que ferais-tu ? Même si le document d'analyse ne faisait que 150 pages ?? Le lirais-tu dans son entièreté, ou irais-tu d'une part glâner des infos auprès des gens là depuis longtemps, puis parcourir les répertoires du source ??

    En tant que CP ou architecte, tu lirais une partie, et tu zapperais vraisemblablement 90%. En tant que programmeur, analyste-programmeur, maintenance, ou système, tu irais sans doute directement dans la structure des répertoires et des sources...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #267
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    C'est également vrai (par excès inverse) des devs Waterfall purs, pour peu quils soient conséquents...

    Qui a vu des docs de specs ou d'analyse, et même de conception, même détaillée, mises à jour réellement ?? Et une remontée au fur et à mesure dans les docs de plus haut niveau lors d'une modification, soit due à un bug d'analyse, soit due à une avancée technologique, soit due à une optmisation d'algo ???

    Trop de docs tue la doc, de même que pas assez est absurde...

    Cependant, l'obligation de documents multiples et variés à chaque étape dans le Waterfall est une source inévitable d'hydre .. Dès que le projet est un tant soit peu conséquent...

    (dans le projet de 60 personnes dont je parlais plus haut, il y avait une pièce de 30m2 entière remplie d'étagères remplies de docs depuis le début du projet.. 16 ans après, d'une part aucune doc n'était à jour, tout le monde (y compris l'Architecte en Chef, là depuis le départ) ne savait plus ce qu'il y avait dedans, et l'état des connaissances et de l'informatique et des utilsateurs avaient complètement changé entre temps, donc la plupart des analyses et conceptions d'origine étaient devenues obsolètes)


    NB: enfin, petite note pratique... Si demain matin tu étais mis dans un tel projet, ayant environ au minimum 100 000 pages de docs, que ferais-tu ? Même si le document d'analyse ne faisait que 150 pages ?? Le lirais-tu dans son entièreté, ou irais-tu d'une part glâner des infos auprès des gens là depuis longtemps, puis parcourir les répertoires du source ??

    En tant que CP ou architecte, tu lirais une partie, et tu zapperais vraisemblablement 90%. En tant que programmeur, analyste-programmeur, maintenance, ou système, tu irais sans doute directement dans la structure des répertoires et des sources...
    Suivant mon dogme, j'aurais pas du plusser, mais je l'ai fait !
    Tu as raison, trop de docs ou du moins trop de docs pas mises à jour tuent la doc.
    Mais d'un autre côté, pas de docs du tout a tendance aussi à couper court toute velléité de faire les choses bien. Et du coup c'est un système qui s'autoalimente...
    J'ai du prendre en main un système sur lequel aucune doc n'existait pour le trasnposer sur un autre système (plateforme de flux boursiers pour être précis). Ben bonjour poru faire le cahier des charges ! rien qui explique ce qui existait, et le seul mec qui maitrisait avait peur (à tord) que je lui pique son boulot ! J'ai ramé comme un beau diable.

    Je dis pas qu'il faut avoir 100 000 pages de docs (ca c'est pour les dossiers de TGI), mais je pense qu'il y a une bonne moyenne... Et puis après tout, la doc est une des phases du dev, et l'ignorer, c'est mettre les autres en danger.
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  8. #268
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2012
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2012
    Messages : 15
    Points : 35
    Points
    35
    Par défaut
    De toute façon le gars qui justifie son absence de docs par l'application de méthodes agile est un gros rigolo. C'est pas parce-que le process de développement est découpé en toutes petites tâches que ça veut dire qu'on ne doit rien mettre à plat, bien au contraire.
    Pour moi un développement effectué selon une méthode agile requiert une gestion des docs bien spécifique. Un wiki me parait d'ailleurs un outil bien pratique pour ce cas. Qu'en pensez-vous?

  9. #269
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Je pense pas que le format Wiki change quoique ce soit.
    Au contraire, c'est moins facile à transmettre (au moins les sources). Et l'édition est généralement très limitée.
    En revanche, le système de forge, surtout les "Task tracker" au lieu du "simple" Bug tracker est un poil plus adapté. Ca permet également de mettre des éléments de documentation directement au niveau du ticket. Au moins ce n'est pas perdu et accessible éventuellement avec le moteur de recherche de la forge.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  10. #270
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    Octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2008
    Messages : 3 615
    Points : 8 080
    Points
    8 080
    Par défaut
    Citation Envoyé par Straits06 Voir le message
    De toute façon le gars qui justifie son absence de docs par l'application de méthodes agile est un gros rigolo. C'est pas parce-que le process de développement est découpé en toutes petites tâches que ça veut dire qu'on ne doit rien mettre à plat, bien au contraire.
    Pour moi un développement effectué selon une méthode agile requiert une gestion des docs bien spécifique. Un wiki me parait d'ailleurs un outil bien pratique pour ce cas. Qu'en pensez-vous?
    Clairement!
    D'ailleurs je vois même pas pourquoi on oppose agile et documentation, ce sont deux notions totalement perpendiculaires.

  11. #271
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    Mais d'un autre côté, pas de docs du tout a tendance aussi à couper court toute velléité de faire les choses bien. Et du coup c'est un système qui s'autoalimente...
    Oui, mais il n'est nulle part fait mention dans l'agilité (que ce soit le Manifeste ou les méthodes-ologies en vogue) que il ne doit pas y avoir de doc..

    Il y a normalement, comme dans toute autre approche, un CdC, une spec, un document d'archi, des documents de conception au moins au niveau global, plus des documents de tests...



    Citation Envoyé par Straits06 Voir le message
    De toute façon le gars qui justifie son absence de docs par l'application de méthodes agile est un gros rigolo.
    Absolument.. C'est plus de l'agilité, c'est de la fainéantise , ou , comme un thread ici-même avait eu pour titre "le développement brouillon".

    Une justification par qqun pris "la main dans le sac"... qui pense que ça va passer parce que "y'a pas de cadre avec l'agilité"...





    Citation Envoyé par Straits06 Voir le message
    C'est pas parce-que le process de développement est découpé en toutes petites tâches que ça veut dire qu'on ne doit rien mettre à plat, bien au contraire.Pour moi un développement effectué selon une méthode agile requiert une gestion des docs bien spécifique.
    Tout à fait..


    Citation Envoyé par Straits06 Voir le message
    Un wiki me parait d'ailleurs un outil bien pratique pour ce cas. Qu'en pensez-vous?
    oui et non.. L'un n'empêche pas l'autre, et il faut surtout garder une trace papier des documents importants (CdC, specs, architecture..)

    Avoir une vue d'ensemble en cliquant sur des pages qui se suivent est pas terrible..

    Disons que c'est complémentaire.. Avoir la base de connaissance Wiki quand on veut revenir sur un sujet paticulier, mais avoir la doc (ou alors des pages TRES bien faites) pour avoir la vue plus d'ensemble..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  12. #272
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Nathanael Marchand Voir le message
    D'ailleurs je vois même pas pourquoi on oppose agile et documentation, ce sont deux notions totalement perpendiculaires.
    c'est ma faute

    C'est moi qui ait signalé que effectivement les besoins en docs sont moindres (et pas qu'un peu) : les besoins en docs des devs Waterfall sont nombreux, extrêmement précis, répondant à des normes de contenu, avec des dictionnaires pour les étapes principales, etc etc.. C'est extrêmement lourd... Et il y a effectivement une "agilité" de la doc.. Mais comme dit plus haut "agilité" ne signifie pas absence..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  13. #273
    Membre régulier
    Homme Profil pro
    Directeur technique
    Inscrit en
    Novembre 2004
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 56
    Points : 105
    Points
    105
    Par défaut
    Ayant moi-même fait passer quelques entretiens techniques pour recruter des développeur .NET (ingénieur ou pas), j’admets que je ne regrette pas d'avoir poser des questions vilainement techniques pour évaluer l'expérience réelle des candidats. Dans mon cas, l'entretien ne se base pas que là dessus, c'est souvent un point de départ pour discuter un concept général ou partager des expériences. C'est un minimum pour quelqu'un qui dit avoir de l'expérience dans un langage que de pouvoir comprendre un code sans l'aide de Google et parler des concepts avancés du langage. Sinon on tombe sur des développeurs qui pensent que faire une application c'est double-cliquer sur des boutons pour bourrer du code dans la fonction qui apparait fort à propos.

    Ensuite, opposer la tête bien faite à la tête bien pleine est un argument soit de débutant (qui croit en lui, tant mieux) soit de fainéant. Un recruteur cherche une tête bien faite et bien pleine de préférence. Une personne qui affirme avoir de l'expérience et une bonne capacité d'apprentissage doit avoir la tête bien pleine. Sinon, c'est la preuve qu'il a économisé sa capacité d'apprentissage de peur de l'user.

    Évidement mon commentaire ne s'applique que pour le recrutement de développeur (qui peuvent tout à fait être ingénieur)

    PS : Comme en Suisse, il est facile de licencier, on peut remplacer les têtes bien pleines récalcitrantes à la reconversion par d'autres têtes bien pleines à jour. Le libéralisme a du bon parfois.

  14. #274
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Quelle connerie.

    Votre test ne vous apporte qu'une seule choses : des gens qui ne font que de coder en .net à longueur de journée.

    Maintenant si effectivement vous ne demandez que ça comme capacité à vos futur employés c'est effectivement une bonne démarche.

    Ceci étant dit on doit bien s'emmerder avec un tel poste.

  15. #275
    Membre habitué
    Profil pro
    Inscrit en
    Avril 2011
    Messages
    81
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 81
    Points : 171
    Points
    171
    Par défaut La méthode agile me laisse perplexe
    La méthode agile me laisse perplexe. Sur le plan théorique elle devrait aider à mieux aborder un projet. Par contre au niveau pratique, de ce que j'en ai vue, elle sert surtout à camoufler un bordel sans nom. Ce bordel n'est pas nécessairement le fait de l'équipe du projet. Quand on a à faire à un client ou une direction qui savent pas trop où ils vont difficile d'avoir quelque chose de cohérent derrière, peut importe la méthode utilisé. Autre fois on nous formait sur Merise maintenant celle qui est à la mode est Agile, et d'ici quelque années une autre pointera sans doute le bout de son nez. Des entreprises vont vers des processus plus lourde comme CMMI ou encore s'appuient sur des templates, qu'il faut le reconnaitre sont très bien fait, fourni par IEEE (Std 1362-1998 Concept of Operations, Std 0830-1998 - SRS - Software Requirement Specifications, Std 1016-1998 - SDD - Software Design Descriptions). Ce que je trouve intéressant avec IEEE c'est qu'ils ne fournissent pas vraiment une méthodologie, qui peut être difficile à appliquer dans certains contextes. Eux fournissent des guides issues de bonnes pratiques. Ensuite à l'entreprise de les adapter en fonction de son besoin et de son mode de fonctionnement.
    Elles peuvent les utiliser en complément ou pas de l'approche Agile, les 2 ne sont pas exclusif l'un par rapport à l'autre. Pour avoir travaillé dans plusieurs compagnies, de mon point de vue, il n'y a pas de méthodologies miracles pouvant s'appliquer sans distinction à tous le monde. Chaque entreprise doit choisir celle avec laquelle elle se sent le plus confortable. Aujourd'hui la méthodologie à la mode est Agile, demain une autre la supplantera de mon coté je m'adapterai à celle que l'entreprise aura choisie.

  16. #276
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par Straits06 Voir le message
    De toute façon le gars qui justifie son absence de docs par l'application de méthodes agile est un gros rigolo. C'est pas parce-que le process de développement est découpé en toutes petites tâches que ça veut dire qu'on ne doit rien mettre à plat, bien au contraire.
    Pour moi un développement effectué selon une méthode agile requiert une gestion des docs bien spécifique.
    C'est clair, 1000 fois d'accord ! D'ailleurs, si on reprend les principes de base du développement, on devrait s'appuyer sur deux choses : la modularité (et al granularité qui va avec) et la ré-utilisabilité (pas sur que les sages de l'Académie acceptent ce mot là...).
    Et je pense que si on respecte ces deux principes, alors oui on peut faire de l'Agile de façon efficace.
    Citation Envoyé par Straits06 Voir le message
    Un wiki me parait d'ailleurs un outil bien pratique pour ce cas. Qu'en pensez-vous?
    Ben le Wiki je suis mitigé pour plusieurs raisons :
    • l'édition est pas toujours très facile
    • c'est souvent peu portable, chacun a son format et son langage, et toute velléité de migration devient un casse-tête
    • tout le monde peut mettre tout et n'importe quoi
    • y a pas trop de formalisation comme des docs Word qui permettent un cartouche, un modèle et des normes (oui je sais j'adore les normes...)

    En général, tous les wikis que j'ai vu finissent par devenir des immondes fourre-tout désorganisés qui s'avèrent plustôt une perte de temps. PAr contre, le système SourceForge me semble pas mal.

    Après pour les docs, moi je suis un fervent amateur des Word et des classeurs bien organisés, mais c'est vrai que je préconise plutôt ça pour l'exploit et le support.

    Mention spéciale pour JavaDoc : c'est utile, bien fait et si on fait un tout petit effort (surtout avec Eclipse qui mâche le travail), on dispose quand même d'un socle de départ tout à fait acceptable.
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  17. #277
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Oui, mais il n'est nulle part fait mention dans l'agilité (que ce soit le Manifeste ou les méthodes-ologies en vogue) que il ne doit pas y avoir de doc..

    Il y a normalement, comme dans toute autre approche, un CdC, une spec, un document d'archi, des documents de conception au moins au niveau global, plus des documents de tests...
    tout à fait. Ce que je voulais dire c'est que certaines personnes qui font de l'Agile se cachent derrière le principe de réactivité et de rapidité pour oblitérer la doc, ce qui est très dangereux.

    Citation Envoyé par souviron34 Voir le message
    oui et non.. L'un n'empêche pas l'autre, et il faut surtout garder une trace papier des documents importants (CdC, specs, architecture..)
    Quoi qu'on puisse penser de la dématérialisation, le papier reste une valeur sure, surtout en cas de coupure de courant, crash serveur, coupure réseau ou plan de secours...
    Citation Envoyé par souviron34 Voir le message
    Avoir une vue d'ensemble en cliquant sur des pages qui se suivent est pas terrible..
    Disons plutôt que ce n'est pas (encore) le mode de fonctionnement intuitif de l'homme, pour qui l'expérience informatique n'a pas plus de 20 ans... Faut laisser le temps de s'habituer. Mais pour l'instant oui nous navigons plus facilement sur du papier.[/QUOTE]

    Citation Envoyé par souviron34 Voir le message
    Disons que c'est complémentaire.. Avoir la base de connaissance Wiki quand on veut revenir sur un sujet paticulier, mais avoir la doc (ou alors des pages TRES bien faites) pour avoir la vue plus d'ensemble..
    Absolument d'accord !
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  18. #278
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par asfez Voir le message
    Ayant moi-même fait passer quelques entretiens techniques pour recruter des développeur .NET (ingénieur ou pas), j’admets que je ne regrette pas d'avoir poser des questions vilainement techniques pour évaluer l'expérience réelle des candidats. Dans mon cas, l'entretien ne se base pas que là dessus, c'est souvent un point de départ pour discuter un concept général ou partager des expériences. C'est un minimum pour quelqu'un qui dit avoir de l'expérience dans un langage que de pouvoir comprendre un code sans l'aide de Google et parler des concepts avancés du langage. Sinon on tombe sur des développeurs qui pensent que faire une application c'est double-cliquer sur des boutons pour bourrer du code dans la fonction qui apparait fort à propos.

    Ensuite, opposer la tête bien faite à la tête bien pleine est un argument soit de débutant (qui croit en lui, tant mieux) soit de fainéant. Un recruteur cherche une tête bien faite et bien pleine de préférence. Une personne qui affirme avoir de l'expérience et mais une bonne capacité d'apprentissage doit avoir la tête bien pleine. Sinon, c'est la preuve qu'il a économisé sa capacité d'apprentissage de peur de l'user.

    Évidement mon commentaire ne s'applique que pour le recrutement de développeur (qui peuvent tout à fait être ingénieur)

    PS : Comme en Suisse, il est facile de licencier, on peut remplacer les têtes bien pleines récalcitrantes à la reconversion par d'autres têtes bien pleines à jour. Le libéralisme a du bon parfois.
    Sans aller jusqu'à dire "quelle connerie", je ne peux pas laisser passer ça...
    C'est de l'Eugénisme, du Taylorisme et de la dictature. Dictature de ceux qui ont tous les droits : le salarié a intérêt à être bien sage sinon dehors. C'est laporte ouverte à tous les tyrans locaux et petits chefs despotiques.
    J'ai beau être libéral, je te souhaite de bien remplir ta tête avec les idées du chef, sinon tus eras viré. Et viens pas pleurer après !
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  19. #279
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par zelegolas2 Voir le message
    La méthode agile me laisse perplexe.
    Je te rassure, moi aussi !
    Citation Envoyé par zelegolas2 Voir le message
    Sur le plan théorique elle devrait aider à mieux aborder un projet. Par contre au niveau pratique, de ce que j'en ai vue, elle sert surtout à camoufler un bordel sans nom.
    Pareil !
    Citation Envoyé par zelegolas2 Voir le message
    Ce bordel n'est pas nécessairement le fait de l'équipe du projet. Quand on a à faire à un client ou une direction qui savent pas trop où ils vont difficile d'avoir quelque chose de cohérent derrière, peut importe la méthode utilisé.
    Alors là je ne peux qu'abonder ! Là où Agile me semble dangereux, c'est que justement cette excuse de la réactivité pousse à générer le bordel. Sans aller jusqu'à dire que ça le provoque, ça l'encourage silencieusement...
    Citation Envoyé par zelegolas2 Voir le message
    Autre fois on nous formait sur Merise maintenant celle qui est à la mode est Agile, et d'ici quelque années une autre pointera sans doute le bout de son nez. Des entreprises vont vers des processus plus lourde comme CMMI ou encore s'appuient sur des templates, qu'il faut le reconnaitre sont très bien fait, fourni par IEEE (Std 1362-1998 Concept of Operations, Std 0830-1998 - SRS - Software Requirement Specifications, Std 1016-1998 - SDD - Software Design Descriptions). Ce que je trouve intéressant avec IEEE c'est qu'ils ne fournissent pas vraiment une méthodologie, qui peut être difficile à appliquer dans certains contextes. Eux fournissent des guides issues de bonnes pratiques. Ensuite à l'entreprise de les adapter en fonction de son besoin et de son mode de fonctionnement.
    Elles peuvent les utiliser en complément ou pas de l'approche Agile, les 2 ne sont pas exclusif l'un par rapport à l'autre. Pour avoir travaillé dans plusieurs compagnies, de mon point de vue, il n'y a pas de méthodologies miracles pouvant s'appliquer sans distinction à tous le monde. Chaque entreprise doit choisir celle avec laquelle elle se sent le plus confortable. Aujourd'hui la méthodologie à la mode est Agile, demain une autre la supplantera de mon coté je m'adapterai à celle que l'entreprise aura choisie.
    J'ai été formé il y a 25 ans sur Merise. Et je pense que cette méthode a du bon. Je viens d'être formé sur ITIL (dans un tout autre domaine), et je dois dire que l'approche est seyante. Mais il en va des méthodes comme des recettes de cuisines, si tu les suis pas bien, t'as intérêt à avoir un Mc-Do pas loins...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  20. #280
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    Octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2008
    Messages : 3 615
    Points : 8 080
    Points
    8 080
    Par défaut
    Non, non, non et non les gars! Je suis désolé, ce que vous avez vu de l'agilité c'est des branquignoles qui ne savaient pas faire. C'est comme si vous disiez que le premier pingouin qui sait mettre trois contrôles sur une fenêtre Winform est un pro du .net. La méthodologie Agile requiert d'être super carré et organisé. C'est pas un fourre tout sans nom. Vous avez connus que des tanches la dedans, tant pis pour vous mais n'allez pas dire que c'est nul car personne ne vous l'a montré correctement.

Discussions similaires

  1. est ce que je suis infecté ou pas?
    Par rokirakat dans le forum Sécurité
    Réponses: 4
    Dernier message: 29/04/2008, 19h31
  2. Réponses: 4
    Dernier message: 18/11/2007, 18h37
  3. Fonction Quoted printable qui ne fonctionne pas.
    Par leCcsympas dans le forum C
    Réponses: 3
    Dernier message: 13/01/2007, 19h54
  4. Pourquoi pas de compilateur?
    Par zMurfs dans le forum Déploiement/Installation
    Réponses: 4
    Dernier message: 11/03/2006, 16h12

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