+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    51
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 51
    Points : 1 517
    Points
    1 517

    Par défaut Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries

    Les développeurs devraient abandonner les méthodes agiles
    selon Ron Jeffries, l'un des signataires du Manifeste Agile

    Ron Jeffries, un informaticien américain de renom dit qu'on devrait abandonner les méthodes agiles dans les entreprises. Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le développement Agile de logiciels. Les méthodes dites agiles sont un ensemble de propositions de démarches et de pratiques pour la mise en œuvre d'un projet. Elles sont vite adoptées par les entreprises surtout celles spécialisées dans le développement d'applications informatiques. On voit alors apparaître des alliances pour la promotion des méthodes du Manifeste Agile : la Scrum Alliance, la Kanban Alliance... Des formations et des offres de projets agiles sont proposées. Toutes ces solutions sont offertes pour assister les entreprises dans leur marche pour le développement. Même si les méthodes ne sont pas toujours bien respectées, le fait de les essayer est toujours bénéfique pour l'entreprise. Car cela leur aura permis d'avoir une vision globale sur l'évolution des projets et les aider dans leur prise de décision.

    Cependant, les choses ne sont pas toujours aussi simples pour les développeurs et tous ceux qui participent à un projet agile. Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années qu' « Agile est un cancer que nous devons éliminer de l’industrie ». Andy Hunt, l’un des 17 coauteurs du Manifeste Agile en 2001 n'a pas caché aussi sa déception. Pour lui, Agile n'a pas atteint les objectifs escomptés au départ. Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau ». C'est maintenant au tour de Ron Jeffries de donner son avis.

    Nom : introduction-aux-mthodes-agiles-4-638.jpg
