Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec J.P. Lambert. J.P. bonjour.
Bonjour.
Tu me parlais du passage à la feature team.
Et ça m'intéresse vachement et je suis curieux de savoir un petit peu plus.
Qu'est-ce que tu entends par feature team ?
C'est quoi pour toi une feature team de ton côté ?
Pour moi finalement la feature team,
tout le monde ne sera pas forcément d'accord sur cette définition-là.
Pour moi c'est ce que nous recommande Scrum en fait.
C'est une équipe multidisciplinaire avec toutes les compétences
pour porter un sujet de bout en bout et qui effectivement
pour fonctionnement de porter des sujets de bout en bout,
c'est une mini start-up.
Et ça on le voit quand on regarde la revue d'iterration,
la sprint review, quand on voit la liste des choses qu'on est censés voir,
il y a beaucoup plus qu'une démo.
Je crois que le dernier élément qui est cité dans Scrum Guide,
c'est on fait une revue du budget.
Donc on est vraiment sur la mini start-up.
Donc ça c'est un peu la vision idéale
et qui je pense est assez cohérente avec la définition standard
qui nous vient d'Enric Niber, il y a Spotify.
Après voilà, beaucoup d'autres gens,
ça va être juste sur le fait qu'on se s'oriente,
on s'écarte du modèle component team.
C'est une équipe qui va gérer une feature de bout en bout
plutôt que juste un composant,
donc du coup on va généralement avoir des développeurs,
monocompetence, etc.
et qui restent entrés sur le composant technique.
Et pour toi la feature team, elle se pose à quoi ?
Elle se pose aux organisations classiques
où tu te retrouves avec des silos, les devs d'un côté,
la QA de l'autre, des devs up de l'autre,
un truc comme ça,
ou en quoi est-ce que c'est différent d'une structuration classique ?
Fondamentalement c'est plutôt comme ça que c'est vu.
On va et si on prend la génèse d'ailleurs d'une entreprise,
d'une start-up, en général on va commencer en mode component team
parce qu'on se structure et puis à un moment on se rend compte
qu'on a un peu tous perdu pied avec la réalité des choses,
avec les objectifs très macro de l'entreprise
et du coup un moyen très fort de se recentrer sur le produit,
sur le business, c'est qu'on ne va plus avoir chacun un composant à gérer
et qui sert un rôle dans le business,
on va avoir un morceau de business à gérer.
Et du coup c'est pour ça qu'on ne va pas plutôt de feature,
qu'après il y a plein de modèles différents,
il y en a où les équipes ont un périmètre fonctionnel qui est figé,
donc à chaque fois elles travaillent sur ce périmètre là,
donc en un à d'autres ça va être des équipes un peu interchangeables
et à chaque itération elles construisent une feature,
mais on va dire d'une itération à l'autre,
la feature touche peut-être pas du tout au même endroit du produit, du fonctionnel,
mais voilà le fondement c'est rentre se dire,
là on pense feature, on est orienté sur le produit
et on le porte de bout en bout, donc on vient sur l'équipe multidisciplinaire,
normalement dans cette équipe on a tous les dév' nécessaires,
que ce soit front, que ce soit back,
on a tout ce qui est design, UI, UX, on a sur le test,
on a peut-être même si on va au bout des choses,
le marketing, les analyses etc.
Ok et du coup imaginons, j'ai un cas en tête,
dans le client que j'ai été à l'événement il y a pas longtemps,
ils ont une quinzaine de développeurs,
quatre mecs à la QA, une dévope de 5-6 personnes,
c'est vrai qu'ils sont structurés de manière assez classique,
c'est ce que t'appelles component par spécialité, par métier,
et comment ça se reventillerait,
ça veut dire qu'on prendrait les équipes,
et on prendrait 3 devs, 1 QA et 2 devs,
c'est on les met ensemble et ça nous fait une feature team.
En gros ça serait ça, après moi ce que j'aime bien dire,
j'en ai parlé dans un de mes articles,
c'est en fait cette notion de,
on est souvent aussi dans une pro-athique de passage à l'échelle,
parce que finalement quand on a suffisamment peu de développeurs
pour être une seule équipe dans le début de la start-up,
le problème se pose pas,
et effectivement la notion d'avoir une vision d'être dans le business
se pose pas non plus,
et quand on grossit, qu'on se retrouve à des silos,
on se dit non, il faut qu'on recasse ces silos
et qu'à chaque fois on est tous une vision complète,
et en fait on n'oppose pas vraiment le component team et la feature team,
en fait c'est plutôt qu'on oppose le fait d'avoir des silos
versus une organisation matricielle,
parce qu'en fait faire des feature teams
mais où on oublie complètement le côté transverse technique,
parce qu'il faut qu'on ait un component team,
les gens par exemple qui vont faire les API,
ils seront tous ensemble, tout le temps, toute la journée, ils travaillent ensemble,
donc on va assez naturellement avoir des API qui vont être cohérentes entre elles,
qui vont avoir le même niveau de qualité
et des gens qui sont capables aussi de maintenir le code d'autre personne
lorsqu'il y a des absences, des malades, etc.
Et ça, tout l'enjeu du passage à l'échelle, c'est de ne pas perdre ça,
de ne pas perdre ça, maintenant on a des feature teams.
C'est comme les anti-beautiques, c'est pas automatique.
Moi j'en connais des components de team qui n'ont pas cet attribut là,
mais effectivement, il est temps de penser,
en tout cas ça favorise le partage des connaissances, clairement.
C'est souvent un peu la solution la plus simple
pour que des gens arrivent à travailler ensemble.
Déjà, mettons les côtes à côtes ensemble dans la même salle 24 sur 24,
enfin, 25 ou 24, alors quand même laisser le temps de rentrer dormir chez eux,
mais en tout cas tous les jours.
Et ça, souvent, ça marche bien effectivement.
Par contre, du coup, on se retrouve à...
Bah maintenant, on a un focus produit, on fait une feature,
mais dans cette feature, il y a une partie back, une partie fronte, et ainsi de suite.
Donc du coup, l'affinité technique et la cohérence qu'on veut avoir,
l'alignement technique, ne se fait plus avec les gens qui sont dans l'équipe.
Ils se fait en partie, mais pas uniquement,
il faut être aussi aligné avec ce que font les gens dans les autres équipes.
Et ça, c'est le gros challenge.
Dans le modèle Spotify, c'est l'échappateur.
D'une manière générale, on parle souvent de communauté de pratique.
Et ça pour moi, c'est un des gros challenges
de réussir à passer en feature team.
Oui, de garder la cohérence technique, le savoir-faire,
de le transmettre, de le partager au-delà des frontières.
Et finalement, d'un mode ou d'un autre, on recréer des frontières.
Exactement, en fait, c'est que le risque qu'il est là, c'est de partir de silos
qui sont des silos purement techniques sur des composants,
à d'autres silos qui sont certes, c'est peut-être un peu mieux
parce qu'on est sur des silos plus business,
mais au final, on va se taper des problèmes.
C'est-à-dire qu'un an plus tard, le code, il est plus maintenable.
Oui, s'il n'y a pas une cohérence, c'est clair que ça va déraper.
Il y a un aspect cohérence, il y a aussi un aspect que les gens se retrouvent perdus
et parfois, ils ont besoin d'une communauté
pour simplement grandir ou ne pas faire n'importe quoi.
Et forcément, je ne sais pas, chacun a eu ses expériences, moi personnellement.
C'est les pires expériences que j'ai connues en tant que développeur
quand j'étais tout seul sur le produit, parce que, enfin,
encore une fois, chacun son caractère.
Je ne pense pas que j'étais fait pour faire du développement tout seul.
C'est un super important d'être à plusieurs.
Effectivement, quand on se retrouve d'un feature team où on est tout seul,
parce que, finalement, sur la partie technique où on est expert,
il n'y a pas besoin de plus d'une personne dans cette équipe-là.
On se retrouve isolé.
On a besoin, effectivement, de cette communauté.
C'est pour ça que je parlais d'organisation matricielle.
On a une dimension qui est donc le business, le produit, les feature,
et on a une autre dimension qui reste ces composants.
Finalement, il existe toujours, en fait.
Et c'est pour faire voir cet alignement technique.
Moi, j'ai envie de te poser une question, mais je vois qu'on arrive à la fin.
Donc, ce que je te propose, dans la fin de la Timebox,
je te la pose comme question.
Et puis, on en reparle demain sur un deuxième épisode.
Ça te va ?
Ça marche.
La question, c'est du coup, dans une feature team,
comment tu définis les frontières, justement ?
Puisque tu passes dans mon gros produit avec des frontières qui sont techniques,
un produit que tu dois éclater en plusieurs modules,
quelque part, adressés par des features team.
Ça te va ?
Tu la gardes pour demain, c'est ta question ?
Ok.
Merci Jean-Pierre d'être venu aujourd'hui.
Merci de m'inviter.
Quand t'as toi, cher auditeur, j'espère que t'as kiffé ce podcast.
Si tu ne connais pas encore le monsieur Jean-Pierre Lambert,
viens sur YouTube, tu tapes J.P. Lambert,
et tu ne pourras pas rater sa chaîne fantastique
que je t'encourage à aller découvrir.
Et si tu n'es pas encore écrit sur artisan-developpeur.fr,
viens vite d'inscrire, rejoindre la communauté.
Je te remercie, je te dis à demain.