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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    1 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 1 757
    Points : 40 262
    Points
    40 262
    Par défaut Les développeurs sont-ils trop lents pour innover ou pour déployer de nouvelles fonctionnalités ?
    Les développeurs sont-ils trop lents pour innover ou pour déployer de nouvelles fonctionnalités ?
    la chasse aux bogues, les petites équipes et les limites budgétaires en seraient quelques causes

    Une récente étude réalisée par la société de logiciels Rollbar a révélé que bien souvent, les développeurs voudraient innover ou déployer plus rapidement de nouvelles fonctionnalités, mais voient leurs prévisions bouleversées par certaines contraintes. L'étude, menée auprès de 950 développeurs, a révélé que 84 % des équipes étaient empêchées de déployer plus fréquemment un nouveau code en production en raison de contraintes comme : la recherche de bogues, des équipes et des budgets très réduits, etc. Elle révèle en outre que seulement 25 % arrivent à déployer du nouveau code en production chaque mois ou tous les deux mois.

    « Les développeurs veulent avoir une idée, l'écrire dans le code et faire en sorte que l'utilisateur vive cette idée », explique le cofondateur et directeur technique de Rollbar Cory Virok. « Mais la réalité est que le code qui est censé offrir ces expériences est souvent truffé d'erreurs et de bogues. Afin d'offrir une expérience client exceptionnelle, les développeurs consacrent jusqu'à 40 % de leur temps aux tests et à l'assurance qualité. Pourtant, les logiciels ne sont jamais parfaits, et la recherche de la perfection constitue un obstacle à l'itération et à l'innovation », a-t-il continué.

    Nom : 45.png
Affichages : 3609
Taille : 171,4 Ko

    En effet, les résultats de l'étude ont révélé que 84 % des équipes étaient empêchées de déployer plus fréquemment un nouveau code en production. La principale raison invoquée par les développeurs pour expliquer ces retards est le test et l'assurance qualité. Plus d'un tiers (36 %) des personnes interrogées ont déclaré que la difficulté de trouver et de corriger les erreurs en production les ralentissait. Un quart (25 %) des développeurs ont déclaré qu'ils ne déployaient du code que tous les mois ou tous les deux mois, tandis qu'environ 22 % ont dit qu'ils lançaient du nouveau code toutes les deux semaines.

    Environ 6 % ne déploient du nouveau code que deux fois par an. Comme souligné par Virok, Rollbar a constaté qu'au total, les développeurs consacrent jusqu'à 40 % de leur temps aux seuls tests et à l'assurance qualité, un temps qui aurait pu être utilisé pour itérer sur leur code et pour lancer de nouvelles fonctionnalités. En outre, des recherches antérieures de Rollbar ont mis en évidence la difficulté pour les développeurs d'essayer de détecter les bogues avant que leur logiciel n'atteigne la phase de production. Cette nouvelle étude réalisée en février montre que cette difficulté retarde toujours les équipes de développement.

    Selon le rapport de l'étude, 88 % des développeurs estiment que les outils traditionnels de surveillance des erreurs ne sont pas à la hauteur, et que la détection des bogues et des erreurs leur prend trop de temps. Cela dit, les processus techniques ne sont pas les seuls à blâmer. Près d'un tiers (30 %) des personnes interrogées ont déclaré que leur équipe était trop petite pour permettre des déploiements plus fréquents. Les restrictions budgétaires ont été mises en cause par 16 % des répondants, tandis que 15 % ont déclaré que leur organisation s'appuyait sur des "méthodologies traditionnelles".

    Nom : 46.png
Affichages : 2179
Taille : 184,5 Ko

    Selon ces derniers, ces méthodologies « ne correspondent pas à leurs plans de développement ». D'après environ 13 % des répondants, leur organisation s'appuie sur une gestion de projet imprécise. Par ailleurs, un dixième des personnes interrogées par Rollbar ont déclaré que le manque de leadership les empêchait d'innover plus rapidement, et 9 % ont déclaré que leurs ambitions étaient freinées par l'absence de vision à long terme au sein de leur organisation. Holger Mueller, vice-président et analyste principal chez Constellation Research, a déclaré que le fait d'essayer de perfectionner le code se fait souvent au détriment de l'innovation.

    Selon ce dernier, cela constitue un inconvénient majeur dans le monde hautement concurrentiel du développement de logiciels. « Les organisations qui s'appuient sur des logiciels, c'est-à-dire toutes les organisations, doivent introduire et itérer sur le code rapidement pour être compétitives », a déclaré Mueller. « Ce n'est pas facile. Les développeurs se retrouvent souvent coincés dans les méandres du code à perfectionner. Mais les nouveaux outils permettent désormais aux développeurs de faire plus de releases plus souvent », a-t-il ajouté.

    Nom : 47.png
