J’ai participé au Lean Kanban France 2016. Parmi les sessions auxquelles j’ai assisté, celle de Gojko Adzic fut très intéressante.
Gojko Adzic (@gojkoadzic) est bien connu dans la communauté Agile pour son livre sur l’Impact Mapping. Cette fois-ci, Gojko nous a parlé de la livraison en continu, ou surtout des conséquences néfastes que pouvait déclencher trop de livraisons. A travers divers exemples, il nous incite à réfléchir et nous livre ses propres règles.
Le titre de sa présentation :
Turning continuous delivery into competitive business advantage
Transformer la livraison en continue en un avantage compétitif
Table
Un nouveau Business Modèle, le logiciel gratuit systématique
Plus nous délivrons, plus nous changeons les attentes des clients.
Prenons quelques exemples :
Tesla a pris l’habitude de mettre à jour le firmware de ses véhicules régulièrement. Un jour, ils ont actionné des éléments physiques (hardware) présents seulement sur les modèles récents : huit caméras, un radar, des capteurs d’ultrasons, …. La version 8.0 du firmware a ainsi offert des fonctionnalités de pilotage automatique nouvelles. La communication n’ayant pas été faite en amont, les propriétaires d’anciens modèles se retrouvaient ainsi avec une différence significative pour la première fois. Ils ont donc lancé une pétition sur change.org pour demander à Tesla une mise à jour matérielle gratuite !
Il est presque de même pour Microsoft et son célèbre système d’exploitation. La mise à jour vers la dernière version, Windows 10, est ainsi devenue gratuite, malgré les changements majeurs apportés.
Aujourd’hui, l’économie du logiciel n’a plus aucun sens. Les mises à jour fréquentes habituent les clients-utilisateurs. Les obtenir gratuitement devient ainsi un dû. Il devient donc difficile de vendre du logiciel. Il est beaucoup plus facile de vendre de la capacité comme le fait Dropbox par exemple.
Qui décide quand ce sera délivré ?
Aujourd’hui, ce sont les fournisseurs qui imposent leurs mises à jour. Quand bien même je n’ai pas besoin d’une nouvelle version qui inclut la traduction en hongrois, il faut quand même que je l’accepte car elle cache peut-être une évolution côté serveur (backend) qui génèrera des bugs. Dans certains cas, l’utilisateur ne peut même plus décider s’il accepte ou non la mise à jour.
Gojko raconte que lors d’un déplacement en Australie, il avait souscrit à un forfait wifi peu cher qui devait couvrir largement les quelques transferts qu’il comptait faire. Or son forfait a été complètement cannibalisé par une mise à jour de Windows qu’il n’avait pas demandé et encore moins accepté.
Ces livraisons fréquentes changent fondamentalement l’intérêt du client. Les évolutions sont tellement mineures qu’elles ne donnent plus lieu à des articles même dans les journaux spécialisés.
On en regretterait presque le temps où le DevOps n’existait pas :
© Commit Strip
Gojko utilise une autre mésaventure pour illustrer les dangers des mises à jour trop fréquentes. En consultant ses comptes Paypal, il découvre un manque important. Ayant refait ses comptes, il ne comprend pas l’écart indiqué. Soudain, il remarque une bannière lui demandant son avis sur le nouveau tableau de bord. En bon développeur, il soupçonne le bug et choisit de re-passer sur la version précédente du tableau de bord. Et là, comme par miracle, tous les comptes sont à jour. La dernière version était bien fonctionnelle mais uniquement pour les clients utilisant une seule monnaie, pas pour ceux ayant plusieurs monnaies sur leurs comptes ! L’appréciation qu’il a mise dans le formulaire de notation fut donc en rapport avec l’effroi suscité par la perte temporaire de son argent.
Il faut donc faire très attention aux effets de bord sur les ventes, le marketing, le droit.
Trois règles pour la livraison en continu
Gojko formule ainsi 3 règles de la façon suivante :
La livraison en continue ne doit pas :
- Provoquer des confusions chez les utilisateurs
- Interrompre le travail ou la session en cours
- Perturber ou entraver les initiatives du marché
Le déploiement n’est pas la publication !!!
Le déploiement est une action du développement qui consiste à mettre le logiciel en production. La publication se fait avec une perspective Marketing pour obtenir des impacts ! Elle répond à la question du pour qui, pour quoi.
La livraison en continu n’est qu’un moyen technique de réduire les risques.
On doit décider de faire paraître :
- Pas du tout
- Pour un ensemble particulier de personnes
- Pour tout le monde
C’est comme cela que Facebook est particulièrement instable en Australie. L’Australie possède en effet l’avantage d’être un pays anglophone et pas trop peuplé. Comme les problèmes n’affectent qu’un nombre réduit de personnes, Facebook l’utilise donc fortement pour ses tests, au détriment des utilisateurs !
La livraison en continu sans système de versions variées est irresponsable.
Les meilleures compagnies ont tort la moitié du temps. De nombreuses User Stories sont supprimées une fois le produit mis en production. Ainsi, l’histoire des 40 nuances de bleu : Google a souhaité changer la couleur du lien dans le navigateur. Quarante variantes de bleu ont été testées auprès de quarante types d’utilisateurs. Il s’est avéré que ce n’était pas une bonne idée : il n’y avait aucun moyen d’en générer des bénéfices !
Conclusion
Tels les règles des robots, Gojko conclue avec trois leçons à retenir :
- Dissocier le déploiement de la publication
- Utiliser la force, mais ne pas forcer l’alimentation
- Donner à 2% des utilisateurs une solution à 100% au lieu de 2% du périmètre à 100% des utilisateurs.
En attendant la publication de la vidéo officielle, retrouvez Gojko Adzic dans conférence similaire à Agile Singapour.