Que faire pour minimiser l'impact des interruptions sur l'activité de développement de logiciels ? Appliquer les méthodes Agile ? 312PARTAGES 9 0 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.





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.





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 :



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 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.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.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 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 ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 36 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Membre régulier https://www.developpez.com

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 7 0 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 Membre extrêmement actif https://www.developpez.com Que faire pour minimiser limpact des interruptions sur lactivité de développement de logiciels ?

Appliquer les méthodes Agile ?

Que faire pour minimiser limpact des interruptions sur lactivité de développement de logiciels ?Appliquer les méthodes Agile ?



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... 5 0 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... Expert éminent sénior https://www.developpez.com



(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). 4 0 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). Expert éminent https://www.developpez.com

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. 5 1 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 complexePar contre, j'ai beau cherché, je ne vois pas du tout ce que l'Agile vient faire la dedansQue 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. Membre confirmé https://www.developpez.com



Je suis convaincu pour l'avoir vécu moi même et vue chez mes collègues qu'on peut faire en 1 jour chez soi ce que l'on ferai péniblement en 5 au bureau si c'est souvent beaucoup plus. Mais bon je ne me fais pas d'illusion je sera déjà à la retraite (après une seconde partie de carrière solo), le jour où les décideurs comprendrons cela. 4 0 Très honnêtement après 18 ans dans le développement il est devenu de plus en plus difficile de se concentrer sur une tache de dev. Je me souviens à mes débuts où je pouvais passer 10h sur un pb sans que personne ne viennent me déranger et j'avais le sentiment d'abattre du boulot à la fin de la journée aujourd'hui ma productivité au niveau code est proche de 10% comparativement à ce que je faisais avant. Les openspaces où tout le monde simmiscent dans l'espace de travail des autres, provoque des réunions sur un coin de la table (merci la méthode agile !) où les téléphones sonnent en permanence ou maintenant un bruit de fond ne baisse pas avant la pause de midi, y sont pour quelque chose. Je milite pour le télé-travaille généralisé pour les développeurs qui peuvent bénéficier d'un environnement apaisé et calme chez eux. Je suis également plus disposé à la concentration entre 19h et 00h malheureusement c'est le moment où je dois rentrer chez moi donc je fais ce que l'on me dit :-(Je suis convaincu pour l'avoir vécu moi même et vue chez mes collègues qu'on peut faire en 1 jour chez soi ce que l'on ferai péniblement en 5 au bureau si c'est souvent beaucoup plus. Mais bon je ne me fais pas d'illusion je sera déjà à la retraite (après une seconde partie de carrière solo), le jour où les décideurs comprendrons cela. Membre émérite https://www.developpez.com Envoyé par Amnésix Envoyé par . Perso, c'est la méthode que j'applique au boulot. Un casque sur les oreilles pour m'isoler sur bruit incessant du bureau, et pour signaler aux autre : foutez moi la paix, je suis concentré. En général sa marche, surtout que lorsqu'on me dérange en pleine réflexion, je suis en général d'humeur massacrante 4 0 Un exemple éclatant de la formidable réussite des open space qui étaient censés "élargir la bande passante de communication" Expert éminent https://www.developpez.com Envoyé par datalandia Envoyé par c'est pas le découpage le propre de l'informaticien mais la parallélisation...

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. 4 1 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. Nouveau membre du Club https://www.developpez.com Envoyé par hotcryx Envoyé par Les employeurs ne seront pas du même avis, ni les collègues jaloux... même si il est plus productif.

Et puis j'ai fait une description de la technique et si tu t'etais bien renseigné tu verrais que le mot pause peut être différent selon les personnes. Dans ces 5 minutes, tu peux bien aller voir le collègue qui t'a sollicité il y a quelques minutes parce que tu lui avais dit bien gentiment: "Je viens te voir dans 10 minutes", ou alors lire quelque chose d'interessant sur la tâche que tu viens d'interrompre, ou encore faire une revue de code de ce qu'a commité l'autre collègue, etc ... Par exemple rediger ce message m'a pris mes 5 minutes de pause



En tout cas, ça fait 4 ans que j'utilise la technique et ça n'a jamais dérangé personne. C'est ma manière de travailler. Si mon employeur n'est pas content, je peux gentiment m'en aller voir ailleur... Et puis cette façon de se surveiller entre collègues, c'est bien un truc frenchy ...



Et puis ça ne fait que 6 à 7h de temps de concentration et 2 heures de pauses dans une journée. Personnellement je trouve ça pas mal. 3 0 On s'en fou de ce que les autres pensent (tant qu'on est productif).Et puis j'ai fait une description de la technique et si tu t'etais bien renseigné tu verrais que le mot pause peut être différent selon les personnes. Dans ces 5 minutes, tu peux bien aller voir le collègue qui t'a sollicité il y a quelques minutes parce que tu lui avais dit bien gentiment: "Je viens te voir dans 10 minutes", ou alors lire quelque chose d'interessant sur la tâche que tu viens d'interrompre, ou encore faire une revue de code de ce qu'a commité l'autre collègue, etc ... Par exemple rediger ce message m'a pris mes 5 minutes de pauseEn tout cas, ça fait 4 ans que j'utilise la technique et ça n'a jamais dérangé personne. C'est ma manière de travailler. Si mon employeur n'est pas content, je peux gentiment m'en aller voir ailleur... Et puis cette façon de se surveiller entre collègues, c'est bien un truc frenchy ...Et puis ça ne fait que 6 à 7h de temps de concentration et 2 heures de pauses dans une journée. Personnellement je trouve ça pas mal. Membre extrêmement actif https://www.developpez.com

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. 2 0 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. Nouveau membre du Club https://www.developpez.com

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...



2 0 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... Poster une réponse Signaler un problème

