Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

100PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de MadiPoupou
Membre régulier https://www.developpez.com
Le 07/05/2018 à 9:48
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
7  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 07/05/2018 à 10:06
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...
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 07/05/2018 à 12:00
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).
4  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 07/05/2018 à 15:08
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.
5  1 
Avatar de Jitou
Membre averti https://www.developpez.com
Le 14/05/2018 à 9:22
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.
4  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 14/05/2018 à 14:50
Citation Envoyé par Amnésix Voir le message
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 .
Un exemple éclatant de la formidable réussite des open space qui étaient censés "élargir la bande passante de communication"
4  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 07/05/2018 à 15:37
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.
4  1 
Avatar de fayabobo
Nouveau membre du Club https://www.developpez.com
Le 09/05/2018 à 10:53
Citation Envoyé par hotcryx Voir le message
Les employeurs ne seront pas du même avis, ni les collègues jaloux... même si il est plus productif.
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 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 
Avatar de hotcryx
Membre extrêmement actif https://www.developpez.com
Le 07/05/2018 à 10:40
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.
2  0 
Avatar de fayabobo
Nouveau membre du Club https://www.developpez.com
Le 07/05/2018 à 10:57
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...

2  0