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

Humour Informatique Discussion :

Coder rapidement ou écrire du code de qualité ? Les deux approches ne servent à rien

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par bleporini Voir le message
    (.../...)
    Je vous conseille de passer un peu de temps à étudier les méthodes agiles. Ce n'est pas uniquement parce qu'on est un développeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqués dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.
    (.../...)
    D'accord avec le reste, mais pour les méthodes agiles, je ne suis pas emballé(enfin, pas toujours). Tout simplement parceque l'important n'est pas la méthode, mais que le client ET la MOA soient impliqués. Quand le client suit le projet de près et répond aux questions(et en pose), ça peut être du waterfall à 18 mois, ça marche. Ca eut marché aussi en agile, mais pas parceque c'est de l'agile. Pour moi, le choix de l'agile est surtout intéréssant pour des projets ou on peut tester vite(tout ce qui comporte une interface, tout ce qui est batches quotidiens). Pour les monstres mensuels que je traite actuellement, ça n'aurait aucun sens.
    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.

  2. #22
    Membre confirmé
    Inscrit en
    Juin 2009
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 219
    Points : 473
    Points
    473
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Je pense que la meilleure méthode reste celle là :



    C'est la méthodologie de la RACHE à découvrir ici : http://www.risacher.com/la-rache/ et qui est utilisée dans de très nombreux projets.
    I like this

  3. #23
    Membre averti
    Profil pro
    Inscrit en
    Août 2005
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 270
    Points : 342
    Points
    342
    Par défaut
    D'après mon expérience, de presque 30 ans, il y a deux types de "clients".

    Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.

    Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...

    Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.

  4. #24
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    Avril 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : Avril 2004
    Messages : 830
    Points : 1 430
    Points
    1 430
    Par défaut
    Citation Envoyé par FR119492 Voir le message
    Bonjour à tous!

    Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:
    1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
    2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

    Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.

    Jean-Marc Blanc
    Pour le point 1, la méthode la plus sûre et la plus rentable n'est-elle pas de reservir ce qui a convenu à un client précédent ?
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  5. #25
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par jmguiche Voir le message
    Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...
    Les commerciaux adorent ce type de client qui, multiplient la durée des projets et transforment les forfaits en régies.
    Bizarrement, les développeurs eux les aiment moins... Allez comprendre...
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  6. #26
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    938
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 938
    Points : 1 806
    Points
    1 806
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Les commerciaux adorent ce type de client qui, multiplient la durée des projets et transforment les forfaits en régies.
    Bizarrement, les développeurs eux les aiment moins... Allez comprendre...
    Pas vraiment. Au début oui. Ensuite les clients râlent parce que le projet n'avance pas, hurlent que les développeurs sont incompétents et exigent que leurs modifications communiquées après la date théorique de fin du projet soient faites sans supplément de délai et de prix ou le projet tombent à l'eau. Les commerciaux n'aiment pas les projets déficitaires.

  7. #27
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par jmguiche Voir le message
    D'après mon expérience, de presque 30 ans, il y a deux types de "clients".

    Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.

    Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...

    Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.
    C'est intéressant comme retour d'expérience, as tu des informations plus formalisées sur le sujet ?

    a+

  8. #28
    Membre averti
    Profil pro
    Inscrit en
    Août 2005
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 270
    Points : 342
    Points
    342
    Par défaut
    Citation Envoyé par kaymak Voir le message
    C'est intéressant comme retour d'expérience, as tu des informations plus formalisées sur le sujet ?

    a+
    Tu veux des noms? je n'en donnerais pas!
    C'est un simple constat. En fait, ce sont deux extrêmes, entre ces 2 extrêmes, tout se trouve.

    Ce que je remarque, par contre, c'est que le phénomène du changement d'avis et de l'incohérence s'accentue peut être (mais ce n'est qu'un ressenti, pas une étude statistique). Comme si les gens ne savaient plus réfléchir, ils effleurent, zappent, sans aller au bout des choses.
    Qu'on ne me dise pas que c'est parce que "tout change, tout va vite, on ne peut pas figer un besoin...". Ce n'est pas ça l'origine du problème. Ce ne sont pas des problèmes nouveaux qui apparaissent en cors de projets, ce sont des points qu'on avait oublié d'exprimer.

    Par contre, la mode des méthodes dites "agiles" accentuent peut être le phénomène. Beaucoup considèrent qu'une vue d'ensemble n'est pas utile : on fonce dans le développement à partir d'un besoin exprimé en 20 lignes dans un mail.
    Je pense que c'est une erreur, une très mauvaise mise en oeuvre de ces approches qui necessitent, au contraire, une maitrise d'ouvrage à l'esprit clair, structuré, avec une immense capacité d'abstraction et d'anticipation. Bref, rien à voir avec les profils que l'on rencontre quelquefois : zappeurs, brouillon, réactif plutot que dans l'anticipation et, j'exagère à peine, avec quelques difficultés avec la logique booléenne !

  9. #29
    Membre averti
    Profil pro
    Inscrit en
    Août 2005
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 270
    Points : 342
    Points
    342
    Par défaut
    Citation Envoyé par BugFactory Voir le message
    Pas vraiment. Au début oui. Ensuite les clients râlent parce que le projet n'avance pas, hurlent que les développeurs sont incompétents et exigent que leurs modifications communiquées après la date théorique de fin du projet soient faites sans supplément de délai et de prix ou le projet tombent à l'eau. Les commerciaux n'aiment pas les projets déficitaires.
    Pour les marchands de viande en régie, et ils sont de plus en plus nombreux, c'est jackpot, il faut l'admettre.

  10. #30
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    hello,

    Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.
    J'aurais du préciser, c'est ce point qui m'à particulièrement interpellé. En fait ce que j'y trouvait d’intéressant c'était ce retour d'expérience de mauvais utilisation, d'une application de méthode qui n'à pas fonctionné.
    Car je trouve que c'est aussi le meilleur moyen de savoir si on pratique bien ou pas telle ou telle chose que de savoir en détecter ces disfonctionnements, et rester clairvoyant face à sa situation.


    Sinon à la lecture de ton post, je suis plutôt d'accord avec toi.
    Mais il est difficile de quantifier de tels choses, par ailleurs chaque situation à des réponses plus ou moins adaptées.
    bref, la réponse est difficile, car je suis convaincu que les deux méthodes ont leurs raisons d'être, malgré tout.

    a+

  11. #31
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2004
    Messages : 253
    Points : 446
    Points
    446
    Par défaut
    Il est aussi facile de coder à partir des spécifications que de marcher sur l'eau
    A condition que les 2 soient gelées
    Il est agréable d'avoir le choix. La difficulté est alors de faire le bon (ou le moins pire).

  12. #32
    Membre confirmé Avatar de Mobius
    Profil pro
    none
    Inscrit en
    Avril 2005
    Messages
    463
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : none

    Informations forums :
    Inscription : Avril 2005
    Messages : 463
    Points : 558
    Points
    558
    Par défaut
    Citation Envoyé par bleporini Voir le message
    Je vous conseille de passer un peu de temps à étudier les méthodes agiles. Ce n'est pas uniquement parce qu'on est un développeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqués dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.
    Je pensais que les méthodes agiles c'était le contraire : voir le graal s'éloigner en perdant du temps.
    Expérience observé : Le client décide de passer aux méthode agile pour réduire les cycle de développement en ayant une qualité accrue. Il fait venir un expert agile expliquant à tout le monde comment faire. Après avoir écouté la grande messe, tout le monde met un maximum de bonne volonté, communique chaque matin sur le job de la journée. Il s'est révélé que ce qui devait prendre 5 minute chaque jour pouvait durée plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avancé, peut donner de nouvelles directive (ou changer d'idée) encore plus souvent. Résultat des courses, on passe plus de temps en réunions (donc moins de temps de développement) et le travail est plus rapidement mis à la poubelle.
    Librairie d'accès LDAP en Java : LdapBeans
    et pensez au tag

  13. #33
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Citation Envoyé par Mobius Voir le message
    Je pensais que les méthodes agiles c'était le contraire : voir le graal s'éloigner en perdant du temps.
    Expérience observé : Le client décide de passer aux méthode agile pour réduire les cycle de développement en ayant une qualité accrue. Il fait venir un expert agile expliquant à tout le monde comment faire. Après avoir écouté la grande messe, tout le monde met un maximum de bonne volonté, communique chaque matin sur le job de la journée. Il s'est révélé que ce qui devait prendre 5 minute chaque jour pouvait durée plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avancé, peut donner de nouvelles directive (ou changer d'idée) encore plus souvent. Résultat des courses, on passe plus de temps en réunions (donc moins de temps de développement) et le travail est plus rapidement mis à la poubelle.
    De la bonne volonté et un daily meeting n'est pas suffisant pour combler une absence de gestion projet.

    Les methodes agiles mettent en oeuvre des cycles de développement complexes, nécessitant une grande rigueur dans la gestion du projet. C'est justement parce que le cadre du projet est très rigoureux qu'on peut se permettre de modifier le cahier des charges ou le contenu des itérations pendant le développement.

    Si déjà on a du mal avec un SDLC simple (waterfall, spiral, sawtooth), il faut éviter de plonger dans l'agile en espérant que ca va magiquement résoudre les problèmes. Enfin, c'est mon avis.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  14. #34
    Membre confirmé Avatar de billynirvana
    Homme Profil pro
    Architecte technique
    Inscrit en
    Décembre 2004
    Messages
    472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Décembre 2004
    Messages : 472
    Points : 552
    Points
    552
    Par défaut
    La méthode Agile est une très bonne méthode de travail si l'équipe (manager du projet + architecte + développeurs) ont de nombreuses années d'expérience avec une méthode plus stricte et rigoureuse.

    Cela donne une certaine souplesse au projet, pas besoin d'attendre le feu vert de la hiérarchie, pas besoin d'attendre la maj du cahier des charges, des specs, des docs annexes (planning...) pour mettre en place une évolution. Tout se réalise en même temps, la perte de temps est fortement réduite.

    Dans une méthode de travail stricte toutes les évolutions sont refusées sous prétexte qu'elles n'étaient pas prévues dans les specs, même si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une méthode Agile, cette question et cette réponse n'a plus lieu d'être (bien entendu si l'évolution reste dans le périmètre du projet initial).

    La méthode Agile selon moi ne sert qu'à ça, cela ne change pas la façon d'architecturer et de développer le projet. La méthode Agile ne doit pas converger vers la méthode à l'arrache.

    Par mon expérience j'ai participé à plusieurs projets où nous avons employé cette méthode Agile, le premier projet était très bien j'ai adoré mais je sens que de plus en plus on se laisse aller. Peut êre faudrait-il alterner les deux méthodes pour garantir dans les deux cas un travail de qualité. Rigueur et souplesse!

  15. #35
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par BugFactory Voir le message
    Pas vraiment. Au début oui. Ensuite les clients râlent parce que le projet n'avance pas, hurlent que les développeurs sont incompétents et exigent que leurs modifications communiquées après la date théorique de fin du projet soient faites sans supplément de délai et de prix ou le projet tombent à l'eau. Les commerciaux n'aiment pas les projets déficitaires.
    Non, quand il s'agit de demande d'évolutions, celles-ci sont chiffrées et ajoutées au coût du projet. Ce sont les anomalies qui sont à la charge de la SSII. Évidemment, les commerciaux s'arrangent avec le client (faudrait pas le braquer non plus) et intègrent au projet une certaine partie des évolutions si leur coût est raisonnable par rapport à l'ensemble du projet.

    Dans le cadre d'une régie, ces questions ne se posent pas...
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  16. #36
    Membre averti
    Inscrit en
    Décembre 2007
    Messages
    222
    Détails du profil
    Informations forums :
    Inscription : Décembre 2007
    Messages : 222
    Points : 434
    Points
    434
    Par défaut
    Le problème survient quand le commercial ne sait pas précisément quel est le cout en travail de telle ou telle évolution ajoutée "pour faire plaisir au client".
    La sécurité de l'emploi
    "Ce n’est pas une pratique médicale sensée que de risquer sa vie en se soumettant à une intervention probablement inefficace afin d’éviter une maladie qui ne surviendra vraisemblablement jamais."
    Docteur Kris Gaublomme, médecin belge ("Vaccins et maladies auto-immunes")

  17. #37
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    hello,

    Dans une méthode de travail stricte toutes les évolutions sont refusées sous prétexte qu'elles n'étaient pas prévues dans les specs, même si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une méthode Agile, cette question et cette réponse n'a plus lieu d'être (bien entendu si l'évolution reste dans le périmètre du projet initial)
    .

    En même temps, il me semble que de demander une validation hiérarchique pour ce genre de demandes, relativement justifiée, ne dénote t'il pas d'un problème dans la méthodologie de gestion du projet et de ces aléas ?

    Je ne suis pas encore passé à l'agile, mais j'espère que cela m'apportera de meilleures réponses dans des situations plus cruciales.

    M'enfin, il y à la gestion du projet d'un point de vue définition des besoins et implémentations, il y à aussi la gestion du projet du point de vue maintenance de l'existant.
    Dans le deux cas il y à besoin de border le périmètre, de contrôler les ajouts et modifications, sans pour autant que cette machinerie ne soit un frein à l’innovation du projet.
    Sans non plus que se soit dangereux ou épique pour l'équipe de développement.
    C'est ce qui est de plus difficile, et malheureusement, je n'ai pas encore trouvé, vue, expérimenté de meilleures solutions que de faire reposer cette logique et ces process sur les épaules d'un homme :/

    Et ça c'est très mauvais.....

    a+

  18. #38
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par OWickerman Voir le message
    Le problème survient quand le commercial ne sait pas précisément quel est le cout en travail de telle ou telle évolution ajoutée "pour faire plaisir au client".
    C'est quand même rare que le commercial valide une évolution sans en faire part au préalable à l'équipe technique (enfin, j'imagine qu'il doit bien y en avoir qui le font... ).
    Dans le cadre d'un forfait, tout dépassement est la charge de la SSII. Accepter de prendre en charge des évolutions sans les chiffrer, c'est aller droit dans le mur.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  19. #39
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par Barsy Voir le message
    C'est quand même rare que le commercial valide une évolution sans en faire part au préalable à l'équipe technique (enfin, j'imagine qu'il doit bien y en avoir qui le font... ).
    Dans le cadre d'un forfait, tout dépassement est la charge de la SSII. Accepter de prendre en charge des évolutions sans les chiffrer, c'est aller droit dans le mur.
    Déjà vécu. Plusieurs fois.

  20. #40
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    Citation Envoyé par billynirvana
    mais je sens que de plus en plus on se laisse aller. Peut êre faudrait-il alterner les deux méthodes pour garantir dans les deux cas un travail de qualité
    Normalement, "se laisser aller" ne fait pas partie du déroulement d'un projet agile. Cela contredit l'un des principes du manifeste "Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.". Le rôle du coach XP (ou du Scrum Master) est de vérifier que ces règles sont respectées. Cela tient donc de la gestion de projet, et non de la méthode en elle-même.


    Citation Envoyé par Mobius
    Expérience observé : Le client décide de passer aux méthode agile pour réduire les cycle de développement en ayant une qualité accrue. Il fait venir un expert agile expliquant à tout le monde comment faire.
    C'est bien d'expliquer aux gens comment faire, mais il faut aussi un accompagnement (coach XP, Scrum Master) qui connaisse la méthode.
    Citation Envoyé par Mobius
    Après avoir écouté la grande messe, tout le monde met un maximum de bonne volonté, communique chaque matin sur le job de la journée. Il s'est révélé que ce qui devait prendre 5 minute chaque jour pouvait durée plusieurs heures.
    On en revient toujours au même : le problème, ce n'est pas la méthode, c'est la manière de gérer l'équipe.
    Le client, se rendant compte au fur et a mesure de l'avancé, peut donner de nouvelles directive (ou changer d'idée) encore plus souvent. Résultat des courses, on passe plus de temps en réunions (donc moins de temps de développement) et le travail est plus rapidement mis à la poubelle.
    Là encore, il ne faut pas croire que méthode agile = chaos. C'est d'ailleurs tout le contraire : il existe des moments pour changer d'idée, demander de nouvelles fonctionnalités, etc. Tout ne se fait pas n'importe quand.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

Discussions similaires

  1. Réponses: 2
    Dernier message: 22/01/2010, 19h07
  2. Réponses: 1
    Dernier message: 17/04/2007, 14h07
  3. Façon d'écrire votre code
    Par reptils dans le forum C
    Réponses: 6
    Dernier message: 03/03/2007, 18h20
  4. Réponses: 3
    Dernier message: 17/08/2006, 05h11
  5. [VBA Excel] Comment écrire un code dans le ThisWorkBook ?
    Par WebPac dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 03/05/2005, 16h03

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