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. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut Agile : un blogueur estime que le but n’est pas de réduire le temps de développement des logiciels
    Agile : un blogueur estime que le but n’est pas de réduire le temps de développement des logiciels
    Qu’en pensez-vous ?

    Quel est le but du développement Agile ? Développer des systèmes plus vite ou être agile dans le sens littéral du terme ? C’est à cette question que Lewis Foti - architecte de logiciel - a essayé de répondre pour corriger certaines conceptions que beaucoup pourraient avoir au sujet du développement Agile.

    La question a été suscitée par un développeur qui estime que l’Agile n’est pas assez rapide et qu’il faudrait aller plus vite. En y réfléchissant, Foti parvient à la conclusion selon laquelle le développement Agile peut permettre de livrer rapidement des projets, mais c’est à tort de croire que l’objectif est de développer des systèmes plus vite.

    Pour l’architecte de logiciel, comprendre le but de l’Agile passe par la compréhension des différences entre les méthodes Agiles et les méthodes de développement traditionnelles dites en cascades. « Agile est basé sur la planification légère, le développement incrémental, la livraison précoce et une réponse flexible au changement », rappelle-t-il pour commencer.

    Par contre, les développements en cascades gravitent autour d’un planning défini dès le départ avec un délai et un budget à respecter, et c’est la raison pour laquelle ce type de projets connait un faible taux de succès. En effet, comme l’explique Foti, il n’y a aucun moyen de savoir exactement combien complexe le système à livrer peut-il être avant qu’il ne soit mis en œuvre. Des imprévus peuvent se produire à tout moment et affecter le planning, tant au niveau du délai qu’au niveau du budget. Faire donc un planning global peut facilement conduire à la livraison d’un produit incapable d’offrir le nécessaire à l’utilisateur final.

    Si au début du projet, les développeurs n’ont pas vraiment une idée claire de ce qu’ils essaient de livrer, ils en saisissent toutefois une meilleure compréhension alors que le projet progresse. Le développement Agile exploite cette compréhension accrue du projet pour améliorer le plan initialement défini.

    Pour répondre à sa question, Lewis Foti conclut que « le développement Agile permet de reconnaître les réalités de l'exécution du projet, sachant que nous ne connaissons pas assez ce qui est nécessaire au début du projet. Agile fournit un mécanisme et un environnement où les plans et les priorités sont adaptés pour profiter des connaissances acquises. La visibilité accrue du progrès et la validation fréquente de ce qui est développé réduit les risques liés à la livraison du projet. Les projets agiles peuvent permettre de livrer plus rapidement, mais ils doivent veiller à ce que l'effort soit investi de manière appropriée et conduire à la qualité de livraison ».

    Source : Big architecture

    Et vous ?

    Qu’en pensez-vous ? Quelle est votre expérience du développement Agile ? Dans la pratique, Agile permet-il de réduire le temps de développement de logiciel ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Agile n'a en effet jamais eu pour but de travailler plus vite... Sinon ça serait la méthode miracle !

    Après en général on fait souvent de l'Agile car c'est classe, mais avec un client et une maitrise d’œuvre qui n'en fait pas et qui ne jure que par la date de livraison avec contenu à 100%.
    Du coup l'Agile c'est beau en théorie, dans la pratique c'est une façon de travailler différente mais qui d'un point de vue projet ne change pas grand chose (si c'est dans le cas que je décris dans la phrase du dessus).

    Si Agile vous dit que vous finissez 100% dans 6 mois mais que la livraison est dans 3 mois vous vous tournez vers vos chefs. Et là qu'on soit Agile ou en Cascade la réponse c'est la même.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  3. #3
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Octobre 2013
    Messages
    1 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2013
    Messages : 1 563
    Points : 3 404
    Points
    3 404
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Après en général on fait souvent de l'Agile car c'est classe
    Pas tout à fais convaincu... Les méthodes Agiles nécessitent un minimum de rigueur et d'investissement des acteurs. Si on s'y intéresse ce n'est pas pour le vendre auprès de ses clients mais bien pour essayer de résoudre les problèmes que l'on peut rencontrer dans des méthodes de gestion de projet telles que le Cycle en V (ou alors on risque d'aller droit dans le mur).

    Qu’en pensez-vous ? Quelle est votre expérience du développement Agile ? Dans la pratique, Agile permet-il de réduire le temps de développement de logiciel ?
    Je n'ai pas encore expérimenté l'agilité, mais il me semble que le but premier n'est pas de réduire le temps de développement, mais de se concentrer sur le besoin du client (d'où une réponse flexible au changement). Je pense que la réduction du temps de développement n'est qu'une conséquence (on développe des fonctionnalités demandées/confirmées par le client en début de sprint et pas une solution négociée l'année dernière).

  4. #4
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    Par défaut
    Le but d'Agile n'est pas de réduire le temps de développement logiciel. C'est de donner plus de marges de manoeuvre, en rendant possible un dialogue plus direct avec les clients, en s'adaptant en temps réel à la demande client (et ses changements d'avis), qui permet de corriger un bug sans avoir à attendre 1 an l'aval de la hiérarchie.

    Avec Agile ça peut au contraire se révéler plus long. Mais à mes yeux ça permet de faire du meilleur travail, d'avoir une façon de travailler un peu plus "humaine", où, au lieu de passer par un téléphone arabe (CP, MOE, MOA, utilisateur,...) on discute directement de vive voix, en toute cordialité.

    Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 713
    Points
    713
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.
    En fait, ce revers de la médaille, c'est la promesse de l'adaptabilité... "Finalement on ne veut plus la fonction comme ça (chiffrée à 1 jour et livrable pour la livraison de dans 2 jours) mais comme ci (nécessitant 4 jours). Nous attendons donc votre livraison après demain avec la fonction ci, merci."


  6. #6
    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
    De développer en Agile ne permet pas de réduire le temps de développement global d'un logiciel, on est bien d'accort.
    Par contre, cela permettrait quand même d'avoir un retour sur investissement plus rapide.

    Je m'explique.

    En Agilité, le but est de livré régulièrement des versions intermédiaires pour avoir un feed-back rapide des clients/utilisateurs.
    En Scrum (une des méthode agile les plus utilisé) on demande, même qu'en fin de sprint, de réaliser un version potentiellement livrable.

    Comme rapidement, au bout de seulement quelque itération, on commence à avoir un logiciel, incomplet serte, mais fonctionnel et qui peut réaliser déjà certaines taches, on pourrait déjà le proposer à des utilisateurs.
    Régulièrement, pas forcement à chaque itération, mais quand les évolutions sont considérer comme notable, on peux alors mettre à jour le logiciel en production alors que celui-ci n'est toujours pas terminer.

    On voit bien, que dans cette logique de livraison, notre logiciel est utilisé au plus tôt et donc rentabilisé avant la fin de son développement.
    Dans une logique concurrentiel, un tel produit prendrait des parts de marché face à un autre développé en Waterfall qui commencerait son développement en même temps.
    Pour un investisseur, il commence également de rentabiliser son outil alors que celui-ci n'est pas encore terminé (voir pas encore payé).

    La notion de 'temps de développement' prend alors un sens différent vu que ce n'est pas forcement le temps où notre logiciel commence à engendrer de l'argent, mais le temps où l'on en dépense plus.

  7. #7
    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 martopioche Voir le message
    En fait, ce revers de la médaille, c'est la promesse de l'adaptabilité... "Finalement on ne veut plus la fonction comme ça (chiffrée à 1 jour et livrable pour la livraison de dans 2 jours) mais comme ci (nécessitant 4 jours). Nous attendons donc votre livraison après demain avec la fonction ci, merci."
    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?

  8. #8
    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 LSMetag Voir le message
    Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.
    Là, je pense que c'est ta boite qui utilise cette argument pour vous faire des heures sups.
    Citation Envoyé par Agile Manifesto - 8ème principe de l'agilité
    Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
    Au contraire, l'agilité encourage à avoir des journées régulières.

    Les coups de bourres, les heures sups soudaines, les phases de surcharges, .... sont justement contraires à l'agilité et au développement logiciel de qualité.
    On est dans un domaine créatif, pas dans une industrie de production: la multiplication des heures dégrades la qualité.

  9. #9
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    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 : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    L'intérêt du développement Agile est d'abord pratique. Cela combat le problème de l'usine a gaz. En effet il est très bien de développer un gros logiciel bien spécifié, mais en pratique le déploiement est complexe, et le besoin des utilisateurs est changeant. De plus quels que soit le logiciels, il n'est jamais finit / totalement stable.

    Un développement agile, intelligent, consiste selon moi à de créer un squelette propre, un Proof Of Concept fonctionnel, de le mettre en prod. De laisser les utilisateur se l'approprié et au fur et a mesure d'y faire des retouches successive.

    L'intérêt : On a un développement beaucoup plus souple ce qui est plus agréable pour le développeur comme pour l'utilisateur. On évite de développer pour rien parce que l’utilisateur n'en a pas besoin. D'un point de vue sécurité comme fonctionnel, le projet évolue vite et dans le bon sens.
    L'inconvénient : On a beaucoup de mise en prod, et donc beaucoup plus de risque d'instabilité voire de faille de sécurité.

    Conclusion : Le développement agile est beaucoup mieux, il offre un meilleur suivi mais n'est pas la solution ultime, il n'est pas adapté a tout les projets.

    C'est comme le NO-SQL, le big data ou le Cloud, innovant, plus adapté parfois mais pas magique.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  10. #10
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    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 : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    domaine créatif, pas dans une industrie de production.
    Ca ne veux rien dire, créatif ne s'oppose pas a industriel. Quel que soit le domaine (logiciel, cinéma, jeu vidéo, automobile...), il faut innover ET produire.
    Les heures sup n'ont rien a voir avec ça. Quel que soit le travail la charge est bonne et la surcharge est mauvaise.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  11. #11
    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
    Je pense que l'agilité peut permettre de réduire le temps de développement même si ce n'est pas l'objectif principal.

    Un truc qu'on oublie un peu, c'est qu'un des gros arguments marketing mis en avant par les créateurs d'une méthode comme Scrum est l'hyperproductivité des équipes. Bien sûr, je trouve le terme hyperproductif complètement surfait, mais il y a des éléments valides dans l'argumentation de Sutherland à propos de Scrum :

    • Se focaliser sur la livraison de valeur métier en mettant dans une même équipe toutes les compétences pour y arriver
    • Pas de multitasking (les équipes sont dédiées, dans une itération on se concentre sur un produit et une fonctionnalité)
    • L'information doit être partagée immédiatement, en travaillant en binôme dès que nécessaire


    Tout cela permet d'aller plus vite, ou plus exactement de ne pas être ralenti par des obstacles : défaut d'organisation personnelle/d'équipe/d'entreprise, manque de connaissance du code, latence de communication et de prise de décision.
    Ces pratiques peuvent paraître évidentes mais force est de constater que le cadre traditionnel de projet cycle en V ne les favorisait pas vraiment jusqu'alors.

  12. #12
    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
    La question me semble mal posée : Agile permet-il de réduire le temps de développement de logiciel ?

    Oui et non, tout dépend de quoi on parle. Faisons simple et demandons au Larousse :
    Agile :
    - Qui a de l'aisance et de la promptitude dans les mouvements du corps ; souple, alerte : Un enfant agile comme un chat.
    - Qui est vif, prompt à comprendre : Un esprit agile.
    En bref, on parle de rapidité dans l'instant (le court terme), et non de rapidité dans l'avenir (sur le moyen/long terme). On peut facilement amalgamer les deux, mais ce n'est rien de plus que cela : un amalgame. Je pense que les méthodes Agiles ont été pensées dans ce sens, et ce serait donc une erreur de considérer qu'elles permettent de travailler globalement plus vite.

    Les méthodes agiles visant l'adaptation continue, cela nécessite de faciliter une telle adaptation, et cela a un coût, je m'attends donc à ce qu'en moyenne les développements soient plus long avec de l'Agile. Mais si on inclut toute la phase de correction et maintenance qui vient en extra à la suite d'un classique cycle en V, du fait des changements de besoins qui n'ont pas été considérés, alors il est probable que le temps total soit plus court en faisant de l'Agile. Mais le fait est que dans le cas du cycle en V, on part sur une idée et on en dévie peu, et si le résultat est exploitable alors on l'utilise tel quel et on change peu de choses. Alors que dans le cas de l'Agile, on change dès qu'on voit qu'il y a quelque chose à changer, donc le produit final a des chances d'être significativement différent de celui fait via un cycle en V. Donc dire qu'on développerait plus ou moins vite, alors que le produit final est différent, n'a pas beaucoup de sens.

    Si on veut avoir tel produit impérativement pour telle date, on utilise un cycle en V et on fait avec ce qu'on a à la date prévue. Si on veut un produit qui répond impérativement au besoin, on fait de l'Agile et on s'adapte aux changements de planning. Question de priorités.
    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 {^_^})

  13. #13
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Là, je pense que c'est ta boite qui utilise cette argument pour vous faire des heures sups.
    En fait je me suis mal fait comprendre. Souvent, dans ce genre de méthodologie, les développeurs sont des personnes motivées, qui ont le soucis de bien faire. Et dans la passion viennent les heures sup, puisqu'on ne nous dit pas précisément quoi faire et comment. On a certes des maquettes et directives sur un logiciel de bugtracking, mais on peut se réserver le droit d'ajouter des bugs au bugtracker, de choisir entre nous qui va prendre le bug, ou de téléphoner au client pour lui faire part d'une fonctionnalité ou erreur de spec.

    Bref c'est la passion qui encourage les heures sup, sauf si le CP est mauvais, ou le client trop chiant.

  14. #14
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    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?
    Et pourtant ça arrive. Et après on livre en retard... Le client veut son produit. Même si le CP est là pour expliquer, le client ne comprend qu'à moitié.

  15. #15
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 713
    Points
    713
    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?
    Ah, cette "contractualisation Agile"... Mon épicier ne fait pas de "sur mesure", ce n'est pas un créatif mais un commerçant, donc les tarifs des boites de pâté sont indiquées et fixes et ne m'a jamais promis d'adapter ses tarifs et se prestation en fonction de mes besoins (mon panier). À l'opposé, les fonctions que nous implémentons ne sont pas toutes sur étagères. Et le trade in/trade out n'a comme mesure que l'effort, pas le délais. Bah oui, il y a une semaine quand on avait proposé le choix des fonctions, on avait annoncé un délais de 1 jour mais aujourd'hui pour l'implémenter il faudra faire quelques modifications du fait du départ sur une autre direction et les ressources les plus adaptées ne sont ne sont pas dispo du jour au lendemain... Peu importe le scénario, de toutes manières, je n'ai jamais vu un pattern de "contrat Agile" où ces "points" sont définis de manières strict et mesurable (conceptuellement, c'est impossible), ce qui en soi peut permettre toute remise en cause.
    Et nos commerciaux vont arriver au problème inhérent à tout produit : l'engagement de livraison. Le logiciel doit être en ligne pour la rentrée des classes (remplacez pas n'importe quel évènement) avec toutes les conséquences contractuelles qui vont avec.
    Et ça, c'est le scénario relation client/prestataire, en interne, la notion de "contractualisation" existe rarement.

  16. #16
    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
    La contractualisation agile est en effet un vaste sujet.
    Bon, mon exemple de l’épicier est un peu exagéré, je l'avoue (bien que parfois, certain commerciaux de SSII feraient mieux de ventre des petits pois)

    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é.

    Si l'équipe développe en Agile, mais que le commercial a signé un contrat 'forfais classique', c'est logique qu'à un moment le client va en profiter pour faire faire des changements de spécification (ben vous êtes agile, vous l'acceptez) qui ne colle plus avec la contrainte commercial et technique ... et là, on est plus dans l'agilité.

  17. #17
    Nouveau Candidat au Club
    Inscrit en
    Janvier 2005
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 3
    Points : 0
    Points
    0
    Par défaut Gros flicage
    Un des buts de l'agile c'est une grande visibilité sur les changements.
    ça donne une grande tracabilité des changements et des couts des changements.

    Un effet pervers aussi est qu'on a un suivi de la performance des devs.

  18. #18
    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 oreI Voir le message
    Un effet pervers aussi est qu'on a un suivi de la performance des devs.
    Pourquoi est-ce un effet pervers ?
    Personnellement, je trouve que c'est une excellente chose et permet d'identifier les dérives très rapidement pour mieux les corriger

    De plus, le suivi de la "performance" des dev n'est pas lié à l'Agile mais à l'intégration continue.

  19. #19
    Membre émérite Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Points : 2 528
    Points
    2 528
    Par défaut
    Une chose est sûr, la méthode Agile mal comprise et/ou mal utilisé, ça va rallonger considérablement les développements. En fait mon postulat est le suivant : Si on crois qu'on va gagner du temps, on va en perdre beaucoup !

    Et là je parle d'un retour réel où dans une entreprise, les petits chefs informatique sous couvert "d'agilité", ne se sont plus embêter à écrire des cahiers des charges, ne font plus d'analyse... Mais créer à la volée avec aucune vision sur le global... Et à la fin, on se retrouve avec une usine à gaz digne d'il y a 30 ans.


    Bien utilisée, la méthode Agile est en fait juste une approche qui paraît de nos jours censée : Plus de contacts avec le client et des équipes, plus à l'écoute des besoins... Ce n'est plus un développement rigide décidé pyramidalement par un chef qui décide de tout envers et contre les équipes et les clients. Éventuellement ça fait gagner du temps sur le projet global en évitant des "gros retours en arrière".
    L'avenir appartient à ceux... dont les ouvriers se lèvent tôt. (Coluche)

  20. #20
    Membre régulier
    Inscrit en
    Juin 2007
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 50
    Points : 74
    Points
    74
    Par défaut
    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.)

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