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

Actualités Discussion :

Jusqu'à quand les entreprises gêneront-elles le développement agile ?

  1. #41
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Faire de l'agile pour de l'agile n'a pas de sens.
    Il faut se poser la question de pourquoi mettre en oeuvre cette méthode pour le projet ? (qu'elles sont les bénéfices espérés ?)
    On ne passe pas à Agile pour rien, on passe à Agile car notre entreprise est Agile. Après, est-ce que c'est un pur argument commercial, ou bien est-ce que des gens qui ont une vision plus globale de l'entreprise et des différents produits pensent que c'est réellement une bonne chose, et qu'après avoir mis en balance les points positifs et négatifs, ils ont trouvé des arguments en ce sens, je ne sais pas.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  2. #42
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Le projet sur lequel je travaille, c'est 15 ans d'historique, des commentaires faux partout, un million de lignes de code, et surtout le même projet vendu a des dizaines de clients. Et heureusement, on a un architecte qui a une vue globale du projet.
    On devrait passer à la méthoede agile bientôt, et vraiment, je ne vois pas qui va avoir cette vision globale : les plus vieux développeurs de l'équipe n'ont "que" 8 ou 10 ans d'ancienneté sur ce produit, et il semble inconcevable qu'une équipe de moins de 10 personnes (c'est bien la taille des équipes Agile non ?) ne soit l'interface avec ne serait-ce que 50 clients.
    Dans mon ancien boulot, je bossais sur une appli qui avait déjà près de 20 ans, et qui avait été porté du C au C++ 5 ans auparavant. Autant dire que c'était bien moche.
    Appli vendu, avec machines qui l'embarquaient, à travers le monde.
    On était plusieurs centaines à bosser dessus bien sûr, dans plusieurs pays, et on travaillait avec SCRUM.
    Oui une équipe SCRUM se limitera à moins d'une dizaine de personnes. Heureusement ça scale, c'est pas juste une méthodologie gadget pour projet étudiant.
    Si t'es plus nombreux, on fait ce qu'on appelle des "SCRUM de SCRUM".
    Chaque équipe a sa portée, ses spécialités, des équipes encadrent, etc etc... Un système "pyramidal", sauf que les fondations ne sont pas simples exécutants écervelés juste bon à abattre une tâche souvent mal définie.

    Citation Envoyé par gangsoleil Voir le message
    Je suis persuadé que les développeurs ont une bonne vue du logiciel, mais je pense aussi que sur de gros projets, une personne avec une vue d'ensemble n'est pas dénué d'intérêt, surtout lorsque le produit en question est distribué à de nombreux clients qui ne peuvent donc logiquement pas avoir une vue globale.
    Quand un développement impactait notre rayon d'action, on était mis au courant. On participait au plus grand nombre de phases du process d'élaborration du cahier des charges etc...
    Ne serait-ce que pour éviter que les catastrophes déjà en place ne se reproduisent, parce que quand un bug, ou un truc foireux sort, l'argument du "c'est ce qui est écrit sur le CDC", bizarrement le client il l'accepte moyen..
    Faire participer l'équipe de dév, c'est tout bénéf amha
    - ça les implique, ça les motive, ça donne moins l'impression d'une hiérarchie prédominante qui ne s'intéresse pas au "bas peuple"
    - avec la motivation, le travail est mieux fait
    - quoi qu'on en dise, ils sont les mieux placés pour se rendre compte que si tu mets tel bouton là, tu vas avoir tel cas dans tel cas où tel action empêche que le bouton apparaisse, ou qu'il apparaitra sous un autre, ou ...
    - avec une vision plus globale il sera mieux armé pour les évolutions à venir, encore une fois il est en première ligne

    Au final, le product owner avait une vision globale oui, mais chaque équipe avait sa vision sur son périmètre et était concertée quand ça l'impactait. Et je trouvais ça très performant et efficace.

    Donc faire de l'agile oui, mais le faire bien, et savoir le faire. Et ça, j'ai l'impression que la plupart des entreprises qui se targuent "d'être agile" n'en ont que le titre, et éventuellement du papier qui le certifie.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #43
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Je suis globalement d'accord avec Gangsoleil et Boursk et je vais essayer de synthétiser mon point de vue : j'ai l'impression que l'introduction d'Agile dans les entreprises se fait par effet de mode et parce que ça fait bien, un peu comme les boîtes qui ont dépensé je sais pas combien et foutu le bordel dans leurs équipes pour avoir la biblique certification ISO 9000 et consorts valable 3 ans et après on retourne dans les façons de faire d'avant.
    J'ai peur qu'Agile soit dans la majorité des cas mis en place pour justifier des développements à la Monsieur Cadbury en se retranchant derrière l'effet de mode "C'est Agile, le truc super" !
    Certes les méthodes que je qualifie de "traditionnelles" n'empêchent pas le travail de porc, mais à mon avis Agile va amplifier ça !

    Quant à dire que les devs se sentent plus impliqués si ils font autre chose que du dev, à mon avis c'est une foutaise : une personne se sent impliquée dans son travail dès qu'on la félicite si elle le fait bien. La société est une gigantesque pyramide, il en a été ainsi de tous temps et dans tous les lieux : des grands chefs, des moyens chefs, des petits chefs des sous chefs et en bas quoi qu'on puisse en dire, des gens qui exécutent.
    Vouloir que tout le monde ait son BAC et aille en fac c'est de la connerie, parce qu'on n'a pas besoin d'un plombier avec un DEUG.
    Ben on n'a pas besoin non plus d'un DEV sur diplômé, on a juste besoin d'un mec qui sache faire son boulot correctement, sans trop de bugs (je rappelle qu'un bug c'est une erreur de codage, ça n'a rien à voir avec une spec erronnée !).
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  4. #44
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    La société est une gigantesque pyramide, il en a été ainsi de tous temps et dans tous les lieux : des grands chefs, des moyens chefs, des petits chefs des sous chefs et en bas quoi qu'on puisse en dire, des gens qui exécutent.
    Et si une autre solution existait ? Et si ce système pyramidal où chacun se dédouane sur le niveau d'au dessus et en cachant la moitié des conneries et en s'attribuant le mérite des gens d'en dessous était suranné ?

    Vouloir que tout le monde ait son BAC et aille en fac c'est de la connerie, parce qu'on n'a pas besoin d'un plombier avec un DEUG.
    Ben on n'a pas besoin non plus d'un DEV sur diplômé, on a juste besoin d'un mec qui sache faire son boulot correctement, sans trop de bugs (je rappelle qu'un bug c'est une erreur de codage, ça n'a rien à voir avec une spec erronnée !).
    C'est une vision partielle du développeur, qui ne colle plus depuis longtemps à la réalité. Il fut un temps où les chefaillons faisaient les specs, et même le prototype des méthodes, et le développeur implémentait l'algorithme qu'on lui avait donné dans la méthode sus-nommée.

    Maintenant, il y a aussi des sociétés dans lesquelles le dev est une personne qui est reconnue pour avoir de bonnes connaissances sur le logiciel, et c'est pour ça qu'il participe aux (réunions de) conception et de spécification, et qui après écrit le code en fonction de ce qui a été décidé.

    Et personnellement, la société dont tu parles dans laquelle le dev s'épanouit parce qu'on le félicite, à mon avis c'est tout aussi faux : moi je m'épanouis beaucoup plus parce que je fais quelque chose d'intéressant que parce que mon travail est reconnu par ma hiérarchie. Si je voulais être reconnu, ça fait longtemps que je serai passé chef, et que je lècherai le cul de mes supérieurs pour qu'ils me félicitent encore plus (et vu les chefs que j'ai eu, je pense que je pourrai être pas mauvais à ce jeu en appliquant ce qu'ils faisaient).
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  5. #45
    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 arkhamon Voir le message
    Quant à dire que les devs se sentent plus impliqués si ils font autre chose que du dev, à mon avis c'est une foutaise : une personne se sent impliquée dans son travail dès qu'on la félicite si elle le fait bien.
    Pour avoir eu l'occasion de le tester avec pas mal de développeurs différents, j'ai pu constater une nette différence dans le comportement entre la simple exécution et la prise en charge de l'ensemble de la fonctionnalité.
    Et même au delà du comportement, le travail est mieux réalisé dans le sens mieux documenté.
    La gestion des connaissances au sein de l'équipe est mieux distribuée et cela améliore la communication.
    Cela permet aussi aux développeurs de se projeter dans le temps au niveau de leur gestion de carrières pro. Tous les développeurs n'aspirent pas forcément à le rester et toucher partiellement aux métiers de la MOA, dialoguer avec les autres équipes (SEO, graphistes, web analystes, etc.) permet de leur ouvrir de nouvelles perspectives.
    Personnellement, je n'y vois que des avantages.

    Citation Envoyé par arkhamon Voir le message
    La société est une gigantesque pyramide, il en a été ainsi de tous temps et dans tous les lieux : des grands chefs, des moyens chefs, des petits chefs des sous chefs et en bas quoi qu'on puisse en dire, des gens qui exécutent.
    Je suis totalement en phase avec le commentaire de gangsoleil sur cette remarque.
    Une autre façon de faire est possible (et personnellement, je dirai même qu'elle est souhaitable).

    Citation Envoyé par arkhamon Voir le message
    Vouloir que tout le monde ait son BAC et aille en fac c'est de la connerie, parce qu'on n'a pas besoin d'un plombier avec un DEUG.
    Ben on n'a pas besoin non plus d'un DEV sur diplômé, on a juste besoin d'un mec qui sache faire son boulot correctement, sans trop de bugs
    Avec la complexité des SI, et des applications qui le composent, on ne parle plus de développeur mais d'analyste développeur
    Ce n'est pas juste un terme bateau, cela a une vraie signification.
    On ne peut plus se permettre "juste de développer", il faut effectuer une véritable analyse à 360° de son développement pour en mesurer tous les impacts, avoir un sens critique aiguisé et constant.
    Ce n'est plus un boulot de "technicien" mais d'ingénieur
    Je ne vais polémiquer sur les niveau d'étude car je ne pense pas que le diplôme fasse tout (surtout que j'ai eu l'occasion de travailler avec des BA+2 bien plus compétents que des BAC+5)

    Citation Envoyé par arkhamon Voir le message
    (je rappelle qu'un bug c'est une erreur de codage, ça n'a rien à voir avec une spec erronnée !).
    Une erreur de codage peut être induite pas de mauvaises spec
    Et puis, au sens client, la définition d'un bug est très large
    Le client se moque de savoir si c'est une erreur technique du framework ou du dev ou de besoin métier mal défini ou de cas non prévus dans la spec

  6. #46
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Et si une autre solution existait ? Et si ce système pyramidal où chacun se dédouane sur le niveau d'au dessus et en cachant la moitié des conneries et en s'attribuant le mérite des gens d'en dessous était suranné ?
    C'est une vision partielle du développeur, qui ne colle plus depuis longtemps à la réalité. Il fut un temps où les chefaillons faisaient les specs, et même le prototype des méthodes, et le développeur implémentait l'algorithme qu'on lui avait donné dans la méthode sus-nommée.
    Encore une fois, c'est ce qu'en fait l'homme qui rend la pyramide inadaptée. Dans un système pyramidal, chacun est responsable devant celui d'au dessus de ce qui se passe en dessous, en "échange" de quoi il a le droit de donner des ordres à ceux d'en dessous. Ca a fait ses preuves et ça continue à le faire partout où chacun a le courage de prendre ses responsabilités. LE problème, c'est ceux qui se battent comme des chiens pour devenir petit chef à plumes, et qui après n'assument pas leurs responsabilités !
    C'est dommage et je suis le premier à le reconnaître, que tout le monde ne soit pas super intelligent et super fort et super beau. Mais c'est la réalité biologique et naturelle : l'intelligence de la population se répartit selon une distribution de Gauss. Donc comme tout le monde ne peut pas être à droite, il faut bien trouver du boulot pour ceux de gauche. D'où une segmentation du travail. Y a des CDP, des ingénieurs, des analystes, des programmeurs et des codeurs. Ça existait au début de l'informatique, comme dans tous les autres métiers. Mais d'une façon incompréhensible, ce n'est qu'en informatique qu'on considère que tout le monde doit pouvoir tout faire.
    Regardez un peu comment ça fonctionne dans le bâtiment, dans les hôpitaux, dans l'armée...

    Citation Envoyé par gangsoleil Voir le message
    Maintenant, il y a aussi des sociétés dans lesquelles le dev est une personne qui est reconnue pour avoir de bonnes connaissances sur le logiciel, et c'est pour ça qu'il participe aux (réunions de) conception et de spécification, et qui après écrit le code en fonction de ce qui a été décidé.
    JE crois que la difficulté est induite par le terme "développeur" qui regroupe tout et rien. Comme "soignant" qui regroupe des professeurs en chirurgie, des chirurgiens des médecins spécialistes, mais aussi les infirmières et les aides soignants. On fait un amalgame entre 10 professions qui sont totalement différentes !

    Citation Envoyé par gangsoleil Voir le message
    Et personnellement, la société dont tu parles dans laquelle le dev s'épanouit parce qu'on le félicite, à mon avis c'est tout aussi faux : moi je m'épanouis beaucoup plus parce que je fais quelque chose d'intéressant que parce que mon travail est reconnu par ma hiérarchie.
    Encore une fois, un travail "de base" peut être intéressant. Il est totalement chimérique de croire que tout le monde peut être en haut de l'échelle en étant compétent !

    Citation Envoyé par gangsoleil Voir le message
    Si je voulais être reconnu, ça fait longtemps que je serai passé chef, et que je lècherai le cul de mes supérieurs pour qu'ils me félicitent encore plus (et vu les chefs que j'ai eu, je pense que je pourrai être pas mauvais à ce jeu en appliquant ce qu'ils faisaient).
    Aïe ça c'est mal !
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  7. #47
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Pour avoir eu l'occasion de le tester avec pas mal de développeurs différents, j'ai pu constater une nette différence dans le comportement entre la simple exécution et la prise en charge de l'ensemble de la fonctionnalité.
    Et même au delà du comportement, le travail est mieux réalisé dans le sens mieux documenté.
    La gestion des connaissances au sein de l'équipe est mieux distribuée et cela améliore la communication.
    Cela permet aussi aux développeurs de se projeter dans le temps au niveau de leur gestion de carrières pro. Tous les développeurs n'aspirent pas forcément à le rester et toucher partiellement aux métiers de la MOA, dialoguer avec les autres équipes (SEO, graphistes, web analystes, etc.) permet de leur ouvrir de nouvelles perspectives.
    Personnellement, je n'y vois que des avantages.
    Ce que je préconise n'est en rien un frein à la progression. Ca permet même à chacun de comprendre à quel moment il a découvert sont point de compétence maximal.

    Citation Envoyé par Saverok Voir le message
    Avec la complexité des SI, et des applications qui le composent, on ne parle plus de développeur mais d'analyste développeur
    Ce n'est pas juste un terme bateau, cela a une vraie signification.
    A mon époque on parlait d'analyste programmeur. Et c'était déjà trop flou.

    Citation Envoyé par Saverok Voir le message
    On ne peut plus se permettre "juste de développer", il faut effectuer une véritable analyse à 360° de son développement pour en mesurer tous les impacts, avoir un sens critique aiguisé et constant.
    Ce n'est plus un boulot de "technicien" mais d'ingénieur
    Je ne vais polémiquer sur les niveau d'étude car je ne pense pas que le diplôme fasse tout (surtout que j'ai eu l'occasion de travailler avec des BA+2 bien plus compétents que des BAC+5)
    PAs d'accord. Si tout le monde se mèle de tout ça devient le bazar !

    Citation Envoyé par Saverok Voir le message
    Une erreur de codage peut être induite pas de mauvaises spec
    Et puis, au sens client, la définition d'un bug est très large
    Le client se moque de savoir si c'est une erreur technique du framework ou du dev ou de besoin métier mal défini ou de cas non prévus dans la spec
    Non pour moi un bug c'est ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Function Diviser(a , b : Real) : Real;
      Result := a / b;
    End;
    Voila ça c'est un bug car si la fonction est appelée avec b=0 ca plante.
    Sinon on parle d'erreur de specs ou d’erreur de conception.
    la définition d'un bug, c'est le fonctionnement "apparemment" erratique ou "aléatoire" d'une application, dans la mesure où le programme s'arrête ou fournit un résultat faux de façon non systématique !
    N'oublions pas que ce mot a une signification historique et technique : c'est au début des ordis dans les années 40 quand les fils mal isolés ou bouffés par les cafards ("bug") faisaient faux contact !
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  8. #48
    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 arkhamon Voir le message
    D'où une segmentation du travail. Y a des CDP, des ingénieurs, des analystes, des programmeurs et des codeurs. Ça existait au début de l'informatique, comme dans tous les autres métiers. Mais d'une façon incompréhensible, ce n'est qu'en informatique qu'on considère que tout le monde doit pouvoir tout faire.
    On ne demande pas à un développeur de savoir tout faire
    L'idée est de mettre le développeur au centre de la conception de la fonctionnalité et supprimer tous les intermédiaires dispensables
    Le CP ne sert à rien en tant que simple "passe plat".

    Pour en revenir au développement Agile, il est souvent rappelé que cela s'adresse à des développeurs expérimentés
    On ne demande pas au débutant de savoir gérer une fonctionnalité complexe dans son ensemble
    Par contre, quelqu'un d'expérimenté peut apporter bien plus que de la simple technique.

    Cela est particulièrement vrai dans le cas du web car c'est un domaine assez spécifique.
    Par exemple, un client est spécialisé dans la vente et la fabrication de meuble et souhaite ouvrir ou développer son activité sur le web.
    Un développeur expérimenté va pouvoir l'aider et le conseiller pour aborder ce canal spécifique. Il n'est pas question de le conseiller sur comment faire ou vendre un meuble.
    De même, dans le cas de la mobilité, ce n'est pas parce qu'un client est présent depuis longtemps sur la toile qu'il maîtrise les codes liés à la mobilité ainsi que toutes les nouvelles fonctionnalités et contraintes de ce canal.
    etc etc
    etc

    Pour finir, même les débutants ont leurs apports
    Dans le cas du web par exemple, j'adore avoir un "jeune" dans mon équipe qui baigne dans les réseaux sociaux car personnellement, je n'y connais pas grand chose
    Il m'est déjà arrivé de me faire accompagner par un stagiaire à une réunion sur l’implémentation de fonctionnalités de social-commerce...

    Tout ça pour dire que ce n'est pas parce qu'un développeur fait un job technique que ses seules compétences sont de l'ordre de la techniques
    Un développeur qui bosse depuis 10 ans dans un domaine métier et qui a eu l'occasion d'implémenter des centaines de fonctionnalités sur des dizaines de projets a un retour d'expérience sans égal
    Limiter quelqu'un comme ça à une stricte tâche de développement, personnellement, je trouve que c'est du gâchi

  9. #49
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    Encore une fois, c'est ce qu'en fait l'homme qui rend la pyramide inadaptée.
    Bah oui, mais moi je bosse avec des humains... Et le système pyramidal, j'en ai bien bien vu les limites :
    • Mon chef, manager de 12 personnes, unanimement reconnu comme extrèmement compétent (aussi bien par les dev que par la hiérarchie), n'a jamais été plus haut, car il disait ce qu'il pensait -- et il a onc dit un jour qu'une décision n'était pas la bonne, avec arguments. Soucis : le type qui a pris la décision était un bon ami des hauts placés.
    • Mes N+2 : j'en ai vu 3 ou 4 en 5 ans dans une seule entreprise, je ne sais même plus. Entre celui qui ne disait pas bonjour aux grouillots (sur 14 dans l'open space, il disait bonjour aux 2 chefs), celui qui faisait des choix techniques aberrants (mais qui lui permettaient de "jouer" avec le matériel), etc... Et absolument aucun ne défendait ses sous-fifres.
    • Dans un grand groupe, les chefs, même au plus bas niveau, sont plus difficiles à joindre que l'administration française, car ils sont réellement tout le temps en réunion.
    • Et je ne pense pas que la segmentation du travail soit une bonne chose : dans une entreprise, il y avait un service documentation qui rédigeait les docs utilisateur. Et ce rédacteur technique avait parfois des questions sur les logiciels, donc il venait voir les devs, ce qui nous prenait environ 5 minutes de temps en temps, et en plus il était sympa, donc tout allait bien. Et puis un jour, le chef des dev n'a pas supporté que le rédacteur vienne poser une question - la question de trop visiblement, et donc il a demandé à ce que la voie pyraidale soit respectée : lorsque el rédatcer a une question, il la pose à son chef, qui transmet au chef des développeur, qui choisit à quel développeur il transmet la question. Celui-ci doit alors répondre par mail à ce même chef, qui transfert au chef du rédacteur, qui transfert au rédacteur.

    Résultat : une doc pourrie car plus d'interaction, une ambiance pourrie, et bien sur le rédacteur qui est allé voir ailleurs, donc en fait plus de doc.

    • etc etc etc


    Donc oui, je pense que si tout le monde était beau, gentil, compétent à la place qu'il occupe, et s'occupait de son poste, alors le système pyramidal serait peut-être quelque chose de bien. Mais là, non, c'est vraiment pas le pied, donc oui, je trouve que tout système qui a tendance à applatir cette pyramide pour que les gens puissent s'exprimer, c'est une bonne chose.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  10. #50
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Bah oui, mais moi je bosse avec des humains... Et le système pyramidal, j'en ai bien bien vu les limites :
    • Mon chef, manager de 12 personnes, unanimement reconnu comme extrêmement compétent (aussi bien par les dev que par la hiérarchie), n'a jamais été plus haut, car il disait ce qu'il pensait -- et il a donc dit un jour qu'une décision n'était pas la bonne, avec arguments. Soucis : le type qui a pris la décision était un bon ami des hauts placés.
    • Mes N+2 : j'en ai vu 3 ou 4 en 5 ans dans une seule entreprise, je ne sais même plus. Entre celui qui ne disait pas bonjour aux grouillots (sur 14 dans l'open space, il disait bonjour aux 2 chefs), celui qui faisait des choix techniques aberrants (mais qui lui permettaient de "jouer" avec le matériel), etc... Et absolument aucun ne défendait ses sous-fifres.
    • Dans un grand groupe, les chefs, même au plus bas niveau, sont plus difficiles à joindre que l'administration française, car ils sont réellement tout le temps en réunion.
    • Et je ne pense pas que la segmentation du travail soit une bonne chose : dans une entreprise, il y avait un service documentation qui rédigeait les docs utilisateur. Et ce rédacteur technique avait parfois des questions sur les logiciels, donc il venait voir les devs, ce qui nous prenait environ 5 minutes de temps en temps, et en plus il était sympa, donc tout allait bien. Et puis un jour, le chef des dev n'a pas supporté que le rédacteur vienne poser une question - la question de trop visiblement, et donc il a demandé à ce que la voie pyramidale soit respectée : lorsque le rédacteur a une question, il la pose à son chef, qui transmet au chef des développeur, qui choisit à quel développeur il transmet la question. Celui-ci doit alors répondre par mail à ce même chef, qui transfert au chef du rédacteur, qui transfert au rédacteur.

    Résultat : une doc pourrie car plus d'interaction, une ambiance pourrie, et bien sur le rédacteur qui est allé voir ailleurs, donc en fait plus de doc.

    • etc etc etc


    Donc oui, je pense que si tout le monde était beau, gentil, compétent à la place qu'il occupe, et s'occupait de son poste, alors le système pyramidal serait peut-être quelque chose de bien. Mais là, non, c'est vraiment pas le pied, donc oui, je trouve que tout système qui a tendance à applatir cette pyramide pour que les gens puissent s'exprimer, c'est une bonne chose.
    Mais pourquoi je suis toujours d'accord avec toi. Pourquoiiiiiiiiiiiiiiii?????

    Le truc le plus important, je crois, c'est la qualité de la communication. Avant même la compétence des gens, leur motivation, ou leur capacité de remise en cause(qui sont pourtant des facteurs essentiels). On est pas à l'armée ou les informations à passer sont simples(3 hostiles au deuxième étage - demande appui!) et ou le respect de la chaine hiérarchique complète est essentiel. La communication, dans nos domaines, ne peut pas se permettre la moindre approximation. Or, à chaque intermédiaire, à chaque passe-plat, on introduit des risques d'approximation ou d'oubli.

    Le genre de communication qu'on a, c'est du genre "il faut dispatcher les paiements entre TIP, virement, et chèque. LE TIP est prioritaire, sauf si montant supérieur à 1 million". Sauf que généralement sont oubliés plein de détails, comme "1 million inclus, ou exclus?" "Quelle priorité entre virement et chèque? Si on ne vient pas d'un TIP au montant trop élevé? Et si on en vient?". Et caetera. Sur un bête aiguillage tout con, on se retrouve déjà avec plein de subtilités.

    Si on passe par la chaine hiérarchique complète, ce genre de subtilités passe complètement à l'as. Le grand chef a autre chose à foutre que de gérer ce genre de détails(et c'est parfaitement légitime, ce n'est pas son rôle). C'est la première raison pour laquelle il faut communiquer directement entre sachants, sans se farcir 7 étapes intermédiaires.

    La deuxième raison, c'est qu'en plus, ça permet de comprendre pourquoi. Quand un programmeur sait pourquoi il doit faire une chose, il anticipera facilement plein de détails. Par exemple, la limite du TIP à 1 million, j'ai fini par l'apprendre, était due à la taille du pré-imprimé : 6 caractères avant la virgule. Donc ça n'était pas du tout un caprice, et ça répondait aussi mécaniquement à la question de savoir si la limite était inclusive ou exclusive(et à 2 ou trois autres, parce-qu'en fait le cas était beaucoup plus compliqué).

    La segmentation du travail est une catastrophe dans notre domaine parce-que justement elle éparpille la connaissance, et la maitrise qui va avec. A mon sens, il ne doit jamais y avoir plus de trois intervenants sur le chemin d'un élément(correction, évolution, morceau de projet) : Métier, Réalisation, Tests. Quitte à découper dans l'autre sens, et avoir plein de gens différents sur plein de sujets différents. A l'extrême rigueur, le métier peut être représenté par une MOA, mais les réalisateurs et les testeurs doivent quand même avoir accès au vrai métier.

    Sinon? Sinon, ben personne ne comprend rien, et des gens très compétents se plantent, parce qu'ils n'ont pas saisi toutes les subtilités du projet.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Discussions similaires

  1. Pour quelles raisons les entreprises devraient-elles opter pour des solutions libres ?
    Par Francis Walter dans le forum Logiciels Libres & Open Source
    Réponses: 116
    Dernier message: 11/02/2015, 12h19
  2. Réponses: 3
    Dernier message: 13/01/2012, 20h45
  3. Réponses: 8
    Dernier message: 11/04/2010, 14h10
  4. Réponses: 6
    Dernier message: 03/12/2009, 11h11
  5. Quand les ressources sont elles associées ?
    Par poulette3000 dans le forum Windows
    Réponses: 1
    Dernier message: 25/08/2006, 23h57

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