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

Débats sur le développement - Le Best Of Discussion :

Une faible charge cognitive a un impact positif sur le développeur, l'équipe et l'organisation


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mai 2019
    Messages
    1 788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2019
    Messages : 1 788
    Points : 35 518
    Points
    35 518
    Par défaut Une faible charge cognitive a un impact positif sur le développeur, l'équipe et l'organisation
    L'amélioration de l'expérience du développeur dans le domaine du développement logiciel, peut avoir un impact positif sur la productivité,
    la charge cognitive et les résultats organisationnels

    Des experts de la recherche, notamment Nicole Forsgren de Microsoft Research, Eirini Kalliamvakou de Github Next, Abi Noda de DX, Michaela Greiler de DX, Brian Houck de Microsoft, et Margaret-Anne Storey de l'Université de Victoria et DX, se penchent sur l'importance cruciale de l'Expérience du Développeur (DevEx) dans le domaine du développement logiciel. Ils mettent en lumière les défis rencontrés par de nombreuses organisations liés à la friction, aux formalités administratives et à une livraison de code source source de frustration. L'équipe de chercheurs affirme que l'optimisation du DevEx, défini comme la façon dont les développeurs perçoivent, réfléchissent et évaluent leur travail, joue un rôle essentiel dans l'amélioration de la productivité et du bien-être des développeurs.

    Cette étude s'appuie sur la Théorie de la Conception du Travail (WDT) pour explorer les résultats du travail à différents niveaux : individuel, d'équipe et organisationnel. Les résultats au niveau du développeur comprennent la performance, la créativité et l'apprentissage. Les résultats au niveau de l'équipe se concentrent sur la qualité du code et la dette technique, tandis que les résultats organisationnels portent sur la rentabilité, l'innovation et la capacité à atteindre les objectifs.


    Nom : JeuneB.png
Affichages : 4716
Taille : 323,6 Ko

    Trois dimensions clés de l'Expérience du Développeur sont identifiées : l'état de flux, les boucles de rétroaction et la charge cognitive. L'état de flux désigne l'immersion totale dans le travail, les boucles de rétroaction concernent la rapidité et la précision des retours d'information, et la charge cognitive mesure la facilité d'accomplissement des tâches.

    Les chercheurs émettent trois hypothèses (H1, H2, H3) afin d'explorer l'impact de ces dimensions sur le développeur, l'équipe et l'organisation. Ils avancent que l'amélioration du DevEx peut avoir des répercussions positives sur la productivité, l'apprentissage, l'innovation et la rentabilité. En conclusion, le texte expose la méthodologie de l'enquête utilisée pour évaluer ces dimensions et tester les hypothèses formulées.

    La charge cognitive est la quantité d'informations que la mémoire de travail peut traiter en même temps, et elle aide à la résolution de problèmes et à l'apprentissage. Dans le contexte du DevEx, la charge cognitive est la quantité de traitement mental nécessaire à un développeur pour accomplir une tâche. La théorie de la charge cognitive décrit un cadre avec trois types de charge cognitive : intrinsèque est la quantité inhérente d'effort ou de difficulté nécessaire pour accomplir une tâche ; étrangère est la façon dont l'information est présentée, qui peut être modifiée pour être plus ou moins intuitive ; et germinale est liée aux schémas.

    Les recherches antérieures sur le la théorie de la conception du travail ont testé les caractéristiques de l'environnement et du travail qui sont bien alignées sur la charge cognitive et qui contribuent aux résultats du travail. Par exemple, une étude antérieure a montré que les tâches faciles à comprendre (intrinsèques) et les flux d'informations bien conçus (en germe) contribuent aux résultats. Une autre étude, qui était une vaste méta-analyse, a montré que la complexité du travail (intrinsèque) et les facteurs favorisant le traitement de l'information (en germe) contribuaient aux résultats.

    Les recherche actuelle mesure la charge cognitive comme la facilité de déploiement des changements, la facilité de compréhension du code et l'intuitivité des processus et des outils de développement. En d'autres termes, les chercheurs émettent l'hypothèse qu'une faible charge cognitive favorise de meilleurs résultats pour les développeurs, les équipes de développement et leur organisation.

    Une faible charge cognitive a un impact positif sur (a) le développeur, (b) l'équipe et (c) l'organisation. Le modèle de recherche proposé est présenté dans la figure ci-dessous. L'enquête utilisée pour mesurer le modèle est décrite dans la section suivante.

    Nom : devExp.jpg
