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.
J.P. aujourd'hui, je voudrais ton avis parce que j'ai un client qui encore me gratte sur
les Sprint Planning.
Et quand on fait des Sprint Planning, il a du mal à accepter.
Je peux le comprendre parce qu'on est sous pression et il faut quelque chose d'avance.
Mais consacrer trois ou quatre heures à un Sprint Planning pour deux semaines de boulot,
ça lui paraît trop long.
Moi, ça me paraît un minimum.
Alors, j'étais curieux.
Qu'est-ce que tu en penses ?
Par-de-jeure, il y a plusieurs manières de répondre.
Il y a la réponse un peu bête et méchante que dit le Scrum Guide.
Puisqu'en Dioré, on applique une méthode.
Donc, on est censé l'appliquer tel que c'est écrit dans le guide.
Le livre est il nous dit que le Sprint Planning, c'est huit heures pour une itération de
quatre semaines d'un mois.
Historiquement, c'était un mois.
Logiquement, une itération de deux semaines.
J'imagine comme le reste du monde, c'est une itération de deux semaines.
On le divise par deux.
Ça nous fait quatre heures.
Alors, dans ces quatre heures-là, on a évidemment la réunion elle-même de Sprint
Planning.
On a aussi tout ce qui va être grooming, refinement.
Quand général, les équipes font d'autres réunions au cours de l'iterration.
Mais voilà, l'équipe typique, elle va passer un grooming d'une heure ou deux trente minutes
pendant l'iterration.
Ça va faire les trois heures qui va être effectivement une heure pour se retrouver
ensemble, faire le tour des user stories et surtout de fixer l'objectif d'iterration.
Parce que c'est très important l'objectif d'iterration que souvent on oublie.
Et une reste de deux heures, pas pour faire le découpage en tâche technique.
Parce que normalement, quand on fait du scrum by the book, on fait des tâches techniques.
Voilà.
Et ce qui permet de même de pousser un petit peu loin.
On se pose les vraies questions concrètement.
L'archie, on peut aller dans le détail.
Donc cette deuxième-là, partie, elle est potentiellement sans PO.
Elle est vraiment technique.
On re-solicite le PO.
Si finalement, au vu des tâches techniques, on a un gros doute.
On se dit, finalement, l'objectif qu'on s'est donné, on ne va pas le faire parce que
si parce que ça, mais mise à part ça, c'est juste l'équipe.
Ok, ça, c'est la réponse by the book en lisant le petit livre qui est quand même
issu de quelques années d'expérience et de trois équipes qui l'ont mis en œuvre.
Toi, c'est quoi ton expérience ? Est-ce que tu as déjà été confronté à ce cas-là ?
Qu'est-ce que ça donne quand l'équipe fait cette fausse économie ?
En fait, au final, ça va beaucoup dépendre de comment travailler l'équipe parce que
souvent, effectivement, on ne fait pas du scrum by the book.
Dans une démarche un peu ligne, on va, on s'oriente même petit à petit vers du camp
banc et on prépare les choses au fil de l'eau.
Ce n'est pas choquant de se dire, on fait moins de choses en planning parce que,
pendant l'iterration, on va préparer les trucs, etc.
Ça suppose qu'il y a quand même déjà une belle maturité dans l'équipe et ça ne
dédouane pas le fait que les user stories soient bien prêtes, qu'on ait plein de critères
d'acceptation, etc.
Donc, la partie grooming, de toute façon, elle va rester.
Mais c'est souvent la partie tâche technique qui saute.
J'ai envie d'avoir regardé, j'ai déjà fait un des scrum life sur les tâches techniques.
Il y a beaucoup d'équipes qui ont du mal avec les tâches techniques.
Pourquoi on fait les tâches techniques ?
Parce que dans le découpage que j'ai fait, au final, sur les 4 heures by the book, il
reste que 2.
Alors, je rappelle quand même que dans le by the book, ça reste des time box.
C'est-à-dire que c'est un temps, mais si on fait moins de temps, ce n'est pas grave.
Mais c'est ce qui sortira de la réunion.
C'est-à-dire qu'on alloue le temps quand même dans le calendrier, après, si on a fini,
on peut sortir avant.
Ce n'est pas l'objet de décramer.
Donc, pourquoi est-ce qu'on passerait 2 heures à faire les tâches techniques ?
Déjà parce que quand on n'a pas de tâches techniques et qu'on se retrouve à travailler
sur une grosse user story, on va avoir potentiellement le PO qui va stresser tout seul dans son
camp, parce qu'il va juste une story qui n'avance pas.
Alors que tout le monde dans l'équipe lui dit, mais tout va très bien, ça suit son
cours.
Et effectivement, si on a les tâches techniques, on va voir que, ben oui, les tâches techniques,
elles, elles avancent.
Donc déjà, ça s'était fait là de communication, de transparence, qu'on ne se retrouve pas
en rétrospective, où les gens ont juste l'impression qu'on ne me dit jamais rien,
on me dit tout va bien, mais en fait, je ne vois rien qui avance, je ne comprends pas
ce qui se passe, etc.
Et après, la grosse différence, elle est bien sûr sur la collaboration au sein de l'équipe,
c'est que, alors parfois, ça va être parce qu'on va avoir des développeurs plutôt
expérimentés et d'autres moins, alors que je dis expérimentés, ça peut être simplement
en bouteilles, mais c'est peut-être aussi simplement sur le projet.
C'est qu'il y en a, il est là, il connaît tout parce qu'il est là depuis longtemps,
et d'autres arrivent et forcément découvrent la base de code et le fonctionnel et le métier
et ainsi de suite.
Donc du coup, comment on se passe cette information-là et qu'on vérifie qu'on n'a rien oublié ?
Les tâches techniques sont très puissantes pour ça.
Et ça aussi, on a toujours quand on est sur une équipe qui va être multidisciplinaire,
normalement Scrum, on est censé être sur une équipe multidisciplinaire qui gère des problèmes
de bout-à-bout.
Ça va permettre de se rendre compte que la story iOS, en fait, il n'y a pas que l'expert
iOS qui peut travailler dessus parce que oui, il y a une partie, ça va être effectivement
ouvrir Xcode et taper du Swift pour lancer sur iPad, mais il y a plein d'autres choses
à côté, ça va être challenger l'architecture, ça va être vérifier que ça marche, ça
va être faire des tests, ça va être valider le création et toutes ces choses-là, elles
ne sont pas du tout spécifiques à une expertise iOS.
Et donc de faire ce travail-là fait que les gens vont pouvoir travailler ensemble au
quotidien que sinon on a juste un gros bloc qui est une story iOS et par défaut, on ne
va pas collaborer.
Par défaut, c'est juste la story du mec iOS.
Donc ça a beaucoup de vertu, les tâches techniques et oui, c'est ça que tu vas entendre
depuis le début, je pense, ce n'est pas du temps perdu parce qu'en fait, si on ne
fait pas tout de suite, de toute façon, il faudra le faire plus tard.
Ça, souvent, c'est sur la partie grooming, on a plein d'équipes, on a des stories qui
sont parédiques, qui sont trouées, c'est n'importe quoi, ce n'est pas ce qu'on doit
faire, on n'a pas le critère d'acceptation.
Et bien, qu'est-ce qui se passe en pratique ? Il se passe que soit les gens font n'importe
quoi, soit les gens s'arrêtent en cours de route pour aller choper cette information
qu'ils auraient dû avoir tout de suite et du coup, ils perdent du temps, ils en perdent
beaucoup parce qu'ils s'interrompent, ils sont au milieu de l'iterration, ils interrompent
d'autres gens, ils ont besoin de d'autres personnes qui n'ont peut-être pas l'information
de suite, du coup, ils passent en mode vitesse dégradée parce qu'ils ont une information
qu'ils n'ont pas de suite, etc.
Donc en fait, il y a vraiment toute une dimension de juste faire ce qu'il y a à faire, mais
avant parce qu'en fait, on en aura besoin de toute manière et là, au moins, c'est
une instance où on s'est synchronisé, donc on perd pas de temps à se retrouver et à
s'interrompre, etc.
Oui, je suis complètement d'accord avec toi.
Après, je cherchais pas forcément ce que tu me disais oui, oui, tu es raison.
Je me remets en cause souvent, je me suis dit, tiens peut-être que JP va me trouver
une solution parce que même moi, quand je fais le calcul au cours horaire, je me dis
la réunion elle coûte cher, donc je suis tenté, mais ton argument qui est de dire
de toute façon le temps, il sera consacré, et ça me paraît évident, et en plus pas
au bon moment.
Le seul point où j'ai peut-être une divérengence de point de vue par rapport à ce que tu dis,
c'est sur la présence du PO, même dans le découpage des tâches techniques.
Moi, ça m'est arrivé plus d'une fois que les choses bougent pendant les tâches techniques
parce que le PO était là.
C'est-à-dire qu'il nous entend un moment donné, le PO, il tend quand même une oreille,
il fait ses emails un peu en même temps, mais il tend une oreille attentive à ce qui se
passe, et quand il sent qu'il y a un truc qui chauffe un peu, des fois ça m'est arrivé
plusieurs fois, régulièrement, au moins une fois dans une séance de littération,
que le mec dit « non mais attendez les mecs, on s'est mal compris, là vous êtes en train
de vous enflammer, moi je veux un truc vachement simple.
» Et que du coup, à un moment donné, les tâches
sont mal compris un truc où il est envisagé trop de choses, et où le mec arrive avec
une solution en disant « de toute façon regardez, et si on faisait comme ça, est-ce
que ça vous simplifie la vie pour qu'on puisse avancer, trouver une solution plus intelligente
ou des trucs comme ça ? » Donc pour moi, le PO est quand même important dans cette
phase de découpage de tâches techniques.
Ce qu'il y a de tasse, ce que je disais, c'est que c'est une question de dynamique
qu'on a, en fait.
Il y a effectivement des équipes qui s'orientent vers dans la bonne direction, on ne spécifie
pas dans le détail tout ce qu'on va faire, et finalement on est sur des choses assez
légères.
Donc oui, le PO est là parce que c'est client, c'est lui qui dit comment on va faire,
et c'est lui qui porte beaucoup d'informations.
Quand on est dans ce mode de fonctionnement-là, qui est très sain, oui, il fait partie de
l'équipe et on l'implique, il peut choper des choses au passage.
Dans l'exemple que tu donnes, j'ai aimé envie de dire, on est un peu sur du pilotage
par la valeur.
C'est le mec qui dit « non, mais moi je veux un truc à deux balles ».
C'est comme une discussion que vous pourrez avoir un jour, mais quand on arrive au stade
où les développeurs ajustent leur effort en fonction de la valeur qu'on en attend,
déjà on est bien en termes d'agilité, on en est à faire ça.
Donc on en reparlera une autre fois.
Après, à l'inverse, t'as aussi beaucoup d'autres boîtes où, leur mode de fonctionnement,
ça reste du « il faut se péquer », il faut très clair sur ce qu'on veut faire, et
du coup c'est plutôt qu'on a un definition of ready qui évite qu'on nous donne de la
merde, etc.
Il se trouve que le PO est très occupé, donc il ne peut pas être là.
Après effectivement qu'il soit disponible, qu'il soit pas long, reste bien sûr une
bonne chose.
À chaque fois, il y a toujours une dynamique qui a construit entre les gens.
Si il n'y a pas de problème que l'équipe délivre, en soi il faut mieux faire les
choses le plus tard possible.
Ça c'est une règle globale en ligne, il faut mieux faire les choses le plus tard possible.
Eh ben écoute, merci J.P.
Ce sera le mot de la fin.
Merci encore d'être venu aujourd'hui.
Avec plaisir.
Quant à toi chère auditeur, j'espère que tu as apprécié cette émission.
Si c'est le cas, je t'invite à la diffuser et à la partager avec un copain.
Ça permettra de faire connaître le podcast.
Et si tu en as envie d'en savoir plus sur le travail de J.P., tu peux venir sur son blog
de mémoire jp-lambere.com.
Point M.
Mais il y aura une redirection sur ta point.
Point M.
Ou sur la chaîne YouTube, tu cherches Crumb Life ou J.P.
Lambert et tu trouveras son travail.
Je te remercie et je te dis à demain.