Cyrille Deruel
Transcription
Je ne vais pas parler de Kata, je ne vais pas parler de Lego. Et sur cette session, on ne va pas construire d'avion en papier. Je suis désolé. Je me présente, je m'appelle Cyril Deruel, je suis Delivery Manager chez Octo Technologies. Je suis praticien Lean et je suis créateur d'Improve Your Board. Cette session va être de vous présenter 12 mois de résultats d'analyse de board qu'on a reçus. Octo Technologies, c'est un cabinet de conseil. On a un Y comme Poult.
Nous croyons que l'informatique transforme nos sociétés. Nous savons que les réalisations marquantes sont le fruit du partage des savoirs et du plaisir à travailler ensemble. Et nous recherchons en permanence une meilleure façon de faire.
Mon objectif à la fin de cette session, redécouvrir des pratiques de board, ou les découvrir,
soigner et analyser trois douleurs sur un board, sur un vrai projet, et analyser les trois boards qu'on a récupérés. Et derrière, vous faire connaître une pauvre board. Avant ça, je voulais commencer par trois petits warnings. On va parler de bonnes pratiques. La première qu'on a observée, donc une bonne pratique, c'est une pratique qu'on a observée sur un projet et qui a vraiment soigné une douleur.
On va parler de projet, on va parler de mise en place de projet, et ce que je vous demande, c'est de bien accepter qu'un projet, est unique, il possède une équipe spécifique et un contexte particulier. Donc chaque équipe projet, vous ne pourrez pas en fait partir avec ce que je vais vous présenter et le mettre automatiquement en place lundi matin. Je vous demande vraiment d'analyser le contexte de votre projet. Et derrière, les situations et les personnages de ce récit étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite. Tous les bords que je vous montre là, on m'a demandé de les garder anonymes, donc les gens qui me les ont envoyés se reconnaîtront. Mais on ne va pas citer de client et on ne va pas citer de projet.
On va commencer par l'histoire d'Improve Your Board. Ça a commencé il y a un an avec un client qui m'appelle et qui me dit« Voilà Cyril, il y a un truc qui ne va pas sur le projet, il faut que tu fasses voir mes devs. Ça ne décolle pas, je ne comprends pas. » Je dis« Ok, envoie-moi une photo de ton board, je vais peut-être comprendre ce qui se passe. » Il m'envoie la photo et je fais« Bon, à première vue, je suis déçu parce que je ne vois rien. » Je fais« Bon, vu que tu as un problème, Paye-moi un café et je veux voir en fait, c'est quoi, quel est ton problème? Et j'arrive.
Et en fait, le problème, il m'explose aux yeux. On a nos deux colonnes attestées et faites, qui sont blindées de post-it. Et là, on se dit, je pense que juste avec une photo de board, mais une vraie photo complète, on doit être capable d'analyser le statut d'un projet, d'identifier potentiellement des douleurs,
et de proposer potentiellement des solutions.
L'objectif d'Improve Your Board, c'est partager des bonnes pratiques de board qu'on a constatées et avoir une boîte à outils pour répondre à des douleurs.
12 mois de board, on a lancé sur le blog d'Octo un appel à envoi de board au mois de juin. Et les deux constats, donc on a un constat positif qui est que globalement les boards qu'on a reçus sont propres. Ça ne veut pas dire que tous les boards français sont propres. Ça veut dire que les gens qui ont osé nous envoyer des boards assument leurs boards. Je n'ai pas d'idée sur les autres.
Les boards qu'on a reçus vont de spécifications à mise en production globalement. Les boards qu'on a reçus ne se limitent pas à trois colonnes. On va au-delà de trois, quatre colonnes.
À côté, on a eu d'autres surprises.
Très peu de dons.
La definition of done qui vous permet en fait de lister tout ce que vous avez le droit de faire, tout ce que vous avez dû faire pour pouvoir passer une tâche d'une colonne à une autre.
peu ou très peu de limites d'encours. Sur l'exemple ici, vous voyez que la colonne de test commence à s'accumuler.
Et le troisième point qui nous a un peu surpris, c'est très peu de swimline. Globalement, on a reçu un seul board avec trois swimlines, avec des swimlines. Donc les swimlines, c'est ce qui va vous faire une séparation entre les différents types d'activités, complexité de votre projet. Ce que je vous propose, c'est de regarder sur une première douleur ce que vous voyez sur le board et ce que vous auriez fait d'un point de vue type. La première douleur s'appelle quand vous avez la tête sur le guidon.
Un peu de contexte, imaginez que votre projet ait commencé il y a 6 mois, vous avez une équipe de 7-8 développeurs, et la machine commence à s'emballer. Ça commence à accélérer, ça veut aller de plus en plus vite, il y a des contraintes de chaque côté, on commence à s'endetter.
Et tout le monde commence à se focaliser sur l'objectif qui est de livrer l'application.
Quand on regarde le board, on se voit, tiens, on a un board standard qui va de réservoir, spécification, développement, test, pré-prod et terminé. Et la douleur, c'est que votre développeur, à force d'être dans cette accélération, dans cette... vitesse, oublie les bases de la construction d'équipe qui sont de partager les informations, partager les informations fonctionnelles, techniques, faire des revues de code et échanger ensemble. Donc vous commencez à avoir vos développeurs qui sont focaliser chacun de leur côté sur leur module fonctionnel. Ah non, cette partie-là, je ne peux pas en parler. Ce n'est pas moi qui l'ai développée, je ne l'ai pas revue. Demande plutôt à Jean-Michel, je pense qu'il a plus d'informations. Ce qu'on a constaté, c'est que cette douleur-là pouvait être réglée en modifiant votre processus, qui est modélisé via votre board, en rajoutant une colonne à revoir. La colonne à revoir, elle est toute simple.
Un seul step, c'est expliquer, le développeur qui a développé le module va présenter son code à un autre collègue, comme une démonstration, mais juste en tête à tête,
d'un point de vue fonctionnel et d'un point de vue technique. Donc vous commencez à revenir sur une diffusion de l'information, et vous commencez à revenir sur une notion de partage, que ce soit sur l'aspect technique ou l'aspect fonctionnel.
Ce qu'on a bien aimé avec cette technique, c'est que derrière ça, on a eu six effets qui se coulent.
On a vu en fait une diffusion des compétences techniques et fonctionnelles auprès de tous les membres de l'équipe. Donc tout le monde commençait à récupérer, à rattraper son retard sur son projet. On a eu une diminution du nombre de bugs par un phénomène super simple, c'est qu'avant de livrer sur l'environnement, ça avait été testé une deuxième fois. Et là, on se rend compte qu'on avait toute une série de dysfonctionnements qui ont été analysés par d'autres développeurs.
L'émergence de standards, c'est-à-dire qu'on commence à présenter du code, et là vous avez deux experts qui s'échangent et qui commencent à parler, et qui remontent le niveau de discussion, et qui sont en train de discuter sur un cas concret.
Derrière toutes ces discussions, ces échanges, si le problème est intervenu avec un développeur et un autre développeur, c'est que potentiellement les 5 autres devs de l'équipe ne sont peut-être pas au courant du problème qu'il y a là. Donc ces échanges ont permis d'alimenter la comité de pratique, le COTEC, avec la liste de toutes les choses que l'on a vues, qui ne devraient plus exister et qu'on va partager ensemble. Et dernier point, il y a eu un gros renforcement de l'esprit d'équipe où chaque personne de l'équipe s'est rendu compte qu'en présentant l'application à quelqu'un d'autre, il apprenait quelque chose et il faisait apprendre aussi quelque chose à son collègue.
Un deuxième exemple de douleur, la gestion des bugs.
Je vais faire une petite pause. Le bug, il est là.
Avec les flèches gauche et droite. Malgré tous les process qu'on voit, malgré toutes les techniques qu'on met en place sur des projets, il arrive toujours un moment où il faut valider la fonctionnalité. Votre business analyst arrive et vous dit« Je viens de tester les trois fonctionnalités que tu viens de me livrer. » Et pas de bol, il y a un bug sur la fonctionnalité B. Sur ce projet, ce qui s'est passé, c'est qu'ils ont une norme qui est que dès qu'on a un bug sur une feature, on rajoute un mini post-it jaune dessus pour indiquer qu'on a un bug. La douleur, elle n'est pas là. La douleur, elle est, ok, moi je suis business analyst, j'ai déclaré un bug sur la fonctionnalité B, le bug numéro 14. La question est, comment je sais que ce bug, il a été corrigé par le développeur?
Les fonctionnalités A et C ont disparu parce qu'elles étaient validées. Et là, on se retrouve avec le business analyst qui passe tous les matins, toutes les heures, toutes les cinq minutes. Il a ses sept développeurs devant lui. Il fait« mais c'est fini, c'est codé, c'est pas codé».
Et on se rend compte que si l'équipe de dev et les business analysts n'ont pas échangé, n'ont pas trouvé une façon de communiquer, ils sont perdus. Le BA, il se dit« moi j'attends en fait, en tant que personne qui a déclaré le bug, j'attends qu'on vienne me voir pour me dire c'est bon, ton bug il est corrigé». Les devs, ils font « Mais si, je te l'ai dit tout à l'heure, mais tu ne l'as pas vu. » Ils se sont cherchés et à la fin, ils ont trouvé un tips, mais attention, c'est du très très très haut niveau. Le tips est, on va incliner le post-it tout bêtement en fait. Ce qui nous donne deux statuts.
Soit notre bug est corrigé, a corrigé, et le bug est horizontal, et le business analyst dit« moi je ne bouge pas, je sais que c'est chez vous, je vous fais confiance et je sais que vous gérez». Et de l'autre côté, les devs ont dit« voilà, nous on l'a corrigé ton bug, ok, mais à coup de pas, est-ce que tu peux nous valider la correction? » Et en fait, on t'a juste incliné. Ce qui est intéressant, juste cette pratique qui est assez simple, c'est qu'on n'a plus d'attente côté business analyst ou côté développeur, on n'a plus de relance et on retrouve un système de fluidification entre ces deux équipes. Mais derrière ça, ce qu'on a aussi constaté, c'est que les mini-post-it avec l'historisation des bugs ont été historisés sur des feuilles A4. Derrière, ils ont été groupés par catégorie, ils ont été classés. Et derrière, on a vu apparaître des erreurs fréquentes, des fautes d'orthographe, des fautes d'alignement, des problèmes d'IHM, des problèmes avec des jeux de données bien spécifiques. Qui ont permis d'alimenter l'équipe sur ces rétrospectives et se dire, derrière ça, maintenant, il faut qu'on arrive à diminuer les bugs sur les fautes d'orthographe ou les bugs sur les IHM ou le compte bancaire de M. Dupont, à chaque fois qu'on l'utilise, Business Analysis l'utilise, à chaque fois il trouve un bug, pourquoi de notre côté on ne l'utiliserait pas? Cette dimension a vraiment permis d'alimenter en data toutes les rétrospectives des projets, de se poser des vraies questions en se disant comment on va faire décoller le niveau de qualité de notre projet.
Troisième douleur, encore un problème entre les business analysts et les développeurs, deux catégories différentes.
Business Analyst a sorti ses trois fonctionnalités A, B et C. Il les voit avancer, il se dit que c'est parfait. A et B sont en cours de développement, tout va bien. Il repasse un peu plus tard, il fait que A est développée, elle va être bientôt testée, donc je vais la recevoir.
Il repasse le lendemain, il fait que B s'est fait doubler par A et C est passé devant. J'ai vraiment l'impression que ma fonctionnalité n'avance pas.
Est-ce qu'ils ne l'ont pas oublié? Là, on est sur juste trois post-it. Je vous le montre en moins de 10 secondes. Vous prenez le même schéma avec une équipe de 7-8 devs. Vous rajoutez une dizaine de post-it avant-après. Vous êtes complètement perdus. La question du business analyst, c'est, excusez-moi, mais ma fonctionnalité B, vous y pensez, parce que ça fait au moins deux mois qu'elle traîne dans le tableau. À partir du moment où vous êtes inquiet, vous avez toujours tendance à bien exagérer les choses.
Et les devs disent « on l'a pris ce matin, ta fonctionnalité, je ne vois pas ce qui matche, on ne voit pas le souci ». L'un des premiers réflexes, c'était de se dire« ok, à partir de maintenant, ce qu'on va faire, c'est qu'on va rajouter la date sur les post-it. » Et la date sur les post-it, un, c'est une galère. Deux, quand vous commencez à avoir un mur de post-it, mais vraiment rempli avec des fonctionnalités, aller identifier la date des post-it sur chaque post-it et faire une soustraction par la date du jour, c'est juste une plaie.
Et le type, ce qu'on a vu, c'est un truc tout bête, ça s'appelle la varicelle. Ça a été surnommé la varicelle. C'est que chaque jour qui passe, vous rajoutez un point rouge sur votre post-it, sur les colonnes que vous identifiez comme colonnes de douleur, où vous avez une perte de confiance entre votre business analyst et votre équipe de développement.
Là, ce qu'on voit, c'est que la fonctionnalité C, elle est passée en deux jours. Donc le matin, avant ou après le stand-up, vous choisissez un standard et vous dites, voilà, maintenant, quelqu'un va mettre des gros points rouges sur chaque post-it de la colonne en cours de développement. Et très facilement, vous voyez que la fonctionnalité B, en fait, ça fait 15 jours qu'elle est coincée dans votre colonne en cours de développement et qu'elle n'avance pas et qu'il va sûrement falloir s'en occuper parce qu'à ce rythme-là, elle peut encore potentiellement rester 15 jours. C'est que chaque jour qui passe, vous rajoutez un point rouge sur votre post-it, sur les colonnes que vous identifiez comme colonnes de douleur, où vous avez une perte de confiance entre votre business analyst et votre équipe de développement.
Là, ce qu'on voit, c'est que la fonctionnalité C, elle est passée en deux jours. Donc le matin, avant ou après le stand-up, vous choisissez un standard et vous dites, voilà, maintenant, quelqu'un va mettre des gros points rouges sur chaque post-it de la colonne en cours de développement. Et très facilement, vous voyez que la fonctionnalité B, en fait, ça fait 15 jours qu'elle est coincée dans votre colonne en cours de développement et qu'elle n'avance pas et qu'il va sûrement falloir s'en occuper parce qu'à ce rythme-là, elle peut encore potentiellement rester 15 jours.
La varicelle dans le temps, ce qu'on a constaté, c'est qu'en fait, on ne l'attrape qu'une seule fois par colonne. À partir du moment où vous avez un problème de confiance entre les business analysts sur la partie en cours de développement, Vous mettez en place la varicelle, ça va durer 3-4 semaines. Au bout de 3 ou 4 semaines, vous avez agrégé suffisamment de données pour redonner un sentiment de confiance et pour que la confiance revienne entre le business analyst et l'équipe de développeurs.
Ce qu'on a vu, c'est que ça ne marche qu'une seule fois par colonne. Mais ce qu'on a aussi constaté, c'est que les business analysts se faisaient aussi reprocher de mettre trop de temps à recéter des fonctionnalités. Donc on peut reporter la varicelle sur la colonne en cours de test. Cette fonctionnalité, ça fait trois jours, trois mois que j'attends qu'elle soit validée. Donc vous avez plusieurs phases, vous pouvez le mettre en place. L'idée, c'est de vraiment réussir à sortir simplement un modèle de mesure qui nous permette visuellement de constater ce qui nous arrive, ce qui se passe sur notre bord dans le temps. Et derrière, dès que la confiance est revenue, vous repassez à autre chose, et ce problème va disparaître.
On a lancé le projet au début de l'année, avec une récupération de bord en fin d'année 2012. Ce qu'on a constaté, c'est que les 15 pratiques qu'on a identifiées sur des bords,
La colonne à revivre. Mais on a aussi des choses encore simples comme la couleur des post-it, les carnets liés, tout ce qui est gestion des anomalies. En fait, on a un point commun, c'est que ce ne sont que des pratiques simples. C'est-à-dire que décaler un post-it d'un quart de tour, ça reste quelque chose de très simple. On a rencontré d'autres pratiques chez des clients où ils décalaient le post-it d'un huitième de tour pour se dire, voilà, cette fonctionnalité-là, je vais en parler au prochain stand-up.
Faire des checklists, ça reste toujours quelque chose de simple. Une bonne pratique sur un board sera toujours quelque chose de simple que vous apprendrez tout de suite.
Ce que je vous propose, c'est maintenant que vous avez vu 2-3 tips sur où on va par rapport à la réception d'une photo d'un board, c'est de parcourir 3 boards ensemble et trouver les 3 points forts et les 3 axes d'amélioration d'un board.
Premier bord.
Est-ce que quelqu'un veut se lancer?
Alors, vous ne voyez rien.
Vous ne voyez pas grand-chose, c'est fait exprès. C'est fait exprès pour deux raisons. L'idée, ce n'est pas de rentrer dans le détail, c'est de faire une grosse vue d'ensemble par rapport à votre board.
Le premier point qu'on a aimé, c'est sur ce board, vous voyez que les noms des développeurs sont regroupés en spec, dev, recette. Les noms des développeurs sont identifiés sur la colonne en cours de dev, ce qui fait que chaque développeur communique auprès de ses collègues où ils sont et implicitement limite leur WIP à deux tâches max par développeur. Donc vous n'avez pas un WIP qui varie en fonction du nombre de personnes. Avec les congés, vous êtes obligé de modifier tous vos calculs. Vous savez que vous avez 4 développeurs en cours sur ce projet-là. Vous savez que chaque développeur est autorisé à travailler sur 2 tâches max. Au-delà de 2 tâches max, vous avez un problème dans votre processus.
Le deuxième point qu'on a aimé sur ce board, c'est les DOD. Alors il y a une fin sur les DOD, donc vous voyez tout simplement les DOD, ça va être la checklist de tout ce qu'on doit faire pour passer d'un état à un autre. Et sur la colonne en test, ici, ils nous ont laissé un point d'interrogation. Juste pour se dire, est-ce qu'on allait analyser et voir le point d'interrogation? Ils avaient un doute, ils ne savaient pas quel DOD mettre, ils savaient qu'ils devaient mettre un DOD sur cette colonne. Et ils nous ont dit, on va mettre le post-it, on verra bien ce qu'on met. Mais au moins, ils ont assumé le fait de ne pas vraiment savoir ce qu'il y avait à faire sur ce point-là.
Une des douleurs, c'est sur ce board, sur la colonne test, et ça c'est un cas qu'on a vu très fréquemment, le nombre de post-it en cours de test est juste impressionnant. Ici, si vous ne relevez pas une dizaine de bugs, c'est que soit vous n'avez pas testé, soit vous avez un niveau de qualité qui est juste exceptionnel, ou un outil d'analyse du code qui est présent et qui remonte, qui a empêché toute dette technique.
Deuxième inquiétude.
Non vérifié, donc on est juste sur du sentiment par rapport à ce qu'on peut constater sur une photo, c'est le nombre de user stories qui sont en spécification. Et donc là, vous êtes en train de générer un stock énorme. Et ce que vous voyez, c'est que vous avez globalement un goulot d'étranglement au niveau de développement. En amont, on est prêt à alimenter fortement l'équipe de développement, donc on est sûr qu'ils ne seront jamais à sec, au moins quelques semaines. Par contre, en aval du flux, on voit bien qu'on a un manque de l'équipe de développement.
La bonne nouvelle, c'est sur la dernière colonne en prod. On a été étonné de voir que les post-it sont organisés par couleur. Donc on a imaginé qu'on était sur des couleurs sur des modules fonctionnels. Donc des points bien spécifiques de l'application. Il rentre dans votre processus de développement. Ils sont chamboulés dans tous les sens. C'est-à-dire que celui qui retrouve un code de couleur dans la colonne de test ou les colonnes d'avant, il est très fort. Mais en sortie de tout votre fonctionnement, vous retrouvez quelque chose de classé par couleur verte, jaune et rose.
Deuxième borne.
Un board amusant, parce qu'on n'a pas compris pourquoi il y avait un pilier au milieu. Le pilier était là avant l'arrivée du projet, ils l'ont gardé. À droite, le dev. À gauche, les specs. C'est le hasard.
On va commencer par les bonnes nouvelles sur le dev.
Ils ont un WIP par case. Donc au lieu de mettre un numéro, ils se sont dit on va créer des cases à la taille de nos post-it pour dire voilà, vous ne pouvez pas dépasser 4 tâches en cours sur la phase de développement.
Et ça, ils le reproduisent sur la colonne d'après, donc la colonne revue de code, où ils sont interdits, pareil, de passer au-delà de 5. C'était 5 avant, je n'ai plus compté. On a aimé aussi le calendrier qui est en bas, qui a permis à toute l'équipe d'être au courant de toutes les grosses dates de livraison, pas de planter de semaine d'itération, ce n'est pas cette semaine qu'on a une démo, ce n'est pas la semaine dernière. Ce qu'on a constaté aussi, c'est qu'il communiquait à travers ce calendrier sur les dates des congés. Donc en fait, juste en regardant le calendrier, vous étiez capable de savoir qui était présent telle et telle semaine. Vous étiez capable de connaître les grandes dates, comités de pilotage, grandes démos et grandes phases de mise en prod de votre projet.
Et tout en bas à droite, là j'avoue on a zoomé un petit peu, on a un bac rouge, donc on a un petit bout de bac rouge. qui nous a...
Pareil, qui est whipé avec des cases, donc vous n'avez pas le droit d'avoir plus de 3 informations en cours dans le bac rouge.
Qui est en fait la base de l'amélioration continue sur ce projet-là. Point intéressant, on a bien des dots qui sont en haut, on les retrouve. Et derrière, aujourd'hui, on se retrouve avec des réflexes qui font que les dots et la limite d'encours commencent à être des choses qui sont standards et non négociables sur la mise en place d'un board.
Point à revoir, sur toute la partie spécification, on a quand même, comme tout à l'heure du stock, on voit bien qu'on est sur un mode où on commence à pousser, on est plus en fonctionnement poussé, en flux poussé qu'en flux tiré, où même si on a senti qu'on devait être en démarrage d'une itération,
On se retrouve ici avec une vingtaine de post-it qui sont prêtes à être développées. Et ici, une dizaine de post-it qui vont pas tarder à être prêtes. Et derrière, encore d'autres séries de post-it qui vont être bientôt prêtes. Et on imagine qu'encore en amont, ils ont déjà fait une planification sur plusieurs semaines et qu'ils sont déjà prêts pour aller très très loin.
Troisième board.
Et dernier, celui-là, assez compliqué.
Compliqué dans le sens où il n'y avait pas grand chose à redire. Vous avez des donnes, mais vous allez Plus loin, c'est que vous avez des DOD et vous avez un template pour écrire vos definitions of DOD.
Et vous ne passez pas à côté.
Vous avez en haut à gauche
Une légende de la couleur des post-it. Et en zoomant, ce qu'on voit, c'est que le post-it bleu, c'est le post-it de gestion de la dette. Donc, en un coup d'œil, vous êtes capable de voir qu'il y a 5 post-it de dette et d'amélioration de désendettement de votre application. Vous avez une swimline et la swimline représente un type d'application. Donc là, on va être sur la partie mobile. Ici, on est sur un autre type. Et ils ont utilisé les couleurs pour se rendre compte, pour représenter les différentes swimlines et les différentes activités sur le projet. On n'a pas trouvé de point négatif sur ce board. On aurait pu gratter pour essayer de remonter le niveau.
On a d'autres faits intéressants. C'est que vous avez un WIP implicite.
Si on reprend l'activité sur mobile, vous avez 4 lignes de mobile. Donc vous n'avez pas le droit de rentrer plus de 4 post-it en même temps. Et votre processus, mathématiquement et par rapport à la taille des cases qui ont été faites, font que vous maîtrisez ce qui va rentrer dans votre processus de développement.
Ce qu'on a appris d'Improve Your Board, c'est que plus on voit de board, plus on en apprend. On a même demandé des explications sur... Je vous disais tout à l'heure, le huitième de post-it qui tourne, on n'a pas compris pourquoi il est post-it qui était décalé d'un huitième de tour et on nous a expliqué. Donc on est vraiment rentré sur un échange entre les gens qui nous ont envoyé leur board et nous, les analyses qu'on avait faites et notre base de connaissances. Comme je vous le disais, on est habitué à avoir des pratiques. Donc il y en a quatre sur lesquelles on est globalement... On vous dira que ça ne va pas, qu'il faudra les mettre. Tout ce qui est Definition of Done. Donc tous les gens qui nous ont répondu, non mais c'est bon, la Definition of Done, elle est implicite, tout le monde la connaît. Derrière, en grattant un petit peu, on se rend compte que toute la logique d'amélioration continue, elle n'est pas là. On s'assoit dessus et on considère que ça va s'améliorer tout seul.
La couleur et le contenu des post-it. Là-dessus, vous voyez tout de suite sur 2-3 bornes que la couleur des post-it va jouer. Soit c'est des différentes couches d'applications iPhone, Backoffice ou autres, mais ça peut être des modules fonctionnels et ça vous permet d'avoir une bonne vision de votre projet. Et les swimlines qui vont être accrochées à la couleur des post-it ou au minimum la swimline correction des bugs.
Derrière, on a réussi à associer toute une série de douleurs à des bonnes pratiques. Sur une douleur présentée à une équipe, on est capable de remonter la bonne pratique qui a permis sur des projets de supprimer cette douleur. On ne s'engage pas à être des docteurs qui vont corriger toutes les douleurs de tous les bords. Mais quand on a déjà rencontré une douleur, on a au moins une pratique qui a fait ses preuves dans le cadre d'un projet. Parfois, il faut peut-être l'adapter. On a réussi à... diffuser nos pratiques en interne et surtout on est content c'est que les pratiques qu'on a diffusées aux gens qui nous ont envoyé leur board, ils les ont appliquées et ils nous ont renvoyé un board. Donc on a vu une évolution, on a vu quelques changements, donc c'est des changements principalement sur les DOD, DOD et Swimline sur ce que je viens de présenter au-dessus. Et si vous avez envie d'essayer, l'article de blog est toujours disponible sur Improve Your Board sur le blog d'Octo.
4 minutes de la fin dans le timing. Mon challenge, c'était de vous faire découvrir ou redécouvrir des pratiques de board. Je pense qu'on est tous OK. Celui qui n'est pas OK, il lève la main.
On a soigné trois douleurs de projet et on aura analysé ensemble trois boards.
Et je vous aurais fait découvrir Improviant Board.
Est-ce que vous avez des questions avant de courir aux autres sessions?
Merci.