Software Development

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 :

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.

"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.

"Faire pousser le logiciel revient à adapter le processus de développement à la nature même de celui-ci : versatile, flexible, facile à mettre à jour. Cet état d’esprit est primordial et se retrouve dans la façon de travailler de chaque membre de l’équipe : au lieu de définir tous les paramètres dès le début, on favorise l'évolution et l’adaptation au fil du temps."

Développement Agile : faire pousser le logiciel plutôt que le construire - Jean-Pierre LAMBERT

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.

Ressources

FR

CQRS, l’architecture aux deux visages (partie 1)

https://blog.octo.com/cqrs-larchitecture-aux-deux-visages-partie-1/

CQRS, l’architecture aux deux visages (partie 2)

https://blog.octo.com/cqrs-larchitecture-aux-deux-visages-partie2/

CQRS PATTERN

https://blog.eleven-labs.com/fr/cqrs-pattern/

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces expériences nous ont amenés à valoriser :

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 :