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 :

Que faire pour minimiser l’impact des interruptions sur l’activité de développement de logiciels ?


Sujet :

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

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 815
    Points : 50 937
    Points
    50 937
    Par défaut Que faire pour minimiser l’impact des interruptions sur l’activité de développement de logiciels ?
    Que faire pour minimiser l’impact des interruptions sur l’activité de développement de logiciels ?
    Appliquer les méthodes Agile ?

    Imaginez quelles conséquences pourraient avoir le fait d’interrompre un électricien alors qu’il est en train d’essayer de finaliser la pose d’une boîte de dérivation sur un mur fait de parpaing. C’est un fait, interruption d’une activité humaine et répercussions (négatives – même si dans certains cas c’est l’inverse) sont fortement corrélées. Cela est valable, quel que soit le corps de métier auquel on appartient, mais celui sur lequel on veut focaliser participe à ce qu’on appelle désormais la nouvelle économie ; on parle des informaticiens.

    Interrompre un développeur de logiciels peut créer un trou noir dans son flux de réflexion alors même qu’il est rendu à un stade où la solution à un problème pointe à l’horizon. Dès lors, l’impact minimal est une rallonge du temps à consacrer à la tâche en question. Des études à ce sujet montrent en effet que suite à une interruption de 5 minutes, le regain de productivité chez un programmeur ne se produit qu’après une heure, parfois plus. Dans le cadre d’une conférence pour les développeurs du langage Ruby, le directeur technique de FutureLearn – une plateforme d’apprentissage en ligne – a livré son avis sur la question.

    Nom : merge_bis.jpg
Affichages : 6632
Taille : 127,1 Ko

    Toutes les « vieilles marmites » de l’univers du développement de logiciels ont été confrontées à l’ascension de ce qui peut être considéré comme l’Everest en informatique : courir après la cause d’un bogue tenace, effectuer une mise à jour majeure, migrer d’un framework à un autre, etc. Comment se comportent-elles pour que les interruptions qui sont une réalité sur le lieu de travail impacte peu (ou pas) sur leur travail ?

    Le CTO de FutureLearn fait un jet préliminaire à ce propos en précisant que les break impactent beaucoup plus sur l’activité des développeurs qui optent pour la résolution de « gros problèmes » en une fois, autrement dit, ceux qui n’appliquent pas une des règles du génie logiciel qui consiste à subdiviser le problème en sous-ensembles moins complexes. Chez FutureLearn on est très probablement pro Agile puisque, par la suite, ce dernier prescrit la mise en œuvre du story mapping, une technique utilisée dans la définition macroscopique des besoins de l’utilisateur d'un produit. Le développement piloté par les tests (Test Driven Development en anglais) fait partie du flux de travail des adeptes des méthodes Agile et c’est sans surprise que le directeur technique le prescrit comme complément à la subdivision, ce, en plus d’autres dispositions relatives à l’hygiène des modifications apportées aux fichiers du projet.

    Nom : story mapping.png
