Pascal Rieux
Transcription
C'est le track de la salle Toulouse ici, puisque Nicolas, précédemment, vient de cette ville aussi.
Je vais vous parler d'organisation. Je vais vous raconter une histoire, une partie de l'histoire d'une organisation qui était un service de R&D. Chez Sierra Wireless, qui développe un produit. Je vais en parler plus précisément. Et comme souvent dans les histoires qu'on peut lire dans des livres, en tête, il y a un certain nombre de citations, donc souvent une citation en début d'ouvrage, voire une citation en début de chaque chapitre. Je ne vais pas faillir à cette pratique et commencer par une citation qui est la loi de Conway. Certains la connaissent peut-être. Il y en a qui la connaissent, la loi de Conway, parmi vous. Donc la loi de Conway, ce n'est pas vraiment une loi, c'est plus un constat qu'une loi. Signifie qu'une organisation, donc la structure d'une organisation, se calque sur la structure du produit qu'elle développe.
Donc il y a un parallèle qui est fait entre l'architecture d'un produit qui est développé et la structure de communication à l'intérieur de l'entreprise. Conway a édité... cette loi dans un article il y a quelques années déjà, puisque ça date de 1968, et c'est basé sur sa propre expérience en tant que développeur informatique à l'époque.
Et c'est une chose qu'on peut retrouver encore aujourd'hui assez souvent.
C'est quelque chose, entre autres,
qu'on retrouve et qu'on a retrouvé au sein du service dans lequel je travaille.
Je vais parler de structure et je vais parler d'évolution de structure, à la fois structure de produit et structure d'organisation.
Donc dans une organisation, l'écran est un petit peu... Il y a moyen de régler le zoom différemment.
Sinon, on risque de perdre un peu d'informations.
Non, mais il y a une touche zoom.
Je suis dans la limite, je pense.
C'est bien.
Donc en fait, l'histoire que je vais vous raconter, c'est l'évolution en parallèle de la structure de l'organisation et de la structure du produit que cette organisation conçoit. Donc je vais vous présenter deux grandes étapes, le départ et l'arrivée. C'est-à-dire, grosso modo, il y a trois ans, dans quelle situation on se trouvait en termes d'organisation et de produits, et la situation courante, celle d'aujourd'hui.
Donc, au départ, la société dans laquelle je travaille, donc Syrah Wireless, concevait une plateforme de services qui s'appelle Arvantage, sur laquelle viennent se connecter des objets, des boîtiers communicants, via des systèmes GSM, 2G, 3G, voire 4G aujourd'hui. Donc ça, c'était ce qui était développé il y a 3-4 ans. Aujourd'hui, ce qui est développé,
C'est la même chose, on continue à développer ce produit, mais on l'a amélioré. En trois ans, on peut espérer que ce produit s'est amélioré. On a aussi amélioré la façon dont on le développe. On a agi à la fois sur la structure du produit et la structure de l'organisation.
Donc dans un premier temps, je vais vous expliquer ou vous montrer la façon dont c'était organisé, à la fois en termes d'organisation et de produits. Et dans un second temps, je vous montrerai l'état actuel du produit et de l'organisation. Puis nous verrons... Comment sont mises en place les différentes évolutions, par quels moyens, avec quels outils, et quelles sont les perspectives à partir d'aujourd'hui. Donc précédemment, Le produit était constitué grosso modo de trois couches.
Donc une couche composant bas niveau, base de données, communication avec les boîtiers communicants, Une couche métier, qui gérait les règles métier et la communication via des API avec des applications tierces. Et puis une couche interface utilisateur. Donc une organisation assez classique en termes d'architecture produit. Parallèlement à ça, donc ça c'est la structure du produit, rappelez-vous la loi de Conway, structure du produit en trois couches. Parallèlement à ça, on avait trois équipes. Donc une première équipe qui s'occupait d'architecture, de travail sur les composants bas niveau, et de communication, tout ce qui est communication avec les systèmes communicants, avec les boîtiers communicants. Première équipe. Deuxième équipe qui gérait toute la partie back-end, logique métier et API. Et puis une troisième équipe, spécialiste en interface utilisateur, qui développait l'interface utilisateur. Vous voyez une division en strates techniques.
Qui prévalait à cette date. En plus de ces trois équipes, deux entités extérieures, à la frontière rouge, qui est le service de R&D dont je vous ai parlé au tout début, s'occupaient pour une de ces équipes d'administrer la plateforme, puisqu'on fonctionne en mode hébergé, et une deuxième équipe externe, toujours à l'équipe de R&D, s'occuper de la validation. Donc une équipe de QA assez classique.
de manière dynamique, comment ces équipes étaient organisées, donc par rapport à une roadmap, édictée par le marketing,
les trucs à faire, le stuff, passer de backlog en backlog, donc un backlog de produits au départ, puis un backlog de sprint, puis un backlog de sprint par équipe, puisqu'on avait trois équipes, Puis un backlog de validation, pris en charge par l'équipe de validation, externe à l'équipe de développement. Et enfin, un backlog de trucs mis en production.
Les activités, assez classiquement, c'était de l'estimation. Il fallait, pour pouvoir prédire ce qu'on allait mettre en production, estimer la taille de chacun des trucs qu'on allait mettre en production. On avait de l'arbitrage.
Des réunions pour estimer, des réunions pour arbitrer, des réunions pour prioriser.
Des réunions pour dispatcher les différents travaux à réaliser dans chacune des équipes. En fonction d'une demande du marketing, il fallait bien orienter cette demande dans un ou l'autre des backlogs, voire dans plusieurs, donc diviser les features suivant les strates techniques.
Donc là aussi, des réunions spécifiques et régulières.
du packaging pour pouvoir valider, et puis une dernière réunion pour dire, voilà, tout ce qui a été réalisé dans le package, on est OK pour le mettre en production.
D'accord? Donc, beaucoup de réunions, des cycles de développement, qui prenait à peu près trois mois. On avait des itérations de trois mois, donc tous les trimestres, on livrait un ensemble de features en production. On pouvait livrer un peu plus souvent, mais pas beaucoup plus que tous les mois, par exemple. Tous les mois, on pouvait livrer des releases de bugfix. Mais généralement les grosses features étaient apportées tous les trois mois.
Et avec un mode qui était un mode Scrum, avec des planning poker pour les estimations, des réunions de préparation pour dispatcher les différents items, prioriser, arbitrer. Et puis un certain nombre de réunions qui impliquaient ce qu'on appelle une core team, donc les différentes parties prenantes qui donnaient le feu rouge ou feu vert pour réaliser en production. Un ensemble de mécanismes assez lourds, on va dire, mais quand même dit agile, puisqu'on était dans un mode pseudo-scrum, on va dire.
Aujourd'hui, donc après. L'organisation ressemble un peu à ça. C'est plus une organisation en réseau, on va dire.
Avec des membres d'une équipe et des sujets.
L'équipe étant une équipe au sens large, c'est-à-dire qu'elle intègre à la fois des développeurs, des compétences de développement, des compétences opérationnelles et des compétences de validation. Donc il y a eu un changement en termes de structure de l'organisation pour rassembler les différentes compétences en une seule équipe.
Alors, je vais en parler. Il y a un certain nombre de déclencheurs, mais il faut bien comprendre que je parle d'une période de trois ans à peu près, entre ce que je vous ai présenté juste avant et ce que je vous présente aujourd'hui.
Non, là on a des sujets. Je vais préciser cette notion par la suite. On a des sujets et les gens de l'équipe étendue, donc du service de R&D, s'organisent autour de ces sujets.
Il n'y a pas de directive pour assigner un certain nombre de sujets à des personnes dépendant de leurs compétences.
Donc si on regarde du côté du produit, vous vous rappelez la structure en strates techniques? On retrouve un peu cette structure en strates techniques, puisqu'on n'y coupe pas, on a quand même besoin de composants de bas niveau, de gérer des données, d'historiser.
On a quand même besoin de composants métiers, voire d'interfaces utilisateurs, voire d'interfaces programmatiques, d'API. Mais la répartition se fait différemment aujourd'hui. J'ai parlé de sujets dans l'organisation des équipes. Les sujets se retrouvent un petit peu sous forme de composants verticaux. Donc on va découper le produit non plus en strates techniques, mais en blocs fonctionnels, qui peuvent regrouper différents niveaux techniques jusqu'à l'interface utilisateur.
Donc un sujet en fait,
C'est un ensemble de fonctionnalités à développer.
avec un ensemble homogène de fonctionnalités à développer, On trouve la notion d'épique qui est assez proche dans la méthodologie Scrum par exemple. Et on peut rattacher à un sujet un composant fonctionnel, donc vertical, On peut rattacher à plusieurs sujets un même composant vertical. Donc il n'y a pas de couplage fort, je dirais, entre la notion de sujet et la façon dont est découpé le produit. Mais le produit est beaucoup plus découpé fonctionnellement qu'il ne l'était précédemment. Donc la loi de Conway s'applique là aussi dans le parallèle qu'il y a entre l'organisation de la structure et la façon dont est designé. Un des composants.
Voilà.
Donc pour la partie organisation du produit.
Donc de manière dynamique, comment ça se passe? Donc on a toujours une roadmap, parce qu'à l'extérieur de l'équipe de R&D, il y a une équipe marketing. Elle est à l'extérieur, mais elle est vraiment très très proche, on travaille en proche collaboration. Donc cette roadmap, elle est amenée par l'équipe marketing, mais elle est aussi complétée ou amendée par les équipes techniques.
Et à côté de ça, on a un train de release.
Qui s'est notablement accélérée. Donc il s'est accéléré grâce à un certain nombre de techniques, mais grosso modo on est passé de release trimestriel à des releases hebdomadaires. Donc aujourd'hui on release toutes les semaines, voire plusieurs fois par semaine. Alors comment c'est devenu possible? C'est devenu possible par, d'une part, la compartimentation du produit en blocs verticaux, donc en fonctionnalités.
C'est devenu possible par l'adoption d'un certain nombre d'outils, on va le voir par la suite. Et donc par le travail sur les sujets sur lesquels chaque membre de l'équipe peut se positionner. On verra comment aussi par la suite.
Donc comment ça se passe quand un truc à faire est extrait d'un sujet? Le marketing et l'équipe technique décident qu'il y a un sujet sur lequel on doit travailler. Ce sujet est découpé en plusieurs petites fonctionnalités, voire tâches. Et pour chacune de ces tâches ou de ces fonctionnalités, on va créer une branche de développement. Sur laquelle l'équipe rattachée au sujet va travailler.
À la fin du travail sur la branche de développement, on a un mécanisme qu'on appelle pull request, on pourrait en parler aussi
au niveau des outils, qui nous permet de donner un accord pour merger ce qui a été développé sur la branche mère, sur le master ou le trunk. L'équipe technique décide qu'il y a un sujet sur lequel on doit travailler. Ce sujet est découpé en plusieurs petites fonctionnalités, voire tâches. Et pour chacune de ces tâches ou de ces fonctionnalités, on va créer une branche de développement sur laquelle l'équipe rattachée au sujet va travailler.
À la fin du travail sur la branche de développement, on a un mécanisme qu'on appelle pull request. On pourrait en parler aussi au niveau des outils, qui nous permet de donner un accord pour merger ce qui a été développé sur la branche mère, sur le master ou le trunk.
À partir de ce qui est développé sur le trinque dernièrement, on va
agréger tout ce qui a été récemment développé sur le trinque pour faire une passe de validation, avec les compétences de validation qui sont maintenant intégrées à l'équipe de R&D.
Et puis, on a toujours un...
Un go, no go à apporter lorsqu'on fait la validation, mais ça se fait sans réunion particulière. Donc c'est l'équipe de validation qui donne le feu vert ou le feu rouge à la fin de sa phase de validation qui dure de une journée à trois journées, mais pas beaucoup plus, pour le déploiement en production.
Donc ce cycle-là, on le fait toutes les semaines.
Donc le cycle de prendre tout ce qui a été agrégé sur le master, l'amener sur une plateforme pour validation, le valider et le déployer en production, ce cycle-là est réalisé toutes les semaines. À date fixe. Donc on a décidé que ça serait le mardi. On a évolué. Au début, c'était le jeudi. Et puis il y avait certaines personnes qui n'étaient pas forcément disponibles dans les bons créneaux pour que ça soit fait de manière fiable. Donc on a avancé la date au mardi. Et tous les mardis, on déploie une version. En production, qui comprend. Les trucs à faire, ça peut être des features, ça peut être des fonctionnalités, mais ça peut être aussi des correctifs.
Alors, ça c'est bien beau, on a vu le flux un peu de ce qui était déployé. Comment on va se synchroniser?
Puisqu'auparavant, on avait des réunions d'estimation, de préparation. De planification, de répartition dans les différents backlogs, de go-no-go pour décider conjointement avec la core team est-ce que c'est bon, on est à la fin du trimestre, est-ce qu'on est ok pour déployer, est-ce qu'il n'y a pas des risques, etc. Aujourd'hui, on n'a plus tout ça, mais il faut quand même se synchroniser.
d'une certaine manière. Donc comment se synchronise-t-on?
Donc on se synchronise tous les lundis matins.
Et sur chacun des sujets, de manière préférentielle, on va faire une démo.
Dans le pire des cas, on donne un statut.
Donc chaque micro-équipe rassemblée autour d'un sujet va faire une démo de ce qui a été développé dans la semaine ou donner un statut.
On a aussi un créneau de 5 minutes pour avoir un update sur la roadmap. Donc là, c'est le marketing qui participe à cette réunion, qui donne un update s'il y a lieu sur les points de la roadmap. Alors c'est généralement un créneau qui est occupé... puisqu'il y a quand même, malgré tout, des annonces qui sont faites à nos différents clients et qui ne sont pas faites toutes les semaines. Il y a un train d'annonce qui est plutôt de l'ordre du trimestre, du mois ou du trimestre. Donc sur des périodes de début de trimestre, on a plus fréquemment des updates sur la roadmap. Que tout au long du trimestre.
Et enfin, on a un créneau de 5 minutes pour un statut sur les déploiements. Vous vous rappelez le feu vert ou rouge dans le train des releases.
Donc ça donne lieu aussi à 5 minutes dans cette réunion du lundi matin. Pour dire, ok, on déploie, ou il y a un bug qui bloque le déploiement, sur lequel il faut travailler en urgence. Alors généralement, on n'attend pas la réunion du lundi pour essayer de débloquer une release qui est bloquée par un bug. On le fait de manière assez interactive. La synchronisation se fait essentiellement par cette réunion du lundi matin qui dure une heure, maximum une heure je dirais. Assez fréquemment ça dure moins d'une heure. Toute l'équipe est rassemblée, donc c'est entre, suivant les lundis, entre 20 et 30 personnes. Avec toutes les compétences de l'équipe R&D, plus des gens du marketing, plus parfois des clients internes aussi, puisqu'on a un service opération qui est en liaison avec les clients, et qui vient écouter ou voir dans les démonstrations ce qui va être amené dans le produit dans la semaine. Donc c'est le meeting préférentiel pour la synchronisation. Oui?
À temps plein ?
C'est 25 à 30 personnes.
Donc c'est assez rythmé, puisque sur chaque sujet, il y a actuellement, je dirais, et la plupart du temps, il y a une vingtaine de sujets qui sont menés plus ou moins en parallèle. Il y en a qui sont en pause, mais qui peuvent ressurgir, puisqu'on a des... On travaille avec les opérateurs de téléphonie mobile, donc on peut avoir des sujets qui nécessitent des dépendances avec des parties prenantes ou des tiers, donc ils peuvent passer en pause pendant que d'autres sujets sont remis en avant. Mais on a grosso modo un backlog d'une vingtaine de sujets et 25 à 30 personnes qui sont affectées à ces différents sujets.
Donc, on n'essaie pas de faire une revue très formalisée de chacun des sujets pendant ce meeting d'une heure. On donne la préférence aux démonstrations. Et ensuite, s'il y a des choses importantes à dire, donc un changement de statut plus précisément, à ce moment-là, c'est le lieu, c'est l'endroit pour le communiquer à tout le monde.
Alors il y a l'ensemble de l'équipe, les développeurs, les ingénieurs de test,
les administrateurs système, le marketing, le product marketing, et les clients internes, essentiellement des gens du service opération, qui sont en liaison avec les clients externes. Qui gèrent le back-office et qui doivent répondre aux clients quand il y a un problème sur la plateforme, répondre aux demandes clients de manière générale.
Exactement. Et il a un créneau de 5 minutes pour le faire.
Il y a un leader dans l'équipe sujet qui va faire la démonstration. Ce n'est pas forcément toujours le même, d'ailleurs. Il n'y a pas la notion de team lead comme elle pouvait y être, je vais y venir un peu par la suite, comme elle pouvait exister précédemment dans l'organisation plus statique où on avait trois équipes, chacune avait son team lead. Là, on a des sujets, il y a des leaders un peu naturels qui vont arriver sur chacun des sujets, qui peuvent changer d'une semaine à l'autre. Et qui vont faire la démo. Mais c'est la manière qu'on a adoptée qui nous permet de rythmer le développement et la mise en production et de donner une cadence aussi dans le travail.
On n'a pas de stand-up, on n'a plus de stand-up, par exemple. On n'a plus de stand-up quotidien.
On a ce meeting-là.
Alors, on a aussi, bien sûr, des meetings ad hoc. Si une équipe a besoin de se rassembler sur un sujet pour discuter d'un design, d'une implémentation, interagir avec le marketing, appeler des clients parce qu'on a besoin de renseignements, à ce moment-là, on ne s'interdit pas les meetings du tout. Simplement, on a beaucoup moins de meetings formalisés, sauf celui du lundi matin, qui est limité à une heure.
On conserve des rétrospectives. On avait des rétrospectives précédemment, on avait des rétrospectives par équipe, donc chacune des trois équipes avait des rétrospectives à la fin de chaque sprint qui durait trois semaines. Aujourd'hui, on a beaucoup moins de rétrospectives. On fait des rétrospectives trimestrielles, mais qui rassemblent les 25 ou les 30 personnes.
On a mis en place aussi une journée qui ne sert pas forcément à la synchronisation au niveau du produit, mais qu'on a appelée une journée Make It.
Dans d'autres organisations, ça s'appelle la Gold Card aussi. C'est une journée toutes les trois semaines sur lesquelles tous les développeurs peuvent... Réaliser ou travailler sur un projet de leur choix, un projet personnel, certainement en rapport avec la plateforme qu'on développe, mais ça peut être un rapport assez lointain avec la plateforme qu'on développe. C'est un projet personnel dans le cadre de l'entreprise, sur lequel chacun peut travailler une journée toutes les trois semaines. Et qui donnera lieu à une démo. Là aussi, toutes les trois semaines, on se garde un créneau d'une heure pour faire les démos des projets Make It. Ce sont des projets indépendants des sujets qu'on a vus précédemment. Ça ne veut pas dire que ça ne peut pas devenir des sujets.
un certain nombre d'idées comme ça, de projets perso qui sont devenus des sujets ou des outils à l'avant-vente, par exemple, de manière assez naturelle. Donc ça, ça permet de catalyser l'innovation, en fait, et de garder... Ça permet aux gens de l'équipe de sortir le nez du guidon et puis de laisser fleurir des idées qui permettent éventuellement d'avancer, de développer un peu plus le produit. Et surtout de se faire plaisir.
On a aussi un certain nombre d'événements spéciaux.
Cet été, on avait la Coupe du monde de foot, donc on a fait un championnat de correction de bugs sur une journée avec une coupe. Et par équipe, l'équipe de développement a concouru pour gagner la coupe de quelle équipe allait corriger le plus de bugs. Plus récemment, on a fait une journée de code retreat, une journée plus focalisée sur la façon de coder, les exercices de codage. Donc on garde du temps aussi, on essaie de garder une journée par trimestre pour des événements de ce type. Il n'y a rien de planifié très longtemps à l'avance. C'est un peu au gré des idées qu'on peut piocher dans les rétrospectives aussi, de gens qui nous disent qu'on aimerait faire des katas, des choses de ce genre.
Alors, il y a eu une transition, il y a eu une évolution dans l'organisation du produit et dans la structure du produit et dans la structure de l'organisation.
Cette évolution, contrairement au premier diagramme que je vous ai présenté, elle ne s'est pas faite de manière continue ou linéaire. Il y a eu des paliers.
Le dernier palier qu'on a franchi, c'était au début de cette année, en début 2014, dans lequel on... Dans le cadre de ce palier, on est vraiment passé à une organisation en réseau. On a regroupé les équipes. C'était la dernière étape de l'évolution de cette équipe. Il y avait un certain nombre d'objectifs à franchir ce palier-là. Un premier objectif, c'était de pouvoir gérer des sujets qui étaient cachés. Donc il y avait un certain nombre de sujets qui étaient émis par l'équipe de développement, des sujets plutôt techniques, qui étaient régulièrement mis de côté parce que jugés non prioritaires. Et donc ça générait de la frustration.
Donc, organiser le service en équipe sur des sujets, ça permet de lister tous les sujets et de les rendre. visible de façon à pouvoir gérer les sujets qui étaient cachés précédemment.
En évoluant vers des releases toutes les semaines, bien sûr, on a minimisé le time to market ou le time to production de manière assez drastique. Et comme le produit est pas mal basé sur le feedback, donc les retours qui sont amenés par les clients, de manière plus ou moins directe dans l'interface utilisateur. Il y a un bouton qui permet aux clients de faire des demandes directement. On a aussi le service opération dont je parlais tout à l'heure, qui est l'interface qui gère des tickets clients, mais aussi des appels téléphoniques. Donc on a des demandes qui sont remontées de cette façon-là.
Et donc on peut réagir très rapidement dans un délai d'une semaine. Si les nouvelles choses à développer tiennent dans ce délai, on peut réagir beaucoup plus rapidement que précédemment.
On souhaitait aussi avoir une architecture moins monolithique.
Précédemment, on avait vraiment...
Un paquet assez lourd à gérer.
Donc là, le paquet s'est splitté en plusieurs composants qui peuvent faire appel à des technos différentes. Pas forcément les mêmes langages, pas forcément les mêmes technos, On verra que c'est une des pistes qui nous pousse aussi à aller un peu plus loin, d'éclater la structure du produit en micro-service.
Donc pour ça, il faut une architecture évolutive. Et c'est ce qui a été amené tout au long de ces trois années. Ce qui était souhaité aussi, c'était la notion d'auto-organisation autour des sujets. Donc avoir une équipe étendue avec plus de compétences, plus de compétences différentes dans l'équipe, et non pas une équipe simplement limitée à du développement. Et il y avait un fort besoin d'auto-organisation.
Alors, ces différents points, d'éclater la structure du produit en micro-service.
Donc pour ça, il faut une architecture évolutive. Et c'est ce qui a été amené tout au long de ces trois années.
Ce qui était souhaité aussi, c'était la notion d'auto-organisation autour des sujets. Donc avoir une équipe étendue avec plus de compétences, plus de compétences différentes dans l'équipe, et non pas une équipe simplement limitée à du développement. Et il y avait un fort besoin d'auto-organisation.
Alors, ces différents points,
Le dernier, c'est une visibilité beaucoup plus large que précédemment. C'est la visibilité qui est apportée par le meeting du lundi, où on peut revoir tous les sujets, mais tout le monde dans l'équipe, les 30 personnes, ont la vision de tous les sujets simultanément.
Et ces différents besoins, objectifs plus précisément, ont été remontées au gré des différentes rétrospectives, par exemple, ou par des discussions de manière informelle. Donc ce n'est pas quelque chose qui a été imposé par le management.
C'est quelque chose qui a été fait en accord avec le management, voire poussé par le management, mais c'est remonté aussi des équipes.
Et on en parlait tout à l'heure, il y avait aussi le besoin qui était que les leaders soient plus des leaders désignés, qu'il n'y ait plus de team lead
avec un titre officiel, mais que des gens qui ont envie de faire avancer un sujet puissent le faire sans contrainte.
Alors, comment ça s'est passé?
Donc ça s'est passé avec du temps.
J'en ai parlé plusieurs fois, donc il a fallu trois ans et des paliers pour amener ce changement d'organisation. Ça s'est passé aussi en partant de là où on était.
On est dans une conf sur Camban, entre autres. Donc on est parti de là où on en était. On n'a pas cherché, il y a trois ans, à vouloir... Combler un gap trop important d'un seul coup. Donc on est parti vraiment de là où on en était, on a utilisé le feedback, on a eu du support du management, donc entre autres le directeur du service qui a plutôt poussé à ce que l'organisation soit libre de changer. Il n'y a eu aucune contrainte.
quelque chose de moteur à ce niveau-là.
Il y a eu une forte collaboration avec le product marketing, donc c'est parfois un écueil, c'était ce qui était un peu remonté dans les toutes premières rétrospectives, c'est-à-dire que le product marketing était assez peu présent
dans la définition des features, dans les interactions avec les équipes. Donc ça, ça s'est beaucoup amélioré. Et aujourd'hui, il n'y a plus aucun problème qui est remonté. La collaboration se fait vraiment très naturellement. Je dirais qu'à la limite, l'équipe est tendue. On pourrait l'étendre au product marketing.
Je dirais que dans l'organigramme officiel, le product marketing est distinct de l'équipe de développement, mais au quotidien, c'est une frontière qui n'existe pas. Il y a des interactions fortes avec le product marketing. Je pense que c'est un des points clés.
On a évolué de manière incrémentale, pas forcément continue, mais avec des paliers.
Donc là aussi, c'est l'approche Camban.
Plus que le... Dans Camban, on avait pris un certain nombre d'éléments il y a quelque temps, dont le management visuel. Ça, c'est un peu tombé en désuétude. Les équipes ont un peu abandonné le management visuel, hormis pour la réunion du lundi. Donc là, on a du management visuel. On utilise aussi le management visuel pour les rétrospectives, voire pour certains événements. Mais on n'a plus de stand-up et pas forcément de tableau. Au mur, on n'a plus ces tableaux-là. Par contre, de Camban, on a gardé l'évolution incrémentale et le fait de démarrer là où on est.
Pas vouloir changer les rôles, les fonctions du tout au tout et du jour au lendemain. Et enfin, on s'est appuyé sur les gens. Ce sont vraiment les individus qui ont participé à l'évolution de cette organisation et à l'évolution du produit sur des pratiques, des outils et des métriques. Donc on va rapidement balayer les outils.
Alors, je parle des outils, j'ai un peu parlé des pratiques et de la façon dont on avait évolué.
Ce ne sont pas les outils qui ont forcé à l'évolution de l'équipe ou l'évolution de l'organisation qui a fait qu'on allait adopter de nouveaux outils. On ne peut pas dire qu'il y ait de relation de cause à effet. Il y a simplement eu une évolution en parallèle des outils. Qui ont certainement déclenché un certain nombre de changements dans les comportements ou dans la façon d'interagir entre les individus de l'équipe. Et puis il y a un certain nombre de pratiques dans les équipes qui ont fait qu'on a adopté des outils différents. Il n'y a aucune relation de cause à effet qu'on puisse noter. Donc on a adopté un système de version... Contrôle de version décentralisé, Git, pour ne pas le nommer. Ça, ça a changé la façon, entre autres, de travailler sur les features, donc en créant des branches de features, en travaillant via des pull requests, donc les pull requests qui ont remplacé
les meetings de revue de code qu'on pouvait avoir précédemment, qui étaient des meetings qui pouvaient être assez formels, Les revues de code, c'était quelque chose qui avait été amené par les toutes premières rétrospectives, là aussi. On avait ressenti le besoin d'avoir ces revues de code ou de faire des... les revues de design aussi. Et puis finalement, en se basant sur l'outil, on est arrivé à un système qui nous permet à la fois de faire de la revue de code et de design, et de gérer les merges de features ou de bugfix dans la branche master.
On a pas mal travaillé sur les tests automatisés, mais pas seulement sur l'automatisation des tests, vraiment sur ce qu'on voulait en termes de testabilité sur le projet, sur le produit.
Donc les revues par pull request, j'en ai parlé. On a aussi plus récemment travaillé sur des containers.
Vous êtes familier de la technologie des containers, Docker, vous connaissez. Donc on a mis en place un... Un système, enfin toute une organisation autour de containers Docker qui permettent aux développeurs d'avoir l'ensemble de la plateforme sur leur poste de dev. Et au-delà de ça, on déploie des containers dans le cloud pour tester les branches de features. Donc ça, ça nous a aussi grandement facilité la vie pour... Améliorer le processus de déploiement. On a bien sûr travaillé sur l'intégration continue et le déploiement continu. Et puis on a mis en place des métriques. Donc David Anderson parlait de métriques tout à l'heure dans la keynote.
On n'a pas mis en place des... des métriques très très compliquées, on a mis en place des métriques très simples, en se focusant sur les bugs,
Pourquoi sur les bugs? Parce que c'est beaucoup plus facile de trouver des métriques sur les bugs que sur les features aujourd'hui.
On est dans un domaine assez exploratoire en termes de fonctionnalités. On prend beaucoup en compte les feedbacks des clients en les mélangeant aux idées qui sont amenées par le marketing ou la technique.
Les features peuvent être assez peu formalisés au moment où on commence à développer. Donc on a focalisé les métriques sur les bugs, parce que ça donne quand même une bonne indication de la façon dont on exécute le process.
Et on compte les bugs, le nombre de bugs ouverts en fonction du temps, et on regarde l'évolution du temps de cycle des bugs. Ce sont les deux métriques qu'on relève, et qui nous donnent quand même une bonne indication de la façon dont on développe et dont on améliore le produit.
Non. On a ces indicateurs et ces indicateurs peuvent nous alerter sur le fait qu'il faut travailler de manière prioritaire sur les bugs ou qu'on peut continuer à travailler tranquillement sur les sujets, sur les features. Mais on a ces indicateurs qui sont disponibles en temps réel, donc ils sont mis à jour quotidiennement.
Ils sont mis à jour de manière automatique quotidiennement et ça nous permet de lever des alarmes. On a l'œil sur ces indicateurs. Et on peut de manière assez réflexe se dire, tiens, là, l'indicateur du compte de bug, il a une tendance à augmenter.
C'est le moment de travailler sur les bugs.
On a aussi des indicateurs, enfin, pas d'indicateurs, mais on a aussi un...
une indication sur les bugs bloqueurs au travers de l'impossibilité de réaliser en production. Et là, le réflexe, il est plus qu'immédiat.
Alors, j'ai quasiment terminé la présentation. Il y a quelques pistes qu'on va certainement explorer. J'ai parlé de l'architecture microservice. Dans l'organisation du produit, vous vous rappelez la loi de Conway, il y a l'organisation du produit. La structure du produit et la structure de l'organisation. Dans la structure du produit, aujourd'hui, on a quelques composants verticaux, 4 ou 5. Ça correspond à 4 ou 5 applications web qui dialoguent entre elles ou qui dialoguent avec l'extérieur.
Une des pistes qu'on aimerait explorer, c'est une architecture microservice, qui serait un split encore plus important en termes d'applications web, en termes de composants indépendants.
Pourquoi? Pour aller plus loin dans la scalabilité. On est sur un produit qui est en phase d'adoption assez forte.
Le nombre d'utilisateurs est en train de grimper sensiblement.
On se pose des questions sur la scalabilité. Une des façons de répondre à la scalabilité, c'est...
Ce sont les microservices.
On se pose aussi pas mal de questions et il y a des avis forcément contradictoires sur une population de 30 personnes sur la façon de tester.
Est-ce qu'il faut faire du BDD, de l'ATDD? Qu'est-ce que le TDD?
Les positions ou les façons de penser sont différentes d'un individu à l'autre. Donc c'est un chantier qu'il faut qu'on mène, qu'on mène déjà depuis de nombreux mois, mais qui n'est pas abouti. À mon avis, il ne le sera jamais, mais on a des questions à adresser dans ce domaine. Donc, quels tests faire? Est-ce qu'il faut faire des tests de régression? Est-ce qu'il faut les automatiser ou pas? Est-ce qu'il faut mettre la priorité à la rapidité de l'exécution des tests? Est-ce qu'il faut mettre la priorité sur l'exhaustivité des tests?
Est-ce qu'il faut tester uniquement les features qui sont utilisées par les clients? Quelles sont les features utilisées par les clients? Donc il y a tout un tas de... Tout un tas de problématiques qui tournent autour de la testabilité. C'est une des pistes qu'il faut qu'on explore.
Je parlais d'automatisation au niveau des tests, mais on n'est pas encore tout à fait dans une... Dans une organisation dans laquelle tout est automatisé, du moment où on crée une branche de feature jusqu'au moment où on va déployer la feature, En production, on a encore des zones d'intervention manuelles.
Et là-dessus, il y a un chantier qui a déjà démarré depuis quelques temps, qui est la claudification de l'application. Pour l'instant, on fonctionne en mode hébergé, mais de manière interne. Et on est en train de travailler sur un mode où on va se décharger de l'hébergement dans un cloud public.
Et là, forcément, on va être obligé d'automatiser encore plus les déploiements. C'est une piste qui va peut-être faire évoluer aussi la structure de l'organisation en parallèle. En particulier, les notions d'astreinte qui étaient prises en compte par les administrateurs système, même s'ils font partie de l'équipe.
On peut se poser la question de... Est-ce que tout le monde dans l'équipe ne peut pas se mettre à faire des astreintes?
Mais essentiellement, on continuera à travailler sur les individus, les personnes et les interactions dans l'équipe. C'est un point crucial. En fait, aucune de ces évolutions que j'ai montrées n'aurait été possible sans que les gens dans l'équipe se sentent impliqués, adhèrent à ces évolutions. Et parfois, ça nécessite du courage. Il y a des changements qui ne sont pas faciles. Il y a des points de vue qu'on doit remettre en cause.
Donc il faut du courage et c'est un travail permanent en fait, de travailler avec les gens, de savoir comment les gens travaillent entre eux.
Et aussi de travailler sur les compétences de chacun.
Donc je terminerai par une citation. J'avais commencé par une citation et je terminerai par une citation qui est de Jean-François Jagodensky qui, lors de l'Agile Tour Toulouse,
avait dit cette phrase que je trouve assez belle, qui est qu'une équipe se cultive comme un jardin.
Moi, je n'ai pas parlé de mon rôle au début. Je suis un peu cultivateur d'équipe, dans l'équipe dont je vous ai présenté l'évolution.
Je voulais finir là-dessus.