Affichages : 25531
Taille : 53,7 Ko

    Lorsque les idées sont mal appliquées, elles créent souvent la confusion et entraînent plus de travail à faire en peu de temps. Cela augmente par conséquent la pression au sein de l'équipe. Cet état de chose n'est pas toujours bénéfique ni pour les développeurs ni pour l'entreprise. Car cela entraîne plus d'erreurs et les objectifs sont de moins en moins atteints. Cette situation fait que plusieurs développeurs démissionnent de leur poste et l'entreprise devient à coup sûr moins efficace avant que les méthodes agiles ne soient adoptées. Ron Jeffries dit qu’il partage la même pensée que Kent Beck qui dit qu'il « voudrait que le monde soit sûr pour les développeurs ». Il dit être toujours un développeur et qu’il est écœuré de voir que les méthodes du Manifeste Agile compliquent la tâche aux développeurs plutôt que de les aider. C’est aussi attristant de constater que l’entreprise n'obtient pas les résultats escomptés.

    Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste. Cela permet aux développeurs de s’épanouir dans leur travail. Le logiciel étant fonctionnel à tout moment, d’importants travaux d’extension peuvent être effectués dans un délai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la réalisation de l'application.

    Source : Ron Jeffries

    Et vous ?

    Êtes-vous du même avis que Ron Jeffries ? Pourquoi ?
    L'Extreme Programming ne va-t-il pas aussi connaître les mêmes problèmes dans sa mise en pratique ?

    Voir aussi

    Un développeur estime qu'Agile est un « loup déguisé en agneau », le Waterfall 2.0, qu'en pensez-vous ?
    CollabNet : l'adoption des pratiques agiles augmente en entreprise mais très peu d'organisations auraient un haut niveau de compétence
    La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui répond un professionnel du secteur
    Que faire pour minimiser l'impact des interruptions sur l'activité de développement de logiciels ? Appliquer les méthodes Agile ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    3 354
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 3 354
    Points : 5 391
    Points
    5 391

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message
    Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années qu' « Agile est un cancer que nous devons éliminer de l’industrie ». Andy Hunt, l’un des 17 coauteurs du Manifeste Agile en 2001 n'a pas caché aussi sa déception. Pour lui, Agile n'a pas atteint les objectifs escomptés au départ. Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau ». C'est maintenant au tour de Ron Jeffries de donner son avis.
    (...)
    Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste. Cela permet aux développeurs de s’épanouir dans leur travail. Le logiciel étant fonctionnel à tout moment, d’importants travaux d’extension peuvent être effectués dans un délai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la réalisation de l'application.
    Moi je pense qu'il ne faut suivre aucun protocole (agile ou pas) à la lettre.
    Il faut une gestion de projet un peu batarde, en prenant les bonnes idées à gauche à droite.

    Ok l'agile ça peut être nul, mais on ne va pas faire du cycle en V strict quand même !? (dans la plupart des cas, les projets évoluent pendant le développement)

    Citation Envoyé par Bill Fassinou Voir le message
    Êtes-vous du même avis que Ron Jeffries ? Pourquoi ?
    Les développeurs font ce qu'ils veulent...
    Si ils ont un bon résultat avec leur gestion de projet agile pourquoi en changer ?

    Citation Envoyé par Bill Fassinou Voir le message
    L'Extreme Programming ne va-t-il pas aussi connaître les mêmes problèmes dans sa mise en pratique ?
    L'Extreme programming c'est un truc de 1999, c'est pas forcément mieux que Scrum ou Kanban...
    Ça me semble même plus compliqué et lourd que le reste.
    "Alors il entrait le type et il disait une baguette pas trop cuite" Émile.
    «You may be black, you may be white, you may be Jew or Gentile. It don't make a difference in our house. And this is fresh!»

  3. #3
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2017
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : France, Charente (Poitou Charente)

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

    Informations forums :
    Inscription : novembre 2017
    Messages : 20
    Points : 62
    Points
    62

    Par défaut Argument d'autorité

    Personnellement je déteste les arguments d'autorité du genre

    Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le développement Agile de logiciels.
    Sa me donne envie de faire l'exacte contraire de ce qu'on me dit.

    Si une équipe projet fonctionne bien (quelque soit la méthode choisie) pourquoi changer ?

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

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 265
    Points : 525
    Points
    525

    Par défaut

    Il y a beaucoup de regrets dans ces explications, mais hélas, on ne peut que lui donner raison quand il dit "Lorsque les idées sont mal appliquées".
    Trop de SSII et d'incompétents se sont emparés de l'Agilité et lui ont porté atteinte (petite digression totalement hors sujet : je prévois exactement le même futur aux micro-services ...).

    Et je suis totalement d'accord avec la conclusion :
    Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste.

  5. #5
    Membre confirmé Avatar de Kihmé Xs
    Inscrit en
    janvier 2007
    Messages
    541
    Détails du profil
    Informations personnelles :
    Âge : 32

    Informations forums :
    Inscription : janvier 2007
    Messages : 541
    Points : 462
    Points
    462

    Par défaut

    J'ai vu énormément de projets gérés, pilotés et managés avec une mentalité "à l'ancienne" sur laquelle on a ajouté des principes agiles.

    Et ça c'est le bordel, ça n'améliore rien, on ajoute au contraire toujours plus de process et de complexité sur le développeur.

    A l'inverse, j'ai vu des projets pensés agiles, où malgré la complexité technique et fonctionnelle du projet, on obtient un projet où tout va presque bien, et où le développeur peut travailler en toute sérénité.

    Il faut juste savoir être critique et améliorer ce qui doit l'être.

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2012
    Messages
    18
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2012
    Messages : 18
    Points : 50
    Points
    50

    Par défaut

    Quand on voit que même les crédits bancaires sont devenus "agiles", on comprend que la méthode est depuis longtemps dévoyée par son succès marketing. Beaucoup de gens dans les hiérarchies parlent d'agilité sans avoir compris que dans l'agile, c'est la base qui doit rester maitresse de l'organisation.

    L'autre chose, c'est que Scrum ou Kanban marchent pas trop mal sur du court terme, mais sur des gros projets, il n'y a pas vraiment de méthodo out-of-the-box qui puisse s'appliquer comme une recette magique.

  7. #7
    Membre expérimenté
    Profil pro
    undef
    Inscrit en
    février 2013
    Messages
    455
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : février 2013
    Messages : 455
    Points : 1 382
    Points
    1 382

    Par défaut

    Alléluia !

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 011
    Points : 21 737
    Points
    21 737

    Par défaut

    Citation Envoyé par clorr Voir le message
    (.../...) il n'y a pas vraiment de méthodo out-of-the-box qui puisse s'appliquer comme une recette magique.
    ça.

    Quand le donneur d'ordres n'a aucun contact avec la réalité, quand le recruteur ne connait que le coût des gens, quand le chef de projet est incapable de sortir de schémas de pensée préétablis, quand le développeur est quelconque, quand le testeur manque de flair, et que tout ce petit monde essaye de refaire google maps en mieux en 6 mois, comment dire..... Je ne sais pas quelle méthode ils vont choisir, mais je sais déjà qu'ils vont l'accuser de leur échec.

    Les gens qui ont signé le manifeste agile étaient des pointures. Des gens à la frontière du progrès, à l'époque. Qui travaillaient dans d'excellentes conditions. Ils n'ont pas pu imaginer que dans de mauvaises mains, tout ceci puisse terminer abominablement mal. Leur méthode fonctionne, quand elle est appliquée correctement.

    Mais depuis les années 1970, le vrai point de blocage est toujours le même : on choisit les gens n'importe comment, sur de mauvais critères, à tous les postes, et on espère naïvement que la méthode perlimpinpin va permettre à 11 chèvres de gagner la ligue des champions.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    768
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 768
    Points : 2 814
    Points
    2 814

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message
    Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles.
    Pas vraiment. Il recommande aux développeurs d'abandonner Agile, qu'il définit comme

    "the many instances, approaches, and processes that use the word “agile” to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to “Faux Agile” for emphasis"

    Citation Envoyé par Bill Fassinou Voir le message
    il est écœuré de voir que les méthodes du Manifeste Agile compliquent la tâche aux développeurs plutôt que de les aider.
    Là c'est carrément un gros contresens, ce n'est pas "les méthodes du manifeste agile" mais la façon dont elles sont interprétées et appliquées en entreprise, ce qui change tout.

    "their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend"

    La tonalité de la news DVP ne me parait pas rendre justice à la précision du contenu du billet de Jeffries - même si à sa décharge, le titre volontairement sensationnaliste et provocateur n'aide pas. Pour moi, il appelle plus à un "protestantisme agile" qu'on pourrait résumer par :

    Résistez à la pression de "l'Agile dévoyé" qu'on vous impose, en rejetant toute méthode étiquetée Agile mais en restant fidèle aux pratiques fondatrices de l'agile manifesto.

  10. #10
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 553
    Points : 3 731
    Points
    3 731

    Par défaut

    Toute ressemblance avec une religion est purement fortuite .

    Le problème c'est comme toujours...l'humain .

  11. #11
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    597
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 597
    Points : 1 039
    Points
    1 039

    Par défaut

    Si une équipe projet fonctionne bien
    Qu'est-ce qu'une équipe qui fonctionne bien? Est-ce que ça existe?

    Je troll un peu car, j'imagine que tu veux dire qu'il ne faut pas chercher la méthode parfaite quand ça fonctionne. Ben c'est un peu en sois le principe d'une méthode Agile
    Je veux dire par là qu'une méthode agile se doit d'évoluer par touche successive plutôt que de faire des super plan décidé par des managers. La méthode agile est bonne dans sa remise au centre du développement (avec donc une meilleur prise en compte des contraintes informatique) et dans l'évolution progressive qui évite de tout casser y compris ce qui fonctionnait bien. Mais cela ne fait bien sûr pas tout. Il faut évoluer mais en douceur tester de petites évolutions. Aller lentement mais sûrement. Pour moi, c'est ça l'esprit de la méthode Agile.

    En informatique tout est possible mais tout a aussi un coup. Ce qui est simple pour l'utilisateur ou pour le manager ne l'est pas forcément pour le développeur. Pire ce qui a priori paraît simple pour le développeur s'avère parfois complexe. Alors si le développeur peut obtenir un léger changement en cours de route on répond rapidement au problème simplement.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  12. #12
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 989
    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 989
    Points : 7 151
    Points
    7 151

    Par défaut

    Citation Envoyé par KnifeOnlyI Voir le message
    Si une équipe projet fonctionne bien (quelque soit la méthode choisie) pourquoi changer ?
    L'un des principes fondamentaux de l'Agile est l'amélioration continue.
    Cela concerne absolument tous les aspects du projet qu'il s'agisse de la qualité du code, de l'orga des réunions, des docs produits, de l'organisation dans l'équipe, la méthode de gestion de projet choisie, etc, etc, etc

    Bref, il est important de dresser un bilan objectif à l'issue de chaque projet afin d'en déterminer les points positifs de ceux à améliorer / corriger.
    On ne doit jamais se reposer sur ses lauriers et tjrs se remettre en question.
    Même si le projet est un succès, cela n'empêche pas d'effectuer cette synthèse ==> bien au contraire, identifier clairement quelles ont été les clés de cette réussite est primordiale afin de savoir le reproduire et de le communiquer au reste de la DSI.

  13. #13
    Membre confirmé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 335
    Points : 615
    Points
    615

    Par défaut

    Le seul pb que l'on rencontre dans ma boite avec les methodes agiles c'est qu'on est dans la pensée positive systématiquement alors qu'on a rencontre pleins de depassements imprevus :
    - fonctionnalités codées par les devs (pour se faire plaisir car non demandées par le client) et non vendues (devs en mode agile hors le projet n'a pas ete vendu ainsi),
    - archi SOA/micro service et au final de gros soucis de perfs - mais les architectes nous rassurent que le code et les TU/couverture de code sont nickels et conformes a l'etat de l'art (actuel)
    (les devs se justifient par des pbs de BDD et d'infra hors cela fait 20 ans qu'on fait le meme genre d'appli dans des infras bien moins couteuses/complexes avec 0 problemes (une 100aine de projets a ce jour))
    Comme on est dans des technos dans l'ere du temps bien on dira que le bilan est du coup biaisé,

    On se cache les yeux sur la vraie realité et les depassements ahurissants des couts/delais (x3).
    Officiellement dans les equipes de dev c'est une reussite (en pratique le client demande des penalités voir est pret a aller jusqu'a annuler le projet).
    Donc assez difficile a vivre car on navigue entre le mensonge et la mauvaise fois (on ne PEUT PAS dire que la methode et les technos sont en cause, alors c'est la faute de qui/quoi ??) - personne a priori.
    Incapables de reconnaitre qu'il y a des pbs; pensee positive coute que coute (et ca mine pas mal les autres equipes ne fonctionnant pas dans ce mode là car ils sont plus lucides de la realité du projet - hors aspect communication qui est soignée).

  14. #14
    Membre habitué
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    septembre 2017
    Messages
    66
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : septembre 2017
    Messages : 66
    Points : 133
    Points
    133

    Par défaut

    Cycle en V ou méthode Agile le fond du problème reste et resteras l'incompétence de la MOA (le client ou son représentant) qui n'est que rarement capable d'exprimer un besoin correctement, la faute à une horde de cadre, chef de projet, produit, qui sont autant éloigné du besoin (le problème) que de l'outil (le développeur).

    La grosse différence c'est que la responsabilité du résultat produit est imputé au développeur dans la méthode agile (c'est pas écrit dans la méthode, c'est mon triste constat), la MOA et MOE se décharge de toute leur responsabilité sur le technique qui supporte toute la charge du projet. Un projet agile ça se passe comme ça :

    Client : J'ai besoin d'une table
    MOA : on a besoin d'une table
    MOE : Fait une table
    Développeur : j'ai fait une table
    MOE : il a fait une table
    MOA : voilà votre table
    Client : mais la table passe pas ma porte ...
    MOA : faut que la table passe la porte (voyons c'est évident)
    MOE : La table doit passer la porte !
    Développeur : Voilà, la table passe la porte
    .
    .
    .

    Un bonheur pour les SSII, un cauchemar pour les développeurs qui subissent tout (et encore j'ai réduit de beaucoup le nombre d'intermédiaire). Au moins l'avantage du cycle en V, c'est qu'on rédige un cahier des charges technique pour le dev (chose inexistante aujourd'hui) à partir d'un cahier des charges fonctionnels étonnamment rare.

    Pour ma part, nous travaillons uniquement en cycle en V avec nos prestataire de service, la charge de travail est plus conséquente, mais les projets sont mieux faits et plus courts. Pour de l'interne, nous essayons de mettre en contact directement développeurs et les services en besoin, cela reste compliqué, on cherche pas des développeurs experts full-stack, mais des humains avec une certaine sociabilité capable de comprendre le métier, le besoin et d'y répondre, mais c'est très compliqué à trouver.

  15. #15
    Membre du Club
    Inscrit en
    décembre 2004
    Messages
    112
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 112
    Points : 69
    Points
    69

    Par défaut Surtout, continuez l'agile!

    Par pitié, s'il vous plaît, continuez l'Agile, sans formation, sans conception, sans méthode, sans outils, sans moyens, sans assurance qualité, à la bite et au couteau!
    Utilisez des langages illisibles comme C++ ou Java. Surtout ne documentez rien ...

    :-)

    Plus vous continuez, plus j'aurai du travail à réparer toutes ces bêtises.

    Sans rire, c'est tellement difficile d'arriver à faire passer le message que de travailler avec méthode, en structurant son architecture et sa conception, en documentant le cahier des charges, en programmant de telle sorte que le source est l'équivalent d'un dossier de conception, en générant la majorité du source, en modélisant les performances et l'architecture, en testant, en mesurant la qualité et l'entropie logicielle (dette technique) et en corrigeant les défauts dès leur apparition, en utilisant des langages puissants et protecteurs, finalement, on va beaucoup, beaucoup plus vite, tout en produisant de la bien meilleure qualité....

    Toutes les disciplines de l'ingénieur travaillent comme cela : la mécanique, la chimie, la physique, la construction, etc. Pourquoi l'informatique y échappe-t-elle?

    Rapide et agile, ça n'a rien à voir.

  16. #16
    Futur Membre du Club
    Homme Profil pro
    développeur logiciel
    Inscrit en
    mai 2018
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : développeur logiciel

    Informations forums :
    Inscription : mai 2018
    Messages : 3
    Points : 5
    Points
    5

    Par défaut tout dépend du projet

    Chaque projet a ses particularités et ne correspond pas à toutes les méthodes, le problème n'est pas vraiment les méthodes mais leur choix ou adaptation pour projet ...

  17. #17
    Membre actif

    Homme Profil pro
    Consultant en technologies
    Inscrit en
    août 2012
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cambodge

    Informations professionnelles :
    Activité : Consultant en technologies
    Secteur : Conseil

    Informations forums :
    Inscription : août 2012
    Messages : 31
    Points : 223
    Points
    223

    Par défaut Je préfère la méthode à Benjamin que la méthode à Gilles

    Agile dans les sociétés de service, ça ressemble plutôt à une tentative de cadrer le bordel avec de la rubalise.

    On commence à voir arriver les premiers projets agiles d'il y a quatre ou cinq ans pour une v2 et là : pas de doc, pas vraiment de spéc. du code pas structuré, mais comme pour le modèle de BDD un assemblage de légo. Du coup, il faut expliquer au client qu'on fait tabula rasa. Bref, les projets agiles que j'ai vu jusqu'à présent ressemblent à des projets de stagiaires.

  18. #18
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 13
    Points : 13
    Points
    13

    Par défaut Cycle en V

    Quelqu’un ici a dit espérer ne pas « revenir » à du cycle en V pur. Alors, juste une remarque : en France, on a l’habitude de parler du « cycle en V », parce que c’est celui qu’on nous donne en modèle pendant les études.

    À ce jour, je n’ai encore jamais vu ce fameux cycle en V appliqué complètement dans une entreprise.
    En réalité, ce que j’observe, c’est plutôt ce que les anglophones appellent le modèle « waterfall ». La différence ? Dans le « V », il y a écriture du plan de test en même temps que la phase de spec/conception/…/dev associée, en préparation de la phase de TU/TV/recette/… qui est en face dans la branche remontante du V.
    Curieusement (vu l’âge de cette méthode), cela n’est pas sans rappeler le BDD, le TDD… ;-)

    Franchement, dans certaines boîtes, je serais plus rassuré de voir un vrai cycle en V, plutôt que la fausse agilité pilotée par le budget qu’on nous fait subir. Et pourquoi pas du cycle en V incrémental (ceux qui ont fait Génie Informatique doivent connaître). Ce serait bien plus adapté aux désirs du management, tout en conservant un développement itératifs en cycles courts et bon nombre des bénéfices de l’agilité.

    Tout ceci étant dit, je préfère malgré tout l’agilité implémentée correctement : tous les clients que j’ai vu en bénéficier en étaient très contents, et avec une qualité finale exceptionnelle.

    N.B. Super, Developpez.net ! les espaces insécables qui deviennent des étoiles… :-/ J’adore revenir sur tout mon texte faire la guerre des étoiles :-p

  19. #19
    Nouveau Candidat au Club
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : mai 2018
    Messages : 1
    Points : 1
    Points
    1

    Par défaut Agile ou pas Agile, telle est la question

    Le gros avantage de l’agile est l’iteration et la valeur apportée au client finale. Fini l’effet tunnel ! Mais d’experience pas tous les projets sont eligibles à être menés en Agile ! Faut faire de l’Agile parce que c’est la mode
    Je ne pense pas que l’Agile est fini, mais c’est vrai que parfois l’implementation ne suit pas la definition.

  20. #20
    Membre confirmé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 335
    Points : 615
    Points
    615

    Par défaut

    Comme dit plus haut meme dans les cycles dit en 'V' en 30 ans je n'ai jamais connu d'effet tunnel et cela en acceptant pourtant des changements/evolutions tout au long du projet. Les seuls projets ou ont est souvent emmerdés c'est les contrats avec les boites anglo saxones. Tu fais exactement ce qui est dans le contrat (meme si c'est debile voir inutile). On a vecu le cas a plusieurs reprises. On avait identifié des choses specifiées pas coherentes; donc proposition de modification pour aller vers le mieux; et bien non, refus categorique, aller au bout du contrat, puis redemarrer un autre contrat pour faire les adaptations.
    Bref du nawak mais bon tant qu'ils paient, faire/defaire/refaire c'est du boulot.

Discussions similaires

  1. Quels sont les langages de programmation les plus utilisés par les développeurs ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 18
    Dernier message: 02/05/2018, 13h29
  2. Réponses: 55
    Dernier message: 08/09/2016, 17h43
  3. Quelles pratiques les développeurs devraient-ils éviter ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 53
    Dernier message: 18/03/2015, 18h18
  4. Réponses: 42
    Dernier message: 25/02/2010, 02h15
  5. Réponses: 0
    Dernier message: 19/02/2010, 08h21

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