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 
Envoyé par Amnésix
.
