Le "Software Craftsmanship" fait partie de ces buzzwords du moment… "Craft" par ci, "Craft" par là… 🤦♂️
On le trouve très fréquemment associé à des pratiques telles que TDD, Clean Code, BDD, …
Malheureusement, comme pour beaucoup d'effets de mode, le terme a perdu de son sens avec sa popularisation (et son merchandising 😅)
⚠️ Le "Craftsmanship" ce n'est pas un package de pratiques sur étagère, c'est une philosophie, un état d'esprit.
🚨 La qualité ne doit pas être une variable d'ajustement dans vos projets. 🚨
Nous savons depuis plusieurs décennies que, sauf dans de rares cas (prototype ou dette technique contrôlée), la qualité logicielle ne doit pas être négligée.
⚠️ Rogner sur la qualité n’a aucun sens tant la vélocité à moyen et long terme des développeurs est abaissée.
Il n’existe donc que deux solutions pour produire des logiciels (fiables 😉) :
Connaissez-vous le "Deadline Driven Development" ("Le développement piloté par les échéances") ?
C'est un "double maléfique" 😈 de la philosophie agile, une pratique Agile Canada Dry ("Ça a la couleur de l'agile, le goût de l'agile… mais ce n'est pas de l'agile")
Voici son manifeste :
Nous découvrons comment développer des logiciels de manière acharnée en prétendant que nous sommes agiles et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :
Tout change dans le logiciel…
Le problème n'est pas le changement, car il va forcément se produire.
Le problème, c'est plutôt notre incapacité à faire face au changement.
Saviez-vous que la complexité accidentelle peut fortement impacter la croissance de votre entreprise ?
❓ Qu'est-ce que la "complexité accidentelle" ?
La complexité d'un logiciel peut être décomposée en 3 parties :
1️⃣ Complexité essentielle
Complexité directement liée au problème métier que l’on cherche à résoudre. Un système de livraison multimodale n’a pas la même complexité qu’un blog personnel en ligne. Les complexités essentielles de ces deux projets sont différentes.
2️⃣ Complexité obligatoire
Ecrire des tests, ça prend trop de temps ! 😅
Comment écrire des tests unitaires de qualité ?
Aidez-vous des principes F.I.R.S.T.
Le développeur ne doit pas hésiter à exécuter les tests unitaires à tout moment de son cycle de développement, même s'il existe des milliers de tests unitaires. Ils devraient fonctionner et montrer la sortie souhaitée en quelques secondes.
C'est lorsque les décisions à propos d’architectures logicielles ou de stack technique sont prises sur des avis biaisés, les médias sociaux, et plus généralement les tendances, plutôt qu’en faisant des recherches solides et en considérant l’impact sur le projet.
La plupart ont une structure similaire :
Une équipe rencontre un pb pour lequel aucune solution n'existe. Elle décide de créer un nouvel outil / librairie / paradigme pour résoudre ce pb.
Vous souhaitez accélérer le développement ?
Mais recruter davantage de développeurs est-il vraiment pertinent ? 🤔
⚠ Dans la majorité des cas, le facteur limitant d’une équipe n'est pas l'écriture du code. Augmenter le nombre de développeurs dans une équipe dont le goulet n’est pas la phase d’écriture du code revient à accentuer ses problèmes.
Les pb de productivité de l’équipe trouvent fréquemment leur origine dans les activités suivantes :
L'aventure STRADA touche à sa fin après 3 belles années de multiples challenges.
Je quitte une société reconnue dans son domaine qui a entamé un virage important. Beaucoup de défis, de travail, de certitudes et d'interrogations. Un contexte exigeant et très formateur. Une expérience extrêmement enrichissante.
Comme l'a écrit Karim Berrouka "La fin d'un voyage est toujours le début d'une aventure".
Dans mon cas, cette nouvelle aventure c'est l'exercice de mon activité de "Agile Leader / Software Craftsman" en indépendant.
