Au cours de la 4ème partie, nous avons abordé les confrontations plutôt épineuses qu’il peut y avoir entre la réalité des promesses, et la réalité du développement. Cet épisode revient sur certaines vérités au sujet de travailler plus dur et d’aller plus vite.

A: Attendez une seconde … Vous n’avez jamais parlé en fait que nous ne pouvons pas aller plus vite. Vous avez seulement dit qu’essayer plus dur ou d’ajouter davantage de personnes n’était pas la voie à suivre.

B: C’est vrai.

A: Donc nous pourrions aller plus vite, c’est possible ?

B: Tout à fait.

Pour parler franchement, nous n’avons aucune idée de la vitesse à laquelle des développeurs pourraient travailler. Un ami m’a appelé et m’a raconté avoir pris en charge un travail qui avait été estimé et de l’avoir réalisé en une matinée car le code était bien structuré, lisible et bien testé. Mon ami m’a dit “toutes les fonctions dont j’avais besoin avaient déjà été écrites et faciles à trouver”

Robert Martin dit toujours que la vitesse des travaux de développement de nos jours dépend principalement de la qualité du code sur lequel vous allez travailler. Du code de mauvaise qualité ? Vitesse réduite. Du code de très bonne qualité. Grande vitesse.

En plus, nous avons fouiné un peu partout et avons constaté que les développeurs passent environ 25% de leur temps en réunion (les plus séniors passant plus de temps). C’est 25% dès le départ.

La plupart des développeurs passent en partie le reste de leurs temps, environ 60 à 80% à corriger des anomalies. C’est un sacré bout de temps. S’ils pouvaient aller deux fois moins vite, mais en ne produisant aucune anomalie, ils iraient au moins 10% plus vite.

Par rapport au temps qu’il reste, le travail en silos, les mécanismes d’approbation dans le processus de travail et autres interruptions obligent les développeurs à passer une partie de leurs temps à attendre d’autres personnes. Le travail fait la queue dans une file d’attente.

Et bien sûr, lorsque le travail d’un développeur attend dans une file d’attente, le programmeur consciencieux reste occupé en prenant du boulot supplémentaire dans sa propre liste de choses à faire, sa propre file d’attente.

Toutefois lorsque les travaux reviennent des tests, ou de la validation, ou d’une autre forme de revue, ces travaux doivent rejoindre une file d’attente attendre que le développeur soit à nouveau disponible pour les prendre en charge. Le développeur moyen type en entreprise que nous avons pu interroger a environ 5 tâches concurrentes (ou branches) ouvertes. Cela peut monter jusqu’à 15.

Vous pouvez voir le temps se réduire à peau de chagrin. Cela n’est en aucun cas surprenant qu’un petit bout de travail puisse prend un temps infini à être développé, même si le développeur est occupé et a beaucoup de tâches en cours à n’importe quel moment.

Les développeurs disent “Je ne suis pas bloqué, j’ai plein d’autres choses sur lesquelles travailler” et c’est vrai. Mais le travail lui en tant que tel est bien bloqué. Le travail ne va pas aller suffisamment tôt en production parce que les développeurs sont occupés à faire quelque chose d’autre. C’est pourquoi les pratiquants Lean disent “regardez le bâton, pas le coureur.” L’efficacité du flux est lié au débit d’un système, non à la charge des employés.

C’est un système bordélique, rendu encore plus bordélique par des processus incluant de nombreux silos, d’efforts individuels, du travail bâclé, cycles d’approbations, de branches et je ne sais quoi encore.

La plupart de nos systèmes semblent faire plus de la prévention logicielle plus que du développement logiciel

Mais toutefois, la qualité du code est le grand déterminant. Si le code est bien organisé, et qu’un bon outillage est utilisé, et que le développeur est familier avec le système, et que le changement n’introduit pas de réarrangements architecturaux majeurs; … eh bien, quelle vitesse surprenante pourrions-nous atteindre ?

