Comment éviter le gaspillage lors de l’écriture de code

Le long chemin vers la qualité est rempli de détournements, de faux départs et de détours. L’ennemi de la qualité est le gaspillage, car le gaspillage n’est jamais souhaitable. Personne ne paie personne pour livrer des déchets. Nous tolérons parfois les déchets dans le cadre du processus de fabrication de quelque chose d’utile et de désirable, mais plus nous pouvons réduire les déchets tout en fabriquant quelque chose, mieux c’est.

En génie logiciel, le gaspillage peut s’exprimer de plusieurs manières :

1. Défauts
2. Au ralenti et en attente
3. Surproduction
4. Surtraitement
5. Toute autre activité qui ne met pas directement de valeur entre les mains des utilisateurs

Examinons chacun de ces cinq types de déchets.

Défauts

Il semble y avoir un sentiment dominant dans l’industrie du logiciel que les bogues (défauts) sont inévitables. Ce n’est pas si, mais quand et combien, les bogues se retrouvent dans la production.

Vous pouvez combattre ce sentiment défaitiste en rappelant aux ingénieurs logiciels que chaque bogue a été créé. Les bugs ne se produisent pas spontanément. Ils sont créés par nous, des êtres humains essayant de faire le meilleur développement logiciel possible. Mais personne n’est parfait. Bien sûr, nous ne créons pas de bogues intentionnellement, mais ils arrivent. Ils sont souvent le résultat d’une précipitation, ou peut-être d’une éducation et d’une formation inadéquates.

Quelle que soit la raison, les bugs sont causé, ce qui signifie que nous pouvons éliminer les bogues en résolvant les problèmes qui les causent.

Au ralenti et en attente

Nos partenaires commerciaux qui financent nos efforts de développement de logiciels ont tendance à percevoir chaque fois que nous ne produisons pas de code d’expédition comme du temps passé au ralenti. Pourquoi marchons-nous au ralenti et qu’attendons-nous? C’est une question raisonnable à poser, si vous considérez qu’ils paient potentiellement des milliers de dollars de l’heure pour maintenir l’équipe en marche.

La marche au ralenti est un gaspillage. Cela ne contribue pas au résultat net et peut être un signe de confusion. Si l’équipe dit qu’elle attend que quelqu’un revienne de son congé, cela signale de faibles compétences d’organisation. Aucune équipe ne devrait jamais arriver au point où elle se retrouve dans un coin et souffre d’un seul point d’échec. Si un membre de l’équipe ne peut pas participer, d’autres membres doivent intervenir et continuer le travail. Si ce n’est pas possible, vous avez affaire à une équipe très fragile, inflexible et peu fiable.

Bien sûr, il existe de nombreuses autres raisons possibles pour lesquelles l’équipe tourne au ralenti. Peut-être y a-t-il une confusion au sujet de la priorité la plus élevée actuelle, donc l’équipe est suspendue et attend de connaître la priorité correcte.

Il existe de nombreuses autres causes raisonnables de marche au ralenti, c’est pourquoi ce type de déchets semble le plus difficile à surmonter. Quoi qu’il en soit, les organisations matures prennent des mesures de précaution pour minimiser les temps d’attente et les temps d’attente potentiels.

Surproduction

Souvent étiquetée « plaqué or », la surproduction est l’une des formes de gaspillage les plus insidieuses. Les ingénieurs logiciels sont connus pour leur propension à aller trop loin dans leur enthousiasme pour la création de fonctionnalités et de capacités astucieuses. Et parce que le logiciel, comme son nom l’indique, est très souple et malléable, il y a très peu de recul contre l’assaut du ballonnement.

Ce ballonnement épouvantable crée beaucoup de déchets. Combattre le ballonnement est l’essence même d’une discipline de génie logiciel prudente.

Surtraitement

L’un des plus gros problèmes du génie logiciel est connu sous le nom de Geek-At-Keyboard (GAK). Une idée fausse courante est que les ingénieurs logiciels passent la plupart de leur temps à écrire du code. C’est loin de la vérité. La plupart du temps consacré aux activités quotidiennes régulières (en dehors de la participation aux réunions) est consacré à des activités au clavier sans rapport avec l’écriture de code : jouer avec les configurations et les environnements, exécuter et naviguer manuellement dans l’application, saisir et retaper les données de test, parcourir le débogueur, etc.

Toutes ces activités sont des déchets. Ils ne contribuent pas à la création de valeur. L’un des remèdes les plus efficaces pour minimiser le temps GAK improductif est le développement piloté par les tests (TDD). Écrire des tests avant d’écrire du code est une méthode éprouvée pour éviter le surtraitement. L’approche du test d’abord est un moyen très efficace d’éliminer les déchets.

Autres activités qui ne mettent pas de valeur entre les mains des utilisateurs

Aux débuts de notre métier, la valeur se mesurait au nombre de lignes de code produites par unité de temps (par jour, semaine, mois, etc.). Plus tard, cette façon plutôt inefficace de mesurer la valeur a été abandonnée au profit d’un code de travail. Il n’y a pas de corrélation convaincante entre le nombre de lignes de code et le code de travail. Et une fois que le code fonctionnel est devenu la mesure de la valeur, le nombre de lignes de code est devenu sans importance.

Aujourd’hui, nous reconnaissons que le code fonctionnel est également une métrique dénuée de sens. Ce n’est pas parce que le code compile, construit et fonctionne qu’il fait quoi que ce soit de valeur. Exécuter du code avec succès peut être un traitement inepte, comme compter de 0 à 10, puis revenir à 0. Il est beaucoup plus important de se concentrer sur le code qui répond aux attentes des utilisateurs finaux.

Aider les utilisateurs finaux à atteindre leurs objectifs lors de l’utilisation de votre produit logiciel est la seule mesure de valeur. Toute autre activité qui ne contribue pas à cette valeur doit être considérée comme un déchet.