Affichages : 790
Taille : 55,8 Ko

    Analyse et résultats du modèle

    Le modèle de recherche envisagé a été soumis à une analyse PLS (partial least squares), sélectionnée pour trois raisons : premièrement, elle convient bien à l'analyse exploratoire et à la construction théorique ; deuxièmement, la PLS ne nécessite pas de suppositions de normalité multivariée ; troisièmement, elle fonctionne efficacement avec des échantillons de taille modeste à moyenne. Comparativement à la CBSEM (modélisation d'équations structurelles basée sur la covariance), la PLS se concentre davantage sur l'adéquation du modèle, ce qui la rend particulièrement adaptée aux modèles prédictifs dans des contextes réels. De plus, le modèle en question comporte neuf variables indépendantes et neuf variables dépendantes, avec deux variables de contrôle, le rendant relativement complexe, où la CBSEM pourrait montrer un ajustement médiocre simplement en raison de cette complexité.

    Une règle empirique suggère de multiplier par 10 la taille du plus grand modèle d'équation structurelle pour déterminer la taille adéquate de l'échantillon lors d'une analyse PLS. Dans cette étude, avec une taille d'échantillon de 219 personnes, largement supérieure à la taille minimale de 30 personnes, cette règle est respectée.

    L'analyse a été réalisée avec SmartPLS 4.24, impliquant deux étapes : l'évaluation du modèle de mesure et du modèle structurel. Pour l'évaluation du modèle de mesure, la validité convergente a été établie en se basant sur trois critères : chaque élément a été chargé sur son construit respectif avec aucun chargement inférieur à 0,50 ; la fiabilité composite de tous les construits est inférieure à 0,70, confirmant la fiabilité ; l'AVE (moyenne de la variance extraite) de tous les construits est supérieure à 0,50. La validité discriminante a été confirmée par le rapport des corrélations hétérotrait-monotrait. Les propriétés psychométriques de nos mesures sont donc solides.

    La PLS, similaire à la régression linéaire, évalue l'importance des relations entre les concepts et fournit des valeurs R2, indiquant la proportion de variance expliquée par les variables indépendantes. Les coefficients de cheminement sont également utilisés pour évaluer la force et l'importance des relations entre les concepts. Lors du test du modèle, deux variables de contrôle ont été incluses : la taille de l'organisation et le secteur d'activité. Cependant, l'analyse a montré que ces variables de contrôle n'étaient pas significatives. Les résultats de la vérification des hypothèses sont résumés dans la figure 2 et présentés de manière détaillée dans la suite de cet article.

    • H1, affirmant que l'état de flux a un impact positif sur les résultats du développeur, de l'équipe et de l'organisation, est entièrement confirmée ;
    • H2, stipulant que les boucles de rétroaction ont un impact positif sur les résultats du développeur, de l'équipe et de l'organisation, est partiellement confirmée ; les boucles de rétroaction influencent les résultats de l'équipe, mais pas ceux du développeur ou de l'organisation ;
    • H3, déclarant que la charge cognitive a un impact positif sur les résultats du développeur, de l'équipe et de l'organisation, est entièrement confirmée.

    Nom : expdev.jpg
