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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2013
    Messages
    268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

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

    Informations forums :
    Inscription : novembre 2013
    Messages : 268
    Points : 7 819
    Points
    7 819
    Par défaut Tout le monde prétend suivre les méthodes agiles dans son travail
    Tout le monde prétend suivre les méthodes agiles dans son travail
    mais en réalité, peu de personnes le font vraiment

    On entend très régulièrement parler de méthodes agiles et plusieurs personnes d'ailleurs disent les utiliser dans leur travail, mais bien souvent la réalité est toute autre. Il se trouve que ces personnes se servent plutôt de quelque chose de très différent des méthodes agiles conventionnelles. Tout d'abord, il faut savoir qu'une méthode agile est une méthode de gestion et de développement de projets ou programmes informatiques qui vise à satisfaire les besoins du client au terme du contrat de développement.

    Lorsqu'elles sont bien appliquées, les méthodes agiles permettent d'organiser le travail de façon à rendre les équipes faisant partie du projet, très productives. Seulement, il a pu être observé que dans bon nombre d'entreprises qui disaient utiliser des méthodes agiles dans leurs projets, il subsiste de graves manquements qui n'existeraient pas si les méthodes agiles étaient correctement adoptées. En fait, malgré l'intention de ces entreprises d'adopter des méthodes agiles, elles sont parfois contraintes en raison de certaines difficultés, de finir par travailler d'une manière qui ne ressemble pas du tout à une méthode de travail agile.

    Nom : toptal-blog-image-1533161962060-643b49790f4c94ea7ade8c4fb609b027 (1).png
