C’est hyper intéressant ton lien pratique sur du TS, j’ai beaucoup aimé l’approche. Pas évidente car nouvelle pour moi, mais j’adore découvrir de nouvelles choses, merci !
Note: c’est PARCE QUE Typescript est un « vrai » langage orienté Objet et pas orienté Class que tout ça est possible.
(même si en vrai, on est pas dans l’OO mais dans le multi-paradigmique qui est, à mon sens, bien mieux)
1 « J'aime »
Et si le Daily Scrum Meeting était un mini Scrum Planning ?
- Durant le Scrum Planning
a. L’objectif du Sprint est défini.
b. Un plan est créé pour un jour, jusqu’au prochain Daily Scrum Meeting. - Durant le Daily Scrum Meeting
a. Un plan est créé pour un jour, jusqu’au prochain Daily Scrum Meeting.
On se retrouve avec des itérations de 1 jour.
- Où ce qui est terminé-terminé est livré.
- Cela permet la boucle de feedback rapide.
- Penser qu’il y a 10 jours dans un Sprint de 2 semaines.
La fameuse petite boucle dans la grande boucle du Sprint, qui elle-même est dans la boucle du Product Goal. Ha, les poupées russes.
Petit rappel : un Sprint n’est pas une itération, mais un investissement/parie sur une période donnée. @const.
Il est donc possible d’avancer jour après jour sur tout un pan de l’applicatif.
C’est la partie la plus difficile, je n’est pas la réponse.
Je paraphrase @const : ça dépend du contexte.
Par contre, je sais par expérience ce qu’il ne faut surtout pas faire : C’est forcer un changement.
Courage.
C’est pas un « Et si ». C’est littéralement ce que c’est.
2 « J'aime »
Ha, bon 
!?!
Exactement.
Dans l’ancienne version du guide Scrum, le but du Daily Scrum : « planifier les prochaines 24h pour l’équipe de développement ».
Bon maintenant c’est d’inspecter le progrès vers l’objectif de sprint et d’adapter le catalogue de sprint, en ajustant le plan de travail restant. J’aime pas trop la nouvelle définition, l’ancienne, sorte de mini sprint planning, me plaisait mieux 
L’un des plus gros problèmes du scrum guide, c’est l’absence d’un versionnage permettant de retracer ces évolutions.
Whaou ! Merci pour toutes ces réflexions !
Malheureusement en vous lisant et aussi en regardant la vidéo partagée par @jplambert, je suis encore plus embrouillé qu’avant :
- On peut faire des tickets techniques ? Je pensais que chaque US devait avoir une plus-value pour l’utilisateur ??
- On peut prendre des tickets liés entre eux (fonctionnellement) ?? Mais alors on prend le risque de ne pas pouvoir finir le 2eme voire 3eme ticket dans la chaîne et donc avoir une vélocité en dent de scie et perdre en prédictibilité
.
Je vous avoue que vos partages sont très excitants et je découvre plein de choses mais je suis un peu perdu…
@MuyBien Vraiment, je pense que parler d’US de manière générale dans Scrum est une très mauvaise idée, d’une parce que peu de personnes ont compris ce qu’elles sont, et de deux parce qu’à aucun moment l’utilisation d’US est prescrite dans le Scrum Guide.
Du coup: un Product Backlog Item (PBI) ou un Sprint Backlog Item (SBI) peuvent être tout élément permettant d’apporter de la valeur aux utilisateurs, autant dans le process (amélioration du fonctionnement de l’équipe, de ses outils, de ses connaissances…) que dans le produit/service en lui même.
C’est un peu là où la notion de Sprint et de Sprint Goal entre en jeu : Tu as lancé un sprint mais la gestion des dépendances entre tes SBI part de travers ? Annule le sprint, repars en Sprint Planning, redécoupe tes SBI et fait en sorte que ça n’arrive plus.
Je te comprends, il y a beaucoup d’informations qui on était partagées. Elles sont toutes de bonnes idées. Mais laquelle sera adaptée à ton contexte ?
Dans une boite de temps donnée, je préfère agir et découvrir que je me suis trompé au lieu de ne rien faire : réfléchir, penser, planifier.
La peur de se tromper peu nous paralyser, il faut la surpasser.
Un joueur de foot, devant la surface de réparation, s’il hésite un instant à frapper au but, alors il est déjà trop tard. Cela arrive même aux meilleurs sur le papier.
La réponse est sur le terrain. Agir est la clé.
Tes coéquipiers et toi êtes sur le terrain, quel premier petit pas choisissez-vous de faire ?
C’est à vous de choisir, n’ayez pas peur de vous tromper !
Ton équipe a besoin de faire un premier pas, peu importe le sens et la direction, pour trouver son chemin.
- Avancer d’un pas
- Regarder la boussole pour ajuster le sens et la destination du second pas
- Avancer d’un pas
- …
@MuyBien es-tu moins perdu ?
#ScrumAppliquéÀLaméliorationContinue
Tout d’abord, lundi 24 (pas demain mais le suivant) nous sortons une vidéo sur le sujet. J’espère qu’elle t’aidera à mieux t’approprier ces subtilités et comment elles s’articulent entre elles.
On peut faire des Product Backlog Items (PBI) techniques, oui.
Une User Story doit bien avoir une plus-value pour l’utilisateur.
Mais tous les Product Backlog Items n’ont pas à être des User Stories.
Malgré tout, les PBI techniques ne sont pas des passe-droits : INVEST s’y applique très bien aussi, en parlant de « Valeur » en général et pas spécifiquement de valeur pour l’utilisateur – en particulier, apprendre ou dérisquer ça a typiquement beaucoup de valeur.
Déjà, va falloir arrêter de prêter attention à la vélocité comme si c’était important.
La question c’est justement de savoir si on crée de la valeur, ça ne se mesure pas en nombre de « stories » livrées, et encore moins en points, mais au fait que l’on s’approche de la réalisation de la vision produit. Le Product Goal, et en particulier des indicateurs associés servant de boussole, étant de bons moyens d’outiller cette démarche.
Désolé si je suis un peu brouillon, j’essaie de te donner des éléments sans dévoiler toute la vidéo 
4 « J'aime »
Pas de soucis sur ça. J’adore tenter des choses et l’équipe s’y prête bien. Nous sommes même passé en squads récemment pour essayer. On verra si on garde le fonctionnement.
Le problème est de savoir quoi tester 
Je vous avoue que j’ai du mal avec les SBI techniques. Surement parce que ça fait longtemps que je me trompe… Je comprends qu’un SBI permet d’avancer vers le sprint goal voire le product goal. J’espère que la vidéo à venir de @jplambert va m’éclaircir l’esprit 
Pour schématiser grossièrement:
Objectif de sprint : Réduire le temps de chargement du site de 2s à 0.5s (problème important pour un site de e-commerce)
SBI possibles : Réduire la taille du bundle, réduire la taille et la qualité des images, améliorer les cycles de vie des composants et ajouter du lazy loading au besoin…
L’apport en valeur est grand pour le business (les stats montrent que ce genre de hausse en performances améliorent de manière significative le CA des sites qui en bénéficie), pourtant c’est à priori pas des changements « évident » du point de vue de l’utilisateur.rice. Tout ce qu’elle voit, c’est que ça charge plus vite.
1 « J'aime »
Ba le problème, c’est que pour la roadmap, la planification, tout ça… C’est important. Alors on est peut-être pas dans un état d’esprit complet agile mais au moment de partager une roadmap aux utilisateurs ou aux partenaires voire à la direction, difficile de leur dire « on prend le but final du logiciel et on va le découper, on verra ce qui est le plus important et on verra ce qu’on peut faire »… J’entend que c’est le mieux. Pour nous la vélocité (calculée en nombre d’US découpées au plus finement) nous permet d’avoir de la prédictibilité et proposer les fonctionnalités qui devraient être dispo à 1 mois.
En vous lisant je me rend bien compte que c’est pas agile et plus mini-cycle en V… Mais je vous avoue que c’est un peu déprimant du coup 
1 « J'aime »
Mais noooooooooon faut pas déprimer !!!
Il faudrait que tu écoutes Frédéric Leguédois. Il explique par exemple que jamais un utilisateur ne regarde la roadmap, ou vérifie que ce qui est livré est bien ce qui était sur la roadmap.
Mais comment faire alors ? L’enjeu est ne pas parler du futur mais du passé. Concrètement, livrer un petit incrément, le montrer à l’utilisateur et échanger alors de ce qui a été fait et de ce que cela nous apprend, plutôt que de plans sur la comète.
Ca marche vraiment ; on se focalise sur la roadmap justement parce qu’on n’a rien de concret à échanger. Voir un produit qui bouge crée un focus très différent.
Il y a peut-être aussi à creuser du côté de la définition de la vision produit. Y’en-a-til seulement une ? Et est-on tous bien alignés dessus en interne ? Le changement d’approche commence généralement pas là. En l’absence d’une vision claire, commune et partagée, et idéalement outillée par des indicateurs qui servent de boussole, c’est quasiment impossible de « se poser la bonne question » et on se rabat alors sur le dépilage de ticket.
1 « J'aime »
LoL
Oui oui on parle beaucoup du passé. Avec les utilisateurs, avec les commerciaux qui font des retours des prospects, etc. On collecte le feedback et on fait évoluer notre roadmap quasiment toutes les semaines. Là dessus on est d’accord. La roadmap est plus utile pour les commerciaux (pour donner à manger aux possibles futurs utilisateurs) et pour nos partenaires pour savoir ce qui va être fait. Ils sont peut-être à l’ancienne mais on leur propose quelque chose quitte à le modifier souvent.
Je vais écouter ce Frédéric Leguédois même si j’entends complètement ce que tu dis à propos de l’utilisateur et je suis d’accord 
Pour ce qui est de la vision produit (qui correspond aussi au product goal si je ne dis pas de bêtise ?), j’avais fait un atelier à mon arrivée justement pour définir les cibles du produit, et les raisons d’être du produit (notamment grâce à une de tes vidéos @jplambert). Donc on est bien censés avoir une vision produit. Peut-être, effectivement, qu’on ne se la remémore pas assez 
Je vais essayer de tout tourner avec comme point de mire ce product goal.
Bon ba vivement lundi prochain, donc…
Dans mon expérience, il n’y avait pas de SBI technique.
Les seuls éléments techniques étaient les tâches techniques. Qui formaient le plan de réalisation d’un SBI.
Le SBI contenait l’information de la valeur à fournir.
- Le besoin utilisateur
- Des critères d’acceptation : du point de vue utilisateur
- L’hypothèse à tester afin de résoudre une problématique donnée.
Avec celui de @Samuel_Abiassi
Je suis obligé de reformuler, l’objectif de Sprint, car je pense qu’il est trop précis et ne s’adresse pas aux utilisateurs :
Fluidifier l’expérience de navigation de l’utilisateur.
Le premier SBI serait :
Réduire le temps de chargement des pages du catalogue
Ce qui permettra de
- Réduire de 2s à 0.5s la durée la première interaction de l’utilisateur possible
Le premier jet du plan de réalisation :
- Quel sont les bottlenecks ?
- La réponse du serveur est elle acceptable ?
- La durée de chargement de l’interface utilisateur est elle acceptable ?
- Optimiser les bottlenecks (cette tâche sera précisée/découper en fonction des découvertes)
- … Ect.
Pour un tel objectif le plan va émergée au fil des découvertes.
Le second SBI :
Réduire le nombre d’actions que l’utilisateur doit faire pour remplir son panier.
3ème SBI :
Réduire le nombre d’actions que l’utilisateur doit faire pour commander.
Ressources
J’ai fait plusieurs postes sur LinkedIn décrivant mon expérience des tâches techniques.
Disponible avec le hashtag #tacheTechniqueMedoucine.
il est préférable de lire dans l’ordre chronologique. Je conseil de trier par post récent.
1 « J'aime »
Je ne vois ni pourquoi c’est trop précis, ni en quoi ça ne s’adresse pas aux utilisateurs. Le fait que ce soit précis est au contraire une bonne chose ! « Fluidifier l’expérience de navigation », ça veux dire quoi ? On le mesure comment ? Quand est ce qu’on sait qu’on l’a atteint ?
Ce sont de très bonnes questions à poser en Sprint Planning.
Pour te répondre : je te poserai cette question :
Est-ce que cela utilise le vocabulaire des utilisateurs ?
Par expérience ; il faudrait parler de ressenti à l’usage.
Par exemple : Passer d’un chargement où rien ne bouge à, l’ajout d’un élément qui bouge comme un spinner. Améliore le ressenti utilisateur.
Et cela montre aussi qu’il n’est pas si facile de définir un objectif de Sprint.
Il faut être précis, oui, mais sans limiter la créativité, ou se mettre des œillères.
1 « J'aime »
Bah euh oui… « charger » et « 2 à 0.5s » ça me parait être du langage lambda.
Bah euh non… On mesure comment ? Comment on sait que l’hypothèse est validé ? Sur du subjectif ?
1 « J'aime »