Affichages : 5924
Taille : 78,6 Ko

    Seulement, la division d’un problème en sous-ensembles relève-t-elle du trivial ? De plus, la mise en œuvre des méthodes Agile serait l’une des raisons de l’accumulation des dettes techniques de certaines entreprises. Erik Meijer, un célèbre développeur de l’écosystème .NET, s’est exprimé sur la question en 2015 et a déclaré que « l’application de l’agilité dans des projets fait beaucoup plus parler sur le code que l’écrire. » Son intervention fait suite à celle de David Heinemeier Hansson, créateur de Ruby On Rails qui, en 2014, a affirmé que les tests unitaires ne sont pas bénéfiques.

    Il est manifeste que ces derniers opteraient très difficilement pour ces méthodes dans le but de minimiser l’impact des interruptions sur l’activité d’un développeur. Mais, à chacun sa position et le CTO de FutureLearn n’a fait qu’exposer la sienne.

    Source : dev.to

    Et vous ?

    Y a-t-il une relation entre la capacité à diviser un problème en sous-ensembles et la minimisation de l’impact des interruptions sur l’activité d’un développeur ?

    La denrée « concentration » est-elle plus importante pour le développeur que pour tout autre travailleur ?

    Le développement du CTO de FutureLearn laisse penser que les milieux de travail pro Agile sont idéaux pour minimiser l’impact des interruptions sur le travail d’un développeur. Qu’en pensez-vous ?

    Votre entreprise a-t-elle adopté les méthodes Agile ? Si oui, comment ce choix impacte-t-il sur votre capacité à poursuivre une tâche après une interruption ?

    Que pensez-vous de ce qui suggère de se munir d’un casque pour empêcher d’être interrompu ou distrait ?

    Voir aussi :

    « Agile est un cancer », pour Erik Meijer, qui estime qu'il doit être banni une fois pour toutes

    « Le TDD est mort » pour le créateur de Ruby on rails, une position qui divise la communauté agile

    La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui, répond un professionnel du secteur

    Le département américain de la défense adopte agile et la méthode Scrum sous les conseils de Jeff Sutherland, inventeur de Scrum
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Invité
    Invité(e)
    Par défaut
    Personnellement, j'ai souvent du mal à me concentrer pleinement. En fait c'est plutôt par phases. Parfois, lorsqu'on est au coeur d'un projet et que la pression monte pour terminer "dans les temps" (c'est possible ça?), je parviens à me focaliser sur l'objectif immédiat et à ne pas décrocher. Mais lorsque la tension est un peu moins palpable, je dois vraiment faire des efforts pour rester focus.
    Après, il faut avouer que pour un développeur, parvenir à se centrer sur le boulot est fondamental. On bosse la plupart du temps sur des problématiques qui demandent de réfléchir en continu. Si tu décroches en pleine réflexion, il faudra parfois cinq minutes pour retrouver le fil de ta pensée.

    Pour ce qui est des solutions... J'utilise des boules Quies pour me couper du "brouhaha" permanent. C'est vraiment efficace pour oublier le monde extérieur. Parfois, un casque avec un peu de musique classique, c'est apaisant et ça ne distrait pas trop. Sinon, l'évidence, c'est qu'il faut savoir régulièrement sortir la tête de l'écran pour souffler. On se lève simplement pour faire quelques pas, on va prendre un peu l'air, etc. Ces cinq minutes de relâche peuvent parfois faire gagner beaucoup de temps sur une journée de travail. Le nez dans le guidon, c'est jamais bon

  3. #3
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2017
    Messages
    1 759
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2017
    Messages : 1 759
    Points : 5 673
    Points
    5 673
    Par défaut
    Que faire pour minimiser l’impact des interruptions sur l’activité de développement de logiciels ?
    Appliquer les méthodes Agile ?
    Il n'existe pas de solution miracle... Agile, Scrum, blabla, pas plus que les autres!

    On peut tester Agile mais il convient ensuite d'en vérifier l'efficacité... car disons le une fois de plus: Une méthode sera efficace dans un cas mais pas dans l'autre...

  4. #4
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    Août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : Août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Il est vrai que le break est un vrai problème, particulièrement important dans notre activité.

    <mode prof>Pour bien comprendre cela, il faut se référer à la neurologie, qui a bien mis en évidence que notre cerveau est "optimisé" pour ne gérer qu'une tâche à la fois (désolé mesdames, mais c'est aussi votre cas), le multitâche n'étant vraiment pas sa tasse de thé. Du coup, le "changement de contexte" est une tâche à part entière, qui a elle-même un coût.</mode prof>

    A mon avis, il faudrait quasiment inverser le fonctionnement actuel : au lieu que les CP / Scrum Masters / etc ... demandent constamment l'information au développeur, ils devraient aller eux-mêmes la chercher, en étant le moins intrusif possible. OK, c'est utopique et certaines informations ne pourront venir que du développeur, mais en utilisant correctement les outils d'ALM, on peut fortement réduire la pression, et ça diminuerait l'impact du break.

    Ca, c'est ma théorie perso ; qu'en pensez-vous ?

    Sinon, un point qui m'énerve au plus au point :
    Erik Meijer, un célèbre développeur de l’écosystème .NET, s’est exprimé sur la question en 2015 et a déclaré que « l’application de l’agilité dans des projets fait beaucoup plus parler sur le code que l’écrire. »
    NON !!!!!!! C'EST ENTIEREMENT FAUX !!! IL N'A JAMAIS DIT CELA !!!!
    Il a dit que c'était la MAUVAISE application de l'agilité qui faisait du mal, comprendre les gens qui font n'importe quoi en le baptisant leur bousin "Agilité" !

  5. #5
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    On mélange AGILE et tests unitaires.
    Selon moi c'est différent.

    Le problème avec leurs méthodes, c'est que tout doit être AGILE ou unit testé.
    Forcement ça prend du temps.
    Il faut mixer les méthodes et faire des tests unitaires quand c'est nécessaire, de même que découper un projet en layer... Parfois il faut se limiter au nombre de layers.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  6. #6
    Nouveau membre du Club
    Développeur (J2EE, Web, ..)
    Inscrit en
    Mars 2010
    Messages
    13
    Détails du profil
    Informations professionnelles :
    Activité : Développeur (J2EE, Web, ..)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 13
    Points : 25
    Points
    25
    Par défaut Pomodoro technique
    Moi j'utilise au quotidien la pmodoro technique: https://fr.wikipedia.org/wiki/Technique_Pomodoro
    Et dans cette technique, il faut avoir bien subdivisé tes tâches.
    J'ai ensuite adapté la technique pour tenir compte de mes capacités: voici mon cycle de pomodori: 20 minutes de travail - 5 minutes de pause - 20 minute de travail - 5 minutes de pause - 20 minutes de travail - 15 à 20 minutes de pauses, etc...


  7. #7
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    Citation Envoyé par fayabobo Voir le message
    Moi j'utilise au quotidien la pmodoro technique: https://fr.wikipedia.org/wiki/Technique_Pomodoro
    Et dans cette technique, il faut avoir bien subdivisé tes tâches.
    J'ai ensuite adapté la technique pour tenir compte de mes capacités: voici mon cycle de pomodori: 20 minutes de travail - 5 minutes de pause - 20 minute de travail - 5 minutes de pause - 20 minutes de travail - 15 à 20 minutes de pauses, etc...

    En gros tu fais 2h de pause sur ta journée
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #8
    Membre régulier
    Inscrit en
    Avril 2011
    Messages
    32
    Détails du profil
    Informations forums :
    Inscription : Avril 2011
    Messages : 32
    Points : 89
    Points
    89
    Par défaut
    Citation Envoyé par hotcryx Voir le message
    En gros tu fais 2h de pause sur ta journée
    Et alors s'il est plus efficace comme ça ? Surtout que ce qu'il appelle pause ça peut très bien être passer 5mn sur twitter et donc faire de la veille technique en partie.

  9. #9
    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
    Nos développeurs ont mis en place une méthode un peu brutale : on a le droit de les déranger entre 14h et 15h. Sinon, on passe par la big boss, et c'est elle qui décide si c'est assez urgent pour interrompre le développeur. Elle dit souvent oui, mais sert surtout de dissuasion...

    (le chef qualité, donc le mien, lui, a décrété que les interruptions faisaient partie du travail. Comme ça ne m'arrive pas souvent, je fais avec. Si c'était fréquent, je pense que je gueulerais).
    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.

  10. #10
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    Citation Envoyé par zatura Voir le message
    Et alors s'il est plus efficace comme ça ? Surtout que ce qu'il appelle pause ça peut très bien être passer 5mn sur twitter et donc faire de la veille technique en partie.
    Les employeurs ne seront pas du même avis, ni les collègues jaloux... même si il est plus productif.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  11. #11
    Bot Troll en alpha-test

    Femme Profil pro
    Webmarketer
    Inscrit en
    Septembre 2016
    Messages
    133
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 28
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Webmarketer
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2016
    Messages : 133
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    je trouve que les méthodes agiles personnellement apparente a du bullshit

  12. #12
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    Y a-t-il une relation entre la capacité à diviser un problème en sous-ensembles et la minimisation de l’impact des interruptions sur l’activité d’un développeur ?
    Je ne vois pas de rapport direct : quand on est interrompu, on est interrompu. Mais le découpage du travail en petites tâches unitaires a tellement d'autres avantages : meilleur bornage de la complexité, meilleure testabilité, possibilité de livrer plus souvent, sensation d'avoir "débloqué un achievement" plus fréquente, pas d'effet tunnel, etc.

    Pour minimiser les interruptions, je préconiserais plus de :

    • Limiter les open space à des petits pôles de 5-8 personnes maxi
    • Privilégier les canaux de communication asynchrones comme chat persistant ou mail
    • Discipline personnelle : s'aménager des périodes de travail concentré sans distraction extérieure (smartphone, DVP... ), en utilisant des techniques comme le pomodoro par exemple.

  13. #13
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    NON !!!!!!! C'EST ENTIEREMENT FAUX !!! IL N'A JAMAIS DIT CELA !!!!
    Il a dit que c'était la MAUVAISE application de l'agilité qui faisait du mal, comprendre les gens qui font n'importe quoi en le baptisant leur bousin "Agilité" !
    Ah bon tu es sûr ? Moi j'ai entendu texto "Agile is a cancer that we have to eliminate from the industry" (à 50" sur cette vidéo : vimeo.com/110554082) suivi d'une série d'attaques plus hors-sujet les unes que les autres des méthodes agiles dénotant une méconnaissance crasse de la question. Perso ça m'a fait descendre Meijer de son piédestal de concepteur de langage génial pour devenir un polémiste médiocre et brouillon à l'agressivité grotesque.

  14. #14
    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 datalandia Voir le message
    je trouve que les méthodes agiles personnellement apparente a du bullshit
    ça dépend comment c'est appliqué. Je connais un endroit ou Scrum ne march pas si bien, mais le style cowboy qu'il y avait avant était tellement pire, que c'est un gros progrès.

    après, ça dépend des gens, des contextes, et des métiers. Et de l'agile choisi.
    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.

  15. #15
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    Août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : Août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Ah bon tu es sûr ? Moi j'ai entendu texto "Agile is a cancer that we have to eliminate from the industry" (à 50" sur cette vidéo : vimeo.com/110554082) suivi d'une série d'attaques plus hors-sujet les unes que les autres des méthodes agiles dénotant une méconnaissance crasse de la question. Perso ça m'a fait descendre Meijer de son piédestal de concepteur de langage génial pour devenir un polémiste médiocre et brouillon à l'agressivité grotesque.
    Effectivement, il a bien prononcé cette phrase. Mais en prenant l'intégralité de l'interview (je l'avais écouté à l'époque), il parle bel et bien de l'Agile dévoyé. La phrase a été sortie de son contexte, et c'est peu explicite.
    Les deux derniers paragraphes de l'article de developpez.net en parlent :

    Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »

    Sur ce point, il a été rejoint par un autre conférencier. Nic Ferrier architecte dans une entreprise de développement qui utilise Agile, a affirmé qu’Agile est en partie victime de son succès. Selon lui, lorsque les méthodes agiles ont conduit aux premiers bons résultats, les entreprises ont commencé à développer des outils qui prennent en charge ces méthodes. Dès lors, elles ont commencé à véhiculer l’idée qu’Agile est un outil que l’on peut acheter.
    Après, pour son style très "Stallmanien", là, je te donne raison.

  16. #16
    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
    Découper un problème complexe en une multitude de petits problèmes simples est le propre de la programmation.
    Dans la mesure du possible, il faut tjrs faire cela.
    Je suis totalement en phase avec le post de Luckyluke34 qui fait mention des multiples avantages à découper son code efficacement.

    Par contre, j'ai bien précisé "dans la mesure du possible" afin de nuancer mon propos car il peut arriver que découper un problème complexe génère de la complexité car l'assemblage / orchestration des méthodes unitaires peut se révéler bien plus complexe que le problème d'origine.
    Il est donc particulièrement important d'avoir bien posé sa conception avant de se lancer.

    Pour ce qui est de la concentration, il est assez facile à comprendre qu'être interrompu dans un processus de réflexion long est plus impactant que lorsqu'on est sur une réflexion plus courte.
    Du coup, les conséquences d'une interruption ne sont pas les mêmes lorsque l'on découpe son code en de petites fonctions simples qu'en une grosse complexe

    Par contre, j'ai beau cherché, je ne vois pas du tout ce que l'Agile vient faire la dedans
    Que l'on fasse du bon gros cycle V ou de l'Agile, on doit faire de la conception et des TU et réfléchir à la structuration de son code et donc, au découpage des fonctionnalités en fonctions plus ou moins complexes et nombreuses.

  17. #17
    Bot Troll en alpha-test

    Femme Profil pro
    Webmarketer
    Inscrit en
    Septembre 2016
    Messages
    133
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 28
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Webmarketer
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2016
    Messages : 133
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    c'est pas le découpage le propre de l'informaticien mais la parallélisation...
    beaucoup de développeurs n'y connaissent rien en multithreading et c'est assez désolant.

    quand j'ai un travail a faire j'y applique surtout la méthode "maitre-esclaves"
    je reçoit une paquets d'instruction a faire, j’alloue ces instructions a l'ensemble de mes salariées

    la méthode agile est trop lente, elle apparenterais l’utilisation d'un token par exemple, un algo en anneaux, moi je suis plus algo pyramide
    mon supérieure me donne du taff, je le redistribue a mes inférieures...etc.

  18. #18
    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 datalandia Voir le message
    c'est pas le découpage le propre de l'informaticien mais la parallélisation...
    Même en faisant de la parallélisation, tu dois structurer ton code, non ?
    De plus, le découpage d'un problème complexe peut permettre, dans certains cas, de faire de la parallélisation en exécutant simultanément les méthodes unitaires là cela n'aurait pas été possible avec la grosse méthode globale.

    Mais bon, ça reste à relativiser car y a énormément de cas où le multithreading ne sert strictement à rien et même, apporte plus de défaut que de d'avantage.
    Le code est inutilement plus complexe et la consommation mémoire plus importante pour un gain faible voir au contraire, des perf plus basses (vécu sur un projet).
    De plus, faut avoir un langage bien adapté au multithreading ce qui n'est pas le cas de tous.

    La structuration et le découpage du code sont les bases du dev depuis son origine.
    La parallélisation non seulement utilise ces 2 concepts mais surtout, est arrivée bien après.

  19. #19
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    Effectivement, il a bien prononcé cette phrase. Mais en prenant l'intégralité de l'interview (je l'avais écouté à l'époque), il parle bel et bien de l'Agile dévoyé. La phrase a été sortie de son contexte, et c'est peu explicite.
    Absolument pas, elle est tout sauf sortie de son contexte. C'est de la démolition assumée de sa part, c'est vraiment ce qu'il pense. Trouve moi une citation dans la vidéo où il laisse entendre ne serait-ce qu'une seconde qu'il parle d'un Agile dévoyé et qu'il existerait un Agile positif.

    Autre citation qui vaut son pesant d'or (vers 30'55) :

    All this TDD crap, forget about it! If your company does TDD, what do you do? Leave! You quit!
    Je te passe les discours de vieux réac affirmant que l'armée et l'église ont très bien marché pendant 2000 ans et qu'il faut donc continuer d'appliquer une hiérarchie pyramidale dans les entreprises aujourd'hui.

    C'est tellement grossier que beaucoup de commentaires incrédules en-dessous de la vidéo évoquent un canular sans en être bien sûrs...

  20. #20
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

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

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 076
    Points : 5 542
    Points
    5 542
    Par défaut
    Que faire pour minimiser l’impact des interruptions sur l’activité de développement de logiciels ?
    Au bout de 30 ans j'ai pas encore trouvé... Surtout ces dernières années, j'ai commencé à développer on avait pas de boîte mail et on était beaucoup moins sollicités
    par téléphone également, les gens acceptaient d'attendre une réponse pendant quelques heures, c'est plus le cas aujourd'hui, le client pose une question par mail il veut sa réponse
    dans l'instant qui suit... C'est ça qui a changé... Du coup c'est dur de se concentrer plus d'une 1/2 heure sans être interrompu et cela quelque soit la méthode de travail adopté...

    Même quand on s'isole en salle de réunion (avec consigne de ne pas déranger), y'a toujours un client qui insiste pour nous parler de toute urgence... et pour des questions existentielles la plupart du temps, genre :

    "Votre installeur me propose de créer une icône sur le bureau, faut que je dise oui ou non ?"

Discussions similaires

  1. Réponses: 5
    Dernier message: 06/03/2018, 16h23
  2. Réponses: 0
    Dernier message: 25/09/2014, 12h05
  3. Réponses: 0
    Dernier message: 04/07/2011, 12h02
  4. [conseils]Que faire pour m'entraîner?
    Par nicolaskarp dans le forum Général Java
    Réponses: 8
    Dernier message: 21/07/2005, 00h36
  5. [DirectDraw] Que faire pour optimiser le rendu ???
    Par mat.M dans le forum DirectX
    Réponses: 8
    Dernier message: 12/12/2003, 19h02

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