larlet-fr-david/david/blog/2016/agile-legacy/index.md

title: Agile et legacy
slug: agile-legacy
date: 2016-05-06
chapo: Pour moi cela n’est pas tant une question de temps mais de complexité et donc de taille.

> L’agilité n’est pas la panacée ms il ne faut pas pour autant tout jeter… L’excessivité dans l’IT me surprendra toujours. L’agilité fonctionne très bien pour des projets « innovants » mais ne répond pas aux cadres de projets industriels c’est pas vraiment une découverte. L’agilité a eu l’énorme avantage de remettre les dév’ au centre des projets et de reconnaître leur travail et leur compétence mais l’agilité est devenue une « religion » pratiquée sans discernement comme beaucoup de choses dans l’IT et a du coup le défaut de sa qualité.
>
> <cite>*[Gautier Poupeau](http://www.lespetitescases.net/) sur Twitter*</cite>

Est-ce que l’agilité se cantonne aux quatre à six premières itérations ? À quel moment un projet commence-t-il a être qualifié de *legacy* ou industriel ? À quel instant perd-on le côté innovant d’un projet ? **Pour moi cela n’est pas tant une question de temps mais de complexité et donc de taille.**

> Rey s’intéresse à la taille, à la mesure, à l’équilibre. “Partout où quelque chose ne va pas, quelque chose est trop gros”, explique-t-il en reprenant les arguments de Leopold Kohr. “Pour paraphraser le principe de population de Malthus, les problèmes sociaux ont la tendance malheureuse à croître exponentiellement avec la taille de l’organisme qui les porte, tandis que la capacité des hommes à y faire face, si tant est qu’elle puisse augmenter, croît seulement linéairement. Ce qui veut dire que si une société dépasse sa taille optimale, les problèmes qu’elle rencontre doivent croître plus vite que les moyens humains qui seraient nécessaires pour les traiter.”
> 
> <cite>*[Numérique : la taille, cet impensé](http://www.internetactu.net/2016/05/04/numerique-la-taille-cet-impense/)* ([cache](/david/cache/c0d076aa2ed33a6c7bfc991abdb0a091/))</cite>

Dans ma [quête de simplicité](/david/blog/2016/simplicite-defaut/), j’en viens à questionner le passage du *réactif* au *défensif* car c’est bien là pour moi l’essence de la culture agile. À un moment dans le projet, l’ajout de fonctionnalités ne permet plus de réagir suffisamment rapidement pour que cela puisse encore être pertinent. Et même en ajoutant des couches pour réduire ce temps et avoir l’impression d’être toujours dans la réaction on est passés insidieusement dans la défense. Le moment où l’on lutte *contre* un système et non plus *pour* la valeur.

La clé est à mon avis de ne pas arriver à cette taille critique en créant des outils pour cela :

* se dire que l’on va mesurer l’impact de chaque fonctionnalité introduite pour en supprimer une sur quatre au bout de x temps par exemple ;
* faire l’exercice d’imaginer une réécriture *from scratch*, que garderait-on et du coup que pourrait-on supprimer ?
* avoir des *flags* pour chaque fonctionnalité et en désactiver certaines de manière aléatoire pour analyser les impacts.

Il y aurait beaucoup de choses à imaginer pour rester à échelle agile. Les conférences/rencontres sur le sujet discutent beaucoup des côtés humains de l’agilité mais peu du code. Il n’y a pas que les relations sociales qui ne passent pas à l’échelle. **Restons petits et (im)pertinents.**