Affichages : 2191
Taille : 198,3 Ko

    En somme, l'enquête de Rollbar a révélé que la majorité des programmeurs se languissaient d'un moyen plus rapide d'éliminer les bogues dans le code. Deux cinquièmes (40 %) des personnes interrogées ont déclaré vouloir de meilleurs outils pour détecter et corriger les erreurs de code. Près d'un tiers ont déclaré qu'une meilleure gestion de projet (38 %), une équipe plus importante (36 %) ou un budget plus élevé (30 %) leur donneraient confiance et leur permettraient de lancer de nouvelles fonctionnalités plus rapidement.

    Parmi les 86 % de développeurs qui ont déclaré que de nouvelles capacités les aideraient à itérer plus rapidement, nous avons :

    • 47 % ont déclaré que le fait de voir l'origine de chaque erreur accélèrerait ces efforts ;
    • 34 % ont déclaré que les capacités de détection de bogues en temps réel permettraient d'améliorer plus rapidement le code ;
    • 33 % ont déclaré que l'accès à des informations contextuelles riches sur chaque erreur serait bénéfique ;
    • 33 % ont déclaré que les nouvelles capacités d'aide à l'assurance qualité permettraient une itération plus rapide ;
    • 22 % ont déclaré qu'un accès ouvert aux API leur permettrait d'accélérer l'itération.

    « Il n'est pas surprenant que les entreprises souhaitent des logiciels de haute qualité qui offrent aux utilisateurs la meilleure expérience possible. Mais les logiciels sont constitués de code, et un code sans erreur est un leurre », a déclaré Brian Rue, PDG et cofondateur de Rollbar. « Les entreprises de premier plan adaptent leurs outils, leurs mentalités et leurs comportements pour faire face à cette réalité. Au lieu d'essayer de perfectionner les logiciels, elles adoptent de meilleurs outils et processus pour découvrir de manière proactive les erreurs lorsqu'elles se produisent et les résoudre immédiatement ».

    Rollbar est une entreprise qui met à la disposition des développeurs une plateforme d'amélioration continue du code qui découvre, prédit et corrige les erreurs de manière proactive grâce à des flux de travail assistés par l'IA en temps réel. Rollbar s'est donné pour mission d'aider les développeurs à améliorer continuellement leur code et à innover constamment plutôt que de passer du temps à surveiller, enquêter et déboguer.

    Source : Rapport de l'étude de Rollbar

    Et vous ?

    Que pensez-vous des conclusions de l'étude de Rollbar ?
    Votre organisation a-t-elle des difficultés pour déployer plus fréquemment de nouvelles fonctionnalités ?
    Comment pensez-vous que les équipes pourraient améliorer leur fréquence de déploiement de nouveau code ou d'innovation ?

    Voir aussi

    Agile pourrait-il conduire les organisations vers une dette technique plus importante ? Oui, selon Don Clos, développeur logiciel, qui propose une analyse détaillée de la situation

    Code Defect AI, un outil IA pour aider les développeurs à repérer les bogues pendant le codage et non à la fin, disponible en open source sous licence Apache v2.0

    Google rend disponible en open source ClusterFuzz, une infrastructure de test à données aléatoires, fonctionnant sur plus de 25 000 cœurs

    Projet Springfield : Microsoft veut aider les développeurs à détecter les bogues de sécurité, en recourant au cloud et à l'intelligence artificielle

    Suivi des linters JavaScript, outils d'analyse statique de code source, ESLint en 4.19.0 et standardJS en 11.0.0
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    juillet 2004
    Messages
    88
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

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

    Informations forums :
    Inscription : juillet 2004
    Messages : 88
    Points : 105
    Points
    105
    Par défaut
    Le kébabier est-il trop lent pour faire le kebab ? La faute aux lois de la physique !

  3. #3
    Membre extrêmement actif
    Profil pro
    Consultant en technologies
    Inscrit en
    novembre 2005
    Messages
    517
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

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

    Informations forums :
    Inscription : novembre 2005
    Messages : 517
    Points : 821
    Points
    821
    Par défaut
    Et pourquoi pas ? Il faut normaliser la chose , pour ne pas réinventer la roue

  4. #4
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 407
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 407
    Points : 2 454
    Points
    2 454
    Par défaut
    Déployer du code simple en production tous les mois c'est facile mais ne dure qu'un temps.

    Déployer une application complexe en production tous les mois réclame de gros moyens, notament une personne chargée de la recette ... qui devrait idéalement être intégrée à l'équipe de dev pour racourcir les délais. Donc il vous faut des springs toujours à l'heure, des nouvelles fonctionalités simples, des test unitaires parfait, des fonctionnalités non bugués, une planification sans faille avec la Q/A, et une mise en production immédiate.

    Aussi la plus sure option pour livrer à temps est bien sur de virer la QA et de se passer d'Agile dans les premières phases de conception (vu que personne ne sait évaluer le temps nécessaire).
    Sinon je vous souhaite bien du courage sauf si vous ne faites que de la Tierce Maintenance Applicative.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : août 2003
    Messages : 451
    Points : 705
    Points
    705
    Par défaut
    Le client demande généralement : je le veux le plus vite possible sans que ça me coute un bras
    J'ai donc rarement le temps de faire des tests unitaires et je suis loin de tester tous les cas. Les gens en recette fonctionnelle testent plus mais des bugs passent à travers.

    En plus quand une société édite un logiciel qui est personnalisé plus ou moins en fonction des clients, cela devient compliqué de proposer des améliorations. Le service maintenance doit suivre

  6. #6
    Membre averti
    Homme Profil pro
    salarié
    Inscrit en
    septembre 2014
    Messages
    131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : salarié

    Informations forums :
    Inscription : septembre 2014
    Messages : 131
    Points : 319
    Points
    319
    Par défaut
    J'hallucine pas mal, là. Les développeurs ne décident de rien. Ils sont au bas de l'échelle. C'est le client qui est en haut.
    C'est son budget qui paie tout. Les "nouvelles fonctionnalités", c'est au client de décider. Pour le reste (sécurité, performances, ertc...) c'est
    au fournisseur de proposer. Mais le code reste la propriété du client.
    Quand je lis "J'ai donc rarement le temps de faire des tests unitaires et je suis loin de tester tous les cas', là aussi j'hallucine :
    c'est qui le responsable en cas de problème ? De mon point de vue, le client. Mais merci la bataille juridique en cas de pertes
    financières.
    Une dernière chose, hélas souvent vérifiée en informatique : le mieux est l'ennemi du bien.

  7. #7
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 472
    Points : 998
    Points
    998
    Par défaut
    C'est exactement ce qu'on vit au quotidien. On est passé il y a quelques années en archi micro services; deploiements chirurgicaux etc. sauf qu'en realité c'est pas du tout ca, mais c'est meme plutot pire qu'avant comme tout est interdependant, il faut penser a tout redonder, a le faire dans un certain ordre et comme l'archi est distribuée et complexe, les gens tremblent quand on doit faire une MAJ en prod, la peur d'avoir oublié quelque chose ou pas fait dans le bon ordre.
    Et ca se verifie, 9 fois sur 10 on a des problemes. Avant on faisait un bug dans un logiciel dans un coin ca ne genait personne, maintenant quand un bug survient c'est toute la plateforme qui deconne.
    Dans le meilleur des cas on trouve et on resoud rapidement le soucis; en pratique malgré notre ELK et nos tonnes de logs, quand ca merde, on pleure a comprendre le pourquoi du comment. Sur la papier pourtant c'etait plus simple, la realité est bien differente. On etait bien plus efficace quand nos applis etaient dite "monolithiques" (alors que ce n'etait pas vrai puisqu'elles etaient en couches); maintenant on se retrouve avec une archi monolithique dans le sens ou on flippe avant chaque mise en prod (malgré les tonnes de TU pourtant). Pas certain que ce soit un progres.

    Bon apres ce sondage ne vaut rien, fait par une boite qui vend un logiciel qui remplit comme par hasard la fonction tant attendue par nos chers developpeurs. C'est du marketing deguisé ca n'a aucune valeur.

  8. #8
    Membre expert

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    2 728
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 728
    Points : 3 855
    Points
    3 855
    Par défaut
    Bonsoir,

    Les développeurs sont-ils trop lents pour innover ou pour déployer de nouvelles fonctionnalités ?
    La lenteur a plusieurs facteurs :

    > un informaticien utilise sa pensée intellectuelle / pensée cérébrale , penser et réfléchir demande du temps ... La logique n'est pas instantanée ! L'humain se fatigue ... Sans parler de la charge mentale et intellectuelle .
    > facteur financier (forcement si un budget est ridicule , le projet évolue peu ...)
    > facteur temps (demander 1 semaines pour un projet qui demande 3 semaines ... forcement on cumule carence de développement, sur carence )
    > facteur humain (quand on a pas assez de personnel ou que celui ci n'est pas assez qualifié)
    > facteur organisationnel (quand on est face à des services qui donnent des instructions contradictoires, c'est du déjà vu !)

    Comment pensez-vous que les équipes pourraient améliorer leur fréquence de déploiement de nouveau code ou d'innovation ?
    C'est propre a chaque entreprise. Cela demande que l'entreprise sache se remettre en question, sur les facteurs précités. Ce qui est rarement le cas ... D’où des situations ou l'on persiste dans la bêtise.

  9. #9
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 198
    Points : 5 089
    Points
    5 089
    Par défaut
    HS microservices : @kilroyFR, pourtant, je me rappelle que, il y a deux ans, tu étais à fond en faveur des microservices. Entre temps, je vois que tu as vécu une désillusion.

    J'en profite pour partager un dialogue intéressant de 2020 entre Martin Fowler et Sam Newman : When to Use Microservices (And When Not To!)

    La vidéo :


    La retranscription : https://gotopia.tech/bookclub/episod...-martin-fowler

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 518
    Points : 30 503
    Points
    30 503
    Par défaut
    Bon, je vais faire la voix de la QA. La QA "ne va pas assez vite". Effectivement, il peut parfois falloir du temps pour trouver un bug, voire pour le reporter.

    Une des difficultés qu'on a, c'est que quand un test automatique (coté interface, pas coté API, ceux-là sont généralement la came des développeurs) plante, plein de causes peuvent être possibles, et il faut du temps pour trouver ce qui a réellement planté. Souvent, el bug est bien en amont de ce qui plante.

    Mais aussi, une fois qu'on a identifié le big, il faut prendre le temps de définir son périmètre, sa dynamique exacte. Presque à chaque fois que j'ai voulu aller trop vite dans la rédaction du bug, le truc m'est revenu dans la tronche avec un bug partiellement corrigé. Donc si j'ai une erreur d'arrondi sur le calcul de dose lors d'une intraveineuse continue, je vais me mettre à vérifier systématiquement tous les calculs similaires (intraveineuse discontinue, cathéters, etc.) qui pourraient avoir le bug. Ca prend du temps. Ca prend du temps, mais ça évite de tuer des gens (le cas est authentique, j'ai eu ça en octobre 2017).

    Il y a des choses qui s'automatisent bien (typiquement, le bug ci-dessus a été trouvé par des tests automatiques d'interface, qui cherchaient juste à vérifier si le point marchait aussi bien que la virgule. On trouve rarement ce qu'on cherche, en QA, et c'est ça qui est rigolo). Et même celles là peuvent parfois prendre du temps avant de pondre un rapport de bug exploitable par les développeurs. D'autres beaucoup moins bien - spécialement l'ergonomie - et il faut du temps pour vérifier tout ça.

    Je dirais à vue de nez que le rapport est 85/15. 85% des problèmes sont détectables par des automatismes (qui sont parfois très couteux, un test d'interface est beaucoup plus long à automatiser qu'un test d'API, principalement pour des raisons de temps d'exécution). Les 15% restants sont souvent des avantages compétitifs.
    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. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 450
    Dernier message: 09/09/2020, 10h08
  2. Forums d’entraide : les développeurs professionnels sont-ils trop fiers pour aider les débutants ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 108
    Dernier message: 17/01/2020, 20h05
  3. Réponses: 100
    Dernier message: 31/03/2014, 14h56
  4. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 345
    Dernier message: 05/05/2013, 17h20

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