[Shape Up] Organisez votre équipe de dév avec cette méthode efficace - Recap 5/5

Bonjour à tous, on se retrouve dans cette dernière vidéo sur ShapeUp où on va essayer de condenser tout ce qu'on a vu en 10 minutes. Donc cette vidéo elle est autant pour ceux qui débarquent, qui n'ont pas vu les vidéos précédentes et qui veulent avoir un aperçu de cette méthode que pour ceux qui l'ont déjà vu, qui ont vu toutes les vidéos complètes et qui veulent avoir finalement une synthèse. Donc c'est parti, on va essayer de tenir le chrono en moins de 10 minutes. Donc ShapeUp, je vous rappelle, c'est un livre qui est sorti... il y a quelques, en 2019 je crois, 2020, par BESCAMP. Donc c'est leur méthodologie, c'est la formalisation de leur méthodologie pour livrer des produits logiciels qui ont de l'importance. Donc le livre est disponible gratuitement sur Internet, donc vous pouvez le télécharger et le lire s'assied très facilement. Donc je ne peux que vous inviter à le lire. Pour faire très simple et avant de rentrer dans le détail, Ça, c'est ce qui résume bien la méthode ShapeUp. C'est qu'on va avoir pendant six semaines une phase principale où une partie des équipes va faire du shaping, une autre partie des équipes va faire du building. Deux semaines de respiration, de cool down, où on va prendre les paris afin de démarrer le cycle suivant. Ça, c'est vraiment l'image à retenir sur ShapeUp. Cette illustration qui apparaît sur la couverture du livre, c'est un petit peu comment l'idée se matérialise au fur et à mesure du cycle. Au début, c'est vague. ça prend forme avec un pitch, on paille dessus et ensuite cette grosse patate, on vient là, on vient découvrir, on vient partir à sa découverte et on vient mettre des petits scopes qui contiennent des tâches et on vient livrer ces scopes au fur et à mesure. Donc on va revoir les grandes parties, une introduction, une partie 1 shaping, une partie 2 betting, la partie 3 building et ensuite la conclusion. Donc l'introduction elle est C'est assez rapide. Il part du principe que les métrodes traditionnelles, soit Catban ou aussi plein de méthodes inspirées autour de l'agilité, ça ne va pas. Il y a toujours des tickets qui débordent. Ça prend beaucoup de temps d'entretenir ces tickets, de les revoir et finalement un backlog qui devient interminable et des tickets qui ne sont jamais traités. Donc ils partent du principe qu'on part sur des cycles de 6 semaines. Ils ont beaucoup étiré sur cette durée et c'est la durée finalement qu'ils ont choisie qui est suffisamment longue pour faire des choses conséquentes et suffisamment courte pour voir l'arrivée dès le début du cycle. La première partie qui est vachement importante c'est la partie shaping. Le but ça va être de faire un petit peu la conception de la feature qu'on veut avec le bon niveau d'abstraction. Donc pas trop précis. pour éviter que les designers et les développeurs n'aient aucune place à leur créativité et soient uniquement des exécutants, mais pas trop abstraite non plus pour justement qu'ils sachent déterminer ce qui est important, ce qui n'est pas, et pas qu'il y ait des allers-retours pendant le cycle. La grosse différence, c'est qu'on ne va pas parler d'estimation, donc on ne parle pas d'une feature et on détermine un chiffre. Là, c'est l'inverse, on détermine un chiffre des 6 semaines et ensuite, on réfléchit à ce qu'on peut faire dedans. Donc, c'est ce qu'ils appellent l'appétit. Derrière, c'est que les équipes, avec cette méthode, elles se responsabilisent beaucoup plus. Et derrière, c'est que le risque aussi est mesuré parce que finalement, on prend un risque que de 6 semaines et si ça ne marche pas, on a un coupe-circuit qui dit que le cycle est terminé, on passe à un nouveau sujet la semaine d'après, il n'y a pas de négociation possible. L'introduction est vastement bien faite. La partie suivante, enfin la première partie plutôt, c'est la partie shaping et donc l'auteur va rentrer en détail en fait dans la méthodologie pour réaliser à la fin un bon pitch afin que l'équipe de designers et de développeurs aient tous les éléments pour avancer. La première partie, ça va définir quelques principes fondamentaux. L'abstraction, on en a déjà parlé. La première propriété, c'est que c'est brut. Il ne faut pas qu'il y ait trop de détails, c'est brut. Mais en même temps, deuxième propriété, il faut que ce soit résolu, il faut qu'on comprenne quel est l'output de la feature. Et le troisième, c'est cadré. C'est-à-dire qu'on va indiquer ce qu'il y a à faire, évidemment, mais on va aussi indiquer ce qu'il n'est pas à faire pour éviter des débordements dans le pitch. Deuxième sous-partie, c'est la mise en place d'un périmètre. Donc il y a l'appétit dont j'ai parlé, qui est très important à mettre en place. C'est un temps fixe avec un périmètre variable. Pendant la phase de shaping, on va voir tout ce qu'on peut mettre et les compromis qu'on peut faire. Gardez en tête que bien c'est relatif, on peut toujours faire mieux. Un exemple qui est assez parlant qui illustre ce concept-là. Grosso modo, quand vous avez faim, un hot dog, c'est bon. Voilà, tout simplement. Et un autre point, c'est la réponse aux idées brutes, c'est que traditionnellement, quand il y a des nouvelles idées, vous allez prendre le temps de formaliser ça sur le ticket, donc ça prend du temps. Là, l'idée, c'est de ne rien formaliser en avance, de dire intéressant, si c'est vraiment important, la bonne idée reviendra. Mais pour l'instant, il y a d'autres sujets qui sont prioritaires maintenant. On ne prend pas d'avance et on ne passe pas du temps à définir des choses importantes. qui seront peut-être importeux. Un autre concept intéressant, c'est la manière de répondre aux idées brutes. Traditionnellement, on va vous transmettre des idées et vous allez peut-être passer du temps à écrire des tickets ou à enquêter là-dessus. Là, l'idée, c'est de se dire, est-ce que cette idée, elle est prioritaire maintenant ? Si elle n'est pas prioritaire maintenant, on n'y passe pas du temps dessus. Un concept important, c'est les bonnes idées ou les idées prioritaires, elles reviendront quoi qu'il arrive sur le devant de la table. Donc, si cette idée, est vraiment importante, elle reviendra à un moment donné. Troisième sous-partie, donc trouver les éléments. Alors c'est important dans cette étape de partir à la bonne vitesse. Il parle de s'entourer avec finalement des profils relativement seniors à expérimenter dans l'équipe, avec une personne à qui vous allez bien vous entendre pour chipper, pour avoir la même approche. Important également d'avoir un profil technique, en tout cas d'avoir une sensibilité technique, puisque... Finalement, dans cette partie conception, il y a toute une partie recherche utilisateur, recherche de produits, de fonctionnalités, mais il y a également comment lever les inconnus, comment anticiper un maximum les questions que les développeurs vont se poser. Breadboarding, c'est ces petites plaques en électronique qui permettent de prototyper. Donc, ceci dit, on ne cherche pas forcément à faire quelque chose d'industriel dès le début, on cherche vraiment à faire un prototype dans ce shaping. Donc, décrivez les choses de manière grossière et ensuite, laisser la place aux designers, aux développeurs, c'est eux qui l'industrialiseront. Ce qui est important, c'est de leur expliquer le cœur, l'essence de la feature. Ensuite, une partie très importante sur les trous de lapin et sur les risques, la phase de shaping, il faut vraiment tordre le problème dans tous les sens, se demander où est-ce qu'il y a des pièges, comment lever ces pièges, est-ce que c'est important, est-ce que ce n'est pas important, donner des recommandations, déclarer ce qui n'est pas dans le périmètre, ça c'est vraiment très très important. Et s'il y a une expertise technique à aller chercher, là encore, c'est le rôle du shaper à aller chercher cette expertise pour anticiper un maximum les risques. Une fois que vous avez fait ça, vous êtes prêt à écrire le pitch. Et le pitch, il faut garder en tête de manière simple, c'est vraiment le développement de la feature en slow motion. Expliquer vraiment étape par étape qu'est-ce qu'on attend de cette fonctionnalité. Donc bien décrire le problème. bien décrire le périmètre, l'appétit, expliquer la solution, expliquer les potentiels pièges à éviter et tout ce qui n'est pas compris et qui ne sera pas à faire, qui n'est pas à inclure dans cette fonctionnalité. Ça c'est la première partie, c'est la partie shaping, tout simplement. La deuxième partie, c'est la partie betting, donc elle est assez simple, dans ce chapitre l'auteur il revient sur quelques... fondamentaux en fait du concept de la méthode Shape-Up. Le premier c'est qu'on fait des paris, on ne fait pas de backlog, je le redis, mais il n'y a pas de backlog à maintenir, c'est une perte de temps. Il peut y avoir des sources, des notes, c'est-à-dire décentralisées pour garder des bugs ou des choses comme ça, mais les pitchs en soi, ce qu'ils préconisent, c'est de ne pas anticiper l'écriture des pitchs. On fait des paris, les paris c'est sur l'instant. et on n'anticipe pas à plusieurs mois parce que les choses évoluent vite. Deuxième sous-partie, c'est la table des paris. Donc là, ce qu'il explique, c'est qu'il y a grosso modo les deux fondateurs, plus des profils très seniors, qui se réunissent autour de la table, qui reçoivent tous les pitches qui ont été écrits pendant le cycle précédent, et on décide quel pitch est important maintenant et prioritaire, et vaut le coup, et sur lequel on va parier. En faisant ça, on parie et donc on s'engage à ne pas interrompre les équipes qui vont travailler sur ces pitchos-là. C'est un engagement très fort qui n'est pas forcément évident à tenir. Deuxième point, c'est qu'à la fin du cycle, on débranche la prise. Il n'y a pas de rallonge ou autre. Il y a trop de risques. Finalement, on pense qu'il y a 5% à faire et finalement, les 5%, à la fin, il y aura encore 5% et ça ne finit jamais. Vous êtes sûrement déjà passé par là. Donc à la fin du cycle, livrer, pas livrer, on arrête et on passera à la fois suivante. Et ça c'est un concept très fort et très important et qui permet finalement à la fin d'avoir un état propre où la beating table se réunit, elle décide des pitches qui sont frais, qui sont neufs pour avancer. Une fois qu'on a ça, une fois qu'on a ces concepts-là, derrière les pitches, il y a trois modes de... possible. Un mode R&D où il n'y a pas forcément de livrable à la fin, c'est plus une exploration sur quelque chose d'inconnu, en général fait par un profil un peu plus senior. Ensuite, il y a un mode production, donc ça c'est le mode classique. À la fin, on attend une feature, qu'elle soit livrée a priori au client, mais pas forcément. Et ensuite, on peut aussi avoir des cycles en mode clean up. Donc le mode clean up, c'est simplement on vient résoudre des bugs qui sont trop importants, on vient améliorer, on vient racheter là des techniques pendant tout un cycle. parce que ça devient plus possible d'avancer sur d'autres choses. C'est la partie 2, betting, qui se fait pendant la période de cooldown, une période de deux semaines, où les gens font ce qu'ils veulent, entre guillemets, mais on en parlera juste après. Troisième partie, c'est la partie building, c'est la partie la plus importante qui est décrite dans le livre, et ça donne plein de conseils pour accompagner les équipes à mener à bien cette partie-là. Première partie, c'est de faire en sorte que les... que l'équipe soit responsable, pardon. À travers cette méthode, on assigne des projets avec une vue d'ensemble, on n'assigne pas des tâches, ce qui donne plus de liberté aux équipes. Il faut bien se mettre d'accord sur la définition du donne, ça c'est assez classique dans n'importe quelle méthode. Ne pas avoir peur au début de laisser 2-3 jours à l'équipe de trouver ses repères, de comprendre le pitch, d'explorer des choses, c'est pas grave s'il n'y a rien qui sort au bout de 2-3 jours. Et ensuite, contrairement à d'autres méthodes, on va peut-être faire toute la conception et tous les tickets en amont. Là, il faut garder en tête qu'il y a toujours des tâches inconnues qui vont être découvertes au fur et à mesure. Et ça, ça fait partie. Il faut accepter ça. Il ne faut pas s'en inquiéter. Deuxième partie très importante, c'est commencer par avoir une partie done dès le début. Donc faites une démo sur une partie complète. Prenez une micro-feature. et développer là de bout en bout pour vous mettre dans le bain et aussi être sûr d'avoir bien saisi le pitch. Ne pas s'embêter au début à faire un design pixel perfect. En fait les choses grossières, la partie design, c'est quelque chose qui prend beaucoup de temps et si en cours de route ça change, ça reprendra beaucoup de temps à la fin donc il vaut mieux amener cette couche de peinture à la fin. Et ensuite démarquer au milieu. Donc ça démarre au milieu c'est en fait commencer avec les sujets les plus inconnus. Ça, c'est un concept très important. Il y a plein de choses qui vous semblent être naturelles et faciles à faire. Commencez avec les choses qui sont le plus risquées. Dérisquez-les au maximum. Passez du temps parce que potentiellement, ça va avoir des conséquences importantes sur l'architecture de votre solution. Une fois que vous avez fait cette démo, la troisième sous-partie, ça va être comment organiser le travail. Il ne donne pas de recommandations très précises. Ce qu'il préconise, c'est d'organiser déjà par structure, par typologie. de sujets et pas de répartir le travail par personne. Ensuite, il y a plein de conseils pour savoir si les scopes justement que vous avez définis sont corrects. Et grosso modo, c'est que les discussions sont fluides, qu'il n'y a pas d'ambiguïté. Et voilà. Une autre partie, c'est la partie sur la progression. Comment communiquer la progression sans être interrompu à chaque fois. Donc le but, ce n'est pas d'avoir des tickets, d'avoir le principe de ticket comme on peut l'avoir dans d'autres méthodologies, parce qu'il y a plein de tâches qui vont arriver au fur et à mesure. Et ce qui est intéressant pour ça, c'est qu'ils utilisent la métaphore d'une colline où chacun des scopes qui ont été définis précédemment peut se positionner sur la colline. Quand vous êtes en bas de la colline, vous n'avez rien commencé. Ensuite vous montez un peu sur la colline, c'est que vous avez commencé à déboursailler, à comprendre ce qu'il en est. Quand vous êtes en haut de la colline, vous avez dérisqué et vous avez des idées très claires, il n'y a plus d'inconnus, vous savez maintenant comment passer à l'implémentation, à l'exécution. Et c'est la descente de la colline qui représente ça, où plus vous allez descendre de la colline, plus vous allez livrer l'implémentation. Donc ce n'est pas forcément évident, puisque quelquefois en montant on se rend compte qu'il y a plein d'inconnus. mais ça permet de visualiser l'avancement de l'équipe. Une personne extérieure aussi va pouvoir voir où est-ce qu'on en est, s'il y a des sujets qui bloquent, et pouvoir apporter son aide. Partie suivante, c'est décider quand on s'arrête. Alors, c'est vraiment pas évident pour des profils de builder de décider où s'arrêter, parce qu'il y a toujours des choses à faire, à améliorer. Ce qu'il faut, là où il faut les accompagner plutôt, c'est le dire, bah... par rapport à ce qu'on avait avant, par rapport à ce qu'ont les utilisateurs aujourd'hui, est-ce qu'on a mieux ? Si on a mieux, c'est déjà une victoire, c'est déjà un positif. Ce n'est pas parfait, mais c'est positif. Limiter les... faire en sorte de faire des trade-off. Donc ça, c'est l'image un peu de... on prend le marteau et on tape sur le... on tape sur le périmètre, on essaie de trouver des raccourcis, on essaie de trouver des compromis pour réussir à livrer et ne pas dépasser la deadline. Et ensuite, la dernière partie, Move On. Ça vient simplement expliquer que forcément quand vous allez livrer des choses, il y a plein de gens, potentiellement des utilisateurs, qui ne vont pas être contents, qui vont se manifester. Laissez couler. Si c'est vraiment grave, ils se manifesteront encore. Et dans ce cas-là, ne partez pas à résoudre immédiatement les problèmes. Respirez, prenez le temps de faire du shaping pendant un cycle sur les problèmes qu'ils ont montés et après avancez dans le système. Faites vraiment confiance en process. Je reviens du coup sur le timing, c'est que du coup il y a un cycle de 6 semaines, où une partie de l'équipe va faire du shaping, une partie va faire du building, 2 semaines de cooldown, donc le cooldown c'est là où toutes les équipes vont pouvoir un peu souffler, elles sortent d'un cycle assez intense, elles vont pouvoir souffler, elles vont pouvoir faire des petites tâches qu'on n'a jamais eu le temps de faire, des petits réfactos, un peu de documentation, un peu de formation, rachat de des techniques, etc. Et donc cette partie de cooldown elle est... elle est très importante et il ne faut surtout pas la négager. Et donc on arrive à la dernière partie. La dernière partie du livre, ça rappelle un petit peu les concepts clés de la méthodologie Shape Up. Donc on va les revoir ensemble. Dans la première partie Shaping, il nous explique le concept, qu'est-ce que c'est qu'un travail shapé. Il insiste bien sur le fait qu'on définit un appétit et surtout pas des estimations. Les estimations, très peu de gens sont bons là-dessus, donc on arrête avec ça. Très important de trouver le bon niveau d'attraction et ensuite de faire en sorte que le pitch soit fait de manière grossière, avec une vision vraiment grosse maille pour ne pas donner trop de détails à l'équipe et vraiment se concentrer sur le cœur du problème. Deuxième partie, betting, on fait un pari, on donne six semaines à l'équipe. Si pendant six semaines, ce n'est pas livré, on arrête là. En contrepartie, on leur garantit aucune interruption majeure. Et ce cycle-là, c'est 6 semaines avec une période de cooldown de 2 semaines. Et enfin, la dernière partie, la partie du Ling. Les équipes, ça va être un designer et un développeur, voire deux développeurs. Ça va dépendre des sujets. Ce qui va être important, c'est de récupérer les projets et de les découper en scopes. Ensuite, les différents scopes, de les positionner sur la colline. Est-ce qu'on est en train de lever les inconnus, donc on monte la colline, ou est-ce qu'on est en train d'exécuter et d'implémenter ? On est dans la descente. Et surtout, très important de communiquer sur les inconnus, de ne pas laisser un sujet en bas de la colline, de s'y attaquer dès le début. Et à l'inverse, quand on est en phase d'implémentation et qu'on a encore plein de choses à faire, prendre son marteau et taper pour faire entrer tout ça dans les délais. Donc voilà pour la méthode Shape-up. Trois grosses parties, Shaping, Betting, Building. J'espère que ça vous a un peu éclairé, que ça vous a soit d'une part donné envie de lire le livre en détail pour vraiment avoir toutes les subtilités. Moi ce que j'ai fait c'est un résumé relativement rapide et express. Si vous l'avez déjà lu, j'espère que ça vous a rafraîchi. un petit peu les idées pour pouvoir le faire, tout simplement. Allez, je vous dis à la prochaine, et n'hésitez pas, si vous avez des retours ou des choses à partager, je suis là. Allez, à plus !

📺 Dans cette vidéo, nous terminons notre découverte d'un livre génial sur l'organisation d'une équipe de Dév : Shape Up, Stop Running in Circles and Ship Work that Matters de Ryan Singer (Basecamp). 


🏋️ Dans cette vidéo, on a abordé (entre autres) :
- le shaping
- le betting
- le building
...


Sur le livre : 
Site officiel : https://basecamp.com/books/shapeup


Maxime Pawlak
Curious CTO
https://twitter.com/maxime_Pawlak
https://www.twitch.tv/maxime_patate
https://maximepawlak.medium.com

Abonnez-vous à ma newsletter afin de retrouver toutes mes meilleurs lectures et découvertes ! C'est très intéressant et c'est toutes les semaines : https://maveille.substack.com/

00:00 Bonjour
02:02 Introduction
04:01 Part 1. Shaping
08:50 Part 2. Betting
11:39 Part 3. Building
17:17 Conclusion