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 :

Comment savoir que votre équipe projet n’est pas agile


Sujet :

ALM

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 473
    Points : 78 485
    Points
    78 485
    Billets dans le blog
    2
    Par défaut Comment savoir que votre équipe projet n’est pas agile
    Comment savoir que votre équipe projet n’est pas agile
    Voici les différents comportements à surveiller

    Si les adeptes de l’Agile le vantent d’être une source d’énormes gains de productivité et d’efficacité, sa pratique exige cependant une parfaite collaboration entre différentes équipes.

    Qu’il s’agisse des utilisateurs finaux, des développeurs, des consultants ou de l’équipe de management du projet, chacun doit jouer un rôle important pour pouvoir atteindre les résultats attendus. Il s’agit en effet d’une chaîne dont la force sera déterminée par sa capacité à soutenir le maillon le plus faible. D’une défaillance de l’une des parties ou d’un manque de cohésion entre les différentes parties, il pourrait donc en résulter l’échec du projet agile.

    Le choix des membres des équipes agiles est donc important, mais bien souvent difficile à évaluer. Au début du projet, il est plus facile de croire qu’on a réuni l’équipe de rêve, mais après le démarrage, certains signes de faiblesse peuvent être observés au niveau des membres de l’équipe projet. Il est donc crucial de les détecter et les corriger le plutôt possible pour garantir le succès du projet agile.

    Les signes qui pourront vous indiquer que votre équipe n’est pas agile sont multiples et dans un billet sur le site cio.com, ils ont été regroupés selon qu’il s’agit d’un utilisateur, d’un développeur, d’un consultant ou d’un manager.

    Comment savoir qu'un développeur n'est pas agile ?

    Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.

    Le développeur agile est également quelqu’un qui n’a pas peur des critiques et qui peut donc explorer d’autres pistes pour apporter une valeur ajoutée au projet, explique le billet.

    Un programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile. Un développeur agile doit plutôt poser le plus de questions dès le début pour avoir une vision claire et nette du chemin à suivre. Cela permettra d’éviter de refaire à nouveau tout le travail.

    Il doit encore fait preuve d’une capacité d’écoute et avoir de bonnes compétences en communication. Un développeur qui présente des insuffisances en gestion de projet ou qui n’a aucune notion de management serait également un fardeau pour l’équipe agile.

    Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.

    Comment savoir qu'un utilisateur n'est pas agile ?

    Du côté des utilisateurs, ceux qui ne sont ni engagés, ni motivés, qui ne voient pas l’intérêt du projet et qui sont plus préoccupés par leur activité régulière représentent une menace sérieuse pour le bon déroulement du projet. Il en est de même pour ceux qui sont rigides au changement, qui y voient un risque et qui considèrent l’apprentissage comme un problème plutôt que de voir ses avantages.

    Vous devez savoir que votre équipe n’est pas agile lorsque vous verrez aussi que les utilisateurs impliqués dans le projet ont tendance à ne pas respecter les délais qui leur sont fixés dans les tâches qu’ils doivent exécuter. C’est le cas notamment lorsqu’il s’agira pour eux de donner leur accord pour la validation de certains documents auxquels ils ne comprennent peut-être pas grandes choses. C’est le genre d’utilisateurs qui ne veulent pas avoir de problème, alors leurs décisions sont extrêmement prudentes. Ils ne prennent aucune décision lorsque les informations à leur disposition sont incomplètes.

    Des utilisateurs qui ont également tendance à beaucoup bavarder lors des réunions sans pourtant faire de propositions concluantes sont une menace pour le projet agile. Ces derniers ne réussissent en général qu’à amplifier les problèmes clairement délimités.

    Comment savoir qu'un manager n'est pas agile ?

    Dans le management également, certains signes peuvent montrer clairement que l’équipe ne fait pas de l’Agile. C’est le cas notamment lorsque vous verrez des responsables qui refusent de participer activement au projet et d’en prendre les rênes. Il en est de même pour un manager toujours prêt à responsabiliser les membres de l’équipe projet sans pourtant leur donner le contrôle des ressources.

    Un exemple typique de manager non agile est ce genre de responsables qui nient les réalités du projet. Ils définissent mal les priorités et pensent toujours que les délais fixés sont largement suffisants.

    Un manager qui utilise la peur comme un outil de management et qui blâme l’échec publiquement pourrait garantir avec certitude l’échec du projet agile. Le projet serait également compromis si ce dernier est plus axé sur le budget que sur la valeur, et s’il accorde peu d’attention aux principaux objectifs.

    Une autre façon pour le manager de faire échouer le projet serait de promouvoir des personnes qui ne savent vraiment rien du domaine et qui ne sont non plus disposées à apprendre.

    Comment savoir qu'un consultant n'est pas agile ?

    Lorsqu’un consultant intervient dans un projet, pour qu’il soit agile, il doit également présenter certaines caractéristiques. Un consultant trop souple, ou trop conforme, ou encore qui est prêt à prendre des engagements qu’il ne peut pas respecter, voilà ce qu’il faut pour mettre le projet en péril.

    Le consultant doit être encore capable de transmettre les mauvaises nouvelles le plus tôt possible et efficacement. S’il dit « non », il doit être capable de s’en tenir à cela, et s’il n’est pas disposé à prendre en charge certaines situations incertaines, alors il serait difficile pour lui de faire de l’Agile, explique le billet.

    Il faut également éviter les consultants incapables d’écouter et qui ne sont pas en mesure de répondre aux demandes des clients le même jour. Entre autres signes qui caractérisent un consultant non agile, il faut également souligner que celui qui n’est pas disposé à venir sur le site du client est un obstacle à la pratique de l’Agile.

    Source : cio.com

    Et vous ?

    Quelle est votre opinion de ce qui caractérise une équipe agile ou qui ne l'est pas ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 520
    Points : 1 644
    Points
    1 644
    Par défaut
    Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.
    Pour mon cas personnel, je suis capable des 2, en gros je fais selon le projet. Parfois l'agile passe sur des phases de programmation maquette et d'adaptation avant de revenir sur la qualité de code. Dans ce cas la qualité des développeurs et leur capacité à anticiper et comprendre le métier est primordiale.


    Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.
    Malheureusement , il y'en a un paquet, je pense qu'agile doit amener la satisfaction de faire plaisir aux utilisateurs.
    Cela responsabilise mieux le développeur et lui donne vraiment l'impression d'être au service de l'utilisateur, et pas d'un amas de papier de spec, cela dis on a souvent tendance à négliger les specs...


    Dans la réalité c'est plus complexe, car l'implication forte des utilisateurs leurs donne envie d'avoir un paquet de fonctionnalités, et il faut trancher sinon on coule !
    Le bon agile doit ( selon moi ) être un bon pédagogue et prendre du plaisir à expliquer le pourquoi du comment !

  3. #3
    Membre actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2014
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2014
    Messages : 42
    Points : 237
    Points
    237
    Par défaut
    Prendre les concepts agiles à l'envers en expliquant les chemins qu'il ne faut pas emprunter est intéressant mais ce n'est au final que du bon sens.
    Nous expliquer que les excès et les insuffisances sont néfastes, ça me parait un peu superficiel.
    Dans tous les cas, nous avons une jolie check-list pour déterminer les "person to blame" quand un projet agile foire

  4. #4
    Membre chevronné

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    "s’il n’est pas disposé à prendre en charge certaines situations incertaines, alors il serait difficile pour lui de faire de l’Agile"

    Celle-là est mignonne. Une situation incertaine est une situation qui peut potentiellement déboucher sur un échec, parce que nous ne sommes pas dans une superproduction hollywoodienne, où quand le héros saute dans le vide, il trouve toujours un truc pour se raccrocher. Prendre ou non le risque va donc dépendre d'abord et avant tout des conséquences d'un échec sur la personne qui a pris ce risque.

    Quand Apple a sorti MobileMe en 2008, le logiciel était clairement inachevé. Ce qui veut dire que quelqu'un a accepté de prendre le risque de créer ce logiciel dans un délai trop court. Le résultat ? Un licenciement par Steve Jobs en personne, devant toute son équipe rassemblée. Le prochain qui accepta un "challenge" de ce genre chez Apple avait vraiment du mérite !

  5. #5
    Membre habitué

    Profil pro
    Inscrit en
    mars 2003
    Messages
    52
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : mars 2003
    Messages : 52
    Points : 159
    Points
    159
    Par défaut
    ..... mais ce n'est au final que du bon sens.
    Entièrement d'accord ! Je suis peut être un peu naïf, mais pour moi ça ne concerne pas que la méthode Agile, mais l'ensemble de la gestion de projet.
    Si une équipe, quelque soit la méthodologie projet employé, se retrouve dans un ou plusieurs de ces points, ça va forcément coincer.

  6. #6
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Quand Apple a sorti MobileMe en 2008, le logiciel était clairement inachevé. Ce qui veut dire que quelqu'un a accepté de prendre le risque de créer ce logiciel dans un délai trop court.
    Ou que quelqu'un a sorti le résultat trop tôt.

    Le résultat ? Un licenciement par Steve Jobs en personne, devant toute son équipe rassemblée. Le prochain qui accepta un "challenge" de ce genre chez Apple avait vraiment du mérite !
    En même temps Jobs était un gros connard arbitraire et sadique et le fait que ce genre d'individu te fasse subir une humiliation publique a davantage à voir avec le fait que c'est un gros connard arbitraire et sadique plutôt qu'avec tes propres manquements et succès.

    Pour commencer l'erreur a été de se placer volontairement sous l'autorité de ce genre d'individu.

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    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 158
    Points : 7 878
    Points
    7 878
    Par défaut
    Citation Envoyé par MintWater Voir le message
    Dans tous les cas, nous avons une jolie check-list pour déterminer les "person to blame" quand un projet agile foire
    Ceci est une parfaite réflexion non agile

    Citation Envoyé par Michael Guilloux Voir le message
    Un manager qui utilise la peur comme un outil de management et qui blâme l’échec publiquement pourrait garantir avec certitude l’échec du projet agile.


    Pour en revenir au topic, ce qui est écrit est assez évident
    Personnellement, je préfère me concentrer sur les qualités communes de l'Agile pour tous les profils : communication et coopération
    Peu importe le rôle de l'individu dans le projet, s'il possède ces 2 qualités, il sera possible de faire de l'Agile avec

  8. #8
    Membre chevronné

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Ou que quelqu'un a sorti le résultat trop tôt.


    En même temps Jobs était un gros connard arbitraire et sadique et le fait que ce genre d'individu te fasse subir une humiliation publique a davantage à voir avec le fait que c'est un gros connard arbitraire et sadique plutôt qu'avec tes propres manquements et succès.

    Pour commencer l'erreur a été de se placer volontairement sous l'autorité de ce genre d'individu.
    Là n'est pas la question. Le fait est que dans l'environnement Apple de l'époque, accepter de prendre un risque nécessitait un grand courage ou une bonne dose d'inconscience.

  9. #9
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 038
    Points
    1 038
    Billets dans le blog
    9
    Par défaut
    En gros personne ne fait de l'agile

    Chez les développeurs par exemple, il est important de surveiller l’excès de perfectionnisme. Un développeur qui a tendance à faire de la sur-qualité n’est pas le plus approprié pour un projet agile. Il faut également veiller à ce que ce dernier ne soit pas trop axé sur l’architecture et la longévité du logiciel.

    Le développeur agile est également quelqu’un qui n’a pas peur des critiques et qui peut donc explorer d’autres pistes pour apporter une valeur ajoutée au projet, explique le billet.

    Un programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile. Un développeur agile doit plutôt poser le plus de questions dès le début pour avoir une vision claire et nette du chemin à suivre. Cela permettra d’éviter de refaire à nouveau tout le travail.

    Il doit encore fait preuve d’une capacité d’écoute et avoir de bonnes compétences en communication. Un développeur qui présente des insuffisances en gestion de projet ou qui n’a aucune notion de management serait également un fardeau pour l’équipe agile.

    Mais le genre de développeur qu’il faudrait par-dessus tout éviter, serait probablement celui qui déteste ou qui n’a aucune empathie pour les utilisateurs. C’est exactement le genre de développeur qui ne voit pas l’importance d’associer les utilisateurs dans les projets et qui considère ces derniers comme un obstacle à l’avancement du projet.
    dsl, mais sa n'existe pas

    Quand bien meme toute l'équipe de dev aurait toutes ces qualités, je doutes que le reste suive, les utilisateurs, manager et co.

  10. #10
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Là n'est pas la question. Le fait est que dans l'environnement Apple de l'époque, accepter de prendre un risque nécessitait un grand courage ou une bonne dose d'inconscience.
    Non, justement, l'erreur est de croire que le licenciement est quand même lié à une insuffisance de l'employé.

    Quand tu bosses pour un CAS (connard arbitraire et sadique), tu peux ne prendre aucun risque et être le meilleur employé au monde tu pourras quand même te faire virer. Simplement parce que ce jour-là monsieur avait ses règles ou parce que tu es respecté de tes collègues et que ça le fout en rogne, ou parce qu'il doute de ta soumission aveugle et totale, ou parce qu'humilier les autres le fait bander.

    Ce jour-là le chef de la secte a ordonné à #454678 de s'auto-incinérer parce qu'il avait échoué à lever une montagne. Ce n'est pas la faute de #454678. Même si ses collègues en sont convaincus.

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    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 158
    Points : 7 878
    Points
    7 878
    Par défaut
    Citation Envoyé par sazearte Voir le message
    En gros personne ne fait de l'agile



    dsl, mais sa n'existe pas

    Quand bien meme toute l'équipe de dev aurait toutes ces qualités, je doutes que le reste suive, les utilisateurs, manager et co.
    L'article énumère les défauts et non les qualités

    Et au passage, l'Agile est possible, en tout cas dans une certaine mesure (car le Manifeste est un peu extrême, avouons le)

  12. #12
    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 145
    Points
    2 145
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Un manager qui utilise la peur comme un outil de management et qui blâme l’échec publiquement pourrait garantir avec certitude l’échec du projet agile.
    Citation Envoyé par Traroth2
    Quand Apple a sorti MobileMe en 2008, le logiciel était clairement inachevé. Ce qui veut dire que quelqu'un a accepté de prendre le risque de créer ce logiciel dans un délai trop court. Le résultat ? Un licenciement par Steve Jobs en personne, devant toute son équipe rassemblée. Le prochain qui accepta un "challenge" de ce genre chez Apple avait vraiment du mérite !
    Donc, Steve Job n'était pas fait pour l'agilité

  13. #13
    Membre éprouvé Avatar de HelpmeMM
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    juin 2007
    Messages
    473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : juin 2007
    Messages : 473
    Points : 969
    Points
    969
    Par défaut Oo
    Ce qui est bien avec cette "Etudes" concernant l'agile c'est qu'avec un projet non agile , elles fonctionnent aussi !!!! étonnant non ?

    n programmeur qui est plus enclin à « coder d’abord et poser des questions plus tard » peut également compromettre le projet agile
    Tu prend toutes ces remarques tu vires agile et sa marche aussi avec un projet classique au passage.

    c'est banalité sur banalité , si ton codeur n'aime pas coder c'est le genre de codeur qui peut faire planté ton projet 'Agile"...
    Si ton codeur va coder dans une équipe et qu'il n'aime pas travailler en équipe sa va faire capoter ton projet 'Agile"
    Garry
    La connaissance c'est ce qu'il manque à tout homme

  14. #14
    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 145
    Points
    2 145
    Par défaut
    Je reviens sur le débat de cet article.

    L'important est de se rappeler la définition de l'Agilité.
    Pour moi, je me réfère à l'Agile Manifesto (http://agilemanifesto.org): Une équipe est agile si elle applique les 10 principes dans l'esprit des 4 valeurs.

    Dans cet article, on identifie les individues qui seraient un frein à cela.
    Je pense que l'agilité repose justement sur le fait que nous sommes une équipe, embarquée dans la même aventure et que malgré les défauts de chacun, il faut trouver une solution pour avancer dans le bon sens.

    Par exemple:
    - un développeur qui serait trop axé sur l’architecture et la longévité du logiciel (=> principe 10 "simplicité") devrait être aider par les autres développeurs pour relativiser son défaut.
    - un utilisateur impliqué qui ne s’impliquerait pas assez (=> principe 4 "les utilisateurs") doit manqué de temps de son management ou n'a pas eu la démarche d'accompagnement pour entretenir sa motivation sur le projet.
    - un manager qui utilise la peur comme un outil de management (=> principe 5 "personnes motivées") n'a pas été correctement coacher pour comprendre les leviers de motivations des équipes.
    - un consultant qui n’est pas disposé à venir sur le site du client (=> principe 1 "satisfaire le client") a eu un manque de formation agile sur le lien client-équipe.

    J'aime pas trop cette article dans le sens où on part à une sorte de chasse aux sorcières des anti-agile (sous entendu, qui faut viré), au lieu de trouver des solutions pour enlever tout ces petits grains de sable que chacun peu apporter dans un projet et qui a tendance à le rendre moins agile.

    Pourquoi pas entamer cette jolie réflexion en rétrospective (=> principe 12 "moyens de devenir plus efficace") pour aider toutes personnes partie prenantes dans un tel projet d'être de plus en plus agile.

  15. #15
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 038
    Points
    1 038
    Billets dans le blog
    9
    Par défaut
    L'article énumère les défauts et non les qualités

    Et au passage, l'Agile est possible, en tout cas dans une certaine mesure (car le Manifeste est un peu extrême, avouons le)

    L'article énumère les défauts et non les qualités

    Et au passage, l'Agile est possible, en tout cas dans une certaine mesure (car le Manifeste est un peu extrême, avouons le)
    Ce que je veut dire c'est que les méthodes agiles ne sont pas inscrit dans un bouquin, y'a une grosse d'adaptation en fonction du milieu.
    Si un développeur a 1 ou 2 défaut cité, c'et pas la fin du monde.

  16. #16
    Membre chevronné

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Non, justement, l'erreur est de croire que le licenciement est quand même lié à une insuffisance de l'employé.
    Je ne vois pas à quel endroit j'aurais dit quelque chose de ce genre.

  17. #17
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je ne vois pas à quel endroit j'aurais dit quelque chose de ce genre.
    Tu considères que le problème est lié à la perception du risque et de l'échec dans cette entreprise.
    Or cela n'a à voir ni avec le risque, ni avec l'échec, ni avec le succès.

  18. #18
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par HelpmeMM Voir le message
    Ce qui est bien avec cette "Etudes" concernant l'agile c'est qu'avec un projet non agile , elles fonctionnent aussi !!!! étonnant non ?



    Tu prend toutes ces remarques tu vires agile et sa marche aussi avec un projet classique au passage.

    c'est banalité sur banalité , si ton codeur n'aime pas coder c'est le genre de codeur qui peut faire planté ton projet 'Agile"...
    Si ton codeur va coder dans une équipe et qu'il n'aime pas travailler en équipe sa va faire capoter ton projet 'Agile"
    Tout pareil, je pensais remplacer le mot "Agile" par "Suspect" ou "Clavier orthogonal". Les phrases se tiennent encore.

  19. #19
    Membre chevronné

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

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Tu considères que le problème est lié à la perception du risque et de l'échec dans cette entreprise.
    Or cela n'a à voir ni avec le risque, ni avec l'échec, ni avec le succès.
    Bien sûr que si. MobileMe a bel et bien échoué. Le succès et l'échec ne sont pas nécessairement lié à la compétence personnelle. Ils sont issus d'un contexte global, dont la compétence est un paramètre, mais pas le seul. Le bon fonctionnement hiérarchique en est un autre. La prise de risque, c'est à dire la décision d'accepter ou pas de diriger un projet, a lieu dans ce contexte.

  20. #20
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 640
    Points : 2 347
    Points
    2 347
    Par défaut
    Citation Envoyé par sazearte Voir le message
    En gros personne ne fait de l'agile



    dsl, mais sa n'existe pas

    Quand bien meme toute l'équipe de dev aurait toutes ces qualités, je doutes que le reste suive, les utilisateurs, manager et co.
    Une intervention à la sazearte, avec ton manque de nuance habituel...

    Je rejoins par ailleurs ceux (et celles ?) qui ont dit qu'on peut supprimer le mot "agile" de l'article.

    Cela me conforte dans l'idée que "agile" n'est qu'un buzz word ; n'importe qui impliqué dans n'importe quel projet professionnel doit être souple et réactif, pas la peine d'en faire une religion genre "ceux qui en sont" et "ceux qui restent dehors".

    Non, moi non plus je ne suis pas toujours nuancé dans mes propos

    Mais il y a plus grave : je ne suis pas forcément d'accord sur certains points de l'article... c'est sans doute pour cela que je suis informaticien au chômage. (et prof pas au chômage en même temps, mais c'est bizarre parce que quand on enseigne il faut aussi être "agile" à fond)

    EDIT / PS : on dirait que le(s) auteur(s) de l'article ont bien souffert de leur expérience du travail en équipe pour écrire ce qu'ils ont écrit ! Je compatis.

Discussions similaires

  1. [WD12] Comment Savoir que INumpage n'est pas encore initialisée ?
    Par le_dilem dans le forum WinDev
    Réponses: 4
    Dernier message: 28/04/2010, 10h36
  2. Réponses: 2
    Dernier message: 12/01/2005, 23h08
  3. Comment savoir que le cable réseau a été débranché
    Par laurent82 dans le forum Web & réseau
    Réponses: 3
    Dernier message: 12/07/2004, 20h37
  4. [C#] Comment savoir si on est logué ou pas?
    Par pc152 dans le forum ASP.NET
    Réponses: 3
    Dernier message: 22/05/2004, 09h47
  5. [Trigger] comment savoir que la bd a ete modifiee
    Par corwin_d_ambre dans le forum Bases de données
    Réponses: 7
    Dernier message: 13/02/2004, 12h50

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