Comme toujours en informatique, il n'existe pas de solution miracle... c'est une question de contexte et de compromis. 😉
Chaque solution amène ses avantages et ses inconvénients, il est important de comprendre les différences pour identifier la solution la plus adaptée. (Voir source)
➤ Pour résumer :
👉 Envisagez les bases de données SQL lorsque…
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.
Petit rappel des 4 valeurs et 12 principes 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 :
Lorsqu'un certain nombre de conditions ne sont pas remplies (connaissance de l'application, pratiques d'ingénierie, culture, …), il est fréquent que notre intention de mettre en place une architecture "microservices" donne, en réalité, naissance à un monolithe distribué.
Car nous avons les inconvénients des 2 architectures sans les avantages :
Vous développez un nouveau produit et envisagez de mettre en place une architecture "Microservices" ?
Malgré des avantages indéniables, elle pourrait ne pas être adapté, peut-être devriez-vous plutôt privilégier une architecture monolithique... 🤔
Recommander une architecture monolithique de nos jours risque de m'attirer les foudres de certains mais comme souvent, il n'existe pas de solution miracle, c'est une question de contexte et de compromis.
Vous connaissez le manifeste agile mais savez-vous par qui il a été écrit ? 🤔
Il a été rédigé par 17 experts du développement logiciel.
Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide.
Comme d'habitude dans la vraie vie, ce n'est ni tout noir ni tout blanc. L'environnement du projet est déterminant dans le choix de l'approche.
👉 Pour les projets parfaitement prévisibles (zone "Simple") : Waterfall
Vous avez du mal à comprendre la différence entre les rôles de "Product Manager" et de "Product Owner" ?
(Cet article est destiné aux organisations mettant en œuvre Scrum.)
C'est un chef de projet. Ce rôle n'existe pas dans une équipe Scrum. Ses responsabilités sont réparties entre les membres de l'équipe (PO, Scrum Master, Developers).
C'est un ensemble d'activités quels que soient le contexte et les pratiques/méthodes (Cycle en V, agile, ...)
Par exemple :
C'est une question qui revient fréquemment au cours de mes interventions auprès de startups/porteurs de projet. Beaucoup de fondateurs rencontrent des difficultés pour comprendre ce rôle. 🤔
A vrai dire, ce n’est pas étonnant, il existe tellement de nuances qu'il est difficile d'établir une fiche de poste universelle pour ce rôle. 😅
Vous êtes à la recherche de métriques pertinentes pour votre organisation ? 🤔
L'approche Evidence-Based Management (EBM) devrait vous intéresser.
EBM est une approche empirique basée sur des expérimentations intentionnelles et des preuves. C'est un excellent moyen d'identifier des indicateurs pertinents basés sur les résultats et non, comme la plupart du temps, sur les activités ou les productions.
