Développement Agile : faire pousser le logiciel plutôt que le construire

On compare souvent la création d’un logiciel à un processus de construction, par exemple à la construction d’une maison. Je vous propose d’explorer une autre analogie bien plus appropriée : celle de faire pousser, comme on fait pousser une plante ou un arbre.

La construction de logiciel est un terme utilisé très couramment par de nombreux outils comme les compilateurs ou les chaînes d’intégration et de livraison continue. La reproductibilité est au coeur de ces outils : en l’absence de changement, ils doivent impérativement générer le même résultat. On parle d’ailleurs d’usine logicielle.

Il ne faut cependant pas confondre ces outils avec le processus de développement, que l’on peut aussi appeler travail d’architecture ou encore conception logicielle. Pour le coup, le processus de développement agile partage plus de points communs avec l’action de faire pousser une plante qu’avec celle de construire une maison.

En effet, parler de construction correspond tout à fait à l’approche traditionnelle en cascade ou en cycle en V :

• On définit en amont ce qui sera construit, et comment cela sera construit
• On procède étape par étape, en se concentrant sur des composants et en laissant l’intégration pour la fin
• Globalement, cela fonctionne parce que le sujet est très bien connu et hautement reproductible

À l’opposé, le développement logiciel nécessite généralement des méthodes Agile ou a minima des méthodes de développement incrémental et itératif. Dans ce cas-là, faire pousser correspond beaucoup mieux :

• On ne sait pas avant de commencer à quoi ressemblera le résultat final ; tout le processus de développement s'adaptera en cours de route
• On va essayer de faire fonctionner le plus tôt possible un scénario de bout en bout afin de pouvoir collecter rapidement des retours
• Globalement, cela fonctionne parce que le processus accepte et prend en compte le fait que l’on ne sait pas où l’on va

Construire VS. faire pousser : une question de mindset

Au quotidien, on peut parler de mindset : la différence entre construire et faire pousser est très profonde.

Retarder la prise de décision

Dans une approche où l’on construit un logiciel, l’idée est de définir le maximum de facteurs le plus tôt possible. À l’inverse, dans une approche où l’on fait pousser le logiciel, on va plutôt essayer de prendre le maximum de décisions le plus tard possible.

Cette différence fondamentale se reflète dans tous les corps de métiers :

1. Le développeur

Le développeur, plutôt que de concevoir une architecture principalement destinée à répondre au besoin connu dès le début du projet, va favoriser une architecture qui pourra évoluer au fil du temps et s'accommoder de changements de besoin.

C’est ainsi qu’il va favoriser des grands principes comme YAGNI (You Aren’t Gonna Need It - “Vous n’en n’aurez pas besoin”) qui consiste à ne coder que le strict minimum pour le besoin connu aujourd’hui, ou encore le Design Émergent, où l’architecture est conçue au fil de l’eau via l’émergence des solutions plutôt qu’en prévoyant en amont à quoi pourrait ressembler l’architecture.

Plus globalement, c’est bien la capacité d’adaptation du code qui prime avant tout. Il n’est pas utile de prévoir des points d’extension partout dans le code (car YAGNI !) mais il est essentiel de pouvoir remplacer individuellement chaque morceau de code pour faire face aux besoins futurs.

Conséquence directe : les changements radicaux et fréquents de direction du produit peuvent être pris en compte sans que cela ne soit un cauchemar pour le développeur. Tout est fait pour pouvoir suivre les évolutions du besoin.

Dans une approche où l’on fait pousser le logiciel, le développeur va favoriser une architecture qui pourra évoluer au fil du temps et s'accommoder de changements de besoin.

2. Le Product Owner / Product Manager

De la même manière, le Product Owner (ou le Product Manager selon votre organisation) va adapter sa manière de travailler. Plutôt que d’imaginer une solution hypothétiquement idéale dès le début du projet, il va partir sur une solution minimale qui permet de sonder le besoin (le fameux MVP) puis itérer dessus à partir des retours continus des utilisateurs.

Au quotidien, le PO/PM va concevoir des fonctionnalités les plus petites possibles et les tester avant de les faire évoluer -- les faire pousser.

Le mot d’ordre est bien de se dire “vous ne savez rien” : la seule vérité est entre les mains des utilisateurs. Il faut donc trouver le moyen de toucher ces utilisateurs le plus vite possible - tout comme une graine va essayer de capter le soleil au plus vite avant de se renforcer et réellement grandir. Sans retour utilisateur, vous travaillez dans le vide : vous utilisez votre énergie limitée pour aller dans une direction qui ne sert peut-être à rien.

Cette approche s’applique-t-elle à tous les cas de figure?

Vous vous demandez peut-être si cette approche ne s’applique qu’au développement de site web et autres applications destinées à nos ordinateurs et téléphones.

Pour répondre à cette question, regardons de plus près ce qui se cache derrière le mot logiciel...

Le logiciel, omniprésent dans notre quotidien

Vous avez certainement déjà entendu cette célèbre phrase : “Software is eating the world”

À chaque année qui passe, cette phrase continue d’être toujours plus vraie : le logiciel est partout. Aujourd’hui, tous les appareils électriques sont pilotés par un microprocesseur et du logiciel. Les appareils qui autrefois n’étaient que mécaniques sont désormais remplacés par des bijoux de technologie avec en leur coeur du logiciel.

Il y a une excellente raison à cela : écrire du logiciel est devenu nettement moins coûteux, justement parce que cela permet une flexibilité sans précédent. Même si une fois en production le code ne changera jamais -- en termes techniques : le firmware de l’appareil ne sera jamais mis à jour -- le coût du développement de la logique de l’appareil avant sa mise en production se retrouve réduit drastiquement par l’utilisation de logiciel.

Sans l’ombre d’un doute, faire pousser du logiciel plutôt que de le construire s’applique à toutes les sortes de logiciels, et pas uniquement ceux destinés à nos ordinateurs et téléphones.

Apprenez-en plus sur le testing agile

Une révolution : la généralisation de la flexibilité du logiciel

Et cela ne s’arrête pas là ! Depuis longtemps la CAD (computer-assisted design) ou CAO en français (conception assistée par ordinateur) permettent de concevoir un objet physique sous une forme numérique, et donc de pouvoir itérer dessus rapidement et à faible coût. Plus récent, l’impression 3D permet de continuer cette approche et de la mener encore bien plus loin : faire des prototypes, collecter des retours utilisateurs et itérer est devenu abordable et accessible.

Rappelons d’où vient la distinction entre soft- et hard- ware : il est facile de changer le logiciel (software) contrairement au matériel (hardware). Finalement, grâce à l’impression 3D, le matériel devient du software, qu’on peut changer facilement.

Dit autrement, les approches de développement à l’origine adaptées au logiciel sont désormais naturellement adaptées à la conception d’objets physiques : il ne fait aucun doute que désormais il faut privilégier l’approche de faire pousser plutôt que celle de construire.

Conclusion : favorisez l’adaptation plutôt que le suivi d’un plan

Finalement, 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.

Comment s’y prendre en pratique ? Le second article se concentre sur la mise en place concrète dans vos projets et produits.