BT

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

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Méthodes Startup : Keepeek, de l'Agile au Lean

Méthodes Startup : Keepeek, de l'Agile au Lean

Favoris

Suite à nos précédents échanges avec Keepeek autour du modèle économique de cette jeune entreprise française spécialisée dans le DAM, Matthieu Joubert nous entraîne à présent dans une rétrospective de fonctionnement quotidien de l'entreprise : passage à l'agile puis au lean, continuous delivery, gestion du multi-site et gestion du Time to Market en situation de forte concurrence.

InfoQ FR : Dans la grande mode de l'Agile, comment travaillez-vous aujourd'hui chez Keepeek ?

Matthieu : Keepeek a démarré son agilité en 2009. Cette initiative est apparue après 8 mois de cycle en V douloureux. Un consultant externe - Thomas Deligny - est venu nous initier au SCRUM et nous avons pris notre envol. Nous avons démarré avec des Sprints de 3 semaines. Cela a changé notre vie de développement.

Le rythme a ensuite été ajusté. Pour la R&D, trois mois étaient un peu court pour tenir le rythme des cérémonies et des écritures de user story. Par contre, pour l’intégration chez les clients, c’était trop long. Au bout de 5 ans, nous sommes arrivés à la limite du modèle Scrum et avons fait appel à un expert Kanban, Laurent Morisseau. Nous avons basculé vers un mixte Kanban et Scrum. Le Kanban pilote les tâches d’intégrations en liens directs avec les clients. Le Scrum est dédié à la R&D. Nous pratiquons un Kanban hebdomadaire, même si aucun rythme n’est imposé par la méthode. Les tâches de la semaine sont décidées les lundi matin et matérialisées sur le tableau. Le Scrum est passé à 5 semaines avec systématiquement une mise en production à la clé. Les tâches du Scrum rejoignent le même tableau que celles du Kanban avec une autre couleur pour les différencier. Cette fusion Scrum Kanban se retrouve dans l’organisation des équipes. Les développeurs peuvent traiter indifféremment des tâches liées à la R&D et/ou à l’intégration. Ce principe de « non spécialisation » atteint cependant ses limites sur une grande équipe. Nous réfléchissons à des variantes pour séparer les deux cycles.

Nos changements d’organisation se font au rythme de notre croissance (30% par an). Ce qui marchait bien quand nous étions 10 ne fonctionne plus à 20. Nous adaptons notre démarche, essayons, et parfois faisons machine arrière si cela ne marche pas. Nous sommes néanmoins assez prudents sur les changements car nous sommes sur une chaîne de développement très industrialisée. Nous devons faire attention à ne pas trop perturber les équipes par des évolutions trop fréquentes ou trop violentes de la méthode.

 

Fig. 1 : Couplage des cycles Kanban et Scrum dans le delivery

 

InfoQ FR : Il y a également une grande vogue autour du "Continuous Deployment". Avez-vous suivi cette vague et pour quelles raisons ?

Matthieu : Nous livrons actuellement une version toutes les 5 semaines. Cette version est déployée systématiquement sur notre Cloud Privé et disponible à nos clients. Pour tenir cet objectif, nous avons mis en place certains principes issus du « Continuous Deployment ». Nous disposons d’un gestionnaire de source puissant pour assurer la gestion des branches master, release et production. Nous contrôlons ainsi ce qui va partir en production. Durant les 5 semaines de Sprint, les équipes communiquent en permanence pour savoir où « commiter » leur code en fonction de l’approche de la livraison. Nous disposons de tests et de builds automatisés pour générer les nouvelles versions. Les déploiements ne sont pas complètement automatisés, mais nous avons développé des scripts pour s’en approcher. La mise en production est plus un travail de surveillance que d’intervention manuelle. Le rythme de 5 semaines nous a imposé d’optimiser les tâches de mise en production. Il y a deux ans, il nous fallait 3 heures pour livrer sur le Cloud, aujourd’hui 20 minutes suffisent.

InfoQ FR : Etant donné votre répartition géographique, comment se passe une journée typique ?

Matthieu : Cela fait plus de trois ans que Keepeek est réparti entre Paris et Rennes. La communication régulière des équipes est donc indispensable. Notre maîtrise des méthodes agiles a été un élément déterminant pour créer une agence à Rennes. Sans cela, nous aurions sans doute échoué.

La journée démarre par un standup. Les deux équipes rennaises et parisiennes se réunissent autour des tableaux respectifs et on fait une audio conférence. Il y a deux tableaux de post-it physiques, un à Paris et un à Rennes, et on veille à ce qu’ils restent synchronisés. Les tickets ne bougent jamais pendant la journée afin d’assurer la synchronisation le lendemain matin. Le matin, chacun dit ce qu’il a fait, ce qu’il va faire et s’il a besoin d’aide sur ses tâches. Ce standup est devenu une routine optimisée. Il est rare de dépasser le délai fixé (1/2 heure). C’est certainement un signal que l’équipe a atteint un bon niveau de maturité dans la méthode.

Durant la journée, les échanges sont plus informels. Nous utilisons beaucoup la messagerie Skype. Un groupe a été créé pour toute l’entreprise et le matin, tous les collaborateurs ont pris l’habitude de dire un petit bonjour par Skype et de préciser leur niveau de disponibilité de la journée.

 

Fig. 2 : Daily devant un tableau physique sur le site parisien de Keepeek

 

InfoQ FR : Comment cela s'articule-t-il vis à vis de la gestion dans la relation avec vos demandes client et de la roadmap du produit ?

