Concepts / Practices

Connaissez-vous le concept de "pensée de second ordre" ?

Nos actions peuvent avoir plusieurs niveaux de conséquences :

• Le premier est volontaire - c’est l’objectif recherché - les suivants ne le sont pas.
• La pensée de second ordre sert à anticiper ces niveaux successifs

Dans des environnements complexes, il n’est pas toujours possible de prévoir les effets de nos actions. D’où l’importance d’analyser non seulement les conséquences de nos actions, mais aussi les conséquences de ces conséquences.

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.

❓ Comment reconnaître une tendance ?

La plupart ont une structure similaire :

1️⃣ Problème réel et solution 🤨

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 :

❝Les mauvaises estimations ne sont pas de votre faute, mais elles deviennent votre problème.❞

Exemple avec une situation que beaucoup d'entre nous ont déjà vécu :

Votre patron, votre Product Owner ou votre chef de projet ont fait des estimations et établi un planning de livraison sans impliquer les équipes responsables de la réalisation. Ils ont frotté leur boule de cristal, inventé une date et l'ont lancée aux équipes "par-dessus la clôture".

"Calculer le ROI d’un changement de pratique dans un système comprenant plusieurs dizaines de personnes, tout autant de briques techniques et des boucles de rétroaction à retardement c’est (presque) mission impossible. Pour pouvoir arriver à donner un tel chiffre, il faudrait lisser tout ça en faisant de nombreuses approximations, et, même comme ça, il serait nécessaire d’avoir accès à des grandeurs dont la plupart des entreprises n’ont pas conscience, préfèrent ignorer ou ne souhaitent pas divulguer : le coût de la non-qualité (taux de rework) et la valeur des features produites.

DevOps c’est quoi ?

Devops est la concaténation des trois premières lettres du mot anglais development (développement) et de l'abréviation usuelle ops du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires. Le mot a été inventé par Patrick Debois1 durant l'organisation des premiers devopsdays à Gand en Belgique, en octobre 2009.

Il existe cependant de nombreuses divergences dans la définition et la description du terme.

Qu'est-ce que la dette technique ?

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham en 1992.

C'est un concept de développement de logiciel qui reflète le coût implicite du travail supplémentaire causé par le fait de privilégier une solution facile à implémenter dans l'immédiat à une meilleure approche technique qui prendrait plus de temps.

Il s’agit de l’ensemble des coûts cachés qui grèvent la rentabilité d’un logiciel :