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

ALM Discussion :

Agile : un blogueur estime que le but n’est pas de réduire le temps de développement des logiciels


Sujet :

ALM

  1. #21
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    Novembre 2011
    Messages
    2 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2011
    Messages : 2 261
    Points : 7 748
    Points
    7 748
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par ZJP972 Voir le message
    Ma conclusion après lecture de certains commentaires : l'Agile permet de faire de..l'Early Access.
    (Désolé, terme utilisé pour le dev ludique : Une partie de mes activités.)
    Autant l'analogie est plaisante, autant pour rester rigoureux je dirais que c'est un raccourci maladroit (mais n'étant pas un dév de jeu, c'est peut-être ma compréhension de la notion de "Early Access" qui est maladroite), et cela pour deux raisons :
    - raison de forme : je dirais plutôt que l'Early Access se base sur la même idée que de faire de l'Agile, donc plutôt "L'Early Access permet de faire de l'Agile" et non l'inverse,
    - raison de fond : l'Early Access est avant tout un moyen de permettre à certaines personnes (hors projet) d'obtenir un accès privilégié en échange de ressources pour continuer le dév (financements, feedback, etc.), on fonctionne donc en sens inverse : la demande ne vient pas du client (identification des besoins, etc.) mais du dév ("Ça vous dirait d'essayer ce que j'ai fais ?").

    NB : Ceci est mon 1000e post ! Et je suis content que ce ne soit pas un troll. {^_^}
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  2. #22
    Candidat au Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Allier (Auvergne)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2014
    Messages : 1
    Points : 3
    Points
    3
    Par défaut Assez d'accord
    Après avoir lu le post, les méthodes agiles permettent effectivement de tenir compte de la réalité effective des projets et donc, de faciliter les corrections en cours de route qui sont excessivement nombreuses plus le projet est long. Quelque part, j'ose estimer que l'agilité n'est qu'une réponse à la défaillance de la définition préalable d'un projet, de sa non spécification, de la nébuleuse qui entoure un certain nombre de points autant du au client qu'au technico-commercial.
    Par contre, utiliser une méthode agile peut permettre de livrer rapidement des fonctionnalités et les corriger au fur et à mesure jusqu'à obtention du résultat final escompté.
    Pour pouvoir livrer plus rapidement une application, il est à mon avis impératif de se souvenir des concepts de réutilisabilité, d'abstraction et être capable de fournir au développeur des lignes guides de développement suffisamment rigides pour éviter les pertes de temps liées à la reprise (parfois la réécriture complète) et en redite, surtout, d'avoir défini précisément les fonctionnalités à mettre en oeuvre.
    Pour ce qui me concerne, l'intérêt des méthodes agiles est d'impliquer l'ensemble des intervenants dans la boucle de développement, d'instaurer une dynamique de groupe et une motivation plus globale.
    Donc non, les méthodes agiles n'ont pas pour but de réduire le temps de développement, mais d'en améliorer la qualité générale.

  3. #23
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Qu’en pensez-vous ?
    Que les chroniqueurs actualités sont à court d'actualité .
    C'est qui ce Lewis Foti ? Avec un post datant du 18 sans aucun commentaires, je n'ai pas trop l'impression qu'il fasse référence dans le domaine.

    L'art de transformer un post quelconque en actualité… quitte à faire, autant le faire bien non ?


    Rien de vraiment nouveau sous le soleil, je pense qu'on est tous d'accord. Bien sûr que l'essence d'agile n'est pas d'aller plus vite. À part en pinaillant sur les mots, je pense qu'on est tous d'accord.


    En ce, la remarque à l'origine de cet article est bien plus intéressante que la réponse :
    “Agile is not fast enough, we have to be liquid”

    Cela me fait penser à des questions bien plus intéressant :
    • qu'est-ce que liquid ?
    • agile est-il réellement plus lent que d'autres méthodes ? Dans quelles proportions ? Est-ce qu'il y a des études à ce sujet ? Ce serait intéressant de faire quelques recherches.
    • est-ce que cette éventuelle perte de temps vaut réellement le coût face aux avantages d'agiles ?
    • si agile fait perdre trop de temps, est-ce dû à une mauvaise utilisation d'agile ? Ou y-a-t-il des moyens/astuce pour éviter de perdre trop de temps ? Ou est-ce une perte nécessaire à l'agilité ?
    • est-ce qu'au final, on ne perd pas du temps pour en gagner ?



    Personnellement, je trouve dommage de transformer un post random en actualité en claquant des doigts, sans même faire de recherches complémentaires.

  4. #24
    Nouveau membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Avril 2015
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : Avril 2015
    Messages : 15
    Points : 34
    Points
    34
    Par défaut
    Comme le souligne cet article ainsi que la plupart des commentaires, le but de l'agilité n'est pas d'aller plus vite.
    On est tous d'accord là dessus.

    Mais alors comment faire pour aller plus vite ?

    La réponse naïve à cette question est souvent la suivante : il nous faut plus de ressources (plus de développeurs, plus de testeurs, plus d'argent, plus de café,...)

    Pour avoir bien étudié la question, rajouter des ressources à un projet fait plus souvent perdre du temps qu'autre chose ! (formation des nouveaux, temps d'intégration, investissement dans de nouveaux sous projets, crise cardiaque due à un surconsommation de café, ...)

    Donc c'est quoi la solution ?

    Un début de réponse est à trouver du coté de Kanban, qui peut être couplé à Scrum (appelé ScumBan pour les intimes).

    La méthode Kanban permet d'appliquer la théorie des contraintes sur votre projet, ce qui permettra de fluidifier le processus en détectant rapidement les goulots d'étranglement. Cette méthode est d'autant plus intéressante que bien souvent, on pense que développer un logiciel se cantonne à pisser du code, ce qui permet aux chefs de projets d'incriminer directement les développeurs sur leur vitesse de production.

    Or, une fonctionnalité n'a de valeur que lorsque celle-ci est entre les mains de l'utilisateur. Une fois qu'on à compris cela, on se rend rapidement compte que la chaine de création d'une fonctionnalité commence au moment de l'expression du besoin, et se termine à son déploiement, c'est donc l'ensemble du processus qu'il faut pouvoir mesurer pour l'améliorer.

    La méthode Scrum est appliquée pour le développement, c'est pour cela qu'elle ne peut pas être garante de la rapidité du projet, car bien souvent les goulots d'étranglement se trouvent dans l'étude du besoin ou au moment du déploiement.

    Et bien sûr, ces deux domaines demandent des méthodes de gestions différentes avec des problématiques différentes !

    With programming, it's always begining again.

  5. #25
    Rédacteur

    Avatar de autran
    Homme Profil pro
    Développeur Java
    Inscrit en
    Février 2015
    Messages
    1 241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2015
    Messages : 1 241
    Points : 7 653
    Points
    7 653
    Billets dans le blog
    55
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Là, ta contractualisation agile est très mal faite.
    Le client ne doit pouvoir changer de fonctionnalité qu'avec une autre de même effort.
    Ton épicier n'accepte pas de t'échanger une boite de pâté contre une boite de fois gras, pourquoi on l'accepterait en informatique?
    Est ce que nos commerciaux sont plus mauvais qu'un épicier?
    Le commercial va malheureusement chiffrer le projet en avant-vente en planifiant des macro-fonctionnalités (identification – commandes – facturation – réapprovisionnement…) en partant du principe que ces macro-fonctionnalités peuvent faire l’objet de modification intérieures durant le projet. C’est ce qui porte les germes des futurs conflits agiles.
    Et reconnaissons que ton épicier connait ses produits mieux que ton commercial ne connait le management de projet agile
    Développeur Java
    Site Web

  6. #26
    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 151
    Points
    2 151
    Par défaut
    Citation Envoyé par Neckara Voir le message
    agile est-il réellement plus lent que d'autres méthodes ? Dans quelles proportions ? Est-ce qu'il y a des études à ce sujet ? Ce serait intéressant de faire quelques recherches.
    est-ce que cette éventuelle perte de temps vaut réellement le coût face aux avantages d'agiles ?
    si agile fait perdre trop de temps, est-ce dû à une mauvaise utilisation d'agile ? Ou y-a-t-il des moyens/astuce pour éviter de perdre trop de temps ? Ou est-ce une perte nécessaire à l'agilité ?
    est-ce qu'au final, on ne perd pas du temps pour en gagner ?
    Pourquoi tu parles que l'Agilité est plus lente que le Waterfall?

    On ne parle pas de cela, on évoque juste que l'agilité n'a pas comme avantage d'aller plus vite.
    Cela ne veux pas dire que l'on va moins vite.
    Cela ne veux pas dire non plus que parfois on ne va pas plus vite.

    Cet article rappel juste que ce point là, n'est pas l'argument de travailler en Agile.

  7. #27
    Rédacteur

    Avatar de autran
    Homme Profil pro
    Développeur Java
    Inscrit en
    Février 2015
    Messages
    1 241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2015
    Messages : 1 241
    Points : 7 653
    Points
    7 653
    Billets dans le blog
    55
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Un vrai contrat agile (ex: http://www.contrat-agile.org/) impose justement cela.
    On ne s'engage pas sur un livrable (contenu ou date) mais sur un processus (ex: Scrum).
    On ne vent plus un résultat précis mais de l'effort de création.
    Et l'ensemble des protagoniste sont impliqué dans les choix et leurs conséquences.
    Le client veux la fonctionnalité A au lieu de la B (deux fois moins coûteuse) 1 mois avant la mise en production: contractuellement, il doit en accepter les conséquence (retard, autre fonction non faite, ...)
    L'implication client, c'est là tout le sens de l'agilité.
    C'est très juste mais je ne sais pas comment faire cela avec le code des marchés publics
    Développeur Java
    Site Web

  8. #28
    Membre habitué
    Profil pro
    Consultant
    Inscrit en
    Janvier 2011
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : Espagne

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2011
    Messages : 82
    Points : 132
    Points
    132
    Par défaut Agile ou le foutoir
    Agile, pour moi, serait un peu... Nous allons faire un dévelopement, on ne sait pas trop quoi, qui et comment... On écrit un canvas, et on avance au fûr et à mesure des entretiens avec le client, ceci put nous donner que, si au début, il fallait faire un bateau sans moteur, on peut se trouver a la fin du project avec le France totalement retapé, renfloué et volant sur la crête des vagues.

    Je crois que Agile est un très bon moyen de définir des lagunes dans la définition d'un project, mais encadrée dans des limites d'une façon très claire, c'est un dire, un complèment, jamais un outil de design complet.

  9. #29
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    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 : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par dacodemaniak Voir le message
    Donc non, les méthodes agiles n'ont pas pour but de réduire le temps de développement, mais d'en améliorer la qualité générale.
    Tout dépend de ce que tu mets derrière le terme qualité.

    En ce qui concerne la qualité du code, ce n'est pas l'Agile qui permet d'agir sur ce point mais l'intégration continue (TU, analyseur de code, etc.).
    Cela n'a rien de spécifique à l'Agile.
    La méthode Agile peut être parfaitement suivi et produire un code de merde s'il n'y a pas l'encadrement technique suffisant

    De même, si par qualité, tu entends performance et tenue à la charge.
    La encore, l'Agile n'agit pas sur ces points.

    Reste la qualité fonctionnelle : est-ce que les fonctions métiers sont présentes et utilisables facilement ?
    Là, effectivement, l'Agile répond à cet aspect.
    Nous seulement les spécifications fines se définissent par itération en lien direct avec les utilisateurs (on se garanti une implémentation fonctionnelle qui correspond à l'usage réel) mais en plus, les priorités sont redéfinies à chaque itération (on se garantit que les besoins les plus importants, avec la plus forte valeur ajoutée, sont couverts).

    Par expérience, l'Agile ne permet pas d'aller plus vite mais il permet de mieux satisfaire les besoins réels des clients.
    Avec l'Agile, on se garantit d'avoir une application fonctionnelle à un instant T.
    Autrement dit, on se garantit de tenir une date de livraison mais si l'ensemble des fonctionnalités voulues au départ du projet ne sont pas couvertes mais celles qui sont présentes, sont utilisables et avec une forte adhérences des utilisateurs.

  10. #30
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2012
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2012
    Messages : 15
    Points : 22
    Points
    22
    Par défaut Agile
    A mon avis le développement agile est destiné à mieux développer, absolument pas développer plus vite.
    Mieux développer, ça veut entre autre réduire les dérives et pertes de temps ce qui peut aboutir à un gain de temps au final. Mais pas à développer plus vite.
    En fait en agile on a une durée estimée imprécise, mais beaucoup moins de risques de dérive et pertes de temps et une bien meilleure visibilité de ces dérives quand il y en a (ce qui permet de les corriger rapidement). Dans un développement en cascade en théorie la spécification est parfaite et toute erreur devrait être juste une mauvaise interprétation (c'est possible) qui risque de ne se voir que trop tard (à la livraison), et donc de faire perdre plus de temps. Si vu plus tôt on peut se retrouver devant l'obligation éventuellement de remettre en question la spécification ce qui est dangereux si on le fait sans consulter la moa/moe ou long en passant par le cycle normal (re-document au moins amendés approuvés et redémarrage du développement (dans le pire des cas suspendu).
    Les méthodes agiles améliorent la visibilité des problèmes et souvent leur résolution en tout cas c'est l'intention derrière.
    La visibilité du terme est plus floue mais le seul moyen de réduire les risques dans la méthode cascade est de maximiser l'estimation des dérives possibles et donc d'augmenter le coût dès l'estimation.

  11. #31
    Membre régulier
    Homme Profil pro
    Expert Testing Services
    Inscrit en
    Juin 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Expert Testing Services
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2012
    Messages : 3
    Points : 73
    Points
    73
    Par défaut Prendre de la hauteur sur le choix de la méthode
    L'Agile, Scrum, XTP et consorts... ne ciblent que les projets des clients qui ne sont pas parfaitement préalablement documentés.
    Tout est une question de choix, mais pour bien choisir, il faut se poser les bonnes questions et prendre de la hauteur.

    Cette approche Agile sert pour l'essentiel à couvrir un manque de spécification, ce qui est pourtant du plein et entier ressort du client.
    Quand le client comprend que le product owner c'est lui et uniquement lui, mais aussi et surtout que cette activité est particulièrement chronophage, il fini soit par demander à ce qu'on torde le coup aux bases de l'agilité pour travailler dans un mode semi agile (où sa présence est minorée), soit il abandonne purement et simplement ce mode d'organisation pour revenir au bon vieux waterfall !!
    Je vous en parle d'expérience...

    Et oui, le client DOIT spécifier son besoin, et ce, dans tous les cas de figure : avant ou pendant les dev.
    De fait, le degré de précision du besoin est un point essentiel. Le moment où le besoin est spécifié aussi.

    Le fond de la question n'est pas tant de savoir si le mode Agile permet de produire des lignes de code plus vite, mais de savoir quel est le niveau de qualité que le client est prêt à payer pour un investissement minimal de sa part.
    En effet, soit il investit du temps en rédaction de spécifications fonctionnelles et techniques générales et détaillées (idéalement AVANT le build), soit il passe du temps au quotidien à suivre les sprint au jour le jour (et là, je vous certifie que la majorité des clients s'en mordent les doigts), mais c'est dans ce second cas que l'agilité peut prendre tout son sens... !

    En fait, le choix de l'Agile ou du Waterfall est fonction du client et/ou de son écosystème projet : un client qui sait majoritairement ce qu'il veut aura tout intérêt à opter pour le cycle en V, et à l'inverse, un client qui ne sait pas vraiment bien définir finement ce qu'il veut pourra opter pour une approche dite Agile.

    Quand à l'écosystème du projet, l'influence sur le choix de la démarche est à l'identique :
    Si par exemple c'est le besoin marketing qui prime et qui du fait des enjeux business, d'image, etc..., il se trouve que le projet est soumis a de très fortes contraintes de temps et donc de réactivité, l'Agile peut être une solution.
    Si c'est le DAF de l'entreprise qui a un besoin de type législatif ou réglementaire, il devra préférablement s'orienter vers un mode de gestion en mode Waterfall pour être un peu plus sûr de respecter le triptyque Cout/Qualité/délai de son projet (surtout le délai dans ce cas là...).

    Ma modeste vision du monde sur ce sujet est que l'Agile n'a jamais eu pour but d'optimiser les temps de développement, mais de répondre à un manque d'implication ou de travail de la part du client, ou encore à un très fort besoin de réactivité, par exemple sur des marchés très concurrentiels.

  12. #32
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Pourquoi tu parles que l'Agilité est plus lente que le Waterfall?
    Je n'ai jamais affirmé cela.

    On ne parle pas de cela, on évoque juste que l'agilité n'a pas comme avantage d'aller plus vite.
    Cela ne veux pas dire que l'on va moins vite.
    Cela ne veux pas dire non plus que parfois on ne va pas plus vite.
    Bien évidement, mais si on parle de rapidité sans parler de rapidité, on ne parle plus de rien.

    L'origine du débat est bien "Agile is not fast enough". On s'en moque que ce soit l'objectif ou non de l'Agile, c'est une constatation (erronée ou non). À partir de là, on peut partir sur des questions très intéressantes que j'ai évoqué plus haut.

    Si l'Agile induit intrinsèquement une multiplication du temps de développement par 10, on est en droit de se poser des questions, même si la rapidité n'est pas l'objectif premier de l'Agilité.
    L'Agilité, c'est aussi essayer de s'améliorer entre chaque itérations, si on est pas assez rapide, ce peut être une piste d'amélioration.

    Pareil, si on dit que l'Agilité coûte plus cher, par exemple, bien que ce ne soit pas l'objectif intrinsèque de l'Agilité de réduire les coûts, il y a tout de même un seuil à ne pas dépasser. Une entreprise n'a pas un budget infini.

    Je vois mal une entreprise choisir une méthode agile si cela induit un "retard" de 9 ans sur un projet de 10 jours. J'exagère, mais avant de pouvoir parler, il serait bien, déjà, de savoir ce qu'il en est en pratique, si il y a des études sur le sujet, plutôt que de parler dans le vide.

    Cet article rappel juste que ce point là, n'est pas l'argument de travailler en Agile.
    Ce n'est pas un article mais une actualité/débat sur un billet de blog choisit aléatoirement.

    On est tous d'accord pour dire que la rapidité n'est pas l'objectif d'Agile, rien de nouveau. Si c'est juste pour définir ce qu'est l'Agile, c'est finalement une discutions stérile où on sera tous d'accord sauf sur les mots employés et on va partir sur une discutions de pinaillage.

    C'est tout aussi intéressant que de faire un débat pour dire que la somme des angles d'un triangle vaut 180°. À part avoir plein de réponses qui disent que c'est vrai, mais qui le disent d'une manière différente, c'est assez limité. Jusqu'à avoir une personne qui se trompe sur l'emploie d'un mot, on va partir sur un HS de pinaillage, ou se retrouver dans un espace pseudo-euclidien par transition dérivative du cosinus tangent.

    Si c'est juste pour dire ce que tout le monde sait déjà, j'ai quelques doutes quant à l'intérêt.
    Si on veut apprendre aux autres ce qu'est l'Agile, on écrit un article, pas une actualité/débat.

  13. #33
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Saverok Voir le message
    En ce qui concerne la qualité du code, ce n'est pas l'Agile qui permet d'agir sur ce point mais l'intégration continue (TU, analyseur de code, etc.).
    Cela n'a rien de spécifique à l'Agile.
    La méthode Agile peut être parfaitement suivi et produire un code de merde s'il n'y a pas l'encadrement technique suffisant
    Pas vraiment d'accord, l'intégration continue telle qu'on la connait actuellement a été formalisée dans eXtreme Programming qui est une méthode agile.

    On croit souvent à tort que l'agilité ne concerne que la gestion de projet et pas les pratiques techniques. Appliqué littéralement, ça donne des dysfonctionnements comme ce que certains ont appelé Flaccid Scrum il y a déjà quelques années avec - et sur ce point je te rejoins - du code de m**** si on ne fait pas attention. Pourtant si on regarde bien, les principes du manifeste agile mettaient déjà l'accent sur la technique : "Continuous attention to technical excellence and good design" et des méthodes agiles comme XP nous le disent depuis des années. Le hiatus vient juste du fait que Scrum, la méthode la plus populaire, n'inclut pas de pratiques d'ingénierie.

  14. #34
    Expert éminent sénior

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Huggy60 Voir le message
    L'Agile, Scrum, XTP et consorts... ne ciblent que les projets des clients qui ne sont pas parfaitement préalablement documentés.
    ..
    Cette approche Agile sert pour l'essentiel à couvrir un manque de spécification, ce qui est pourtant du plein et entier ressort du client.
    Tout à fait faux...

    Un gros projet (gros == >= 10-50 années/h) avec une super belle spec bien dans le cycle Waterfall a d'excellentes chances de se planter...

    Que ce soit parce que l'analyse/spec est faite à un temps X, que entre ce temps et la mise en place bien des changements technologiques ont pu avoir lieu, que ce soit du côté des devs ou des utilisateurs, que ce soit parce que ceux qui rédigent les specs sont des informaticiens peu au courant des pratiques des utilisateurs, que ce soit que ceux qui rédigent le Cahier des Charges qui ne PEUVENT pas tout savoir ni tout appréhender, dans un très gros projet, mais aussi parce que on ne peut JAMAIS faire une analyse totale, et du problème, et de la manière de travailler des utilisateurs, et/ou de leurs mécanismes "automatisés" dont ils ne se rendent même pas compte, mais que l'info doit faire..


    Tu peux avoir la plus belle et complète spec possible, si tu suis Waterfall tu risques de manquer tout un tas de trucs.. et avoir éventuellement un truc qui marche, mais qui correspond pas à ce qui était demandé (ce qui était réellement souhaité)

    C'est en ça (du point de vue dev) que l'agilité est irremplaçable...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

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

    Je ne réponds pas aux MP techniques

  15. #35
    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 151
    Points
    2 151
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    ...
    Un gros projet (gros == >= 10-50 années/h) avec une super belle spec bien dans le cycle Waterfall a d'excellentes chances de se planter...

    Que ce soit parce que l'analyse/spec est faite à un temps X, que entre ce temps et la mise en place bien des changements technologiques ont pu avoir lieu, que ce soit du côté des devs ou des utilisateurs, que ce soit parce que ceux qui rédigent les specs sont des informaticiens peu au courant des pratiques des utilisateurs, que ce soit que ceux qui rédigent le Cahier des Charges qui ne PEUVENT pas tout savoir ni tout appréhender, dans un très gros projet, mais aussi parce que on ne peut JAMAIS faire une analyse totale, et du problème, et de la manière de travailler des utilisateurs, et/ou de leurs mécanismes "automatisés" dont ils ne se rendent même pas compte, mais que l'info doit faire..
    ...
    Réaliser un gros projet informatique de ce type en waterfall reviens à vouloir pré-régler à l'avance la température d'une pièce via de simple robinet de radiateur
    On va passé beaucoup de temps à analyser les capacités thermiques de la pièce, l'incidence des baies vitrées, le rendement des radiateurs en fonte, .....
    On connaissant à l'avance le nombre de personnes présentes pour une réunion
    On récupère les prévisions météo avec l'indice de confiance associé.
    Mais le nombre de PCs présents est inconnus.
    => On a toute les chances qu'il fasse soit trop chaud soit trop froid dans la pièce.

    En agile, on sait que l'on ne sait pas tout.
    On ne cherche pas a faire un grosse étude du départ mais on met en place avec un thermomètre une régulation de la température.

    L'agilité, c'est comme un "thermostat" finalement dont le "thermomètre" est la satisfaction client.

Discussions similaires

  1. Comment savoir que votre équipe projet n’est pas agile
    Par Michael Guilloux dans le forum ALM
    Réponses: 27
    Dernier message: 29/05/2015, 19h31
  2. Tim Berners-Lee estime que le monde a besoin d'une Magna Carta en ligne
    Par Stéphane le calme dans le forum Actualités
    Réponses: 6
    Dernier message: 29/09/2014, 22h39
  3. Agile est simple, mais n’est pas facile
    Par Arsene Newman dans le forum Méthodes Agiles
    Réponses: 24
    Dernier message: 09/09/2014, 15h21
  4. Réponses: 2
    Dernier message: 12/04/2011, 17h06
  5. Réponses: 2
    Dernier message: 12/02/2011, 11h21

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