Matthieu : Nous avons réussi à combiner deux cycles qui ont deux fréquences différentes. Ces cycles correspondent assez bien au rythme de demandes des clients. Des demandes rapides gérées au fil de l’eau (correctifs, installation, évolution légère) sont traitées par le Kanban. Des rythmes plus longs pour gérer la R&D sont gérés par le Scrum.

Les rythmes de 5 semaines sont très structurants. Cette structure offre finalement beaucoup de souplesse et de transparence avec nos clients. Nous sommes capables de savoir quand une nouvelle fonctionnalité va voir le jour. Nous pouvons nous engager plus honnêtement sur des délais de mise à disposition. Ces cycles engagent aussi les clients dans leur choix de prendre part au développement d’une fonctionnalité nouvelle. Ils savent qu’il faut au moins un Sprint pour une évolution, et qu’un retard dans la prise de décision peut décaler la livraison de 5 semaines supplémentaires.

Notre roadmap est construite à partir de briques de 5 semaines. Nous visions un enchainement court de petites versions plutôt qu’un plan quinquennal et une sortie de version une fois par an. Notre roadmap est facilement ajustable d’un Sprint à l’autre. Il faut cependant prendre garde à la dispersion. Ces cycles itératifs sont un terrain favorable aux « fonctionnalités prototypes », qui finalement ne sont jamais vraiment abouties.

Ce rythme est un vrai battement de cœur pour toute l’entreprise. Tout le monde est engagé dans ce processus : la Direction Technique, mais aussi le support, les chefs de projet, les commerciaux et la communication. Il faut bien sûr développer mais pas seulement. Il faut spécifier finement, tester, déployer, communiquer, documenter et faire un webinar de présentation des fonctionnalités etc…

InfoQ FR : Comment évaluez-vous l'apport de votre démarche d'agilité pour vos clients ?

Matthieu : On va différencier les deux approches.

Pour le SCRUM :

  • Les clients existants bénéficient d’une mise à jour par mois de leur environnement de façon automatique. Ces versions sont suffisamment légères pour ne pas perturber l’expérience utilisateur. Ces nouveautés sont accompagnées de la documentation, d’une présentation gratuite (webinar), parfois d’une vidéo. C’est une sorte de formation continue au DAM Keepeek.
  • Pour les nouveaux clients, les cycles de 5 semaines structurent les étapes de mise en place et le déploiement des fonctionnalités nouvelles.

Pour le KANBAN :

Cette méthode permet de gérer les tâches courtes et les urgences. Elle donne également une bonne visibilité sur les tâches en attente (de notre fait ou celui du client). Elle force à trouver une solution rapide et à évacuer du « tuyau » les sujets dormants. Elle permet également aux chefs de projets de savoir si leurs demandes vont être traitées dans la semaine ou pas.

InfoQ FR : Quels liens faites-vous entre vos choix techniques et vos choix de pratiques ? Comment se renforcent-elles et qu'impliquent ces couplages en termes de dépendances sur le long terme ?

Matthieu : L’intégration continue a un impact sur nos architectures. Elle pousse au découplage au niveau des sources, ainsi que sur les dépendances des différentes couches. Le développement d’une nouvelle fonctionnalité peut impliquer la création d’une branche temporaire, ou simplement la mise en place d’un « feature flipping » pour activation. Notre architecture SOA est de plus en plus mise à l’épreuve par l’agilité. De plus en plus de composants viennent l’utiliser (plugin externes, intégration clients, …) et nous devons être très vigilants à la compatibilité ascendante.

Sur le plan purement technologique, nous conservons nos choix initiaux et notamment Java. Il est probable que de nouvelles technologies avec compilation à la volée ou interprétées se prêtent mieux aux développements agiles. Avec une quinzaine de développeurs et des centaines de milliers de lignes de code, nous préférons sécuriser nos développements au moins sur les couches basses. Nous sommes amener à utiliser des technologies plus récentes (node.js ou angular) sur des couches plus hautes. Pour nous, l’agilité c’est aussi cette capacité à faire cohabiter astucieusement du code legacy avec les dernières technologies à la mode.

InfoQ FR : Vous semblez avoir un TTM impressionnant. Comment envisagez-vous d'évoluer dans les mois ou années à venir ?

Matthieu : Notre marché est ultra dynamique. Nous sommes obligés de proposer des évolutions et des améliorations. Ce n’est plus un avantage compétitif que d’être réactifs, c’est une question de vie ou de mort. Nous sommes aujourd’hui à des livraisons mensuelles et nous travaillons pour réduire les délais. Les équipes techniques sont très outillées pour développer, tester et livrer du code rapidement. Les autres (product owner, marketing, ventes, support…) doivent trouver également leurs outils pour assurer la continuité de la chaîne. Cela ne sert à rien de livrer une fonctionnalité rapidement si personne ne sait qu’elle existe ou qu’aucune documentation permet de l’utiliser. Nous travaillons beaucoup sur notre management d’équipe pour renforcer notre efficacité et notre agilité. Nous formons nos collaborateurs aux bonnes pratiques de communication afin de fluidifier les chaînes de décision. Notre séminaire de rentrée en septembre 2015 a d’ailleurs été l’occasion de former toute l’entreprise. Nous nous sommes faits accompagner par une équipe externe spécialisée (Cédric Watine et Lorry Hanne - http://www.outilsdumanager.com/). Ces nouvelles pratiques de management d’entreprise sont les étapes naturelles (et indispensables) en complément de l’agilité.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT