Sans Agilité

"Cycle" en Racine Carrée ou la Caricature à Éviter
Le client exprime son besoin
avec une phrase...
Je veux une application mobile pour un réseau social avec du rouge en couleur dominante.
Rendez-vous dans 6 mois.
... ou pire encore, avec un cahier des charges.
3 mois plus tard...
Retards.
Client déçu par la version beta.
Trop tard pour tout remettre en question.
Tensions avec le client et au sein de l'équipe.
Le "lead developer" quitte l'entreprise.
3 nouveaux développeurs rejoignent l'équipe en renfort.
Le renfort ralentit encore plus l'équipe.
Cycle en racine carrée de Michel ARBOI


Not Agile
Coût du changement
Avec le cycle en V, le coût du changement augmente au fil du temps à travers le Software Development Life Cycle.
Il est donc plus difficile et plus cher de remédier à une erreur de conception à la livraison qu'au début des développements.
De même, sans méthode de développement, plus le développement avance, plus le code devient complexe et plus le changement est coûteux.
​
Cost of change
Conséquences
Conséquences Générales
🐢 Time to Market trop long.
⌛️ Les délais ne sont pas respectés et le retard est découvert tardivement car la vélocité de l'équipe est rarement mesurée.
😖 Inadéquation par rapport au besoin.
🐞 Problèmes de qualité.
Conséquences Intermédiaires
🙈 Manque de visibilité sur l'avancement.
🏓 Pas de feedback des clients et utilisateurs.
😰 Décisions maladroites dans la panique et augmentation exponentielle du stress à l'approche des deadlines.
Conséquences Intermédiaires Techniques
🙀 Peur du changement.
🤕 Développement empirique.
🤯 Complexité artificielle (i.e. : développement inutile ou inutilisable).
👩‍🚒 L'équipe est débordée par la correction de bugs.
La correction d'un bug en provoque un autre.
🚇 Effet tunnel: Plusieurs fonctionnalités en cours de développement mais aucune de finalisée.
👹 Integration Hell.
Causes
⚽️Absence de Collective Ownership.
🗜Absence d'intégration continue.
📦Absence de livraison continue.
🎯Manque de propagation et de compréhension de la vision.
📝Manque de conventions et pratiques de développement.
📈HiPPO (Highest Paid Person’s Opinion), Ego-Driven Decision et Tradition-Driven Decision au lieu de Data-Driven Decision.
Le paradoxe des spécifications
L'objectif principal de la rédaction de spécifications est de réduire les risques.
Paradoxalement, dans la plupart des cas, cela finit par augmenter le risque et le coût au lieu de les réduire.
Inconvénients de la rédaction de spécifications
⌛️ Perte de temps avant l'implémentation de la première fonctionnalité.
🥊 Incompréhensions et conflit à la livraison / validation.
🤷‍♂️ Déresponsabilisation de l'équipe de développement car de nombreux choix sont figés par les spécifications.
💰 Le rapport valeur vs. coût de chaque fonctionnalité est rarement (ou difficilement) pris en compte.
📜 Péremption des spécifications : Les besoins et contraintes ne sont probablement plus les mêmes entre le moment de la rédaction des spécifications et lors du développement de l'application.
🥇 Problèmes de priorisation.
🤯 Over-thinking et Analysis Paralysis.
​