> For the complete documentation index, see [llms.txt](https://guide-agile.wishtack.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide-agile.wishtack.io/sans-agilite.md).

# 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](/files/-LHD98WQBpPknOsT-lrE)

<br>

![Not Agile](/files/-LLvXvFbeIzow1TN3UtK)

## 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](/files/-LHD9u399Y213M0cYU0e)

## Conséquences

### Conséquences Générales

* **🐢&#x20;*****Time to Market*****&#x20;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](/extreme-programming/pratiques-de-l-extreme-programming.md#collective-ownership).
* **🗜**Absence d'[intégration continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/integration-continue.md).
* 📦Absence de [livraison continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue.md).
* 🎯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.
* **🤯&#x20;*****Over-thinking*****&#x20;et&#x20;*****Analysis Paralysis***.

###