Affichages : 31203
Taille : 30,3 Ko

    Certaines entreprises, juste pour suivre la tendance, se lancent dans certaines pratiques plus ou moins agiles et qui parfois ne correspondent pas à leurs équipes. C'est le cas de celles qui décident d'organiser le travail en Sprints de 2 semaines au cours desquelles les équipes doivent pouvoir produire des livrables (solutions présentables au client). Cette façon de faire peut ne pas correspondre à toutes les équipes et entraîner des ralentissements dans le travail étant donné que parfois le livrable produit par une équipe ne peut fonctionner sans celui produit par une autre.

    Les méthodes agiles impliquent de développer un produit dans sa forme la plus fine et de le mettre le plus rapidement possible entre les mains de véritables utilisateurs, afin que ces derniers le testent et donnent leurs avis. De plus en plus, les clients veulent participer au développement du produit qui leur sera proposé et non plus être des consommateurs passifs. Le fait que certains dirigeants d'entreprises ne s'en rendent pas compte peut aussi constituer une difficulté à la pleine adoption des méthodes agiles.

    Bien que les dirigeants d'entreprises aient leur part de responsabilité puisqu'ils sont les décideurs, ils ne sont pas les seuls fautifs dans cette affaire. Les employés eux aussi peuvent constituer un problème dans le sens où ils s'opposent à la culture même des équipes agiles. En effet, pour fonctionner efficacement, les méthodes agiles s'appuient sur des personnes ayant une profonde expertise dans un domaine, un intérêt général et une volonté d'apprendre dans de nombreux autres domaines de compétences. Mais, il peut arriver qu'au sein d'une équipe, se trouvent des personnes qui s'en tiennent uniquement à un seul domaine d'expertise en refusant d'apprendre ou de contribuer dans un autre domaine.

    A tout ceci, peuvent encore s'ajouter plusieurs autres éléments qui compromettent la pleine adoption des méthodes agiles dans les entreprises. Pourtant, à la question de savoir s'ils utilisent des méthodes agiles, plusieurs managers répondent par l'affirmative, ne sachant pas vraiment qu'en réalité, en ne respectant pas certains aspects qu'impose Agile, ils ont plutôt adopté quelque chose de très différent.

    Source : QZ

    Et vous ?

    Que pensez-vous des méthodes agiles ? Pensez-vous comme certains qu'elles devraient être abandonnées ?
    Que pensez-vous des Sprints ? Sont-ils adaptés à toutes les équipes ?
    Pensez-vous que vous ou votre entreprise utilisez réellement les méthodes agiles ?

    Voir aussi :

    Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile
    Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative
    CollabNet : l'adoption des pratiques agiles augmente en entreprise, mais très peu d'organisations auraient un haut niveau de compétence

  2. #2
    Membre expérimenté Avatar de supergeoffrey
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2010
    Messages
    668
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2010
    Messages : 668
    Points : 1 421
    Points
    1 421
    Par défaut
    Pour rappel, il y a 4 règles qui définissent les méthodes agiles.

    https://agilemanifesto.org/iso/fr/manifesto.html
    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
    Ce n'est pas très compliqué à faire des méthodes agiles quand on y pense.
    Pensez à marquer vos tickets comme résolus.
    Pensez aussi aux pour les réponses pertinantes

    Quand une discution est résolue depuis un moment pour revenir dessus, il est mieux d'en crée une nouvelle avec un lien vers l'autre car :
    • Elle sera en haut du forum, elle sera donc plus visible
    • Une discussion résolue, on ne passe pas dessus pour aider, on passe dessus si on a le même problème
    • Tu demandes surement à tes clients de faire le même

  3. #3
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    2 103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 2 103
    Points : 13 780
    Points
    13 780
    Par défaut
    Cet article est très réaliste. Ce mot est utilisé par pleins de gens pour faire croire qu'ils sont à la mode, mais dans les faits les processus sont rarement respectés.
    D'une façon générale dans le secteur du développement il y a un manque flagrant de bons managers, car le management n'est pas tellement dans la culture des geeks qui constituent le plus gros de ceux qui vont dans la filière IT, et quand il y a de bons managers issu des filières de management et pas de l'IT ils sont le plus souvent largués sur la partie technique, donc les deux mondes ont du mal à se rejoindre de façon efficace. Ça peu parfois déboucher vers quelque chose chez un très petit nombre d'individus mais le plus souvent après un très grand nombre d'années d'expérience.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  4. #4
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    5 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 5 997
    Points : 9 108
    Points
    9 108
    Par défaut
    Citation Envoyé par Jonathan Voir le message
    Que pensez-vous des méthodes agiles ?
    C'est toujours mieux que le cycle en V ! (excusez-moi j'ai un problème avec le cycle en V)
    Mettre un peu d'agilité dans la gestion de projet c'est pas mal, ça permet d'être plus souple et plus proche des besoins du client.

    Citation Envoyé par Jonathan Voir le message
    Pensez-vous comme certains qu'elles devraient être abandonnées ?
    Je pense qu'il faut laisser les équipes de développement bricoler comme elles veulent.
    Il n'y pas besoin d'imposer une vision des choses aux autres.
    Si des développeurs sont content de mettre un peu d'agilité dans leur gestion de projet, il faut les laisser faire. (à moins que le développement soit bloqué)

    Citation Envoyé par Jonathan Voir le message
    Que pensez-vous des Sprints ? Sont-ils adaptés à toutes les équipes ?
    C'est juste une liste de tâches à réaliser...

    Citation Envoyé par Jonathan Voir le message
    Pensez-vous que vous ou votre entreprise utilisez réellement les méthodes agiles ?
    Pas à la lettre, parce que ce serait de la folie.
    Déjà SCRUM ce serait chiant, mais alors Extreme programming ce serait impossible.
    Je crois que vouloir suivre le concept à la lettre ferait perdre du temps au final.

    Citation Envoyé par Jonathan Voir le message
    Certaines entreprises, juste pour suivre la tendance, se lancent dans certaines pratiques plus ou moins agiles et qui parfois ne correspondent pas à leurs équipes. C'est le cas de celles qui décident d'organiser le travail en Sprints de 2 semaines au cours desquelles les équipes doivent pouvoir produire des livrables (solutions présentables au client)
    Ouais enfin c'est pas un vrai livrable, il faut juste faire des modifs pour montrer au client, mais le client ne pourra tester qu'à la prochaine vraie livraison d'alpha, beta, je sais pas quoi, qui peut tomber dans 6 mois.

    Faire une réunion toutes les 2 semaines avec le client permet de ne pas tomber trop loin de ses besoins.
    Comme ça il peut dire "je vous avais demandé ça, mais en fait j'ai besoin d'autre chose".
    Keith Flint 1969 - 2019

  5. #5
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 73
    Points : 649
    Points
    649
    Par défaut
    Globalement, dans toutes les entreprises, il y a des professionnels TRES agiles: ils sont extrèmement doués pour éviter les patates chaudes...

    Dans une startup ou une équipe qui est très autonome, les méthodes agiles peuvent présenter un intérêt... Pour une boîte de 20000 personnes avec des dépendances/adhérences entre les équipes cela devient plus compliqué...

  6. #6
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    5 544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 5 544
    Points : 14 986
    Points
    14 986
    Par défaut
    A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

    Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
    - "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
    - "euh ... on à fait qu'une branche du V, va falloir attendre ..."

    Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

    Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

    Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Membre émérite
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    602
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 602
    Points : 2 794
    Points
    2 794
    Par défaut
    Citation Envoyé par grunk Voir le message
    A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

    Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
    - "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
    - "euh ... on à fait qu'une branche du V, va falloir attendre ..."

    Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

    Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

    Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..
    Je rejoint ton expérience là : Je suis dans une petite boite (seulement 4 dév dans l'équipe) et ce qui prime surtout en fin d'exercice quand il va falloir faire le bilan c'est de livrer tout ce qui est possible de livrer alors on prend des chemins de traverse , plus d'assurance qualité (alors que pendant le reste de l'année c'est : revue de projet, analyse, point d'avancement, etc...) là on jette le tout aux orties pendant les 3 trois derniers mois de l'exercice... Ceci ça m'a toujours fait rire... Quand je vois la tête de notre consultant qualité lorsqu'on lui que pendant les trois prochains mois il peut se carrer ses formulaires qualité dans l'oignon... et le directeur lui dit devant tout le monde que c'est bien beau mais qu'il faut penser au chiffre d'affaire en priorité...

    Et puis les méthodes agiles... en vieillissant ça devient de plus en dur (j'ai passé la cinquantaine)....

  8. #8
    Membre chevronné

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 810
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 810
    Points : 1 950
    Points
    1 950
    Par défaut
    La méthode agile sera celui le plus soumi et documentant le moins son travail. C'est excellent quand vous devez reprendre un projet et qu'aucun interlocuteur n'a de document .. que vous êtes tout seul qui plus est ...

    Travailler en mode agile c'est faire aujourd'hui ce qui était necessaire hier ... vous êtes pas content ? C'est de l'insubordination ? C'est le même tarif vous attendrez .

  9. #9
    Membre expert

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    1 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 1 761
    Points : 3 576
    Points
    3 576
    Par défaut
    A chaque fois qu’on m’en parle je dis que je connais mais jamais appliquée complètement, quand on m’a sorti le pipo ici on pratique la méthodologie agile je les vois arriver avec leur gros sabots, au finale le client prend ce qui lui arrange, résultat des réunions de 30-45 min tous les matins, ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...

  10. #10
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    5 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 5 997
    Points : 9 108
    Points
    9 108
    Par défaut
    Citation Envoyé par youtpout978 Voir le message
    résultat des réunions de 30-45 min tous les matins
    Hein ?
    Normalement ce n'est pas censé être un stand-up meeting et durer moins de 5 minutes ? On dit ce qu'on a fait hier, ce qu'on a prévu de faire aujourd'hui et si on a vu un problème qui pourrait empêcher d'attendre les objectifs du sprint ?
    Il y a des concepts qui sont mal appliqués.

    Moi l'aspect agile que j'aime bien c'est de montrer régulièrement au client la progression du développement et de récupérer ses retours sur la dernière version qu'il lui a été livré.
    Keith Flint 1969 - 2019

  11. #11
    Membre expérimenté

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 642
    Points : 1 419
    Points
    1 419
    Par défaut
    La méthode agile a pas mal d'avantages, mais pour moi un gros inconvénient qui en découle : celui d'avoir du mal à définir un budget et une date de livraison globale précise.

    Quand je l'ai vu fonctionner à 100%, c'était uniquement avec de gros ou très gros clients : soit en interne d'une grosse entreprise, soit avec des clients ayant beaucoup de moyens.

  12. #12
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 238
    Points : 17 462
    Points
    17 462
    Par défaut
    Citation Envoyé par blbird Voir le message
    La méthode agile a pas mal d'avantages, mais pour moi un gros inconvénient qui en découle : celui d'avoir du mal à définir un budget et une date de livraison globale précise.
    J'ai du mal à te suivre. L'agile avec SCRUM c'est justement un budget fixe avec des dates de livraison figées et un scope qui varie. C'est ça le principe. T'as des échéances de livraisons prédéfinies et tu livres ce que tu as terminé (variable) à ces dates.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  13. #13
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 238
    Points : 17 462
    Points
    17 462
    Par défaut
    Citation Envoyé par youtpout978 Voir le message
    ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...
    C'est juste que vous faites pas de l'agile. Le principe de base de l'agile c'est que le contenu d'un sprint n'est pas un engagement sur un périmètre. Il y a des dates de livraisons fixes avec un scope variable. Les tâches sont estimées et ensuite on voit le consommé réel. En aucun cas on ne peut exiger une livraisons d'un scope figé à une date figée. C'est justement pour arrêter de faire ça que l'agile a été créé.

    La situation que tu décris c'est une organisation qui faisait du waterfall ou du Cycle en V et qui essaie de se mettre à l'agile sans avoir changé fondamentalement sa manière de travailler. C'est un problème très courant du à un manque de compréhension de l'agile à tous les échelons de l'organisation (chef qui veut sa feature à date).
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  14. #14
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 238
    Points : 17 462
    Points
    17 462
    Par défaut
    Citation Envoyé par grunk Voir le message
    A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

    Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
    - "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
    - "euh ... on à fait qu'une branche du V, va falloir attendre ..."

    Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.
    Ça c'est du forfait. Ce n'est pas compatible avec de l'agile.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

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

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 640
    Points : 4 107
    Points
    4 107
    Par défaut
    Citation Envoyé par supergeoffrey Voir le message
    Pour rappel, il y a 4 règles qui définissent les méthodes agiles.

    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
    C'est exactement le 1er point dont il s'agit ici.
    Certains estiment que "ce n'est pas agile" parce que ne respecte pas l'un des cahiers de charges d'une des méthodes agiles reconnu.
    Agile ou pas, c'est le boulot du manager de faire qu'une équipe fonctionne bien pour délivrer un bon produit. Le gars qui pense que "faire de l'agilité" va régler les problèmes ce fout le doigt dans l’œil. En fait le problème c'est de croire qu'on peut être un bon manager à partir d'un bouquin, alors qu'une méthode va juste permettre de donner un cap. Il ne faut surtout pas l'appliquer à la lettre, mais bien l'adapter à l'équipe, avec pourquoi pas un mélange de 12 autres méthodes.
    Un bon manager est agile par nature mais pas forcement parcequ'il applique une méthode dite "agile".

  16. #16
    Membre expérimenté

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 642
    Points : 1 419
    Points
    1 419
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    J'ai du mal à te suivre. L'agile avec SCRUM c'est justement un budget fixe avec des dates de livraison figées et un scope qui varie. C'est ça le principe. T'as des échéances de livraisons prédéfinies et tu livres ce que tu as terminé (variable) à ces dates.
    Ces 2 points ne vont pas avec un plan budgétaire initiale précis, fixe et très peu variable voulu par les clients, ce qui est malheureusement souvent le cas.

    L'agile ne convient pas à tous les projets, ni tous les clients.

  17. #17
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 238
    Points : 17 462
    Points
    17 462
    Par défaut
    Ces 2 points ne vont pas avec un plan budgétaire initiale précis, fixe et très peu variable voulu par les clients, ce qui est malheureusement souvent le cas.
    Parce que tu fais un lien entre budget et scope fonctionnel. Ça s'appelle du forfait. Le forfait n'est pas compatible avec l'agile, c'est antinomique.

    L'agile ne convient pas à tous les projets, ni tous les clients.
    Tout à fait d'accord. Je dis simplement qu'on ne peut pas dire qu'on fait de l'agile en prétendant figer un scope ET une date de livraison, c'est totalement contradictoire.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  18. #18
    Futur Membre du Club
    Profil pro
    Inscrit en
    décembre 2009
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2009
    Messages : 4
    Points : 7
    Points
    7
    Par défaut le dévoiement des méthodes agiles
    "Les individus et leurs interactions plus que les processus et les outils": chacun utilise ses propres outils et plus rien n'est compatible ensemble. Par exemple, l'un fait les docs en markdown, l'autre utilise Word. Après c'est un bordel total.
    "Des logiciels opérationnels plus qu’une documentation exhaustive": le retour des logiciels sans doc et non maintenables 1 an après. Et le créateur du logiciel redevient le seul maître à bord (alors que l'objectif des méthodes de conception était justement de partager la connaissance avec le client)
    "La collaboration avec les clients plus que la négociation contractuelle": le dialogue impossible avec le client, soit parce qu'il n'est pas toujours disponible (alors que c'est indispensable en Agilité), soit parce qu'il changera sans arrêt selon son bon plaisir. Et pas de négociation contractuelle, c'est une blague à l'heure des centres de services en SSII où tout les échanges sont minutieusement contractualisés étant donné que la responsabilité de la SSII est maintenant engagé (engagement de résultat et plus de moyen)
    "L’adaptation au changement plus que le suivi d’un plan" : comme il faudra toujours être à la pointe de la technique, le logiciel sera toujours en béta, ultra-buggué et non maintenable. En plus, comme il n'y aura plus d'architecture (trop contraignant) le logiciel ne satisfera plus les exigences techniques du cahier des charges (performance, sécurité, maintenabilité)

    Bref, l'agilité pour les petits projets en interne d'une boite, ça peut marcher...mais ça représente environ 5% des projets

  19. #19
    Membre actif
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    98
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2011
    Messages : 98
    Points : 228
    Points
    228
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Hein ?
    Normalement ce n'est pas censé être un stand-up meeting et durer moins de 5 minutes ? On dit ce qu'on a fait hier, ce qu'on a prévu de faire aujourd'hui et si on a vu un problème qui pourrait empêcher d'attendre les objectifs du sprint ?
    Il y a des concepts qui sont mal appliqués.

    Moi l'aspect agile que j'aime bien c'est de montrer régulièrement au client la progression du développement et de récupérer ses retours sur la dernière version qu'il lui a été livré.
    on en est pas loin,
    5-10 min de sprint planning par jour
    60 min "sprint planning 1" par sprint pour qualifier les taches (compter 2h d'étude avant le SP2)
    60 min "sprint planning 2" par sprint finir la qualification et l'attribution des taches
    90 min " sprint review" par sprint
    60 min de retrospective par sprint.

    Au final l'agilité se transforme en une torture de réunions sans fin

  20. #20
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 290
    Points : 28 059
    Points
    28 059
    Par défaut
    Salut,
    Citation Envoyé par grunk Voir le message
    Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
    - "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
    - "euh ... on à fait qu'une branche du V, va falloir attendre ..."

    Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.
    C'est peut-être justement là qu'est le problème.

    Les gens sont tous près de croire que l'informatique c'est soit simple soit magique.

    Sur un forum concurrent, j'ai même rencontré quelqu'un qui m'a sorti un truc du genre de
    ben, le développement informatique, c'est simple : il suffit d'écrire du code
    Mais, si tous les développeurs prenaient l'habitude de refuser ces délais impossibles qu'on essaye de leur imposer à la dernière minutes, en faisant comprendre au client que le développement ce n'est ni facile ni magique, et que
    Désolé, monsieur, mais on avait convenu d'une semaine, qui correspond au délais dont j'ai besoin pour arriver à un résultat valable, et que je suis aussi incapable de compresser le temps que vous de parcourir 700 km en voiture en deux heures
    les gens arrêteraient peut être de nous prendre pour des sur hommes ou des magiciens

    Après, j'ai bien conscience que la première règle du business est "le client a toujours raison", mais quand même!!!
    Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.
    C'est justement là qu'est le véritable problème!

    Tant que l'on ne se décidera pas à utiliser des commerciaux qui savent ce qu'est le développement, qui prennent en compte le triangle d'or, les mentalités ne pourront pas évoluer.

    EDIT
    Citation Envoyé par xbrossard Voir le message
    "Les individus et leurs interactions plus que les processus et les outils": chacun utilise ses propres outils et plus rien n'est compatible ensemble. Par exemple, l'un fait les docs en markdown, l'autre utilise Word. Après c'est un bordel total.
    Tu semble ne pas comprendre le sens réel de cette phrase.

    Elle veut surtout dire que le client doit venir avec le "quoi" et l'équipe de dev (dans son ensemble) avec le "comment". C'est donc à "l'équipe de dev" de choisir les outils adaptés à la fourniture du comment obtenir le quoi demandé par le client.
    "Des logiciels opérationnels plus qu’une documentation exhaustive": le retour des logiciels sans doc et non maintenables 1 an après. Et le créateur du logiciel redevient le seul maître à bord (alors que l'objectif des méthodes de conception était justement de partager la connaissance avec le client)
    Une fois encore, tu ne sembles pas avoir compris le sens de cette phrase.

    Elle signifie que l'on va préférer fournir un logiciel fonctionnel, qui fonctionne selon les envies et les besoins du client plutôt que de passer son temps à écrire un bouquin de 500 à 2500 pages (que personne ne lira de toutes manières jamais dans son ensemble) décrivant toutes les fonctionnalités et comment les utiliser.

    En plus, il y a plusieurs types de documentations, qu'il s'agit de distinguer très clairement:

    D'un coté, tu as la documentation utilisateur qui explique comment utiliser le programme (et que la méthode agile considère comme "ne devant pas être exhaustive"), et, de l'autre, tu as la documentation développeur, qui explique le but des différentes fonctionnalités qui ont été développées.

    Mais, même pour la documentation développeur, si tu indiques:
    • le but d'une fonctionnalité quelconque
    • les prérequis (pré conditions) qui doivent être respectées lorsqu'on veut y faire appel
    • les impératifs qui doivent être respectés lorsqu'elle a fini son travail (post conditions)
    • (éventuellement) les fonctionnalités similaires entre lesquelles il faudrait faire un choix, et, dans ce cas, le critère de choix à utiliser

    Tu fournis plus qu'assez d'informations, et il ne sert à rien d'ajouter une explication sur l'algorithme qui est utilisé (et qui sera de toutes manières changé dans deux jours )

    Nous en arrivons donc "tout simplement" à faire une distinction claire entre une documentation "suffisante" (comprends : assez complète que pour permettre au développeur d'utiliser une fonctionnalité), et une documentation exhaustive (comprends : qui passe le moindre détail en revue)

    "La collaboration avec les clients plus que la négociation contractuelle": le dialogue impossible avec le client, soit parce qu'il n'est pas toujours disponible (alors que c'est indispensable en Agilité),
    Ca, c'est effectivement un réel problème : la méthode agile oblige les deux parties à communiquer en permanence. Que "quelqu'un de l'équipe de dev" doit pouvoir répondre n'importe quand au client, mais aussi (et surtout) qu'il faut quelqu'un chez le client qui doive pouvoir répondre à l'équipe de dev.
    soit parce qu'il changera sans arrêt selon son bon plaisir.
    Et c'est donc à nous d'essayer de le "garder dans les clous" (qu'il a lui-même planté, d'une certaine manière), en lui rappelant la décision diamétralement opposée qu'il avait prise la semaine précédente
    Et pas de négociation contractuelle, c'est une blague à l'heure des centres de services en SSII où tout les échanges sont minutieusement contractualisés étant donné que la responsabilité de la SSII est maintenant engagé (engagement de résultat et plus de moyen)
    C'est malheureux à dire, mais là, on récolte juste ce que l'on a semé depuis plus de vingt ans (et que certains développeurs continuent à semer aujourd'hui)...

    Les SSII, ce sont, d'abord et avant tout des société commerciales, qui s'intéresse au quota d'heures qu'elle doivent payer à leurs employés par rapport au forfait qu'elles ont pu "extorquer" à leur client.

    Et, depuis plus de vingt ans, les développeurs ont préféré satisfaire leur patron (en passant "le moins de temps possible" sur une mission donnée) que d'essayer de satisfaire pleinement le client (en lui fournissant un logiciel de qualité, correspondant réellement à ses besoins).

    Comment peux-tu t'étonner qu'il y ait maintenant une obligation de résultats dans de telles conditions

    Et puis, beaucoup trop de développeurs semblent oublier que leur principal outil n'est pas leur clavier, mais que c'est leur cerveau!

    Il arrive encore beaucoup trop souvent que des développeurs utilisent l'excuse du "oui, mais quand on n'a pas le temps" pour justifier l'écriture de code cradingue.

    J'écris particulièrement vite en dactylographie, et, pourtant, je réfléchis encore plus vite que ce que je n'arrive à écrire. Et je suis sur que c'est le cas de tout le monde.

    Il serait temps que les développeurs finissent par se rendre compte qu'il vaut mieux écrire dix lignes après une minute de réflexion que d'en écrire cinquante ou cent sans y avoir accordé de réflexion

    "L’adaptation au changement plus que le suivi d’un plan" : comme il faudra toujours être à la pointe de la technique, le logiciel sera toujours en béta, ultra-buggué et non maintenable.
    La (non) maintenabilité et l'(in)adaptabilité, c'est surtout la conséquence du (non) respect de quelques règles simples, pour lesquelles trop de développeurs vont nous sortir l'excuse du "oui, mais il y a toujours des exceptions" pour justifier qu'ils n'essayent même pas de les suivre

    Dans le pire des cas, on parle de cinq principes (SOLID), de trois lois (Déméter, emmerdement maximum et Finagle, les deux dernières étant des lois empiriques ) , de quelques acronyme (YAGNI, DRY, KISS) et de conventions de nommage (spécifiques à un projet) à respecter, mais qui permettent de rendre un projet maintenable dans le même délais (et même parfois encore plus vite) que quand ces principes, ces loi, ces acronyme ne sont pas pris en compte

    Un logiciel développé rapidement n'est pas forcément synonyme de logiciel buggé. Il faut juste que les développeurs apprennent à utiliser leur cerveau

    Après, qu'il faille être à la pointe de la technique, ca, c'est un tout autre problème

    En plus, comme il n'y aura plus d'architecture (trop contraignant) le logiciel ne satisfera plus les exigences techniques du cahier des charges (performance, sécurité, maintenabilité)
    Je suis développeur C++, qui est un langage particulièrement proche de l'architecture, vu que certains types de base ont des tailles potentiellement différentes en fonction de l'architecture, justement.

    Et pourtant, j'arrive à faire en sorte que mon code soit portable (qu'il puisse être compilé aussi bien sur une architecture 8bits que sur une architecture 32 ou 64bits), qu'il présente des performances plus que respectables, une sécurité qui ne sera pas prise en défaut, et le tout, en assurant une maintenabilité maximale.

    Or, je peux t'assurer que je ne suis pas un extra-terrestre... Je veille simplement à appliquer des règles simples et à utiliser les bons outils

    Bref, l'agilité pour les petits projets en interne d'une boite, ça peut marcher...mais ça représente environ 5% des projets
    J'admets que, pour les projets externes, l'agilité n'est pas forcément la meilleure solution.

    Mais tu me semble pour le moins pessimiste en parlant de 5% des projets

    Maintenant, je présume que cela dépend aussi grandement du domaine d'application et du langage utilisé
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Discussions similaires

  1. Invitation à découvrir les méthodes Agiles en PACA
    Par mamat.83 dans le forum Méthodes Agiles
    Réponses: 0
    Dernier message: 28/02/2009, 17h39
  2. Méthodes Agiles dans les entreprises françaises
    Par HokutoNoOlivier dans le forum Méthodes Agiles
    Réponses: 0
    Dernier message: 04/08/2008, 17h25
  3. Sources sur les méthodes agiles
    Par __Ez__ dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 25/05/2008, 11h29

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