Claude Aubry
Transcription
C'est parti, c'est parti. Et c'est un plaisir de parler après Laurent. Et d'ailleurs, nous allons recommencer à Agile Grenoble dans le même ordre d'ici un mois et demi, en novembre. Alors, d'habitude, quand je fais des présentations, je mets souvent des mêlées.
Je mets l'équipe du stade toulousain, souvent. Là, j'ai toujours quelque chose qui est dans la région, c'est toujours autour de Toulouse. Donc vous avez peut-être reconnu le canal du Midi. C'est le canal du Midi.
On parle de flux aujourd'hui, donc de l'eau. Et un canal, le canal du Midi, là on est à l'écluse du Sanglier.
Et donc, imaginez Scrum, avec les bateaux qui arrivent, ça serait dire, les écluses vont s'ouvrir à heure fixe.
Il y a une notion de rythme très forte. Et puis, vous avez une durée fixe pour aller jusqu'au prochain bief, où il y a l'écluse suivante. Donc là, ça serait après l'écluse du sanglier, on doit voir l'écluse de Gardouche. Et donc, il y en a une autre avant. Il faudrait donc arriver à Orfix aussi. Il y a une notion de rythme très fort.
Donc on va voir comment Camban, tel qu'on vient de vous le présenter, peut permettre de fluidifier un peu le trafic. Pour le canal du Midi, si on attend heure fixe, par exemple, toutes les heures pour ouvrir les écluses, qu'est-ce qui va se passer?
Est-ce qu'il y aura beaucoup de bateaux? Ça dépend des périodes. Il n'y a plus de péniches, maintenant c'est des bateaux de plaisance.
Il peut y avoir des moments où il y aura beaucoup de monde, mais la plupart du temps, il n'y aura pas grand monde. Pour essayer d'avoir quelque chose de plus fluide, c'est-à-dire par rapport à un rythme scrum,
pas trop de files d'attente, donc les bateaux qui attendent, pas trop de famine, on ouvrirait l'écluse alors qu'il n'y a personne. Donc on va essayer de fluidifier tout ça.
Je suis Claude Aubry.
Je fais beaucoup de Scrum. En fait, ça, c'est ma deuxième vie. Dans ma première vie, je fais du développement, chef de projet. J'ai même travaillé sur quelque chose que David Anderson a cité tout à l'heure, le RUP.
Tout ça, c'est du passé.
Donc, de l'agilité et principalement du Scrum.
J'ai écrit un livre sur Scrum. On est à la troisième édition. Et cet exemplaire-là, offert par les éditions Duneau, sera gagné ce soir pour ceux qui restent et qui font des jeux.
Et donc je fais du coaching, ou de ce qu'on appelle maintenant du coaching agile, de la formation, de l'accompagnement, notamment à Toulouse, dans des entreprises plutôt industrielles, plutôt grosses et industrielles. Donc c'est un peu de cette expérience-là dont je vais vous parler.
Alors on rentre tout à fait dans ce qui a été présenté, donc en banque, comme de l'amélioration de processus. Donc là, moi je me mets dans le contexte où on utilise déjà Scrum, dans un contexte, je dirais, assez classique pour Scrum. Une équipe, donc une équipe de taille normale, des sprints, alors des sprints plutôt longs par rapport à la moyenne, là c'est un peu lié au contexte industriel que j'évoque,
où on a des choses à faire, donc ce qu'on appelle un périmètre qui est quand même pas mal défini au début, donc parfois même... On a des documents de spec qui existent avant. Une release de quelques mois, donc 4 à 6 mois, avec des sprints de 3 à 4 semaines. Ça va nous en faire 3, 4, 5 dans la release. Et puis un déploiement qui est fait en fin de release.
Est-ce que vous pratiquez Scrum ici ? Donc ceux qui connaissent, pratiquent déjà Scrum? Une bonne moitié, un peu plus, d'accord. Alors le début de ma présentation va rappeler quelques principes de Scrum pour aller un peu plus loin que ce que nous a dit Laurent sur la présentation. On va partir sur la présentation des tableaux. Donc je vais vous présenter beaucoup de tableaux et beaucoup de post-it. Alors, mais je commence quand même par le vieux Scrum.
Déjà vieux. Scrum, vous avez sûrement vu ce schéma-là, si vous regardez, le schéma de Mike Cohn. Donc, ça date à peu près de 2005. Moi, je l'avais traduit à l'époque. Donc, ce schéma-là qui nous présente Scrum d'une façon très simple, voire simpliste. Donc, c'est bien, il y a du backlog. On va parler pas mal de backlog aujourd'hui. On voit un gros backlog de produits, et puis ce qu'on appelle un backlog de sprint. Alors je dis 2005, mais si on regarde sur le site de la Scrum Alliance, On voit encore ça, j'ai regardé juste avant, on voit encore un schéma comme ça, qui ressemble pas mal. Il y a juste un truc au milieu, entre le product backlog et le sprint backlog, on a mis, tiens, il y a quand même des choses à faire ici, pour commencer le sprint, on se dit, ah oui, on prend les choses du backlog et puis on y va, bon, il y a peut-être des choses à faire, à travers la planification de sprint. Mais je pars quand même de ce principe. Et donc pourquoi je vous parle de cambandiser le Scrum, de rajouter du camban à du Scrum qui existe déjà ?
Scrum, il y a des succès, c'est pas mal, c'est même bien, mais on voit dans les contextes variés, et même dans les contextes que j'ai cités, on voit des choses qui embêtent un peu. Donc on voit par exemple du multitâche. Du multitâche, la règle Scrum, c'est de dire qu'on n'est pas perturbé pendant le sprint. Donc toute la période de temps ne va pas être perturbée. Alors s'il y a des événements à l'extérieur, des clients qui veulent quelque chose, du support qui veut réagir, la règle stricte de Scrum dit qu'il faut attendre le prochain sprint. Il y a des cas où ce n'est pas tenable. Donc il faut imaginer des solutions à ça. Ce qu'on constate aussi parfois, c'est la difficulté à finir des choses à la fin du sprint. C'est-à-dire qu'on commence un certain nombre d'éléments. Le vocabulaire que j'utilise, c'est des stories pour dire que dans le backlog, on va mettre des stories. Je reviendrai sur cette notion-là.
On commence des choses, on a du mal à les finir. C'est peut-être une des raisons d'ailleurs, c'est peut-être parce que finalement au début du sprint, c'est assez mal connu. C'est-à-dire que l'équipe va travailler sur des morceaux, mais elle ne les connaît pas si bien que ça. C'est un peu lié à ce qu'on appelle le backlog. Ah, c'est dans le backlog. C'est bien, on y va. Mais qu'est-ce qu'il y a dedans? Exactement. Et puis, notamment quand on a essentiellement des tableaux au niveau de l'équipe, ce qu'on appelle les scrum boards, les tableaux des tâches, les parties prenantes, tous nos stakeholders, ont du mal à savoir exactement où on en est de l'avancement du produit.
Moi je dis bien que le gros backlog, comme la grosse spécification avance, ça constitue du stock. J'avais fait un sondage sur mon blog, je pense l'année dernière, sur les tailles de backlog. Les tailles de backlog, je me demandais combien d'éléments il y avait dans le backlog. Il y avait des réponses variées, mais on avait des backlogs à plus d'une centaine d'éléments. Je ne sais pas si parmi vous, il y en a qui font du Scrum. Est-ce que vous avez des backlogs avec plus de 100 éléments dedans? Il y en a? Oui, il y en a quelques-uns. Plus de 200? Oui, il y en a aussi. D'accord. Plus de 50? Pour ceux qui font les autres, oui. D'accord. Voilà, donc il y a beaucoup d'éléments dedans. Donc ça constitue du stock. Bon, on a vu que le stock, on peut dire rapidement c'est mal, on va essayer de le diminuer.
Donc, vous voyez pour la troisième fois les principes du Kanban. Donc, ça, c'est ce qu'a présenté David et ce qu'a repris Laurent. Alors, moi, je vais m'arrêter dans ma présentation aussi aux quatre premières, essayer de voir comment, en partant de Scrum, on peut travailler sur les quatre premiers principes. Donc le côté visuel évidemment existe déjà dans Scrum, ce qu'on introduit c'est la limitation de travail à finir, le WIP en anglais ou ce que j'appelle le TAF, la gestion du flux et rendre les choses explicites. Donc visualiser, si on repart de notre schéma de MyCone, alors ce qu'on voit le plus souvent c'est quand même le tableau Scrum, le taskboard ici. Le tableau Scrum. Et puis souvent au niveau visuel, il n'y a que ça. Le reste, c'est fait un peu comme d'habitude. Alors ça correspond à ce que j'appelle un peu le cycle en vroom, en fait. Le cycle en vroom, c'est de dire on fait du Scrum pour le côté vraiment ce qu'on appelle le dev, mais avant on fait de l'aspect un peu comme d'habitude, puis après on fera du déploiement ou de l'intégration un peu comme d'habitude. Donc on va essayer de voir comment aller plus loin. Donc un tableau Scrum typique, je dirais que ça se présente comme ça, ça a des colonnes,
des colonnes où on va mettre les tâches, les morceaux de travail, et puis une quatrième colonne à gauche. où on va mettre les éléments à faire, on va parler de story, des stories à faire et des tâches. Est-ce que vos tableaux ressemblent à ça?
Il y a plus de colonnes que ça?
Des fois, oui.
Un tableau typique, c'est ça. Alors ce qui arrive parfois, c'est que les stories, on a beau avoir un coach, un scrum master, les stories, les tâches, ça bouge, mais à la fin du sprint, on s'aperçoit que finalement, il y a pas mal de stories qui ne sont pas finies. Puisque je rappelle, le sprint, c'est une période de temps, on s'arrête. Toujours à la date fixée.
Alors certains, voyant ça, se disent, tiens, et notamment la difficulté à tester. Pourquoi ça ne finit pas? Souvent, c'est parce qu'on a peut-être un product owner qui n'est pas disponible, ou on a
des personnes qui ont fait du scrum essentiellement côté développeur, les développeurs travaillent et disent, ah ben non, ce n'est pas nous qui faisons les tests, c'est peut-être le product owner, voire des personnes extérieures à l'équipe. Donc, pour qu'on voit ça, parce que c'est un problème, on va rajouter une colonne à tester. Et puis on va dire, donc, product owner, tu as pu vérifier tes règles et tout.
Alors ça, c'est peut-être du camban, mais je trouve que ce n'est pas du scrum. Donc je suis absolument opposé à rajouter des colonnes si on veut continuer à faire du Scrum.
Des colonnes en plus, ça n'est pas nécessaire. Alors on va voir pourquoi. Donc éviter, souvent on en voit, on dit, ah Scrum c'est un peu rigide, on va rajouter, on va passer au Kanban, donc allez, on rajoute des colonnes.
C'est tout à fait compréhensible de rajouter des colonnes quand on a un processus qui correspond à ça. Quand on veut rester dans du Scrum, on n'a probablement pas besoin de rajouter des colonnes. C'est ce qu'on va voir en se posant quelques questions. Une façon aussi d'éviter les colonnes, c'est de les supprimer.
Finalement, les colonnes, les post-it, ils peuvent tomber, ils ne tiennent pas bien. Et puis, on ne voit pas bien le stock dans les colonnes, c'est en dessous. Quand vous voyez un tableau, souvent, s'il y a beaucoup de stock, ça va en dessous, ça va en dessous, ça va tellement bas qu'on ne le voit pas. Donc, ce que je propose, c'est de ne pas faire des colonnes, mais de faire des bacs. Donc, c'est un peu un clin d'œil au mot backlog, en fait. Mais faire des bacs, ça permet donc... Déjà, quand des stories sont finies, les autres post-it, ils descendent tout seuls. Presque.
Donc, des bacs. Des bacs. pour notre backlog. Alors on va commencer par le bac de sprint, donc je reviens rapidement dessus. Un bac de sprint, on a nos quatre colonnes, les stories, les tâches à côté qui sont ici. Et quand commence le sprint, au début du sprint, on a quelque chose qui ressemble à ça. C'est-à-dire qu'on a nos stories et puis on a identifié les petits morceaux de travail qui sont ici, qui sont prêts à démarrer pour le sprint.
Donc au début, on a tout ça.
Vous êtes d'accord?
Bon, tout ça, on peut voir comme ça, on peut déjà se dire, il y a beaucoup de choses, et on ne va pas travailler sur tout ça d'un coup, il y a quand même du stock ici. Il y a du stock. Alors, comment avancer là-dessus? Le sprint, il y a quand même du flux, c'est-à-dire qu'il y a des... Dans l'équipe, on prend des tâches, on les commence, on les finit, elles passent dans la colonne de droite.
Alors, première chose à faire, le premier principe visuel, ça c'est visuel, c'est bien. Le deuxième, c'est de dire limiter le travail en cours. Donc limiter le travail en cours, ça revient à dire finalement il y a des tâches, on peut mettre une limite sur les tâches. Pour éviter que des gens commencent trop de tâches et ne les finissent pas, on va limiter le travail.
On a cette limite qui a été rajoutée ici. Bon, on s'aperçoit vite. C'est peut-être une première approche, mais ça ne va pas très loin. Ça n'empêche pas quand même de commencer des tâches sur des stories différentes. Et finalement, l'objectif quand on fait un sprint en Scrum, ce n'est pas de finir des tâches, c'est de finir des choses qui apportent de la valeur. Donc c'est plutôt, ce qui compte, c'est de finir les stories. c'est de finir les stories. Alors finir les stories, comment faire? Ça met tout de suite le point sur la notion de comment l'équipe va travailler sur ce qu'il y a à faire. Sur ce qu'il y a à faire, on prendra donc... Des stories à faire, on a éventuellement, c'est pas indispensable d'ailleurs, c'est pas obligatoire de passer même par les tâches, on a des tâches, comment s'organiser le travail dans l'équipe.
Donc c'est ce qu'on appelle l'essai mage, ou le swarming, une notion qui vient du Kanban. Le principe c'est quoi? Vous avez des stories dans le sprint. Alors un sprint moyen en Scrum, avec ce que j'ai dit au début, une équipe de 5 à 9 personnes, des sprints de 3 semaines, une équipe fait une dizaine de stories par sprint. dizaines, peut-être un peu plus parfois, mais ça donne un ordre d'idée. Une équipe de 7 personnes, personne, d'histoire, comment on s'organise pour faire le travail. Donc le principe de l'essai-mage, c'est d'avoir la meilleure tactique possible pour ça.
Qu'est-ce qu'on fait? Donc à l'extrême, on pourrait dire, chaque développeur, chaque développeur, alors c'est des développeurs au sens large, même s'ils ont l'air de coder, ça prend toutes les activités qui sont nécessaires pour finir la story. Donc on pourrait se dire, chaque développeur prend une story, Ce que j'ai dit au début, une équipe de 5 à 9 personnes, des sprints de 3 semaines, une équipe fait une dizaine de stories par sprint. dizaines, peut-être un peu plus parfois, mais ça donne un ordre d'idées. Une équipe de 7 personnes, 10 stories, comment on s'organise pour faire le travail. Donc le principe de l'essai-mage, c'est d'avoir la meilleure tactique possible pour ça. Qu'est-ce qu'on fait? Donc à l'extrême, on pourrait dire, chaque développeur, chaque développeur, alors c'est des développeurs au sens large, même s'ils ont l'air de coder, ça prend toutes les activités qui sont nécessaires pour finir la story. Donc on pourrait se dire, chaque développeur prend une story,
Ils travaillent sur une story. À l'autre extrême, on pourrait se dire, on a tous les développeurs qui travaillent sur une story.
Et puis quand ils auront fini, ils passeront à la deuxième.
Qu'est-ce qui vous paraît le mieux?
Qu'est-ce que vous faites, vous, d'habitude? En Scrum. Vous n'en occupez pas? Les gens prennent les travaux?
Comment?
Deux développeurs par story.
Deux développeurs par story, d'accord. C'est une règle que vous avez?
Non, on n'en a pas de plus.
D'accord, d'accord. Ben voilà, l'idée de l'essai majeur. Alors on s'aperçoit plutôt dans les domaines du développement logiciel que l'idéal évidemment ce serait d'avoir une story, tout le monde travaille dessus, on l'a fini, on passe à la suivante. C'est le pattern, on fait une chose à la fois et puis quand on a fini on passe à la suivante. C'est vraiment, on n'a pas de... De temps mort, pas trop de multitâches, donc c'est bien. On s'aperçoit que dans nos domaines, c'est quand même difficile et qu'on a plutôt un nombre de développeurs par story qui peut aller, qui dépend des stories bien sûr, qui peut être 2, 3, 4. En général, au-delà, c'est difficile. Donc ça veut dire que si vous avez une équipe de 5 développeurs, vous allez pouvoir commencer plusieurs... plusieurs stories en même temps et donc la... Deux, voilà, donc deux, si vous avez là deux stories qui commencent en même temps, donc c'est pas la même chose, c'est plus que là on a une première story où il y a quatre développeurs et puis une deuxième où il y en a deux. C'est variable selon le type de story. Ce qu'on peut se dire effectivement, c'est qu'on commence à travailler sur deux stories en parallèle et puis qu'on s'interdit de commencer une troisième pendant que... Donc une des deux n'est pas finie, ça peut être une des règles informelles qui est mise dans l'équipe, il y a des équipes qui travaillent comme ça. Donc des développeurs sur une story. Alors j'ai mis un point, un trait plus fort pour dire qu'il y a peut-être dans l'équipe quelqu'un qui va porter la story, donc le coordinateur de la story qui va travailler étroitement avec le product owner. Donc c'est pour avoir un responsable qui irait jusqu'au bout. C'est typiquement pour éviter le multitâche. Ce qui se passe souvent, quand on met la colonne test, c'est-à-dire les développeurs ont fini, ils vont travailler sur une autre story. Si on teste après, qu'est-ce qui va se produire? Si on trouve une erreur, un défaut à corriger, il va falloir revenir sur la story alors qu'on travaillait sur une nouvelle. Donc ça provoque typiquement un changement de contexte avec du multitâche. Donc pour éviter ça, on peut se dire qu'il y a une personne qui va rester jusqu'au bout sur la story. Qui va aiguillonner aussi pour qu'elle soit testée tout de suite, pour ne pas attendre, si c'est nécessaire. de demander fortement un produit de tonneur à une autre personne, et puis il va rester là pour corriger s'il y a un défaut, jusqu'à ce que la story soit finie. Donc c'est ce que j'ai noté comme compteur, pour faire référence aux stories, donc SMH, compteur. Et ces images compteur, c'est des dessins de Patrice, qui est le dessinateur pour mon livre, qui sont dans la troisième édition. Et donc, à quoi ça sert tout ça? On pourrait se dire, pour reprendre du vocabulaire Scrum, que les images améliorent la vélocité.
Alors pourquoi, au-delà du fait qu'il y a des abeilles qui piquent, c'est en diminuant typiquement le multitâche. L'objectif est de limiter au maximum les changements de contexte et les pertes de temps qui sont dues à ces changements de contexte.
Donc SMH. Alors si on vient sur notre tableau avec des tâches, donc ici notre tableau Scrum, il va se présenter donc avec ces colonnes-là. J'ai rajouté une colonne à droite pour dire que la story est finie. Souvent aussi les équipes sont embêtées s'ils n'ont que les quatre colonnes pour montrer que la story est finie. Il y en a qui mettent... Un petit point dessus, il y en a qui les retournent, bon, chacun... Et c'est bien, donc chacun va inventer une façon de le noter. Une façon encore plus simple, si on utilise les bacs, c'est d'avoir quelque chose qui garde les stories finies, qui pourront servir pour la revue.
Ok, donc là, tableau typique. On va oublier les tâches finalement, les tâches on peut s'en passer. On va oublier les tâches, si on regarde donc juste les stories, donc là j'ai gardé que les post-it jaunes qui correspondent à nos stories. Alors on se dit, ce qu'on vient de voir donc c'est qu'on pouvait déjà appliquer un certain nombre de pratiques pendant le sprint. Donc on a notre bac de sprint avec les stories qui sont mises dans le sprint au début du sprint, lors de la planif. Donc lors de la planif, qu'est-ce qu'on fait? L'équipe va décider. de ce qu'elle fait pendant le sprint. Elle prend un certain nombre de stories, j'évoquais le chiffre de 10, et puis au fur et à mesure qu'elle est finie, elle va les mettre éventuellement dans un sous-bac ici pour dire c'est les stories qui sont prêtes pour la démo.
Alors, on a toujours à droite les stories qui seront déployées pour la release. Donc, je parle ici de back de récolte. Et puis, on a toujours avant notre gros backlog. Donc on va essayer maintenant d'améliorer ces deux aspects.
Donc, en parlant d'abord du gros backlog. Le gros backlog au début.
Alors, il y a des anciens étudiants ou des gens qui m'envoient parfois leur mémoire. Ils font des mémoires ou des tests sur les méthodes agiles et puis ils me demandent de relire. Donc là récemment, il y a Julie qui m'a envoyé son mémoire. Julie, je crois qu'elle est en miage et elle fait son stage dans une grande entreprise française. Un opérateur télécom. Et donc, elle m'a envoyé, elle décrit Scrum, elle m'a envoyé sur un extrait de la description de Scrum, et notamment du backlog. Donc, qu'est-ce que vous en pensez? Donc le PO, c'est pour Product Owner. Le Product Owner rédige les User Stories, qui sont les spécifications.
Vous êtes d'accord ? Non? Ben non. Et non, c'est tout faux. Disons que ce n'est pas tout à fait exact. Alors, il y a plusieurs choses qui ne vont pas.
Donc déjà, le produit d'honneur, alors il y a Redige. Prédige. rédige, l'idée c'est que les documents ça pose des problèmes en fait, si on est passé à l'agilité user story c'est pour mettre l'accent sur le contact direct, la discussion, la conversation comme on va le voir Donc peut-être qu'il y aura des choses rédigées, il ne faut pas non plus dire qu'on jette tout, mais néanmoins, ce n'est pas le Product Owner qui rédige les spécifications comme avant. Un analyste pouvait écrire l'aspect. Donc le Product Owner ne rédige pas vraiment. Il n'y a pas que lui qui le fait en plus, c'est collectif. Si l'équipe attend que le Product Owner fasse tout le travail, elle peut peut-être attendre longtemps, ça va créer. Donc elle va arriver à un sprint peut-être avec des choses qui seront soit en nombre insuffisant, soit en qualité de description insuffisante. Donc l'équipe va aider, évidemment travail collectif. Alors on pourrait dire aussi que ce n'est pas de l'aspect, effectivement, que les user stories, il y en a évidemment, ne sont pas de l'aspect.
C'est seulement si on rajoute les tests, tout ce qui va avec, c'est-à-dire les tests d'acceptation, qu'on peut comparer à ce qu'on avait avant. Et puis, on pourrait rajouter aussi que dans le backlog, il n'y a peut-être pas que des user stories, mais c'est un débat que je ne vais pas trop lancer ici. Donc Julie, elle n'a pas bon ici, je lui ai dit. Et donc, c'est ça qui pousse en fait à avoir, même si ce n'est plus une grosse spec au début, donc on a plein de choses. Donc notre stock au début. Alors voyons comment l'éviter. Là, il faut faire du tri sélectif. Vous avez le gros backlog, le gros backlog noir. Pour passer donc... Pour passer aux petits bacs, qui sont plus facilement maîtrisés, il faut faire du tri, du tri sélectif. Alors sur quoi faire du tri dans nos stories?
Alors déjà, on va constater qu'une story, ça n'est pas une exigence. On parle de façon classique de gestion des exigences, de requirements engineering. Une story, ce n'est pas une exigence. Je reviens sur ce côté-là. Il y a un côté conversation qui est important. Ça se raconte. Vous allez me dire, il est un peu endormi, il ne réagit pas beaucoup. Mais vous faites ça avec des clients, avec des parties prenantes, ça va discuter, ça va discuter beaucoup plus. Donc on raconte une histoire plutôt que de s'échanger des documents. Donc c'est l'idée.
Certains d'entre vous ont lu les belles histoires quand ils étaient petits.
Vous allez avec les utilisateurs, à travers le Product Owner, raconter les belles histoires du produit. Tout ça, ça nous vient d'où? Ça nous vient d'Extreme Programming, de Ken Beck et de Ron Jeffries. J'ai repris un slide de Jeff Patton. Jeff Patton, vous connaissez peut-être certains. C'est quelqu'un qui travaille beaucoup dans la définition de produits. Il ne fait pas souvent des présentations, mais quand il en fait, c'est touffu. Il vient de sortir une présentation qui s'appelle Agile Requirements and Product Management, dans laquelle il... Il a repris ça et je me suis dit, c'est tout à fait ce qu'il me faut ici. Et en plus, il dessine bien. Et Aaron Jeffries. Donc c'est ce qu'on appelle, si certains vous avez suivi des cours, des formations sur l'agilité, on parle sur les stories des 3C, 3C pour la carte, la conversation et la confirmation. Et donc Jeff Patton présente ça en disant les stories finalement, c'est un cycle de vie simple.
On écrit sur une carte, alors on va dire ça c'était un peu préhistorique, est-ce qu'on écrit encore vraiment sur des cartes? D'abord maintenant c'est plutôt des post-it, bon ben ça marche aussi. Mais c'est l'idée, on met ici simplement des choses très simples, une idée qui va être proposée pour aller dans le produit. Donc on va donner un titre ici en fait. Après, on a besoin de conversation et puis besoin de confirmation. Alors si on voit la confirmation ici de Jeff Patton, vous voyez qu'il y a du texte, il y a du diagramme éventuellement, on peut faire de l'UML ici. Donc confirmation. Et finalement, moi quand j'ai vu ça, je me suis dit, la confirmation et la conversation, on en a besoin, finalement on le fait plusieurs fois, ça ne se fait pas une seule fois, on fait une conversation et puis après on confirme. Alors la confirmation, on a aussi souvent l'habitude de la faire avec du test, donc de dire c'est une confirmation qui va être faite par les tests d'acceptation, et donc on comprend souvent que cette confirmation a lieu à la fin du sprint pour dire que la story est finie.
Donc finalement, on a peut-être besoin de faire ces cycles de conversation et de conversation plusieurs fois. Donc on va passer des 3C aux 5BAC. Donc, premier cycle de la story, on va faire... De la conversation, et puis on va confirmer que... Finalement, on va confirmer quoi? On va confirmer...
Que la story est prête finalement. Il y a un premier cycle qui va être de dire, oui, on a discuté entre le product owner, les parties prenantes et l'équipe de développement. Et donc, suite à tout ça, on confirme que, l'équipe confirme, puisque c'est elle qui va le faire, elle confirme que la story est prête pour démarrer le sprint.
Donc c'est la notion maintenant sur laquelle on insiste dans Scrum, qui est la notion de definition of ready, prête pour démarrer le sprint. Et puis évidemment pendant le sprint, on peut continuer à discuter bien sûr, on peut éventuellement rajouter des conditions d'acceptation encore pendant le sprint pour confirmer à la fin du sprint que la story est finie. Donc on a ici, à partir d'une idée de départ qui est mise sur la carte, on va avoir besoin de garder des stories prêtes et des stories finies, une fois que le sprint s'est déroulé. Donc entre les deux de la conversation, on ne fait pas que ça, on travaille. Et un peu finalement, pendant le sprint, évidemment, on va travailler pour développer. On va développer toute la story. Donc développer, coder, documenter, tester, tout ça, ça fait partie de ce qu'on fait pendant le sprint. Et puis, pour finalement, pour s'assurer que la story est prête, il y a besoin de travailler aussi. Pour que la story soit prête, il y a besoin de travailler. Le terme que j'utilise, c'est« cultiver». En anglais, le terme qui a été utilisé jusqu'à maintenant, c'était« grooming»,« backlog grooming». C'est celui qu'on trouve dans la littérature anglaise. Dans le nouveau guide Scrum, il parle de« raffinement». Je vais le dire en français, raffinement, et en anglais refinement. Donc le vocabulaire a légèrement changé. C'est la même idée. On va cultiver le backlog, faire pousser les stories pour arriver à ce qu'elles soient prêtes. Coder, documenter, tester, tout ça, ça fait partie de ce qu'on fait pendant le sprint. Et puis, pour finalement, pour s'assurer que la story est prête, il y a besoin de travailler aussi. Pour que la story soit prête, il y a besoin de travailler. Le terme que j'utilise, c'est« cultiver». En anglais, le terme qui a été utilisé jusqu'à maintenant, c'était« grooming»,« backlog grooming». C'est celui qu'on trouve dans la littérature anglaise. Dans le nouveau guide Scrum, il parle de« raffinement». Je vais le dire en français, raffinement, et en anglais refinement. Donc le vocabulaire a légèrement changé. C'est la même idée. On va cultiver le backlog, faire pousser les stories pour arriver à ce qu'elles soient prêtes.
Et donc de ces trois C, on peut avoir cinq bacs qui vont collecter les stories selon leur état. Alors on s'aperçoit que ça, en gros, c'est une file d'attente. On a vu un peu les notions tout à l'heure. Ça, c'est la file d'entrée, en gros. C'est pour que les utilisateurs mettent...
Les idées qu'ils ont, et puis on a la file de sortie là-bas, et puis au milieu, on a une file d'entrée également. C'est la file d'entrée qui va permettre de découpler le travail, parce qu'évidemment, on a toujours des sprints ici, donc la phase de sprint ici, elle commence toujours à heure fixe. À date fixe. Donc on a besoin de garder dans une file d'attente les stories qui sont prêtes pour le sprint. Donc rapidement ces notions-là détaillées. Le bac à sable, c'est une notion qu'on retrouve depuis longtemps dans Wikipédia. L'idée est d'y déposer des idées jusqu'à ce qu'elles soient finalement acceptées. Donc c'est l'endroit où tout le monde peut mettre des idées, donc le product owner évidemment, toutes les parties prenantes, tout le monde peut proposer des idées et les mettre dans le bac à sable. C'est plutôt le product owner qui va décider ce qu'il en fait, c'est-à-dire est-ce que finalement cette story-là, cette idée, je la conserve pour mon produit ou pas.
Alors, il y a encore une conversation que je n'ai pas mise. sur le schéma, mais évidemment pour faire ça, il a sûrement besoin de dialoguer, de discuter avec ceux qui ont fait la demande. Une story au début, elle est très légère, peu d'efforts dessus, on a juste besoin d'avoir un titre, un bref descriptif. Probablement, puisqu'on parle de limite, c'est difficile de limiter la taille du bac d'entrée puisque c'est là où on a des idées, mais ce qu'on peut faire, s'assurer, c'est que la durée de séjour ne soit pas très longue, c'est-à-dire que le product owner... Avec l'équipe, traite les demandes rapidement pour au moins savoir ce qu'on va en faire. Donc là, on peut avoir évidemment du rejet, c'est-à-dire que des utilisateurs, on peut leur dire, non, votre idée, on ne la garde pas, au moins pour la release courante. Le bac suivant, c'est en gros l'ancien bac log, c'est là où on va cultiver les stories pour les faire pousser. On a notre product owner qui a des idées, il a semé les petites pousses dans le bac à sable et maintenant il va les faire grandir. Il va les faire grandir jusqu'à ce qu'elles puissent être prêtes dans le sprint, jusqu'à ce qu'on puisse les implanter dans le sprint. Donc qu'est-ce qu'il y a comme travail à faire dans ce bac de culture? Il y a pas mal de travail quand même. Dans le bac de culture, on a des idées au début, donc il faut les faire mûrir. Qu'est-ce qu'on fait? On va donner des précisions, mais souvent on a des choses trop grosses, donc il va falloir les décomposer en plus petits morceaux. Puisque l'idée c'est pour qu'une... soit prête, donc en sortie de ce bac de culture, il faut qu'elle soit compréhensible par l'équipe, et puis que l'équipe sente qu'elle puisse la finir en un seul sprint. Donc on va les décomposer, éventuellement on va aussi estimer, alors vous connaissez peut-être le planning poker, le planning poker c'est une conversation. Le planning poker, c'est une conversation qui sert à estimer, qui sert aussi à comprendre, à communiquer entre l'équipe et le producteur.
Donc notre bac de culture peut contenir pas mal de stories. On verra tout à l'heure comment on peut encore réduire ce nombre. Le bac de départ, c'est là où on met les stories qui sont prêtes pour le sprint. Donc elles sont dans les starting blocks. Oui?
J'ai juste une question sur le bac de culture.
Oui.
Est-ce que c'est l'ensemble de l'équipe qui doit participer à la maturation et avoir des réunions un petit peu finir de l'équipe pour la partie conversation? Ou est-ce qu'on peut limiter quand même l'impact sur la charge de l'équipe? Peut-être que tu étais une personne à chaque fois sur une story, faire tourner un petit peu ce rôle-là. Ou est-ce que c'est la troisième version? Ce serait plutôt le Scrum Master?
Alors, c'est aux équipes de choisir, effectivement. Donc, peut-être pas la dernière option, parce que ça ne rentre pas dans les attributs du Scrum Master de faire ça, je dirais. Le mieux, c'est de faire participer...
Ça ne serait pas dans le sens de nous organiser?
Non. Le mieux, c'est de faire participer toute l'équipe. Donc, de faire ça dans ce qu'on appelle des... Je vous en parlerai tout à l'heure. Des revues de backlog où toute l'équipe va participer. Mais on s'aperçoit que ce n'est parfois pas suffisant de garder un temps pour ça. Et donc, ce qu'on peut être amené à faire, c'est créer ce que j'appelle des stories de découverte ou des stories d'analyse qui sont le travail sur le bac de culture. Et de les faire apparaître de façon explicite. qui peuvent être prises par quelqu'un de l'équipe. Alors on peut aussi, en plus de l'équipe, c'est peut-être le moment aussi où on fait participer les parties prenantes. On a besoin de personnes à l'extérieur de l'équipe également.
Donc le bac de départ, donc starting block, c'est l'idée de commencer un sprint dans de bonnes conditions pour être prête. Donc les conditions, c'est l'équipe qui décide si la story est prête. Donc, auto-organisation, c'est l'équipe qui décide si la story est prête. Alors, elle fait ça en fonction de ses propres conditions. Donc, c'est à chaque équipe de définir qu'est-ce qu'elle attend. Donc, généralement, en tant qu'équipe, on va dire qu'il faut qu'elle soit en capacité de la développer, notamment qu'il n'y ait pas de dépendance. On évoquait les dépendances d'équipes extérieures ce matin, c'est un problème. Si l'équipe commence alors qu'elle dépend d'autres personnes qui ne sont pas disponibles, c'est risqué. Donc on va dire que la story n'est pas prête dans ce cas-là. Et puis qu'elle puisse la finir dans le sprint qui vient. Alors je passe sur le sprint, puisqu'on l'a déjà vu. Donc finalement, les résultats, ça va dans un bac de récolte. Le bac de récolte, c'est là où on place les stories finies. Donc elle finit quand? Ses définitions le finissent, elle satisfait à ses conditions d'acceptation. Plus des critères de finition, donc pour faire la nuance entre les deux, les conditions d'acceptation c'est spécifique d'une story,
on transformera ça en test sur la story, donc évidemment les tests sont dépendants, chaque story a des tests différents, par contre les critères de finition c'est des critères de qualité qu'on peut associer à des types de stories qui vont être en gros reprises pour chaque story de ce type. Notamment pour les stories avec du code, on pourra définir, c'est ce qu'on fait généralement dans la définition de fini, qu'est-ce qu'on attend à la fin d'un sprint. Donc c'est généralement le product owner qui dit si la story est finie et qui la passe dans le bac de récolte. Et elle va rester ici jusqu'à ce que le déploiement se fasse, en gros. Alors, ça serait mieux de le faire avant, puisque c'est prêt, on peut se dire, ça serait bien de déployer plus vite. Donc, j'y reviendrai rapidement tout à l'heure. Alors si on regarde la vie de la story avec ces cinq bacs, on a un bac à sable dans lequel tout le monde propose des idées. Évidemment, les idées ne sont pas toujours acceptées. Il peut y avoir des rejets possibles de la part de l'équipe du Product Owner. Et là, il ne paraît pas nécessaire d'avoir des priorités. Les éléments vont rester un temps normalement limité avant qu'on les traite. Le bac de culture, qui sera en fait probablement le plus gros bac, donc là on est dans un état où le product owner dit, c'est pas mal, j'aimerais bien qu'on le fasse, mais par contre ce n'est pas encore faisable par l'équipe. Donc il va falloir le travailler avec les réunions dont on vient de parler, éventuellement estimées, et puis là on a besoin de priorité, puisqu'on va chercher à travailler et à décomposer, ce qui est le plus prioritaire évidemment.
Le bac de départ pour commencer le sprint. Donc là, on peut se dire, l'équipe est d'accord pour dire, oui, oui, c'est bon, on peut partir là-dessus. Pendant le sprint.
Un schéma qui montre qu'au fur et à mesure de la vie des bacs, on va rajouter des informations sur la story. Peut-être au départ, quand la story est dans le bac à sable, il y a juste le nom. Dans le bac de culture, on va rajouter des choses comme le template que vous devez connaître. Donc on va utiliser le rôle et puis montrer, alors généralement j'en ai mis que deux, mais il y a trois rubriques, donc en tant que l'action qui est faite et puis le bénéfice pour celui qui déclenche la story, en tout cas pour un utilisateur.
C'est généralement dans le bac de culture également qu'on va estimer en points si on le fait. Et puis qu'on commencera... Alors pour que ça rentre dans un bac de départ, il faut probablement avoir une bonne idée des conditions de réalisation, qui sont en gros des dépendances soit vers des composants externes, soit vers des personnes extérieures à l'équipe qui vont aider à... À finir la story.
Et puis, donc, typer la story, par exemple, dire c'est une story de type user story, il y a différents types de stories, celle-là, une user story avec du code, on a une définition de fini pour ça, et donc cette définition de fini va s'appliquer à notre story.
Alors, pour diminuer encore la taille du bac de culture, parce que néanmoins, malgré tout ce que j'ai dit, il peut y avoir pas mal d'éléments dedans, donc comment faire ? Alors, je vous rappelle qu'on est dans le cadre d'une livraison, d'une release, donc avec plusieurs sprints. Alors, pour limiter, on peut se dire qu'il y a probablement des éléments qu'on ne va pas faire tout de suite, qui ne sont pas pour la release courante, mais qui seront pour la release suivante. Donc là, c'est typiquement une responsabilité du product owner de dire, si ce n'est pas pour tout de suite, ce n'est pas la peine de le mettre ici, on va le mettre dans un autre bac. On ne le regarde pas, ce bac à sable, bac à glace, on gèle un peu tout ça, on le ressortira quand on en aura besoin. Donc ça permet de limiter la taille du bac de culture et de ne pas polluer l'équipe qui va travailler là-dessus avec des choses qui ne sont pas prioritaires. Elles vont attendre la fin de la release qui peut être dans quelques sprints.
Donc un bac à glace, ça fera encore un bac en plus.
En gros, c'est un outil qui sert à ce que vous faites sûrement et qui s'appelle diminuer le périmètre ou changer le périmètre, donc faire du descopage de story.
Si on regarde à quel moment on prend les décisions, avec nos bacs, ici on a vraiment des idées, les idées peuvent être rejetées évidemment.
À quel moment on a vraiment un engagement? C'est au moment où ça rentre dans le sprint en fait. Entre temps, on a encore des options. Évidemment, le product owner s'il l'a mis là, c'est qu'il souhaite l'avoir, mais il y a plein de raisons. Qui font que peut-être on ne le fera pas, ou on le fera différemment, ou on ne le fera pas tout de suite. Donc on va retrouver peut-être des stories dans le bac à glace, ou carrément dans la corbeille, si on les rejette.
Alors, engagement, engagement, est-ce qu'il y a vraiment un engagement de l'équipe? C'est un débat dans la communauté.
En tout cas, l'engagement qui peut exister, c'est un engagement. Si les stories rentrent ici, on les finit. Peut-être qu'on ne les finira pas dans le sprint là, même si on l'espère, mais on les finira au moins dans le prochain, donc on s'engage à les finir.
Je ne préconise pas d'avoir un engagement sur des stories quand on fait du sprint.
Alors, si vous préférez vraiment les tableaux, si vous n'aimez pas les bacs, on a la même version, la version de ce que je viens de vous présenter avec des tableaux. Et encore une fois, tout ça, c'est un exemple que je vous donne, qui peut être utilisé dans les contextes que j'ai décrits au début. C'est évidemment à vous de faire vos propres tableaux. À rajouter les colonnes qui vous vont bien par rapport à tout ça.
Les indicateurs, avec ces bacs-là, on peut faire un diagramme de bacs cumulés.
Certains connaissent peut-être le diagramme de flux cumulé. C'est une variante du diagramme de flux cumulé qu'on retrouve dans le Kanban. Là, le faire sur les bacs. Regarder l'état soit en point, soit en story sur les bacs. J'ai mis ici à chaque sprint, finalement, c'est mieux de le faire de façon désynchronisée pour éviter les à-coups, parce qu'en fait, si on regarde comment ça se passe le sprint, au début du sprint, on prend tout ce qui est dans le bac de départ et on met tout dans le bac
de sprint. Donc le schéma, selon qu'on fait juste avant ou juste après, il y aura des variations et ça sera peut-être difficile à comprendre. Donc peut-être préférable de le faire toutes les semaines en fait. Ça donne des indications supplémentaires sur l'état des bacs, sur éventuellement les efforts qu'il faut porter. On va voir aussi s'il y a du stock.
excessif. Alors je reviens rapidement sur le stock. En fait, si on regarde bien notre sprint, il y a quand même du stock encore, puisque on a gardé notre planification du sprint, et bien quand on dit au début du sprint je vais faire 9, 10 stories, on a vu tout à l'heure qu'on travaillait peut-être sur 2, 3 stories en même temps, Donc, beaucoup trop, puisqu'on ne va pas travailler dessus tout de suite. Donc, il y a encore du stock. Comment limiter ce stock dans le sprint?
Donc déjà on peut travailler sur les types de stories, donc dire que toutes les stories ne sont pas de la même nature, c'est ce qu'évoquait Laurent avec la notion de classe de service, éventuellement donc limiter et faire des rangées pour ces différents types de stories. Mais pour aller plus loin, on peut mettre une limite explicite sur le sprint. On a vu les CMH tout à l'heure. Finalement, les CMH, c'est quoi? On voit que ce n'est pas la peine d'avoir autant de stories dans le sprint puisqu'on ne travaille que sur deux, trois, peut-être quatre en même temps. Autant mettre cette limite ici. Et donc interdire d'avoir plus que trois stories dans notre bac de sprint, si on considère que trois est la bonne limite.
Ah, qu'est-ce qu'on en fait alors des stories avant? Ça veut dire que ça remet en question quand même la façon de faire des sprints. La planification de sprint est adaptée, c'est-à-dire au lieu lors de la planification du sprint de prendre toutes les stories sur lesquelles l'équipe va s'engager, on se dit on s'arrête à la limite, c'est pas la peine de les planifier en détail, de trouver des tâches même, on a le temps. Donc on s'arrête à la limite et on va dire si c'est 3, on s'arrête à 3. Alors évidemment, il faudra replanifier pendant le sprint ces stories-là pour se mettre d'accord, pour éventuellement trouver les tâches dessus. À quel moment le faire? On peut se dire qu'on le fera dès qu'une story est finie. Dès qu'une story est finie, on va faire une replanification, on va voir la... la prochaine story. Le mieux, c'est peut-être d'attendre la réunion quotidienne.
En attendant, si notre story est finie, on va aider les autres, on va attendre la réunion quotidienne, puis on verra comment on va relancer les CMH avec une nouvelle story après cette réunion quotidienne.
Donc ça favorise les sémages et puis évidemment l'intérêt c'est que ça évite de bloquer, de fixer les stories sur lesquelles on va travailler pendant le sprint sans avoir de possibilité de changer.
Ou en tout cas, si on le fait, c'est très perturbant. Là, il n'y a pas de problème puisque... Les stories ne sont pas encore vraiment considérées comme étant dans le sprint. Alors si on remonte encore un peu en arrière, on peut se dire, c'est bien, on a limité le sprint, mais notre bac de départ finalement, est-ce qu'on ne pourrait pas le limiter aussi? Alors le bac de départ, de toute façon, toutes les stories prêtes, il faut les limiter. Ça ne sert à rien d'avoir 50 stories prêtes, évidemment, puisqu'on va travailler dans un sprint que sur 10, à peu près. Donc on peut se dire, c'est bien d'avoir, en général on se dit, c'est bien d'avoir des stories pour un peu plus d'un sprint, peut-être deux. Donc en général, le bac de départ où il y a les stories prêtes, il faut le limiter sur un sprint normal à 15, 20 stories maximum. Mais avec cette notion de limitation sur le sprint, on peut encore aller beaucoup plus bas, puisqu'il suffit qu'il y ait suffisamment de stories, pour prendre en compte peut-être ce qui va se passer en tout dans un sprint. Donc on peut se dire 3, 6, 9, je ne pense pas faire plus de 9, story en tout cas, en général c'est ce que je fais, donc ce n'est peut-être pas la peine d'en mettre plus. Donc on peut mettre une limite haute qui diminue. Qui diminue la taille de ce bac.
Mais il reste, donc on a vu comment on pouvait déclencher ici avec en gros une story et finis, ce qui revient à avoir une limite basse, en disant chaque fois qu'on arrive à deux, on déclenche une nouvelle planification de sprint qui va consister à prendre une story qui est là pour la mettre là
en la... En se mettant d'accord dessus et la décomposer en tâches, et bien ici on peut se dire aussi qu'il y a une limite basse qui va déclencher la culture en fait. Une limite basse, quand il y a moins de trois stories par exemple ici, on va déclencher du travail ici pour que l'équipe puisse produire des stories qui soient prêtes
Donc on a diminué nos bacs. Alors il reste notre bac de culture. Notre bac de culture, comment diminuer cette taille-là? On a vu le bac à sable, on vient de voir de limiter en amont.
Mais on peut quand même avoir pas mal de stories dedans, puisque je prends l'exemple 10 ou 12 stories par sprint, 5 sprints, ça veut dire qu'on pourrait avoir 60 stories quand même dans le bac de culture. Heureusement, on ne décompose pas tout au début, ce n'est pas l'objectif du tout, on décompose progressivement. Donc on va avoir des gros morceaux. Au début, des gros morceaux, et puis seuls les plus petits morceaux seront décomposés parce qu'ils sont prioritaires. On pourrait le limiter effectivement, par exemple, à une quinzaine d'éléments, ça paraît tout à fait faisable avec les chiffres que j'ai donnés avant. Alors pour aller encore plus loin, la solution c'est d'avoir en fait un niveau supérieur, de dire on a des features, donc les features c'est les plus gros morceaux en fait, les features en gros, si je prends les bacs classiques, c'est à faire, en cours, fini, Dans un sprint, les features, c'est des morceaux qui apportent de la valeur significative, qui peuvent être déployés. Dans un sprint, ça ne sert peut-être pas à grand-chose de travailler sur plus de 2, 3 features en même temps pour l'équipe à la taille que j'ai mentionnée au début. Donc on va limiter le bac de features. aussi.
La technique de décomposition de feature, ce sera pour une autre présentation, je passe là-dessus. Juste pour finir, la big picture, ça nous permet d'avoir des tableaux à deux niveaux, comme on l'a vu tout à l'heure, peut-être au niveau plus produit, là au niveau plus équipe. Et donc avec un bac à sable de départ, les éléments sont alimentés sur... Donc si c'est des gros morceaux, ça va dans les features et dès qu'une feature passe en cours, on peut la décomposer ici. La règle qui peut être ajoutée, c'est que quand on travaille sur une feature dans un sprint, on va la cultiver avant pour qu'elle soit prête pour ce sprint. Et donc, ça sera un déclencheur pour décomposer les grosses stories en plus petites stories. Et ce qu'on livre à la fin finalement, c'est des features qui constituent des choses tout à fait livrables, déployables, donc qui contiennent un certain nombre de stories. Et donc, c'est juste pour finir. Donc, si on veut avoir vraiment un déploiement plus rapide, on peut se dire que ce n'est pas la peine d'attendre. Évidemment, l'idéal, ce serait de ne pas attendre une période de temps de quelques mois pour déployer, mais de déployer dès qu'on a des choses qui sont déployables, parce qu'elles apportent de la valeur aux utilisateurs.
Voilà, donc c'est fini. Les événements du sprint, donc, déjà dans un sprint, on a ce qu'on appelle, alors maintenant ça s'appelle plus cérémonial les événements, donc planification, la revue, la rétro, ce qui est fait déjà de façon habituelle, donc c'était un peu la réponse à la question qui était posée tout à l'heure, on peut faire, donc pour travailler, pour cultiver le backlog, on peut faire des revues de backlog régulières. Par exemple, une bonne façon de procéder, c'est de faire toutes les semaines deux heures de backlog grooming ou de revue de backlog. Pour aller plus loin avec ce que j'ai mentionné, ça revient donc, le principe de limitation sur le sprint revient à faire une réunion de planification bien plus petite, et puis après à faire de la planification sur demande. Et de la même façon, la culture du backlog, plutôt que de la faire à date fixe, on peut se dire qu'on va la faire sur demande quand on est déclenché par la limite basse sur les story prep.
Donc en conclusion, ouvrez les vannes pour que ça soit plus fluide, même dans les canaux.
Donc je crois que c'est l'heure d'aller déjeuner.