BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Kanban as code -- comment livrer quand c'est prêt

Kanban as code -- comment livrer quand c'est prêt

Favoris

Les retours d'expérience sur les entreprises ayant opéré une transition agile sont nombreux. Celles ayant dépassé l'agile au sens classique le sont moins. Dimitri Baeli présentera cette après-midi au Lean IT Summit 2017 le voyage des Beasties, l'IT des Furets.com. L'entreprise est exactement dans le thème du LIS de cette année : "Du Lean Startup au Lean Scale up".

Nous avons pu échanger avec Dimitri autour de l'évolution des Beastie Furets (nom que s'est donné l'équipe de développement du site LesFurets.com, présente sur le web via son blog ouvert en début d'année).

 

InfoQ FR : Bonjour Dimitri. Nous te connaissons en tant qu'Editeur InfoQ FR. En dehors de cela, que fais-tu ?

Dimitri : Bonjour, le jour je suis CTO chez LesFurets.com après 4 ans comme Development Team Capability Manager qui consistait à aider l'équipe à améliorer son organisation, tant sur l'organisation des mises en production (passage de mensuel à quotidien), de l'usine logicielle (automatisation de ... tout), de l'organisation du code (feature branching n'en déplaise à certains), de l'organisation des tâches (mise en place d'un Kanban à la mode David Anderson & Don Reinertsen), et enfin de la priorisation des fonctionalités par leur valeur potentielle plus que par leur coût.

La nuit, je fais partie de l'association Lean Kanban France qui organise depuis 5 ans la conférence éponyme, qui s'addresse aux responsables d'équipes qui cherchent à comprendre quelles sont les organisations possibles pour les équipes. Nous sommes là pour leur ouvrir les yeux, à base d'agilité, de Kanban, de Lean Startup, d'entreprise libérée, et une pointe de Lean (comme l'année dernière avec Michael Ballé).

InfoQ FR : Durant le Lean IT Summit, ta conférence s'appelle "Kanban as Code" et présente votre organisation du code pour livrer ce qui est prêt. Mais quel est l'intérêt de livrer ce qui est prêt pour les Beastie Furets ?

Dimitri : Je retourne la question "Pourquoi attendre quand c'est prêt ?" ou pourquoi, lorsqu'un développement est terminé, attendre que l'itération à laquelle il appartient soit terminée ? Ou pourquoi une tâche qui est bloquée ou en retard doit-elle mettre en retard les autres ?

Je sais bien que ce discours et l'approche est l'inverse de la planification habituelle où on cherche à réunir un maximum de tâches pour une date fixée. Nous on livre le moins possible le plus tôt possible, un peu comme "Amazon Prime".

L'intérêt de livrer ce qui est prêt est de "Commencer par finir", et ça, l'entreprise et mon patron ont bien compris que c'était une stratégie payante. En effet, nous avons la chance d'être un site qui tourne 24/24, et il est simple de comprendre que si ce n'est pas en production, ça ne risque pas de rapporter de l'argent. Si c'est prêt : on livre, et on gagne, ou on voit qu'il faut faire autrement.

Curieusement personne ne me dit, maintenant que c'est prêt on va attendre la date prévue pour livrer. C'est terminé quand c'est en production, et pas avant. Est-ce que ce principe vaut pour d'autres ? J'ai du mal à penser le contraire.

InfoQ FR : Et pour livrer ce qui est prêt, comment faites-vous, c'est quoi le "Kanban as code" ?

Dimitri : L'approche "infrastructure as code" donne aux équipes qui gèrent les serveurs la capacité de programmer les déploiements et passer d'une erreur de manipulation à une erreur dans un programme (beaucoup plus facile à repérer, à reproduire, à tester). L'idée est de tout automatiser, vraiment tout.

J'ai nommé pour cette session notre organisation du code source "Kanban as code" car chaque tâche est à l'image des cartes Kanban une entité indépendante qui représente un futur produit fini et qui va suivre un cycle de vie complet jusqu'à la production.

Pour les connaisseurs, nous sommes organisés en "feature branching", ce qui veut dire que chaque fonctionnalité est développée en isolation du reste sur une copie complète du code de production. Venez à ma présentation pour en savoir plus, je vulgariserai autant que possible.

Sans spoiler la présentation, je peux vous dire qu'ainsi chaque copie du code (aka branche), telle une carte Kanban, n'est dépendante ou ne dépend d'aucune autre tâche. Les seuls freins sont la disponibilité des personnes pour travailler dessus, et c'est déjà suffisament compliqué comme ça !!!

InfoQ FR : Le voyage pour arriver là où vous êtes semble long. Pourrais-tu retracer ce voyage vers la livraison au fil de l'eau ?

Dimitri : Pour faire simple, j'ai oublié :-) Je vois surtout le voyage qu'il reste encore à faire pour reduire la quantité de tâches à faible valeur ajoutée qu'il nous reste à faire, et les développements coûteux qu'on fait en pensant qu'ils paieront à coup sûr. Et c'est bien ça l'état d'esprit du voyage, regarder le prochain pas à faire, qu'est-il possible d'améliorer, comment fluidifier le système. Chez nous ce fût tout d'abord une simplification des livraisons (pour pouvoir en faire plus), la recette des développements unitairement plutôt qu'en lot, l'automatisation et la simplification des tests de regression (Interaction utilisateur & Graphiques), l'insolente parallelisation des développements (sujet du talk), et enfin le passage à des expérimentations et mise en place de fonctionalités de façon incrémentales (MVP, AB Tests dont chaque étape attend le résultat de la précédente en production) plutôt que de grands projets avec des hypothèses globales (disons des objectifs).

Pour la gestion du code, ce que je présente, nous ne pensions pas avoir la maturité suffisante pour passer tout d'un coup à du Trunk Based developpement (tous les développements faits sur la branche de production, et livrés en continu). Alors nous avons eu l'idée un peu folle de tout séparer et utiliser un outil pour gérer la fusion de toutes ces branches séparées automatiquement.

5 étapes si on cherche à simplifier le voyage : moderniser le monitoring, simplifier la livraison, flexibiliser les tests, paralléliser le développement, et enfin fragmenter la conception.

La suppression des itérations, et la mise en place d'une livraison quotidienne est arrivée un 2 janvier 2014 par surprise, suite à un réveillon un peu arrosé de développements expérimentaux. Demandez à l'équipe, l'amélioration continue c'est aussi pour notre organisation, une grande direction et des petits pas... ça nous suffit.

InfoQ FR : Quelles limites avez-vous rencontrées avec les formats agiles "classiques" comme Scrum ou XP ?

Dimitri : Parler de limites pour les formats agiles est trop fort, c'est notre nourriture, notre histoire, sans eux rien de tout ça n'aurait existé. Mais un peu comme les millenials ça ressemble aux anciennes méthodes (des années 2000 !). Depuis 15 ans, les systèmes et les pratiques ont évolué, nous essayons simplement d'appliquer ce qu'il se dit et se fait sur l'organisation des équipes. Je vous rappelle que la puissance des ordinateurs double tous les 18 mois, et que ce qui prenait 1 semaine de calcul en 2000 prend maintenant 10 minutes !! (6060247/2^(1512/18) = 590 secondes) sans parler de l'amélioration des outils. Il faut donc s'adapter et donner à l'ordinateur tout le travail que l'on peut.

Il n'y a aucun blocage technologique pour qu'une équipe ne puisse livrer quotidiennement, ce qui bloque c'est le poids du passé pour beaucoup d'architectures et de systèmes qui n'ont pu évoluer et se moderniser. C'est un fait, sans être une critique. Alors quand vous avez comme nous la chance et le budget pour faire évoluer une architecture qui est tout de même agée de 8 ans, vous n'avez aucune excuse et vous cherchez comment arriver à cette norme : livrer chaque jour ce qui est prêt.

Nous venons de travailler en Scrum pour un projet et ça s'est très bien passé, on a juste remarqué que la planification sur une semaine poussait à prendre des décisions un peu trop tôt sur certaines fonctionnalités, des décisions qui auraient pu attendre un peu plus. Décider le plus tard possible, c'est un super luxe et un avantage concurrentiel car ça nous permet de ne pas passer de temps inutile sur une décision qui pourrait être prise plus tard.

XP de son côté est comme les mathématiques ou la grammaire, un socle sur lequel on se repose sans même le savoir pour certains jeunes développeurs. Le TDD, le pair programming, le refactoring, le rythme soutenable, c'est notre Jidoka : l'intransigeance sur la qualité.

InfoQ FR : En pensant au terrain, quel est l'impact de la transition d'un mo(n)de agile à Lean pour les équipes ?

Dimitri : Nous sommes encore loin d'une transition Lean, c'est au mieux un guide ou une influence (ok, l'influence est assez forte à mon niveau suite à ma formation CES Lean Management avec Michael Ballé, Catherine Chabiron, Thomas Houy).

InfoQ FR : Sur une période comme celle-ci, quelles ont été les plus belles réussites et les plus grands défis ?

Dimitri : Le plus grand défi est que la transition ne se fasse pas pour la transition mais pour un bénéfice au niveau entreprise, pour l'équipe. C'est comme beaucoup le disent un choix de transformation personnelle, avec la perte des repères qui va avec. Sortir du confort des planifications à date, et sauter dans le bain du "quand c'est prêt" c'est encore aujourd'hui un défi.

Les réussites sont clairement les mises en production quotidiennes par un développeur tout seul auto sélectionné. Chaque jour l'un d'eux se propose pour faire la mise en production, voir même propose de la faire avec un visiteur qui appuie lui-même sur le bouton : "deploy".

L'autre réussite est de voir les équipes Marketing et Commerciales s'approprier les codes du continuous delivery : "merci de ne pas livrer la fonctionnalité A et la fonctionnalité B le même jour, je voudrais voir séparément l'impact avant de décider quoi faire". Ou lorsque l'on décale la mise en production d'une fonctionnalité sans entrainer de cataclysme sur les autres !

Et je suis sûr que les plus belles réussites sont à venir et liées au succès de l'entreprise plus que d'une technologie ou d'une méthode, mon travail est de transformer l'équipe IT en avantage compétitif.

InfoQ FR : Les Beastie Furets semblent avoir beaucoup innové et créé des réponses avec du tooling sur ces dernières années. Quels sont les facteurs de ce dépassement et de cette créativité ?

Dimitri : L'outillage, l'innovation, la créativité on ne les planifient pas, on s'attache franchement à résoudre les problèmes qui se posent sur notre route. "Livrer plus souvent", "Travailler en parallèle" c'était la cible car très motivant, et clairement un progrès. Ensuite on a essayé avec les outils existants, à partir de nos outils d'origine.

Au final, nous n'avons fait que de la résolution de problèmes en boucle infinie, avec des voies sans issues. Mais par et pour l'équipe, sans plan contraignant ou définition donnée par une instance supérieure externe et visant une cible imaginée de toute pièce. Notre créativité est celle qui est nécessaire pour résoudre nos problèmes, et la libérté qui va avec. Oui c'est un luxe, et oui c'est plus que rentable, je pense que les membres de l'équipe sont fiers du travail accompli, d'autant qu'il leur appartient. Et ils restent motivés pour passer à l'étape d'après : une livraison par fonctionnnalité.

InfoQ FR : Maintenant que vous arrivez à livrer tous les jours, quel est la suite pour les Beastie Furets et pour les Furets en général ?

Dimitri : Comme je viens de le dire, depuis un moment on rêve d'avoir une livraison par fonctionnalité et autant de fois que nécessaire chaque jour. Ca permettrait d'évacuer la problématique de fusionner certains travaux et relancer les tests.

Le réel objectif côté Lean est en fait de continuer notre exploration d'une pratique de la résolution de problèmes en continu, plutôt que l'exécution de plans qui sortent d'intuitions ou de fausses croyances. Si nous arrivons à passer ce cap, les challenges de la culture Data Driven, ou l'intelligence artificielle seront plus facile à gérer. Le modèle directif, basé sur le pouvoir ou l'intuition vont avoir de sérieux concurrents dans les années à venir, et nous voulons être prêts à moderniser.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT