Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur qui parle de techniques,
bien sûr, de codes durables, mais aussi du métier en lui-même,
de recrutement, de développement personnel ou encore d'entrepreneuriat
pour t'accompagner dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui, je suis avec Jean-Pierre Lambière.
Jean-Pierre, bonjour. Salut !
Tu me parlais là, il y a deux secondes, tu m'as agiché complètement
et ça nous donne le sujet du podcast.
Tu es donc... J'ai le plaisir d'être en physique cette fois
avec Jean-Pierre Amarseille qui vient pour intervenir chez un client.
Et tu me disais que tu allais faire un sprint d'une journée.
Alors ça, ça me plaît beaucoup parce qu'en tant qu'extrême programmeur
des sprints d'une journée, si tu veux, c'est...
Bah c'est juste la norme, tu vois, mais c'est pas la norme pour beaucoup de monde.
Donc je suis très curieux.
Comment est-ce que tu vas mettre ça en œuvre ?
Concrètement, ça va ressembler à quoi ?
Déjà, évidemment, c'est pas moi qui ai inventé ce concept.
Effectivement, on peut...
Il y a notamment Ron Jeffries qui en parle.
C'est en disant si en gros, l'équipe, elle arrive pas à terminer son sprint,
à faire tout ce qu'elle a à faire, y compris jusqu'à l'au bout,
jusqu'à mettre en production, notamment, souvent ça qui est un peu douloureux
dans certains contextes.
Eh ben, il faut essayer avec une iteration plus courte.
Ce qui est complètement contre-intuitif par rapport à ce que font tous les gens
que je vois qui disent c'est trop court, dans le temps, ralange la dur.
C'est trop court dans la joutes, sur le projet.
Et ça remplir les choses, souvent.
Bah parce qu'on en met plus, en fait.
Déjà, parce qu'à la limite, si on n'en mettait pas plus, ça pourrait marcher.
Mais après, il y a quand même d'autres problèmes, on va prendre tout le temps qu'on a, etc.
Donc, il est plutôt, on en fait moins.
Et il va jusqu'au bout de cette pensée en disant, et s'il le faut,
on va jusqu'au sprint d'une journée.
Et puis, en fait, il va même plus loin, quand il dit même, même si on n'arrive
même pas à développer quelque chose dans une journée.
Alors, on n'a qu'un seul objectif, c'est réussir à faire une mise en prod
avec rien de nouveau dessus.
Et voilà, effectivement.
Donc, t'imagines tous les leviers, que derrière, on se retrouve à faire
qu'on ait une chaîne de bulle qui marche bien et ensuite.
Et ça, ce qu'on sait de là, il a été repris par d'autres personnes,
notamment John Cutler, qui voit beaucoup, beaucoup de vertus sur.
Et moi, c'est plutôt sous ce tango-là que je leur prends, en fait, c'est que du
coup, ça force les gens à réellement travailler ensemble.
Ah bah oui, sur une journée, t'as pas le temps de dire, je t'envoie une spéc, on se
fait une confesse. C'est tout de suite là maintenant, on règle le truc.
Ça, il y a cet aspect-là, il y a aussi beaucoup l'aspect, puisque moi,
je suis un grand fan des feature teams.
D'ailleurs, on a vu plusieurs podcasts sur le sujet là et un problème
récurrent qui arrive, c'est comment on fait pour travailler tous ensemble,
alors qu'on n'est pas sur les mêmes stacks, qu'on n'a pas les mêmes
complétances, etc. Du coup, c'est compliqué.
Et donc, en général, les gens imaginent qu'il faut rentrer dans des usines à gaz
de planification où on a chacun de ses tâches, alors qu'il faut faire l'inverse.
Surtout, tu vas aider ton copain.
Et l'idée, elle est là, c'est, ben non, tu as une journée, tu as une chose à faire.
Et c'est la seule chose à faire.
Et tout le monde est focus.
Donc on se retrouve bien à un cas de focus.
Voilà. Et on y va.
Et donc finalement, même un peu plus loin, on a même ce qu'on appelle le
swarming, qui est un peu comme du mode programming, mais sauf que c'est pas
forcément des programmeurs en fait, quoi. C'est toute l'équipe, le testeur,
le designer, un suite.
Clairement, le truc qui me vient instinctivement, quand tu me parles de ça,
tout de suite, je pense binommage, binommage pour raccourcir les cycles.
Mais aussi, ça, c'est quelque chose que j'aimerais tester.
Tu vois, dans un des gros projets sur lequel je bosse, on galère toujours un peu
sur le côté UX design et le passage de l'UX design à la ODEV,
cette espèce d'interaction.
Et j'en suis arrivé à me dire, il faudrait qu'on essaye.
On n'a pas eu encore le courage de le faire,
mais je me suis dit, il faudrait qu'on essaye de faire binommé un UX designer
avec un développeur.
Et je suis convaincu qu'en fait, on y gagnerait du temps.
En fait, c'est un genre qui le fond naturellement au moins un peu,
au moins sur les dernières étapes, quand il y a la passation, souvent,
il y a un peu de flottement après.
Pour moi, binommé, c'est vraiment être là.
Je d'accord.
Pour moi, tu sais que tu binommes quand tu fais des choses chiantes ensemble.
Dire que tu fais des choses qui ne justifieraient pas d'être à deux
et que tu le fais quand même à deux.
C'est là que tu es en train de binommé.
Et il y a encore beaucoup de valeur qui se passe à cet endroit-là,
même si ce n'est pas forcément dans les merces.
Et même moi, je dois reconnaître que depuis qu'on est passé en remote,
et même avant, quand on était ensemble,
même si j'aime le binommage, ce n'était pas forcément quelque chose de très,
très répandu.
On ne le faisait pas tout le temps.
J'y reviens parce que j'en redécouvre les vertus.
Et je me dis, est-ce qu'on ne pourrait pas pousser le curseur jusqu'à prendre des gens
dont c'est des métiers complètement différents, pas juste une question de front et back,
mais de les faire bosser ensemble ?
Et finalement, ce que tu me dis, ça part pas d'attendre.
C'est exactement ça, l'enjeu.
C'est ça, effectivement, il y a le front et le back qui ont du mal à travailler ensemble.
Du coup, le contexte n'est pas très clair du est-ce qu'il faudrait qu'ils
assument ça jusqu'au bout et qu'ils structurent deux équipes.
Mais ce n'est pas forcément ce qu'ils veulent.
Et probablement pour les bonnes raisons,
parce qu'il y a au contraire à travailler plus vite et se focaliser sur le produit.
Donc s'il y a beaucoup de sens à les mettre dans la même équipe,
par contre, du coup, fait-il, il y a un moment où il faut qu'ils travaillent ensemble,
soit travailler ensemble, soit commencer même à acquérir une forme de
devenir un peu les backup de leurs camarades sur l'autre techno.
On ne s'attend pas à ce qu'ils deviennent experts surtout,
mais qu'ils viennent backup, qu'ils aient un minimum de connaissances,
de compétences pour aider.
On n'arrive jamais à avoir une charge qui occupe pile poil 100% tout le monde.
Donc on est toujours obligé d'avoir des choses comme ça,
on peut se passer du travail.
Et à lazoxas, c'est sur l'aspect un peu purement technique
des gens qui ne travaillent pas ensemble.
Après, il y a toutes les vertus de juste
on veut raccourcir le cycle et en fait,
c'est les passages de bâtons qui prennent du temps plus que le travail lui-même.
Ce qui, d'ailleurs, fait un peu écho quand on parle de no-estimates.
C'est un peu l'idée qu'en vrai, en général,
quand on donne une estimation, on donne l'estimation de la partie dev.
Il y a énormément avant, il y a énormément après,
plus tout un tas de trucs autour de juste synchroniser, se parler, etc.
Et en fait, une petite ou une grosse user story,
en fait, elle prend autant de temps quand on prend tout en compte.
Donc, comptons juste le nombre d'éléments
et torranéoristique qui marchera très, très bien.
C'est un peu ça, en fait.
Si on ne regarde pas juste la partie dev,
qu'elle focusse traditionnelle, productivité.
Il faut que les gens soient occupés à 100%.
C'est les machines. Tu perds de l'argent si tes machines ne sont pas occupées.
Alors que ça, c'est faux et c'est pas faux parce qu'on parle de machines,
puisque même ça, c'est l'histoire de Toyota et du Linn.
C'est qu'on a plus d'intérêt à avoir des machines moins productives,
mais flexibles qu'à avoir des machines qui produisent à fond à fond
et qui en fait produisent plus que le reste de la chaîne.
Et ça, ça sert à rien.
Ça crée du stock, le stock, ça a du coup aussi, etc.
Donc, c'est vraiment comment on rapproche les gens
et comment on réduit le time to market finalement tout simplement.
Depuis, on a l'idée jusqu'au moment où il est entre les mains de l'utilisateur.
Et si tu reviens sur cette expérience d'une journée,
alors ça ressemble à quoi, typiquement, si j'étais dans un sprint d'une journée ?
Le matin, les personnes.
Alors du coup, forcément, on imagine qu'il peut faire ça,
on aurait quand même une logique où les gens doivent se synchroniser.
Ce que le but c'est qu'ils fassent ensemble.
Donc, ils arrivent à une heure prédéfinie.
Et on va passer typiquement le matin ou le début de la matinée
à juste avoir des discussions.
Qu'est-ce qu'on doit faire ?
Quelle est une chose, une seule, qu'on pourra faire ?
Qu'on arrivera à faire dans la journée
et qui apporte de la valeur pour l'utilisateur.
Tant qu'à y être.
Voilà. Donc, évidemment, il y aura peut-être déjà tout un tas d'échange
de juste comment on allège, on allège jusqu'à ce que la chose tienne
dans la journée, tout en apportant toujours de la valeur.
Donc là, on voit qu'en plus, il y a le change traditionnel
de faire du découpage qu'on est obligé de répondre.
On peut pas juste se dire, ce serait une grosse théorie,
on la mettra en première dans le sprint, comme ça, ça passera.
Ça, c'est un enjeu à part entière.
Et après, on discute parce qu'il faut du coup, on a une idée,
mais comment on va au bout ? Du coup, en quelque part, on se fait les specs.
C'est toujours la même chose.
Donc, le specs est devenu un gros mot,
mais à place fait des critères d'acceptation.
On dit clairement ce qu'on veut.
C'est une autre forme de specs.
On dit clairement ce qu'on veut, on dit comment on va y aller.
Et puis, assez naturellement, on embraye sur
comment on s'organise, comment on y va.
Et après, on espère que ça te viendra un peu fluide.
Mais voilà, les gens, ils seront là.
Et en fait, le jour où la même chose, c'est comme quand on est en campant,
ça va marcher parce qu'à un moment, le pipeline est plein,
donc tu n'as plus de travail, donc t'objetes d'aider tes copains.
Tout comme quand tu es en scrum.
Même si c'est porté le café et soutenir la pop-up girls.
C'est la même chose quand on est en scrum,
mais avec la fin de sprint, c'est la fin de sprint.
Il reste trois trucs à finir.
Ce n'est pas les choses qui sont chez toi.
Du coup, comment tu aies de les autres ?
La réelle idée, c'est vraiment de prendre juste cet élément là.
Et là, sauf qu'on l'a sur une seule journée.
Donc en fait, ce qu'on attend, c'est que, oui,
il y a des moments où les gens n'ont rien à faire.
Et donc mécaniquement, qu'est-ce qu'ils font ?
Bah ils vont être obligés d'aider les autres,
ou de s'intéresser, ou trouver d'autres choses, etc.
Et voilà, et donc ça va être une forme de binommage.
J'ai une forme puisque dans le binommage, on est plus dans l'idée de développeurs
qui connaissent déjà la chose sur laquelle on travaille et qui s'apporte quelque chose.
On est plus dans le partage de compétences, dans le complément de compétences.
On a le designer, le front, le bac, le database, la production et ainsi de suite.
Et on voit comment on avance du début de la conception de l'idée jusqu'à la mise en prod.
Et ce que disait justement John Cutler là-dessus, c'est que c'est pas forcément un schéma pérenne.
Voilà, c'est pas forcément la bonne manière de s'organiser, de faire que d'esprit d'une semaine.
Par contre, dans tous les cas, les équipes qui l'ont fait, on sont toujours sortis grandis, en fait.
Ils ont toujours appris quelque chose.
Oui, tu as repoussé le curseur quelque part et ça t'a obligé à réfléchir sur ta manière de travailler.
C'est toujours un exercice intéressant pour se challenger, pour voir comment travailler autrement, etc.
Donc, ce n'est pas forcément la manière de travailler, mais toujours une manière intéressante,
une bonne expérience pour expérimenter, pour tester, pour voir comment faire les choses.
Ecoute, Jeterre, merci de cette insight.
Je te propose que ce soit le mot de la fin.
Si les gens veulent en savoir plus et te contacter, ils peuvent venir où ?
Ils peuvent me contacter en allant par exemple sur mon blog, jp-lambere.me.
Et puis, bien sûr, peuvent continuer de regarder mes vidéos et demander des messages d'amour à propos de Scrum Life.
Genre, ce toujours beaucoup, ça fait très plaisir, mais continuez, continuez.
Ça marche, merci Jean-Pierre.
Quant à toi, chers auditeurs, j'espère que tu as apprécié ce podcast.
Et je t'invite à nous rejoindre sur artisan-developer.fr pour rejoindre la communauté des développeurs passionnés.
À demain.