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

Méthodes Agiles Discussion :

Les méthodes agiles sont-elles une arnaque ?


Sujet :

Méthodes Agiles

  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 4 570
    Points : 252 372
    Points
    252 372
    Billets dans le blog
    121
    Par défaut Les méthodes agiles sont-elles une arnaque ?
    Les méthodes agiles sont-elles une arnaque ?
    Les développeurs les préfèrent pour éviter de planifier et de documenter selon un rapport de Voke


    Présentées comme des méthodes de développement permettant de concevoir une application en impliquant au maximum le client, les méthodes agiles sont de nos jours de plus en plus adoptées dans les équipes de développement.

    Ces méthodes tentent de résoudre les défauts des anciennes méthodes de gestion de projets en définissant quatre valeurs fondamentales : l’interaction avec les personnes plutôt que les processus et les outils ; des logiciels opérationnels plutôt qu'une documentation exhaustive ; la collaboration avec le client plutôt que la négociation contractuelle, la réactivité face au changement plutôt que le suivi d’un plan.


    Derrière l’adoption grandissante des méthodes agiles se cacherait autre chose que le souhait de répondre au mieux aux besoins du client. Selon une étude du cabinet d’analyse Voke, les développeurs préfèrent les méthodes agiles pour éviter de planifier et de créer la documentation.

    L’étude menée auprès de plus de 200 entreprises et experts IT a permis à Voke de faire ressortir seulement quatre observations détaillées décrivant le succès des méthodes agiles, avec 40% d’utilisateurs de ces méthodes qui n’ont identifié aucun avantage de celles-ci.

    « Le mouvement Agile pourrait très bien être simplement soit une rébellion du développeur contre les taches indésirables et les horaires, ou tout simplement un moyen de vendre des services, y compris formation et certification Agile » conclut Voke.



    Source : Le rapport de Voke (accessible après inscription)


    Et vous ?

    Etes-vous d’accord avec ce rapport de Voke ? Pourquoi avez-vous adopté une méthode agile ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre régulier

    Profil pro
    Inscrit en
    Mars 2009
    Messages
    83
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 83
    Points : 89
    Points
    89
    Par défaut
    Salut

    En quoi les méthodes Agile n'impliquent pas la rédaction d'une documentation?

  3. #3
    Invité
    Invité(e)
    Par défaut
    ... avis partagé. Je suis persuadé qu'à l'origine il s'agit effectivement d'un principe permettant au développeur d'être au plus prêt de son client, pour répondre au mieux et au plus vite à ses besoins.

    Le contre-coup nous permettant d'être exemptés d'une partie des contraintes non-techniques, qui nous permet de nous recentrer sur l'essentiel en limitant les interruptions parfois malvenues de planification et prévision est bien sûr un bonus à ne pas négliger, mais je pense que ce n'est pas la raison de la création des méthodes agiles...

  4. #4
    Membre éprouvé

    Homme Profil pro
    Ingénieur logiciel embarqué
    Inscrit en
    Juillet 2002
    Messages
    386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur logiciel embarqué
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juillet 2002
    Messages : 386
    Points : 1 164
    Points
    1 164
    Par défaut
    de mon expérience (j'ai adopté ces méthodes sur demande de mon chef de projet, initialement) il y a toujours beaucoup de doc, de réunions et d'heures sup. J'airais tendance a dire, dans le contexte dans lequel je l'ai vécu que les méthodes agiles apporte plus de souplesses dans le travail, ce qui permet de mettre plus de pression sur le développeur. Je n’aurai jamais fait 50h par semaines payé 35 si on m'avais dit de pointer a 8 et 17h, et sans une ambiance de travail me permettant d’être heureux au boulot.

    Par contre j'ai connu une autre situation bien moins efficace ou on a essayer de faire marcher "certaines" méthodes agiles sur de la maintenance applicative, sans aucun membre de l’équipe de conception. (le projet ayant été conçu selon la bonne vielle méthode traditionnelle) Et effectivement a la place du client je n'aurais pas été satisfait.

    Mon avis en général c'est qu’avec une bonne équipe, de la motivation et de la bonne volonté, l’agilité peu apporter énormément car elle laisse la liberté d’innover (aussi bien dans la gestion de l’équipe que du projet) avec un feedback. Si on est dans un projet en appliquant a la lettre la "méthode" trouvé dans un livre, ce n'est plus vraiment de l’agilité. Même si certains le revendiquent.

  5. #5
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 23
    Points : 45
    Points
    45
    Par défaut 200 chef de projet.... ?
    Voila pour moi les personnes sondées... 200 Chef de projet de l'"ancienne école" accros du cycle en V et du Gant ! qui ont très certainement vu dans l'avènement des méthodes agile une attaque sur leur périmètres.

    C'est vrai que les méthodes agiles paraissent plus souple, mais c'est complément faux. Il s'agit de vrai méthodes de bout en bout définissant clairement les rôles et les responsabilités de chacun. Ces Process combinés à l'usage de bonnes pratiques comme celles de l'XP, ont à mon sens révolutionner l'industrie du développement. Et ces méthodes sont de plus en plus appliquées et pour moi leur adoption est directement issue des échecs des anciennes méthodes.

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2012
    Messages
    371
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2012
    Messages : 371
    Points : 1 002
    Points
    1 002
    Par défaut
    Et ben si les méthode AGILE sont un moyen habile de faire faire au salarié 50h au lieu de 35, il faut en effet les interdire au plus vite. Car faire du travail gratuit, c'est du vol

  7. #7
    Membre à l'essai
    Directeur technique
    Inscrit en
    Juillet 2012
    Messages
    1
    Détails du profil
    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : Juillet 2012
    Messages : 1
    Points : 17
    Points
    17
    Par défaut L'agilité n'est pas une méthode !
    L’agilité n’est pas une méthode. Selon moi, c’est plutôt une philosophie qui conduit à observer nos métiers selon un angle précis, guidé par des principes fondateurs simples :
    • Les individus et leurs interactions plus que les processus et les outils
    • Des logiciels opérationnels plus qu’une documentation exhaustive
    • La collaboration avec les clients plus que la négociation contractuelle
    • L’adaptation au changement plus que le suivi d’un plan

    Naturellement, des “méthodes” ou “frameworks” existent (Lean, Scrum, Kanban…), et sont nécessaires pour cadrer les pratiques, voire même pour faire adhérer aux principes sous-jacents de manière opérative.
    Mais en fin de compte, la mâturité des équipes reste très faible sur l'agilité, et les SSII retardataires qui ne font que surfer la vague, noient encore plus le message d'origine à grands coups de marketing...
    Pour celles et ceux que cela intéresse, j'ai posté un article il y a quelques semaines sur ce sujet :
    Camarades agilistes, indignez-vous !

  8. #8
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2006
    Messages
    572
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 572
    Points : 631
    Points
    631
    Par défaut
    Comme on dit sur internet : "this post gave me cancer"

    L'agile c'est pas une solution miracle qui va faire que tout va fonctionner et c'est la fête. Ce n'est certainement pas non plus l'anarchie. Et ce n'est pas un modèle en V rebrandé.

    En gros, vous savez que c'est la merde quand vous entendez : "je suis chef de projet scrum master" ou "c'est de l'agile on fait pas de specs" ou encore "vous êtes en retard alors que vous faites de l'agile !".

    Le modèle en V c'est un modèle théorique. Pour qu'il fonctionne, il faut que tout le monde soit parfait. Oh et que le monde arrete de tourner le temps qu'on sorte l'application.

    Ce modèle plait aux "corporates" (chef de projet, personnel transverse et autres superviseurs) parce qu'il permet de mettre la tête dans le sable pendant 95% du projet, en n'envoyer que des rapports dans le vert (bon pour le bonus). Il ne reste plus que 5% de panique à la fin.

    L'agile, c'est la volonté de regarder un projet informatique avec les yeux d'un adulte. On ne peut pas prédire l'avenir. Tout le monde se plante. Le monde change, les besoins aussi. Il peut arriver n'importe quoi.
    L'agile c'est de dire "on sait qu'il y a des problèmes, et qu'on ne peut pas les prévoir. Ce qu'on peut faire, c'est limiter les risques au maximum".

    Oui, l'agile c'est fait pour limiter les risques.

    Exemple d'un risque : dans une grande société audiovisuelle, il y a eu un grand projet en interne sur plusieurs années pour gérer tout ce qui a trait à la publicité. On va passer sur les problèmes, sur les retard, ou sur l'ergo cauchemard. Le fait notable et marquant est le suivant : après 3 ans dans le pipe, à investir des millions, le projet sort enfin... Un mois avant l'application de la loi interdisant la publicité sur ce support.

    S'ils avaient fait de l'agile, ils n'auraient pas changé la loi. Le projet aurait été mis à la poubelle au même moment. Par contre, vu qu'il y aurait eu des livraisons en prod régulière (2 semaines ou un mois), certaines parties de l'application auraient pu être utilisées pendant 2 ou 3 ans avant d'être obsolètes.

    Les specs wiki, les test fonctionnels automatisés en avance de phase, le tdd, les équipes réduites, les user stories, le kanban, les rétrospective, le backlog, le pair programming, les standups, la communication avec le client... Tout ça, ce sont des outils de l'agile qui permettent de limiter un risque.


    Pour répondre plus directement à la question : montrez moi un développeur qui n'est pas content de l'agile, je vous montre un projet qui n'est pas agile.
    Venez partager vos expériences au sein d'un projet sur slicesofit, agile & amélioration continue

  9. #9
    Membre averti Avatar de Shinzul
    Homme Profil pro
    Lecteur assidu de code source
    Inscrit en
    Janvier 2008
    Messages
    174
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Lecteur assidu de code source
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2008
    Messages : 174
    Points : 333
    Points
    333
    Par défaut
    L'adoption des méthodes agiles peut être poussée par les développeurs mais généralement il s'agit plutôt d'une pression managériale ou business.

    Le problème de ce type d'intégration au sein des équipes est que les clients n'entendent que ce qui les intéresses dans les méthodes agiles (entendre par la de la réactivité et une réponse rapide aux besoins).
    Malheureusement, ceux-ci ne veulent pas se plier aux contraintes que l'agile impose et gardent leurs ancienne méthode en demandant plus de réactivité et de livraison aux équipes de dev.

    Donc pour moi l'agile, si c'est vraiment appliqué, ne pose aucun problème aux développeurs, elles permettent même un gros gain mais elles demande une éducation des clients et de l'implication. Si les méthodes ne sont pas vraiment appliquées, elles deviennent effectivement un problème pour l'équipe à qui on demande d’être plus réatif et plus "agiles" sans amélioration réelle des méthodes de travail ...
    N'oubliez pas le quand vous avez votre solution.

  10. #10
    Membre chevronné Avatar de zeyr2mejetrem
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2010
    Messages
    471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable de service informatique

    Informations forums :
    Inscription : Novembre 2010
    Messages : 471
    Points : 2 040
    Points
    2 040
    Par défaut
    Je suis assez d'accord avec Faiche.

    Le problème n'est pas le concept, mais l'implémentation du concept.

    Qui n'a pas travaillé avec un "Pointy-Haired Boss" qui interprète l'agilité uniquement comme une absence de documents ou de cadre contractuel qui permettrait au client de lui coller un papier sous le nez en lui disant "Ce n'était pas les termes du contrat, vous avez fait de la m***, je paie pas !!" ?

    Qui n'a pas travaillé avec un client dont l'émissaire était une grosse feignasse qui trouve dans l'agilité l'excuse pour ne pas donner les billes pour mener le projet à bien (pas par malveillance mais parce que ça lui imposerai de faire autre chose que de blablater de façon interminable dans des réunions pour bosser et produire un document) ?

    Le problème de l'agilité réside dans le fait qu'il prône une communication entre individus, donc plus verbale.
    Cette communication laisse moins de traces et donc il est plus facile de se planquer quand on est un gros glandeur.

    J'ai connu des projets menés à l'ancienne qui ont très bien marché.
    J'ai connu des projets agiles où la dynamique était telle qu'on avait même pas l'impression qu'il y avait une conduite de projet et où ca a cassé la baraque.

    A chaque fois l'élément commun était la bonne volonté et la qualité de l'équipe.

    Hélas, j'ai aussi souvent connu l'inverse.
    • Chef de projet "Scrum Master XP+" injoignable et inexistant ou omniprésent, inflexible et avec un QI de moineau blond lobotomisé.
    • Représentant client qui n'a rien à péter du projet parce qu'il sait que de toute façon tout faire capoter lui apportera moins d'emm*** que de mener à bien. (Si si, ca se voit souvent chez les gros clients)
    • Développeurs glandeurs (si si, ca existe ) où hermétiques à tout changements.
    Si tu ne sais pas faire, apprends. Si tu fais, fais bien. Si tu sais bien faire, enseigne.
    Mieux vaut paraître stupide quelques temps que rester stupide toute sa vie.

  11. #11
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    Juste une chose : pour ce que j'ai pu en voir, ce rapport est payant. Je veux bien aller jusqu'à m'inscrire sur leur site, mais de là à sortir 126,03 € pour un rapport (en fait, il s'agit de 2 rapports, donc 252.06 €), faut pas déconner !

    Sur le fond, je pense qu'affirmer que les mauvaises pratiques qui découlent d'une mauvaise application des méthodes agiles peuvent vraiment constituer une critique valable de celles-ci, je ne suis pas sûr que ça soit bien sérieux.

    Ce qui constitue pour moi le coeur des méthodes agiles :

    • Cycle de développement court
    • Développement itératif
    • Implication de représentants métiers du début à la fin du projet
    • Outillage du code avec des tests automatisés
    • Adaptation au changement en cours de route


    Contrairement à beaucoup d'idées reçues, les méthodes agiles bien appliquées nécessitent de la discipline. Un des principes de l'XP, par exemple, est que le code doit toujours être le plus simple possible, sans duplication de code. Pour ce faire, le refactoring doit être constant ! Il faut constamment factoriser, maintenir à niveau, maintenir les tests, etc. Ce n'est pas forcément facile.

    Je pense que les méthodes agiles viennent clairement d'un ras-le-bol de la part de la communauté des développeurs envers les méthodes anciennes dont le but était surtout de permettre à la hiérarchie de se rassurer, mais qui ne permettait pas de produire du logiciel de qualité. Ça ne veut pas dire que les méthodes agiles sont forcément plus simples à appliquer.

    Oui, les méthodes agiles sont conçues, à mon avis, pour permettre aux développeurs de se consacrer sur leur travail, au lieu de devoir se consacrer à d'innombrables tâches parasites, mais je ne vois pas en quoi ça constitue un problème.

    De par mon expérience, je sais que les méthodes agiles ne sont pas faciles à appliquer dans des entreprises qui n'ont pas une culture d'ingénierie très forte. Les commerciaux, les gens du marketing, les gens du métier ne sont pas faciles à convaincre, parce que effectivement ces méthodes sont conçues pour répondre aux besoins des développeurs, et que ça, souvent , ça déplait. Mais les logiciels qui ne fonctionnent pas bien, ça déplait aussi.
    Le résultat, ce sont des méthodes agiles mal appliquées, et ça, ça débouche souvent sur des catastrophes :

    http://en.wikipedia.org/wiki/Avalanche_model

    Dans l'entreprise où je bosse, ils prétendent appliquer la méthode Scrum. En fait, ça veut effectivement dire qu'on travaille sans spec. Mais ça, ce n'est pas du Scrum, où le backlog constitue bel et bien une spec. Ils font de la Rache, en fait...

  12. #12
    Membre averti
    Inscrit en
    Mars 2008
    Messages
    283
    Détails du profil
    Informations forums :
    Inscription : Mars 2008
    Messages : 283
    Points : 380
    Points
    380
    Par défaut
    J'ai déjà vu le projet Agile à la "définition fonctionnelle uniquement et surtout pas technique". J'ai fait mes propres parties communes avec documentations (vu que les autres n'en avaient pas). Performances multipliés par 100 juste par le fait que les outils étaient bien utilisés par mes collègues et pas utiliser certaines anciennes fonctions des bourrins pour ouvrir des sessions pour récolter des infos dans un seul champ (sur des milliers d'enregistrements ).

    Et non je ne suis pas dieu. On s'est rendu compte bien plus tard que mes fonctions existaient déjà. On ne savais juste pas qu'elle étaient là.

  13. #13
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    Citation Envoyé par Grimly Voir le message
    J'ai déjà vu le projet Agile à la "définition fonctionnelle uniquement et surtout pas technique". J'ai fait mes propres parties communes avec documentations (vu que les autres n'en avaient pas). Performances multipliés par 100 juste par le fait que les outils étaient bien utilisés par mes collègues et pas utiliser certaines anciennes fonctions des bourrins pour ouvrir des sessions pour récolter des infos dans un seul champ (sur des milliers d'enregistrements ).

    Et non je ne suis pas dieu. On s'est rendu compte bien plus tard que mes fonctions existaient déjà. On ne savais juste pas qu'elle étaient là.
    Une rumeur très répandue voudrait que les méthodes agiles seraient contre la documentation. C'est totalement faux. Simplement, elles préfèrent une documentation minimaliste plutôt que des PDF et des Powerpoint vendus au kilo. De préférence de la documentation embarquée dans le code, façon Javadoc ou Doxygen. L'avantage, c'est que ça a plus tendance à rester à jour. Parce que le PDF de 200 pages, il restera comme il est pendant 10 ans et, une fois obsolète, induira plus en erreur qu'il ne donnera d'informations.

  14. #14
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2006
    Messages
    572
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 572
    Points : 631
    Points
    631
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je pense que les méthodes agiles viennent clairement d'un ras-le-bol de la part de la communauté des développeurs
    [...]
    Oui, les méthodes agiles sont conçues, à mon avis, pour permettre aux développeurs de se consacrer sur leur travail, au lieu de devoir se consacrer à d'innombrables tâches parasites, mais je ne vois pas en quoi ça constitue un problème.
    Non non, ni "par les développeurs" ni "pour les développeurs". Ne pas confondre l'outil et l'objectif.

    Le but c'est de livrer le meilleur produit dans le meilleur budget/temps.

    Les "taches parasites" c'est un coût, un risque. Il y a donc des outils dans l'agile qui permettent de s'en abstraire (standup de 5 min le matin plutot que réunion de 2h hébdomadaire, management visuel plutot que reporting et réunions ...)

    Et d'expérience, une direction marketing sera bien plus intéressée par l'agile que la DSI. Parce que la méthode agile remet le business en avant, comme enjeu principal.


    @Grimly : Un projet c'est un ensemble de besoins fonctionnels. Chaque développement entrepris doit avoir une valeur directement pour le client. On ne paye pas pour un socle d'entreprise, on paye pour une fonctionnalité.
    Maintenant s'il y a des outils qui doivent être réutilisés, il est de ton devoir de le communiquer.

    Pour ça repose toi sur les standups, les retros et un wiki. Mais ce qui te permettra le mieux de réussir, c'est de binomer de temps en temps.
    Dans mes différents projets, on a mis en place une validation de code croisée avant de livrer chaque story. C'est le créneau idéal pour comparer les pratiques et arriver à un standard.
    Venez partager vos expériences au sein d'un projet sur slicesofit, agile & amélioration continue

  15. #15
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2006
    Messages
    572
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 572
    Points : 631
    Points
    631
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Une rumeur très répandue voudrait que les méthodes agiles seraient contre la documentation. C'est totalement faux. Simplement, elles préfèrent une documentation minimaliste plutôt que des PDF et des Powerpoint vendus au kilo. De préférence de la documentation embarquée dans le code, façon Javadoc ou Doxygen. L'avantage, c'est que ça a plus tendance à rester à jour. Parce que le PDF de 200 pages, il restera comme il est pendant 10 ans et, une fois obsolète, induira plus en erreur qu'il ne donnera d'informations.
    Pour moi il y a 3 docs :
    - les specs fonctionnelles, par fonctionnalité puis par story. Dans un fitnesse ou greenpepper, accompagnées des tests. C'est écrit par les fonctionnels, assistés par les devs.
    - la doc technique : un wiki pour les bonnes pratiques, les FAQ. Pour le reste, suivre la règle : "si tu veux mettre un commentaire, regarde d'abord si tu devrais pas refactorer ton code à la place".
    - la doc utilisateur. Obligatoire, jamais lue. Pour ça j'ai pas de solution, c'est gerbant.
    Venez partager vos expériences au sein d'un projet sur slicesofit, agile & amélioration continue

  16. #16
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2012
    Messages
    1
    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 : Juillet 2012
    Messages : 1
    Points : 5
    Points
    5
    Par défaut
    Dans le secteur des jeux-vidéo, les japonais travaillent encore avec les anciennes méthodes de développement. En occident, les équipes de développement ont été influencées par le secteur IT et ont adopté ces méthodes agiles.

    On peut constater qu'aujourd'hui, l'industrie japonaise se porte assez mal. Elle ne s'est pas adaptée aux consoles next-gen et ne sort quasiment plus aucun blockbuster (voir l'E3 2010-2011-2012), et ceux qui sortent font souvent pâles figures. Les grands éditeurs japonais (Capcom, Konami et etc.) confient carrément aujourd'hui le développement de leurs plus grandes licences à des studios européens ou canadiens (Castlevania et Devil May Cry par exemple) et SquareEnix s'en sort actuellement grâce à son rachat d'Eidos (Hitman Absolution).

    Les studios occidentaux eux enchaînent les jeux triple A (même si j'en ai personnellement marre de cette débauche de FPS et TPS...) et les méthodes agiles y sont pour beaucoup.

  17. #17
    Membre habitué
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    Mai 2006
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2006
    Messages : 49
    Points : 167
    Points
    167
    Par défaut
    D'un point de vue commerce, les méthodes agiles sont un formidable outil.

    Le client ne sait/veut pas faire la description de son besoin/spécifications. Les méthodes agiles, c'est des livraisons fréquentes. Tant qu il y a de l'argent le projet continue. A chaque livraison, le client exprime des besoins, corrige ce qui ne lui plait pas.....

    D'un point de vue commerce, les méthodes agiles sont un formidable outil.
    Le client reçoit régulièrement des livraisons, qu'il doit valider avant la prochaine livraison, sinon c est considéré comme validé. Bref, une économie pour la société informatique, qui fait supporter le coût de la validation au client (M$ copyright).

    Dans les faits, c est différent....

  18. #18
    Membre régulier Avatar de MenshaKaine
    Inscrit en
    Juin 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Juin 2009
    Messages : 68
    Points : 81
    Points
    81
    Par défaut
    Analysons cette phrase:

    « Le mouvement Agile pourrait très bien être simplement soit une rébellion du développeur contre les taches indésirables et les horaires, ou tout simplement un moyen de vendre des services, y compris formation et certification Agile » conclut Voke.
    On trouve sémantiquement les mots:
    rébellion, taches indésirables, horaires

    Il s'agit bien encore de présenter les développeurs comme des empêcheurs de tourner en rond ou plus tot comme des gens qui n'aime pas qu'on les presse comme des citrons !

    De plus, on associe ce mouvement au développeur ... sont-il les seules à participer à la création de produits informatiques ?
    D 'où un développeur doit-il tous faire ? Est-il le seul à fournir de la plus-value ? Est-il le seul à connaitre son produit ? Et les autres font quoi ?

    Je me demande qui a commandé cette enquête !

    Mon observation du monde de l'IT m a montré que peu de gens ont une démarche produit ... maintenant agile, cycle en V, ... y-a-t-il un processus idéal ? Un processus qui remplace les hommes compétents et de bonne volonté ?

    Merci et bonne journée.

  19. #19
    Membre à l'essai
    Inscrit en
    Août 2002
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : Août 2002
    Messages : 13
    Points : 18
    Points
    18
    Par défaut Intent : moyen de garder la doc synchronisée
    Je pense qu'un des problèmes majeurs avec la doc est de la garder à jour.

    C'est toujours pénible d'avoir à penser à remettre à jour la doc au fur et à mesure des avancées du projet, et au final, comme elle est souvent désynchronisée, elle finit par être presque abandonnée (ou pire, elle est faite juste parce que ca fait parti des livrables, mais sans réel envie qu'elle soit utile).

    Et avec les méthodes agiles, comme on livre de plus en plus souvent, cette désynchro est de pire en pire.

    Et je trouve justement que le projet OpenSource Intent a bien ciblé ce problème et propose une solution assez sympa pour régler ça.
    C'est un projet assez jeune mais on voit déjà à quoi ça va ressembler : http://www.eclipse.org/intent/

    J'ai assisté à présentation du leader du projet et la vidéo vient d'être mise en ligne : http://t.co/e9xa5PQv

    En gros, on peut à la fois avec de la doc dans une syntaxe WikiStyle, du code, des modèles de conception, et l'outil se charge tout seul de savoir si des désynchros ont eu lieu et aide à maintenir tout ça en cohérence.
    Dans un contexte agile, je pense que ca aide pas mal.

  20. #20
    Membre averti
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    290
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 290
    Points : 426
    Points
    426
    Par défaut
    Agile pour éviter de planifier

    Faire un planning au début d'un projet c'est formidable pour se donner une idée de son organisation, du plan de charge et d'une date de livraison. Après, on peut le mettre à la poubelle et travailler avec un burndown chart pour vérifier très régulièrement si on est dans les clous. C'est bien si on a des échéances de releases espacées. A mon avis c'est souvent le cas car le client n'a pas forcément les ressources pour faire de la validation en continue : quand ce n'est pas son métier il faut l'accompagner, l'aider à s'outiller.

    Quand on pousse XP par exemple, on se dit qu'on va livrer toutes les semaines, ce n'est plus nécessaire de construire son diagramme de Gantt, on peut se limiter à prioriser les items. Une semaine c'est peu de temps à l'échelle d'un projet et en même temps c'est une durée qui peut permettre de sortir une killer feature ! L'approche n'est pas "je dis que je suis agile parce que je n'aime pas faire de planning" mais "en étant agile, je peux faire l'économie de la rédaction d'un planning"

    Agile pour éviter la doc

    Aujourd'hui dans notre boulot, la doc a 2 utilités :
    * Communiquer (de façon unidirectionnelle) : le client communique son besoin dans le CdC, nous donnons notre interprétation dans des specs. Dans cette optique, la documentation n'est valable que lorsqu'on a besoin de communiquer de l'information de façon compréhensible pour les 2 parties. Quand c'est fait, on est censé avoir suffisamment d'info pour commencer à coder. Quand le code est réalisé, on devrait se débarrasser de la doc., pour ne partir que des fonctionnalités existantes. Si le client a besoin de faire évoluer le système, on a à nouveau besoin de communiquer, on refait des docs.
    * Se protéger : on s'attend à ce que la maintenance d'un système soit bon marché. Pour cela on opte pour de la maintenance corrective (le système n'a normalement pas de bug puisqu'il a été testé de nombreuses fois). Pour décider si un incident nécessite une correction comprise dans le forfait de maintenance ou une évolution à commander, on se tourne vers les spécifications. Les parties se mettent d'accord sur leur interprétation du document pour aboutir a un compromis. Ce fonctionnement est néfaste et prend du temps. Pourquoi faire la distinction entre anomalie et évolution et ne pas simplement faire évoluer le programme ?

    Dans les deux cas, l'utilité de la documentation souffre de son ambiguïté : elle dépend de la compréhension du lecteur. Elle ne pourra jamais être aussi précise que le code lui même. Elle constitue un point de départ qui sera progressivement remplacé par le code, bien plus précis.

    En ce qui concerne la doc technique : elle peut servir à savoir quelle partie du code réalise une fonctionnalité donnée. A mon avis, ce besoin est dû à une mauvaise organisation des systèmes. La structure des applications devraient se baser sur des conventions, pour que tout le monde puisse s'y retrouver peu importe le système.

    La doc utilisateur ? OK, ça peut être important. Mais, bon, il va tout le temps vous appeler de toute façon : dites lui de rédiger un wiki .

    En définitive, on ne se sert pas des pratiques agile pour éviter la doc mais pour trouver un moyen de ne pas avoir à tenir un jour la doc obsolète. Dans l'informatique, lorsque quelqu'un sort un livre, on peut presque dire qu'il devrait le mettre à jour toutes les semaines. Ce n'est pas possible car le temps à consacrer à la rédaction et le coût de l'édition sont trop important. En quoi serait-ce différent pour nos spécifications ?

Discussions similaires

  1. Réponses: 4
    Dernier message: 19/05/2016, 00h32
  2. Les tablettes sont-elles une mode éphémère ?
    Par Idelways dans le forum Hardware
    Réponses: 35
    Dernier message: 20/10/2012, 11h05
  3. Les tablettes sont-elles une mode éphémère ?
    Par Idelways dans le forum Actualités
    Réponses: 0
    Dernier message: 01/04/2011, 15h30
  4. Réponses: 5
    Dernier message: 29/12/2010, 16h13
  5. Application : Les procedures stockées sont-elles inévitables ?
    Par nytmare dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 19/11/2006, 19h49

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