+ Répondre à la discussion Actualité déjà publiée
  1. #61
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 6
    Points : 13
    Points
    13

    Par défaut

    Depuis quelques jours je ne vois que les perversités de cette méthode. Personnellement, d'après les projets que j'ai vu, cette methode est plutôt utilisé pour ce qu'elle apporte au clients : spec bâclé ou absente, MOA qui ne sait pas ce qu'elle veut, et surtout toujours demander plus au développeurs, bien évidemment en gardant les mauvaises pratiques: flicages, délais client à respecter avec un taux de 90% de travail à produire obligatoirement. Au final chacun applique la méthode à sa sauce. Et surtout personnellement je passe 80% du temps à documenter.
    Au final il reste plus rien de la methode agile et scrum, si, peut etre les devs qui s'arraches les cheveux.

  2. #62
    Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2012
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

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

    Informations forums :
    Inscription : juin 2012
    Messages : 18
    Points : 43
    Points
    43

    Par défaut La redécouverte du file à couper le beurre

    Ben ouai ! nous voila rendu au nœud du problème : le partage du pouvoir. Je comprend que les "informaticiens" prennent mal la méthode (la doctrine...) Agile ou Lean Machin-bidule. Une enieme ressaucé ou l'on (re)découvre béatement que c'est le client (payeur) qui est au milieu de nos préoccupations (quelle découverte!) (8O) ben ouai on n'écrit pas du code pour faire de la prose et pour faire plaisir aux développeurs technophile et par nature un brin autiste. Ben ouai l'utilisateur finale est fatigué de s'entendre dire qu'il est nulle en informatique et qu'il incapable de comprendre LA vision du gourou spécialiste parce que figuré vous que le client a aussi un métier et que pour lui tous ça n'est qu'un outil. Comme pour tout outil il n'y a que deux alternatives : ça fonctionne et ça lui fait gagner du temps (et de l'argent) ou ça ne fonctionne pas (obliger de réinstaller un nieme patch avec le plugin bidule à qui il manque la dll machin mais à cause la technologie hyperhype C*M qui a été mis à jour pour...) et on met l'outil à la benne.
    Ben ouai les gourous que cela vous chagrine je le comprends mais il va falloir descendre de temps en temps de votre tour d'ivoire et discuter, demander l'avis au client et cesser de considerer qu'on fait de la techno. pour faire de la techno.
    En parlent de cancer je pointerais plutôt du doigt celui qui consiste à balancer dans la nature un truc mal ficellé et laisser le client faire le beta testeur (gratuit, que dis-je il a payé pour, quelle nouille...) en l'obligant bien évidement à s'inscrire en ligne à un compte pour remonter tous les bugs... Avec internet no limit a cette facon de développer du code. Mais bon là on touche le domaine du marketingo-managerialo-commerciale...

  3. #63
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    août 2011
    Messages
    342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : août 2011
    Messages : 342
    Points : 1 016
    Points
    1 016

    Par défaut

    Citation Envoyé par dhamm Voir le message
    Ben ouai ! nous voila rendu au nœud du problème : le partage du pouvoir. Je comprend que les "informaticiens" prennent mal la méthode (la doctrine...) Agile ou Lean Machin-bidule. Une enieme ressaucé ou l'on (re)découvre béatement que c'est le client (payeur) qui est au milieu de nos préoccupations (quelle découverte!) () ben ouai on n'écrit pas du code pour faire de la prose et pour faire plaisir aux développeurs technophile et par nature un brin autiste. Ben ouai l'utilisateur finale est fatigué de s'entendre dire qu'il est nulle en informatique et qu'il incapable de comprendre LA vision du gourou spécialiste parce que figuré vous que le client a aussi un métier et que pour lui tous ça n'est qu'un outil. Comme pour tout outil il n'y a que deux alternatives : ça fonctionne et ça lui fait gagner du temps (et de l'argent) ou ça ne fonctionne pas (obliger de réinstaller un nieme patch avec le plugin bidule à qui il manque la dll machin mais à cause la technologie hyperhype C*M qui a été mis à jour pour...) et on met l'outil à la benne.
    Ben ouai les gourous que cela vous chagrine je le comprends mais il va falloir descendre de temps en temps de votre tour d'ivoire et discuter, demander l'avis au client et cesser de considerer qu'on fait de la techno. pour faire de la techno.
    En parlent de cancer je pointerais plutôt du doigt celui qui consiste à balancer dans la nature un truc mal ficellé et laisser le client faire le beta testeur (gratuit, que dis-je il a payé pour, quelle nouille...) en l'obligant bien évidement à s'inscrire en ligne à un compte pour remonter tous les bugs... Avec internet no limit a cette facon de développer du code. Mais bon là on touche le domaine du marketingo-managerialo-commerciale...
    On peut écrire le même genre d'argumentaire débile à propos des clients qui ne savent pas ce qu'ils veulent et demandent une nouvelle fonctionnalité tous les 4 matins... Mais ce n'est pas ça qui fera avancer le débat.

  4. #64
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    4 201
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : avril 2005
    Messages : 4 201
    Points : 18 801
    Points
    18 801
    Billets dans le blog
    3

    Par défaut

    dhamm,

    Tu parles de développeurs autistes et d'implication client en même temps ?
    Moi je trouve que c'est le monde à l'envers. Je suis avide de savoir pourquoi on calcul ce montant de quelle manière et pourquoi on utilise ce taux et pas un autre. Mais pour mon utilisateur je ne suis qu'un geek qui doit rajouter une fonctionnalité et qui ne comprend pas pourquoi je mets 10 jour avec mon cycle en V pour rajouter un simple rapport alors que l'équipe à côté le fait en une demi-journée - équipe à côté qui n'a qu'un seul environnement, la prod, et des milliers de backups.

    D'un autre côté mon collègue qui est dans une mission où le client s'empresse de le venir dans son bureau pour avoir telle fonctionnalité mais celui-là reste borné parce qu'il ne peut pas utiliser la dernière librairie à la mode et avoir un "challenge technique".

    Deuxio... moi ça me fait marrer la "documentation exhaustive".
    Quand t'es sur un projet où la spec technique (réalisée par un chef de projet) indique " cf spécification fonctionnelle", que la spec fonctionnelle indique "cf spécifications techniques de besoin" et que la STB indique "voir cahier des charges" et que le cahier des charges est un fichier Excel qui ressemble à une sorte de grosse table de hachage (genre cellule A1 "voir cellule B3" cellule B3 "calcul avec cellule K7" et cellule K7 vide ?).
    Tu m'étonnes que du coup, sans documentation c'est tellement beaucoup mieux...
    Ce qui manque c'est des vrais gars qui ont à la fois un bagage technique et métier, qui aura travaillé dans les deux. Non, on préfère foutre des mecs issus de "société de conseil" pour faire la MOA, parce que le teckos est trop borné pour écouter les besoins des utilisateurs, et qu'un utilisateur veut juste un truc sur un écran mais sait même pas ce qu'il veut...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!

    ****

    On dit "le jeu" / "un jeu" / "ce jeu", pourquoi mettre un x à ce mot au singulier ?

  5. #65
    Membre à l'essai
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2012
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 4
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par Hinault Romaric Voir le message
    « Agile est un cancer », pour Erik Meijer
    qui estime qu’il doit être banni une fois pour toutes


    Erik Meijer, un développeur célèbre de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des déclarations acerbes contre Agile, lors d’un événement.

    Les méthodes agiles sont de plus en plus adoptées par les équipes de développeurs. Elles se positionnent comme une meilleure alternative au cycle de développement en cascade, qui ne répond plus aux exigences des organisations qui évoluent rapidement. Elles sont donc considérées comme une recette pour accélérer le processus de développement, tout en réduisant le taux de bogues dans les applications.

    Les méthodes agiles sont unies par le Manifeste agile qui doit son succès à la description de 4 valeurs essentielles, facilement compréhensibles pour les développeurs, à savoir :


    • Les individus et leurs interactions priment sur les processus et les outils.
    • Du logiciel qui fonctionne prime sur une documentation exhaustive.
    • La collaboration avec les clients plutôt que la négociation contractuelle.
    • L’adaptation au changement prime sur le respect des plannings.


    Cependant, l’agilité ne fait pas l’unanimité auprès des développeurs. Lors d’une conférence en Finlande, Erik Meijer a eu des propos très durs envers Agile. « Agile est un cancer que nous devons éliminer de l’industrie », a déclaré celui-ci.

    Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ». Erik Meijer s’en prend particulièrement à la méthode Scrum, qui entraine des « interruptions inutiles ».

    Selon celui-ci, les « Scrum Meeting » sont des interruptions ennuyeuses, au mieux des mécanismes de contrôle subtil utilisés par les gestionnaires pour conduire une équipe, en donnant l’illusion d’un leadership partagé. « Nous devons cesser Scrum et Agile. Nous sommes des développeurs. Nous devons écrire du code », a affirmé Meijer.


    Meijer continue sa diatribe en s’attaquant aux TDD. « C’est tellement ridicule. Pensez-vous que vous pouvez modéliser les échecs réels qui se produisent pendant la phase de production ? », s’est interrogé Meijer, avant de répondre. « Non. » Il préconise un cycle où le logiciel est déployé, et les erreurs fixées lorsqu’ils sont découverts.

    Il faut noter que le créateur de Ruby On Rails, David Heinemeier Hansson, s’était aussi attaqué aux TDD, en affirmant que les tests unitaires n’étaient pas bénéfiques.

    Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »

    Sur ce point, il a été rejoint par un autre conférencier. Nic Ferrier architecte dans une entreprise de développement qui utilise Agile, a affirmé qu’Agile est en partie victime de son succès. Selon lui, lorsque les méthodes agiles ont conduit aux premiers bons résultats, les entreprises ont commencé à développer des outils qui prennent en charge ces méthodes. Dès lors, elles ont commencé à véhiculer l’idée qu’Agile est un outil que l’on peut acheter.

    Un avis d’ Erik Meijer, certes tranché, mais qui reflète la frustration d’un passionné du code, qui souhaite par-dessus tout consacrer son temps à sa passion : écrire du code.


    Source


    Et vous ?

    Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?

    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?

    Agile freine-t-il l’écriture du code ?
    Bonjour, je pense que la méthode AGILE n'est pas pour les développeurs simplement, mais pour une équipe pluri-disciplinaire (développeur, chef de projet, financier (évaluation des couts, ...).

    Je pense qu'ici, c'est le développeur qui parle et qui met plus en avant son amour pour le code et en omettant l'organisation complex qu'il y a derriere et qui intégre le client, ses besoins, les changements de ses besoins ....

  6. #66
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 885
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 885
    Points : 6 734
    Points
    6 734

    Par défaut

    Citation Envoyé par dhamm Voir le message
    Ben ouai les gourous que cela vous chagrine je le comprends mais il va falloir descendre de temps en temps de votre tour d'ivoire et discuter, demander l'avis au client et cesser de considerer qu'on fait de la techno. pour faire de la techno.
    Je partage globalement ton avis même si j'y mettrai pas mal de nuance (surtout dans la formulation).
    Par contre, avant de faire de l'Agile, je ne travaillais qu'avec la MOA et cette MOA, parfois en prestation externe également, pouvait être en décalage avec l'usage réel des utilisateurs de terrain.
    Autrement dit, les RG étaient là (avec une qualité variable mais c'est un autre débat), par contre, en ce qui concerne l'ergonomie et l'enchaînement des actions, cela correspondait assez rarement aux attentes des utilisateurs (le client "donneur d'ordre" et l'utilisateur ont parfois un point de vu assez éloigné l'un de l'autre).

    Depuis que je fais de l'Agile, le client en tant que product owner est présent à chaque point projet mais en plus, à chaque fin de sprint, une démonstration est effectuée auprès des utilisateurs réels.
    Et ça, ça change tout.
    On n'attend plus que l'application soit en production pour avoir les retours utilisateurs. On les a en cours de projet.
    Du coup, on a une adhérence nettement plus forte au projet car bien plus proche des réalités du terrain.

    Par expérience personnelle (j'ai fais 5 projets en Agile), j'estime qu'à budget équivalent, mes nouveaux projets ont env. 20% de fonctionnalités en moins par rapport aux projets en cycle V.
    Le niveau de qualité est équivalent (à peu près autant de bug)
    MAIS un niveau d'utilisation et de satisfaction client nettement plus élevé (même s'il y a des bugs, le clients y accorde nettement moins d'importance qu'avant)

    Avant, c'est un peu comme si je développais des couteaux suisses moyen de gamme.
    Il y avait plein d’ustensiles mais tous assez moyen et surtout pas pratique du tout à l'usage (lame couteau trop courte, trou des poignet du ciseaux trop petit pour les doigts, par exemples)
    Désormais, je développe moins d'outils mais chacun est parfaitement adapté à l'usage.

  7. #67
    Membre à l'essai
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2012
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 4
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par Glutinus Voir le message
    dhamm,

    Tu parles de développeurs autistes et d'implication client en même temps ?
    Moi je trouve que c'est le monde à l'envers. Je suis avide de savoir pourquoi on calcul ce montant de quelle manière et pourquoi on utilise ce taux et pas un autre. Mais pour mon utilisateur je ne suis qu'un geek qui doit rajouter une fonctionnalité et qui ne comprend pas pourquoi je mets 10 jour avec mon cycle en V pour rajouter un simple rapport alors que l'équipe à côté le fait en une demi-journée - équipe à côté qui n'a qu'un seul environnement, la prod, et des milliers de backups.

    D'un autre côté mon collègue qui est dans une mission où le client s'empresse de le venir dans son bureau pour avoir telle fonctionnalité mais celui-là reste borné parce qu'il ne peut pas utiliser la dernière librairie à la mode et avoir un "challenge technique".

    Deuxio... moi ça me fait marrer la "documentation exhaustive".
    Quand t'es sur un projet où la spec technique (réalisée par un chef de projet) indique " cf spécification fonctionnelle", que la spec fonctionnelle indique "cf spécifications techniques de besoin" et que la STB indique "voir cahier des charges" et que le cahier des charges est un fichier Excel qui ressemble à une sorte de grosse table de hachage (genre cellule A1 "voir cellule B3" cellule B3 "calcul avec cellule K7" et cellule K7 vide ?).
    Tu m'étonnes que du coup, sans documentation c'est tellement beaucoup mieux...
    Ce qui manque c'est des vrais gars qui ont à la fois un bagage technique et métier, qui aura travaillé dans les deux. Non, on préfère foutre des mecs issus de "société de conseil" pour faire la MOA, parce que le teckos est trop borné pour écouter les besoins des utilisateurs, et qu'un utilisateur veut juste un truc sur un écran mais sait même pas ce qu'il veut...
    Glutinus, bien dit. Il faut que le développeur s'humanise un peu aussi ! ! !

  8. #68
    Membre averti
    Avatar de Cyrilange
    Profil pro
    Inscrit en
    février 2004
    Messages
    261
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 261
    Points : 328
    Points
    328

    Par défaut

    Un art ça ne se réglemente pas.

  9. #69
    Membre éprouvé

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

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 621
    Points : 1 255
    Points
    1 255

    Par défaut

    Allez ça fait un moment que j'ai pas ronchonné sur ce site je me lance...

    D'abord sur la méthode : privilégier la rapidité de livraison sur la documentation les études et le reste me semble dangereux, surtout en cas de prestataires : la mémoire risque d'être perdue, et du coup on va à la catastrophe.
    Sur l'utilisation de la méthode : là par contre on peut dire ce qu'on veut, Agile mal utilisé c'est comme Merise mal utilisé : ca fout en l'air un projet !
    Le problème est quand une méthode dangereuse est mal utilisée vous voyez où je veux en venir ?

    Une personne comparait Agile au cloud et au Big Data. Je ne suis pas d'accord. Pour moi, Agile est une mode (dont on reviendra je pense après quelques catastrophes), alors que le Cloud et Big Data sont pour moi de vraies révolutions : pour le Cloud c'est un changement total de paradigme concernant l'informatique en tant qu'outil (physiquement je veux dire) et pour el Big Data, c'est une nouvelle conception qui arrive qui va bouleverser la façon dont on va utiliser les données qui s'amassent par Pétaoctets un peu partout !

    J'ai vu aussi quelqu'un dire sérieusement je pense "laissons les utilisateurs nous rapporter les bugs en direct c'est mieux...". S'il y en a, les passagers survivants du vol 7524 qui s'est écrasé en mer sont priés d'appeler le SAV Airbus (ou Boeing) afin de décrire l'incident. Merci.Sinon toutes nos condoléances... Je rêve !

    Enfin, le client roi ça va bien. Y a qu'en informatique qu'on accepte ce genre d'intrusion permanente dans le travail des autres. Essayez un peu de faire pareil avec un plombier ou un chirurgien vous allez voir comment cous allez vous retrouver dehors ! A quoi servent les chefs de projets MOA au juste ? à faire des ronds de jambe ?

    Quant à Cyrilange , l'informatique n'est pas un art, c'est un outil donc ça se réglemente. Cf ma remarque plus haut sur le vol 7524...
    "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.

  10. #70
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 135
    Points
    2 135

    Par défaut

    Quand t'es sur un projet où la spec technique (réalisée par un chef de projet) indique " cf spécification fonctionnelle", que la spec fonctionnelle indique "cf spécifications techniques de besoin" et que la STB indique "voir cahier des charges" et que le cahier des charges est un fichier Excel qui ressemble à une sorte de grosse table de hachage (genre cellule A1 "voir cellule B3" cellule B3 "calcul avec cellule K7" et cellule K7 vide ?).
    Tu m'étonnes que du coup, sans documentation c'est tellement beaucoup mieux...
    Finalement, ce problème là, ne viens pas de l'utilisation de tel ou tel méthode, mais beaucoup plus de certaine incompétences (ou je-m'en-foutisme ou en étant gentil "j'ai-pas-le-temps-trop-débordé") de certain manager.
    Si le chef de projet avait correctement écris la spec technique, si son collègue manager avait détaillé la spécification fonctionnelle, si le responsable métier avait rédigé "tip top" les spécifications techniques de besoin et même si le commercial avait bien relu le cahier des charges .... et bien le projet serait déjà beaucoup plus facile.

    Ce qu'apporte l'Agilité, c'est de partir avec une simple liste de besoins établi grosse maille par le client et que l'équipe de développement puisse l'étoffer avec lui tout au cours de la réalisation du produit en fonction de ses priorités.
    Attention, cela ne veux pas dire que l'on ne fait pas de descriptif fonctionnel (appelé aussi en Scrum "critère d'acceptance d'une user story"), mais juste que l'on les fait que quand on en a besoin.

    Mais alors, le chef de projet, le manager, le responsable métier, le commercial : ils vont se sentir tous inutile là si on a pas besoin d'eux.
    Il faudrait alors qu'ils fassent évoluer leurs rôles dans l'entreprise.

    Et si on pouvait passé au "Management 3.0" ?
    => ça va pas la tête, que les collaborateurs décident dans une entreprise auto-organisée et sans manager, et puis quoi encore ?

  11. #71
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 885
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 885
    Points : 6 734
    Points
    6 734

    Par défaut

    Citation Envoyé par arkhamon Voir le message
    Enfin, le client roi ça va bien. Y a qu'en informatique qu'on accepte ce genre d'intrusion permanente dans le travail des autres. Essayez un peu de faire pareil avec un plombier ou un chirurgien vous allez voir comment cous allez vous retrouver dehors ! A quoi servent les chefs de projets MOA au juste ? à faire des ronds de jambe ?
    Le client peut intervenir car en informatique c'est possible de le faire, voilà tout.
    Si tu te fais un costume sur mesure, à chaque essayage, tu peux demander des ajustements.
    Si tu te fais préparer une voiture de courses pour les 24H du Mans, à chaque essaie, tu peux demander des ajustements.
    Si tu fais construire une maison sur mesure par un architecte, tu peux demander des ajustement à tout moment au fur et à mesure de l'avancement des travaux (car tu prends consciences des volumes, des lumières, etc, etc, etc)
    etc.

    Comme dit à de nombreuses reprises plus haut dans le topic, l'Agile ne correspond pas à tous les projets.
    L'Agile est bien adapté pour faire du spécifique et/ou un prototype.
    Si tu veux du standard, tu choisis une solution standard.

    En ce qui concerne la qualité, si l'application exige un haut niveau (enjeux business, forte charge, données critiques, etc), absolument rien n'empêche de mettre en place en fin de projet une recette globale rigoureuse (avec test de charge, test d'intrusion, etc, etc, etc)
    Cela n'a rien à voir avec l'Agile ou n'importe quelle autre méthode.

    Pour ce qui est de la MOA, elle est plus présente que jamais et joue un rôle centrale bien plus impliquée que dans le cycle en V.
    Le product owner est là tout au long du projet (et pas uniquement au début pour le spec puis à la fin pour la recette comme dans le cycle en V).

  12. #72
    Candidat au Club
    Inscrit en
    février 2005
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    Il est vrai qu'Agile permet au client d'avoir une application qui réponde à ses besoins sans avoir à refaire perpétuellement des avenants...
    Bref ! Méthode agile appliquée = client satisfait !

    Maintenant, Agile est une méthode d'analyse plus que de développement.
    Le code ne doit être écrit qu'en fonction de spécifications techniques données, qui sont issues de l'analyse.

    Donc, je ne vois que 2 explications au message de l'auteur :
    • l'analyse n'est pas faite au moment où le code est développé
    • l'auteur préfère les avenants et faire raquer le client que d'adapter son code


    Personnellement, en tant que client, j'ai toujours eu un produit adapté quand la méthode Agile était employée et j'ai toujours du passer des avenants quand elle ne l'était pas.
    (un bémol pour les avenants : les entreprises concernées font preuve d'une très grande mauvaise foi)

  13. #73
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    159
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 159
    Points : 379
    Points
    379

    Par défaut

    J'ai longtemps cru aux méthodes agile et à Scrum en particulier après avoir lu quelques ouvrages et ce jusqu'à ce que je le vois en application dans un projet. Je me suis trouvé souvent ridicule dans ces stand-up imposés tous les matin, déjà pourquoi se lever et abandonner sa concentration alors qu'on bosse les uns en face des autre pour se faire une réunion du genre les alcooliques anonymes dans un coin de la pièce ?

    Enfin pendant ces réunions on a souvent rien à se dire et il faut quand même se farcir ce que les autres ont a dire sur le travail alors que l'on ne partage pas les mêmes sujets, d'ailleurs plus personne n'écoute personne mais il faut le faire ... encore une fois ridicule et inefficace. Ensuite les petits post-it sur le tableau encore une invention ridicule, on a l'impression qu'une panne d’électricité et survenu et que l'on se mets alors à gérer le projet à l'ancienne ... de toute manière les papiers plus personnes ne les lit maintenant ils ne servent plus qu'à donner bonne conscience au directeur de projet et à égayer le mur fades de papiers colorés.

    On en a un peu ras le bol de ces méthodes contraignantes élaborées par des consultants et qui visent à déposséder le développeur de son travail. J'ai expérimenté d'autres méthodes "agiles" qui elles marchent et je n'ai pas eu besoin qu'on me dise quoi ou comment faire.

  14. #74
    Membre à l'essai
    Homme Profil pro
    Architecte technique
    Inscrit en
    décembre 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : décembre 2012
    Messages : 7
    Points : 18
    Points
    18

    Par défaut il n'est pas toujours possdible de faire de l'agile

    Personnellement j'adore les développements agiles. Elle permet une grande souplesse de ne bride pas l'imagination par des spécifications inutiles.
    Par contre faut être pragmatique, et il faut l'adapter au contexte :
    par exemple, si les programmeurs ne maîtrisent pas le découplage et le re usinage du code, l'agile est condamné à l'échec. il faut alors prévoir un mentorat très important de l'équipe.

    Certains programmeurs sont même incompatibles avec ses méthodes.

    Pour mes équipes, je ne vends jamais une méthode mais plutôt une efficacité en fonction de l'environnement. Un bon exemple avec eux et plus utiles qu'une grande théorie.

  15. #75
    Membre actif
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    128
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 128
    Points : 262
    Points
    262

    Par défaut

    Enfin quelqu'un qui ose taper sur la table et dénoncer les manipulations de la méthode Agile.
    Cette méthode est née pour permettre aux programmeurs de continuer a travailler alors qui n'ont pas la capacité d'organisation suffisante. Tout le reste s'est construit autour de cette idée. Alors oui, il y a bien quelques notions intéressantes dans la méthode Agile, mais sur le long terme, c'est une vaste fumisterie qui conduit trop souvent dans le mur ou aboutie a des projets absolument impossible a maintenir / modifier / terminer.
    Je parle bien évidement ici de projets d'une certaine taille, pas du bout de code pondu en 1 journée pour un client.

  16. #76
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    mai 2011
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 5
    Points : 7
    Points
    7

    Par défaut

    Ce qui est idiot c'est de faire du tout Agile. C'est une autre alternative au cycle en V qui comme le precedent a ses avantages et inconvenients.
    On pourrait tres bien jongler entre les methodes selon les projet au gre du bon sens des managers.
    Un cycle en V quand tout le monde joue le jeu ca marche aussi tres bien, c'est toujours pareil.

    Bref, ca va faire comme la gueguerre C/Java ou Nadal/Federer, les debats sont pas finis entre les partisants enflames pas toujours objectifs, plutot que d'essayer de voir les avantages des 2 parties.

  17. #77
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    239
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 239
    Points : 512
    Points
    512

    Par défaut

    @Jitou : pour avoir vu des projets en Agile et en Cycle en V réussir comme échouer, je me permets de te faire part de mon expérience pour te répondre.

    Je me suis trouvé souvent ridicule dans ces stand-up imposés tous les matin, déjà pourquoi se lever et abandonner sa concentration alors qu'on bosse les uns en face des autre pour se faire une réunion du genre les alcooliques anonymes dans un coin de la pièce ?

    Enfin pendant ces réunions on a souvent rien à se dire et il faut quand même se farcir ce que les autres ont a dire sur le travail alors que l'on ne partage pas les mêmes sujets, d'ailleurs plus personne n'écoute personne mais il faut le faire ... encore une fois ridicule et inefficace.
    Tu as tout à fait raison. Cela vient d'une perversion du stand-up meeting : à l'origine, c'était très informelle, genre à la machine à café, mais ce n'était pas du tout une réunion. Y participait qui veut, quand il peut, et on parlait aussi bien du code que du dernier film que l'on est allé voir que de la fille que l'on a rencontré ce week-end. L'intérêt, c'est de créer un moment convivial où les gens sont accessibles. Par exemple, tu avais une question à poser à Truc, mais il était plongé dans son code et tu ne pouvais pas le déranger ; à la machine à café il est libre et là tu peux lui poser ta question, sans l'interrompre dans son travail.
    Malheureusement, c'est devenu une réunion à part entière qui, comme tu le dis, ne sert à rien et gêne les développeurs dans leur travail. Il faut, dans ces cas là, revenir au principe de base (message à faire passer au chef de projet / team leader).

    Ensuite les petits post-it sur le tableau encore une invention ridicule, on a l'impression qu'une panne d’électricité et survenu et que l'on se mets alors à gérer le projet à l'ancienne ... de toute manière les papiers plus personnes ne les lit maintenant ils ne servent plus qu'à donner bonne conscience au directeur de projet et à égayer le mur fades de papiers colorés.
    Encore une fois, tu as raison. Les post-its sont juste un point de départ des méthodes agiles. Maintenant, il existe des outils permettant de gérer les user stories / defects en se débarrassant de cette contrainte (si vous voyez un jour mon écriture, vous comprendrez pourquoi c'en est une !), et de manière bien plus efficace.

    On en a un peu ras le bol de ces méthodes contraignantes élaborées par des consultants et qui visent à déposséder le développeur de son travail. J'ai expérimenté d'autres méthodes "agiles" qui elles marchent et je n'ai pas eu besoin qu'on me dise quoi ou comment faire.
    Si, à nouveau, on revient aux origines de l'Agile, on se rend compte que ce n'est ... que du simple bon sens. Souvent, un bon développeur seul ou une équipe compétente saura s'auto-organiser, et fera de l'agile sans même le savoir, et ça fonctionnera parfaitement ! Et effectivement, il y a danger quand on voit débarquer sur un projet un "consultant-chef de projet-team leader" spécialisé dans l'agile qui veut mettre en place une méthode avant même de regarder la nature du projet, ses contraintes et le besoin du client.

  18. #78
    Membre actif Avatar de Tr0n33
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    novembre 2014
    Messages
    69
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Service public

    Informations forums :
    Inscription : novembre 2014
    Messages : 69
    Points : 216
    Points
    216

    Par défaut

    L'Agile c'est utile quand on n'essaie pas de te le vendre à tout bout de champ. Ca ne s'adapte malheureusement pas à toutes les entreprises ou tous les projets. Mais globalement tout le monde utilise des méthodes de travail qui se rapproche de Scrum. Le souci c'est que beaucoup veulent l'appliquer à tout sous le prétexte que c'est magique. Ca ne s'adapte pas à toutes les entreprises, pas à tous les projets. J'ai par exemple vu du Scrum dans une TMA sans développement. Scrum c'est chouette, mais pas dans des structures monolithiques gigantesques. Allez donc organiser en Scrum la refonte de tout un SI dans 3 ou 4 technologies différentes. Scrum est une plaie, un cancer causé par les gens qui l'utilisent n'importe comment . Le TDD c'est comme tout, il n'est pas besoin d'en faire des tonnes, l'objectif étant de développer. Trop de développeurs vont se lancer dans un désir de perfection monstrueux sans comprendre l'aspect jetable de certaines choses pour gagner du temps.

    Et beaucoup de choses sont informelles dans Scrum. Y a pas besoin d'organiser une réunion tous les jours si les différents parties savent se causer à la machine à café.

    J'ai passé de bons moments en Scrum comme de bons en cycle en V (et de très mauvais moments dans les deux).

    Bref. Ca ne s'apprend pas sur un coin de bureau l'Agile, ni avec 50 ppt... C'est une mise en pratique quotidienne d'éléments qu'on peut faire évoluer ou disparaître quand les gens sont habitués. C'est un "cadre".
    "Dans une hiérarchie, tout employé a tendance à s'élever à son niveau maximum d'incompétence" - Principe de Peter
    "Il n’y a pas de langage informatique dans lequel vous ne puissiez pas écrire de mauvais programmes" - Dérivation de Murphy
    Un scientifique doit douter de tout et connaître l'échec : http://fr.wikipedia.org/wiki/Corr%C3%A9lation_illusoire

    Tr0n

  19. #79
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 135
    Points
    2 135

    Par défaut

    N'oublions pas qu'il n'y a pas une méthode Agile, mais des méthode Agiles.

    J'ai un ami qui travaillait dans une Web entreprise.
    Ils avaient voulu faire un virage à l’agilité mais après quelque temps ils ont laissé tombé.

    En faite, ils ont voulut appliquer Scrum.
    Or, leurs projets pour les clients étaient pratiquement que des développements de quelque jours, faisant intervenant des personnes de compétences différences (infographiste, développeur, production, ....).
    Et bien sur, chaque personne était à cheval sur plusieurs projets en même temps.
    Il est évident que Scrum ne pouvait pas marché dans ce contexte.
    L'itération régulière de colle pas avec le rythme de livraison client.
    La spécificité de chaque équipier ne permet pas à rendre chacun polyvalent sur un projet.

    Par contre, ils auraient utilisé Kanban, je pense qu'ils auraient pu faire vraiment évoluer leurs façon de travailler dans le bon sens.
    Les livraisons en production auraient pu suivre la logique du développement en intégrant ces personnes dans les projets.
    Ils auraient pu mieux anticiper les goulots d'étranglement (ex: le spécialiste SGBD a trop de projets en même temps)
    Ils auraient une meilleur réactivité sur la réalisation des besoins de leurs clients.

    @Jitou: c'est peut être ton cas, Scrum correspondait peut être pas à votre équipe. Une autre organisation agile aurait peut être pu être plus bénéfique que celle là.

    Maintenant, Agile est une méthode d'analyse plus que de développement.
    Scrum est en effet une méthode fortement appuyé sur l'analyse du produit client, mais Scrum n'est pas à lui seul l'agilité.
    Prend par exemple la méthode eXtrem Programming (XP) et là, tu auras peut d'analyse produit mais une collection d'outils d’ingénierie agile (TDD, pair programming, Intégration Continue, ...) pour aider le développement d'application informatique.

    Quand une entreprise à bien compris l'esprit de l'agilité, elle peut même trouver sa propre organisation en mélangeant plusieurs concepts de plusieurs méthodes (parfois un mixte entre Scrum, Kanban, XP et autres ).
    L'important alors:
    • Ne pas oublier que l'on développe un produit informatique pour un client et des utilisateurs qui ont leurs besoins et leurs contraintes propres.
    • Avoir toujours un temps de rétrospective afin de bien se poser, en équipe, la question de ses pratiques et de voir comment on peut toujours les améliorer.

    Mais sinon, l'agilité est très ouverte.

  20. #80
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 885
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 885
    Points : 6 734
    Points
    6 734

    Par défaut

    Citation Envoyé par Jitou Voir le message
    Je me suis trouvé souvent ridicule dans ces stand-up imposés tous les matin, déjà pourquoi se lever et abandonner sa concentration alors qu'on bosse les uns en face des autre pour se faire une réunion du genre les alcooliques anonymes dans un coin de la pièce ?

    Enfin pendant ces réunions on a souvent rien à se dire et il faut quand même se farcir ce que les autres ont a dire sur le travail alors que l'on ne partage pas les mêmes sujets, d'ailleurs plus personne n'écoute personne mais il faut le faire ... encore une fois ridicule et inefficace.
    J'ai souvent eu ce retour
    Cela vient surtout d'une mauvaise compréhension de ces réunions par l'équipe et d'un leadership du scrum master pas au point
    Etre en position debout a 2 objectifs :
    * aller droit à l'essentiel / être le plus concis possible
    Comme ça fait chier tout le monde d'être debout, il faut aller vite
    Le but est de ne surtout pas rentrer dans les détails mais de faire un point de synchro
    Si quelqu'un rencontre une difficulté, il ne la détaille surtout pas à ce moment là
    Le stand up meeting est juste là pour dire "j'ai un problème, qui peut m'aider ?", un ou plusieurs autres membres de l'équipe se manifestent et on passe au sujet suivant. Pour le détail du problème , l'analyse et l'aide, ça se fait après la réunion.
    Si un stand up meeting dure plus de 10min (et encore, c'est déjà long), c'est qu'il y a un problème que le scrum master doit résoudre
    C'est là que ses compétences de management entrent en jeu dans les méthodes Agiles.
    Il doit identifier les membres de l'équipes qui font des interventions trop longues et leur faire remarquer / comprendre cela et les accompagner pour les aider à être plus synthétique (le tout, sans froisser les susceptibilités, ce qui peut parfois être incroyablement compliqué).

    * s'assurer de l'attention de tout le monde
    La réunion est très courte et tout le monde doit être attentif
    Quand on est debout, on ne peut pas consulter / répondre à ses mails, ni analyser un rapport de compilation, ni lire des spec, etc.
    Idéalement, le stand up meeting se fait avec le PC fermé

    J'ai très souvent eu des stand up meetings qui ne duraient pas plus d'une minute car justement, il y a des jours où on a rien à se dire et dans ces cas là, autant ne rien dire !
    Le tord de beaucoup de scrum master est de faire du remplissage alors que ça ne sert à rien

    Pour ce qui est des post it
    Il y a des outils super bien pour les dématérialiser (par exemple : https://kanbanize.com/ctrl_home est très bien et gratuit)
    Utiliser les vrais post it n'a de sens que pour la hiérarchie qui aime bien voir les grands tableaux dans les bureaux
    C'est juste une question d'image
    Ca leur donne l'impression qu'on travaille et ça fait bien quand il y a des visites des bureaux pour les clients "regardez, on fait de l'Agile, il y a plein de post it sur les tableaux et ils sont de toutes les couleurs" (histoire de faire hype)
    Encore une fois, si le scrum master est à l'aise dans son rôle, il sait faire le tampon entre sa hiérarchie et son équipe et se passer de tout cela

Discussions similaires

  1. « Agile est un cancer », pour Erik Meijer
    Par Hinault Romaric dans le forum Actualités
    Réponses: 84
    Dernier message: 27/01/2015, 10h47
  2. Le JPanel est trop reduit pour mon interface !
    Par LeNeutrino dans le forum JBuilder
    Réponses: 4
    Dernier message: 25/07/2005, 18h58
  3. [Info] Eclipse est-il gratuit pour développer une application ?
    Par kaishef dans le forum Eclipse Platform
    Réponses: 2
    Dernier message: 12/04/2005, 11h04
  4. apprentissage du C est-il necessaire pour C++ ?
    Par Anonymous dans le forum C
    Réponses: 6
    Dernier message: 02/05/2002, 12h56

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