Affichages : 787
Taille : 79,0 Ko

    En vue de maximiser la prédiction des variables dépendantes, la PLS offre des informations complémentaires sur les éléments susceptibles d'avoir un impact plus significatif. Nous avons réalisé une analyse IPMA (analyse de la carte importance-performance) sur notre modèle de recherche afin d'identifier les éléments qui pourraient offrir aux équipes et aux organisations des perspectives supplémentaires. En résumé, cette analyse identifie les éléments ayant à la fois un impact et une performance élevés par rapport à la variable dépendante considérée. Pour améliorer les résultats des développeurs, le travail approfondi et le travail engageant semblent avoir le potentiel d'impact le plus significatif. En ce qui concerne l'amélioration des résultats organisationnels, plusieurs éléments ont le potentiel d'avoir un impact considérable : le travail approfondi, le travail engageant, les processus intuitifs et les outils intuitifs pour les développeurs. Malheureusement, nous n'avons pas pu effectuer l'analyse des résultats de l'équipe en fonction du modèle émergent.

    Il est important de noter que ces résultats sont spécifiques à notre contexte de recherche, mais ils offrent des indications pouvant être précieuses pour les équipes et les organisations. Par exemple, si l'objectif est d'améliorer les résultats des développeurs tels que la productivité, l'apprentissage et la créativité, il serait judicieux de réfléchir à la manière d'offrir des opportunités de travail approfondi. Cela pourrait impliquer des stratégies telles que l'encouragement du temps de concentration pour les développeurs individuels et des périodes de concentration coordonnées au sein des équipes, comme des journées avec peu ou pas de réunions. De plus, il peut être bénéfique de créer un environnement de travail engageant et de favoriser l'apprentissage, par exemple, à travers des journées "hack".

    L'analyse démontre que le travail approfondi et motivant contribue de manière significative aux résultats organisationnels tels que l'innovation, la fidélisation, la rentabilité et les objectifs plus larges de l'organisation. Des processus et des outils intuitifs soutiennent également ces objectifs. Par conséquent, les organisations pourraient envisager de rationaliser et de clarifier leurs processus, ce qui s'est avéré efficace dans d'autres études, ou de fournir des outils de développement intuitifs et faciles à utiliser. Des recherches antérieures ont souligné que l'inefficacité des processus de travail constitue un défi majeur pour les développeurs, et que l'amélioration des processus et des outils est un moteur de résultats.

    Modèles alternatifs

    Une autre approche que nous avons envisagée repose sur la Théorie du Développement Écologique (TDE). En analysant la théorie, nous avons reformulé les résultats de l'équipe tels que la dette technique et la qualité du code en tant que facteurs environnementaux modérant les résultats du développeur et de l'organisation. En d'autres termes, ces facteurs pourraient atténuer (réduire) ou amplifier (augmenter) l'impact des éléments de l'expérience développeur (DevEx) sur les résultats.

    Cependant, un test de ce modèle a révélé que les « résultats de l'équipe en tant que modérateurs environnementaux », en particulier notre opérationnalisation de la dette technique et de la qualité du code, ne présentaient pas de significativité. Par conséquent, les détails des résultats ne sont pas inclus. D'autres facteurs environnementaux pourraient être pertinents, et il est à noter que les variables de contrôle n'ont pas été significatives dans cette analyse.

    Une autre perspective sur l'impact : Analyse de vraisemblance

    Pour contextualiser ces résultats, nous examinons les résultats attendus lors de la mise en place d'interventions spécifiques en matière d'expérience développeur (DevEx). Voici les résultats statistiques observés dans cette analyse de probabilité, décomposés selon les trois dimensions du DevEx : l'état de flux, la charge cognitive et les boucles de rétroaction.

    État de flux

    • Les développeurs disposant de temps significatif pour un travail approfondi se sentent 50 % plus productifs que ceux qui ne bénéficient pas de temps dédié. Bien que la réservation de créneaux horaires puisse être un défi, encourager les développeurs à se concentrer et à minimiser les interruptions peut considérablement améliorer la productivité ;
    • Les développeurs qui trouvent leur travail intéressant estiment être 30 % plus productifs que ceux qui le jugent ennuyeux. Repenser la répartition des tâches au sein des équipes peut être bénéfique pour maintenir l'intérêt des développeurs et favoriser la productivité.
    • Les développeurs comprenant parfaitement le code sur lequel ils travaillent se sentent 42 % plus productifs que ceux qui ne le comprennent que peu ou pas du tout. Des outils et des conventions favorisant la clarté et la compréhension du code sont essentiels pour préserver la productivité à long terme ;
    • Les développeurs utilisant des outils et des processus intuitifs estiment être 50 % plus innovants que ceux confrontés à des processus opaques ou difficiles à comprendre. Des outils intuitifs favorisent la créativité en minimisant les obstacles et les frustrations.

    Boucles de rétroaction

    • Les développeurs bénéficiant de délais rapides pour la révision du code se sentent 20 % plus innovants que ceux confrontés à des délais plus lents. Des révisions rapides facilitent le passage à de nouvelles idées ;
    • Des boucles de rétroaction rapides sont également liées à une dette technique réduite de 50 %. Documenter les questions fréquentes des développeurs et mettre en place des outils pour faciliter la recherche de réponses contribuent à réduire cette dette technique.

    La contribution majeure de cette étude réside dans la démonstration que l'amélioration de l'Expérience Développeur (DevEx) génère des résultats positifs pour les individus, les équipes et les organisations. À notre connaissance, il s'agit de la première analyse statistique des relations entre les facteurs de DevEx et les résultats aux niveaux individuel, d'équipe et organisationnel. Alors que des études antérieures avaient suggéré ces relations, elles n'avaient pas été quantifiées. Les résultats présentés ici fournissent des preuves tangibles qui peuvent soutenir les équipes de développement et les dirigeants dans leur plaidoyer en faveur de l'investissement dans le DevEx.

    Le concept des trois dimensions clés de l'Expérience du Développeur (DevEx) - l'état de flux, les boucles de rétroaction, et la charge cognitive - constitue une approche intéressante pour comprendre les facteurs qui influent sur le bien-être et la performance des développeurs. Cependant, quelques points méritent une réflexion critique.
    En ce qui concerne l'état de flux, l'idée d'immersion totale dans le travail est essentielle, mais la façon dont elle est mesurée et interprétée peut varier d'un individu à l'autre. Les chercheurs devraient être attentifs aux diverses perceptions subjectives de l'état de flux pour éviter toute généralisation excessive.

    Les boucles de rétroaction et leur impact sur la rapidité et la précision des retours d'information sont également pertinentes, mais la complexité des environnements de développement peut nécessiter une analyse plus approfondie des différents types de rétroaction et de leur influence sur des aspects spécifiques du travail des développeurs.

    La charge cognitive comme mesure de la facilité d'accomplissement des tâches est une dimension cruciale. Cependant, il est important de noter que la charge cognitive peut varier en fonction des compétences individuelles, de l'expérience et du contexte du travail. Une évaluation plus nuancée de cette dimension pourrait apporter des insights plus précis.

    Les hypothèses formulées (H1, H2, H3) sur l'impact de ces dimensions sur le développeur, l'équipe et l'organisation sont valables, mais leur validation nécessite des preuves solides et une méthodologie robuste. Une attention particulière doit être portée à la manière dont les variables sont mesurées pour garantir la validité des résultats.


    L'affirmation selon laquelle l'amélioration du DevEx peut avoir des répercussions positives sur la productivité, l'apprentissage, l'innovation et la rentabilité est plausible, mais des études de cas ou des exemples concrets seraient bénéfiques pour étayer cette assertion.

    Bien que le texte expose la méthodologie de l'enquête utilisée, une transparence accrue sur les limites de l'étude, les éventuels biais, et la généralisabilité des résultats serait essentielle pour renforcer la crédibilité des conclusions. En outre, une approche plus contextualisée, prenant en compte les variations individuelles et organisationnelles, pourrait enrichir davantage l'analyse.

    Source : ACM

    Et vous ?

    Les conclusions de cette étude sont-elles pertinentes ?

    Peut-on obtenir des exemples concrets ou des études de cas illustrant comment l'amélioration de l'Expérience du Développeur a conduit à des résultats positifs en termes de productivité, d'apprentissage, d'innovation et de rentabilité ?

    Voir aussi :

    73 % des développeurs ont été victimes d'épuisement professionnel, d'après le dernier rapport sur l'état de l'Écosystème des Développeurs en 2023 : quelles astuces pour éviter le burnout ?

    Low code : les patrons soulignent l'avantage de la diminution des coûts de gestion des projets, mais des développeurs expliquent les raisons de leur scepticisme à propos de ces solutions
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 799
    Points : 32 029
    Points
    32 029
    Par défaut
    Charge cognitive liée à la livraison du code... début des années 2010. Je suis développeur COBOL pour une banque de taille moyenne. On a aussi des équipes JAVA. Plusieurs fois, les gens du métier veulent faire un nouveau truc. Ils vont demander aux gens du JAVA (qui n'étaient pas des mauvais, je le dis tout de suite). Estimation, 250 jours. Trop cher, donc ils viennent nous voir. 120 jours. Alors on a fait - et bien fait - en vieux COBOL.

    La différence? En COBOL, on avait un robot pour pousser nos livraisons en quelques minutes, quelque soit la cible. En JAVA, les pauvres malheureux devaient passer par un process d'une complexité infâme pour livrer chaque petite correction. Nous n'étions pas meilleur, notre langage pas meilleur (en tous cas pas pour tout, loin s'en faut, même si il a sa niche de prédilection). Mais nous avions les moyens de bosser.

    N.B. quand je suis parti en 2013, ils parlaient de verrouiller sérieusement les livraisons coté COBOL. Soi disant pour sécuriser les livraisons (foutaises, malgré toutes leurs souffrances, les gens du JAVA ne livraient pas moins de bugs que nous, les malheureux). Bien content d'être parti
    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. Réponses: 3
    Dernier message: 19/08/2021, 20h15
  2. Réponses: 2
    Dernier message: 06/11/2020, 22h29
  3. Réponses: 3
    Dernier message: 05/07/2007, 01h13
  4. [VB.NET]comment q'une page charge des parametres
    Par arize dans le forum ASP.NET
    Réponses: 2
    Dernier message: 22/11/2006, 13h46
  5. choisir ds une liste charge une autre liste par les bons elements
    Par kamaldev dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 25/07/2006, 11h06

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