Il serait facile d’aller plus file, mais arriver là peut s’avérer être un travail acharné du point de vue humain et pas uniquement pour les développeurs.

À ce sujet :

A: Donc, comment pouvons-nous amener les développeurs à redoubler d’effort ?

B: Enlevez-leurs leur outils. Ajoutez plus de bureaucratie. Faites-leur utiliser des ordinateurs plus lents et d’anciens langages de programmation.

A: Et cela va ramener de la vélocité ?

B: Non. Vous avez demandé à comment les faire redoubler d’efforts. Ceci met en lumière un problème dans l’approche d’en faire plus. Dans la deuxième partie, nous avons fait allusion à cela. Dans mon article de 2009 intitulé Platitudes of Doom1, nous avons traité de cela en profondeur. Il y a ce postulat qui est que la raison pour laquelle le travail avance lentement c’est parce que les personnes ne travaillent pas avec assez d’acharnement.

Être focalisé sur la charge et les efforts n’est d’aucune aide.

La conversation précédente est un peu ironique mais illustre le point que le problème n’est pas dans l’augmentation de la charge et dans des efforts accrus, mais dans les résultats obtenus. La plupart des programmeurs travaillent bien plus dur qu’ils ne le devraient et créent de cette manière bien moins de valeur.

Si nous insistons à mettre plus d’effort dans le travail, nous finissons par obtenir par quelque chose qui ressemble plus à de la force brute, et non avec de meilleurs résultats comme nous pouvons espérer. Cela sera abordé de manière plus approfondie lorsque je me mettrai à l’écriture de The Journey.

A: Nous voulons qu’ils travaillent plus dur afin que nous puissions faire plus de choses.

B: Mais si vous voulez accomplir davantage, ne devriez-vous pas rendre le travail moins dur ?

A: Nous voulons juste que le boulot soit fait.

B: Bien sûr, et eux aussi..
Voici ce petit quelque chose de magique et d’intéressant. Si nous voulons que les gens puissent en faire plus, nous aurons probablement plus de chances de réussir en enlevant tout le superflu, l’incertitude, et le risque du processus, plutôt que d’y mettre de plus grands efforts et d’y mettre plus de pression.

De nouveau, dans la 3ème partie, nous avons évoqué la formule de l’effort fourni pour faire une tâche par rapport à l’effort demandé. Allez jeter un coup d’œil jusqu’au diagramme illustrant ce point et au texte associé puis revenez ici.

Cet extrait de la discussion a pour de but de simplement redire les points que vous avez déjà vu précédemment. Mais il y a une certaine probabilité que vous n’êtes pas un lecteur de longue date de ce modeste blog, perdu dans un coin sombre des vastes terres des blogueurs, donc cela vous aidera peut-être d’avoir davantage de choses à lire sur ce sujet.
À savoir :

Peut-être bien que la programmation n’est pas si lente que ça, si l’on considère l’état de la base du code et la présence du risque et de l’incertitude dans les exigences, la difficulté de prévoir l’effort intellectuel, etc.

Peut-être que les estimations sont basses au lieu de dire que le travail est lent

Nous ne savons pas vraiment.

Nous savons seulement qu’il existe une différence entre ce que nous nous attendons (et voulons) et ce que nous réalisons vraiment. Nous pouvons considérer cela comme d’une trahison, ou nous pouvons la considérer comme d’un espace de curiosité2

Je sais quels sont les choix qui mènent au blâme et à la frustration, et lesquels mène à l’alignement et à l’amélioration.

Mais je vais vous laisser méditer là-dessus jusqu’à la 6ème partie

Auteur : Tim Ottinger
Source : Q and A on Velocity, part V
Date de parution originale : 23 Octobre 2018

Traducteur : Nicolas Mereaux
Date de traduction : 15/07/2019

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

  1. en vo ↩ ↩2 ↩3 ↩4 ↩5

  2. en vf ↩