Revenir au site

GrowTogether Octobre 2019

by beNext

· product-vision

Pour ce GrowTogether du mois d'Octobre, c'est notre coach Nils qui nous a accompagné pour la journée : intervision et formation/pratique à deux ateliers l'après-midi.

Intervision

Problématiques retenues

1. Comment prendre le temps de faire des sujets locaux quand on a déjà une roadmap remplie de sujets stratégiques ?

2. Comment éviter d’avoir un backlog infini ?

3. Comment réussir à jongler entre sujets locaux et traitement des anomalies ?

4. Comment améliorer la compréhension des testeurs ?

Problématique 1 : Comment prendre le temps de faire des sujets locaux quand on a déjà une roadmap remplie de sujets stratégiques ?​

Quel est le problème ?

Je suis PO et sur mon projet aujourd'hui il y a quasiment que des sujets stratégiques à réaliser. Avec mon équipe, nous sommes sans cesse dans le delivery et nous n'avons pas le temps de réfléchir à proposer nos propres sujets pour améliorer le produit.

As-tu essayé de...

  • prendre quelques tickets à chaque sprints

  • prendre un nouveau développeur front qui pourrait s’occuper des sujets locaux

  • les inviter à un atelier de prio pour mettre en évidence l’importance des tickets

  • aller parler directement au métier pour leur proposer les sujet locaux avec KPI

Si j'étais toi...

  • mettre en évidence un apport financier aux sujets locaux

  • faire un audit (UX, RC, KPI) pour montrer ce qui ne fonctionne pas

  • je montrerais que les utilisateurs app ne sont pas les utilisateurs web

Problématique 2 : Comment éviter d’avoir un backlog infini ?​

Quel est le problème ?

Sur mon projet, nous sommes passé de cycle en V à Kanban puis à Scrum. Tous les 6 mois je me permet de sortir des ticket de mon backlog s'ils n'ont pas bougé (priorisé, en développement, etc.) mais la direction n'est pas d'accord avec mon action car ils souhaitent garder une trace de tous ces tickets.

As-tu essayé de...

  • faire un deuxième board bac à sable pour mettre les tickets qui sont trop anciens et qu’on ne fera jamais

  • laisser dans le backlog ce que l’on souhaite traiter d’ici 3 mois sinon bac à sable

  • exporter les tickets et leur dire “Ne vous inquiétez pas, tout est là”

  • faire une mind map ou impact map

Si j'étais toi...

  • confronter la stratégie par rapport aux utilisateurs : stratégie d'entreprise VS stratégie produit

Problématique 3 : Comment réussir à jongler entre sujets locaux et traitement des anomalies ?

Quel est le problème ?

Sur mon projet, un concept vient d'être créé par la direction : création d'anomalies VIP. Nous sommes 18 feature team dont 2 qui travaillent sur près de 50% de l'application. En plus de nos sujets nous devons traiter les anomalies dont le nombre ne cesse d'augmenter, en plus des anomalies dites VIP.

As-tu essayé de...

  • la méthode d’Eisenhower : mettre en évidence pour chaque ticket ce qui est urgent et ce qui est important

Si j'étais toi...

  • build et mise en prod en continu

  • assurer une rétro compatibilité entre le front et le back

  • faire une pyramide de DILTS en commençant par l’Identité

  • utiliser Contract testing

  • faire en sorte qu’ils se brûlent pour qu’ils comprennent que ça ne fonctionne pas

Matrice d'Eisenhower
Pyramide de DILTS

Problématique 4 : Comment améliorer la compréhension des testeurs ?

Quel est le problème ?

Depuis 2 ans, notre nombre d'anomalies augmente. Notre équipe de test à changé. Nous faisons des tests unitaires et des tests fonctionnels et la différence entre le nombre d'anomalies créé et le nombre d'anomalies corrigé est conséquent.

Si j'étais toi...

  • demander leur cahier de recette

  • faire de l’example mapping : écrire des test pendant le backlog grooming (testaure, cux, dv, PO) tout le monde participe à l’écriture des tests fonctionnels

  • avoir une meilleure culture de la qualité : pour ne pas emmagasiné de dette

  • voir si les nouvelles feature créées des bug

  • regarder la couverture de code des tests unitaires

  • mutation testing

  • faire un tres amigos

Ateliers personnalisés

Atelier 1 : Event storming

Format : Atelier collaboratif de minimum 2h

Présents : les experts métiers et les développeurs, possibilité de rajouter un UX/UI

Objectifs de l’atelier :

  • engager les équipes

  • clarifier et avoir une même vision pour tout le monde

  • mettre en commun

  • couvrir les domaines métiers qui se dégagent

  • optimiser des parcours

Contexte : “Je suis un agent et je souhaite contrôler les billets de train.”

Etape 1 : On écrit les event au passé (post-it orange)

On liste l’ensemble des événements qui ont quelque chose de significatif au participe passé.

Exemple : Billet vendu

broken image

Etape 2 : On affiche les événements dans une timeline

On place les événements sur une ligne de temps pour montrer qu’un événement peut être prédécesseur d’un autre.

Ne pas se contraindre à une timeline, il peut y avoir une bande intemporelle. Tout comme on peut faire émerger des branches différentes.

Pour rappel : la timeline n’est jamais finie. L’event storming sert aussi à rappeler des choses qui ont pu être oubliées (et permet aussi de limiter les scopes).

Pour bien voir si notre timeline est claire pour tout le monde, on peut lire l’histoire en sens inverse pour ne rien oublier.

broken image

Etape 3 : On met les commandes que notre utilisateur fait à l’infinitif (post-it bleu)

Ici c’est notre contrôleur, mais il est possible de le faire avec plusieurs personas (post-it jaune).

On relate les événements qui sont les conséquences d’action des utilisateurs.

Exemple : Vendre un billet

Cette étape va générer beaucoup de discussions. S’il y a conflit, on regarde seulement ce qu’il y a dans le réel (ce qui est en place).

broken image

Etape 4 : On met des règles (post-it rose)

C’est lorsque qu’une commande doit être exécutée suite à un événement mais qu’il y a des conditions. Cela peut être des règles métiers.

Exemple :

  • l’agent a regardé la carte réduction ( événement)

  • demander la carte réduction (commande)

  • j’ai entre 12 et 25 ans (règle)

broken image

Etape 5 : On ajoute les éléments externes

Il est possible d’avoir besoin de faire appel à des éléments externes pour faire fonctionner.

Exemple : avoir la liste des gares

A la fin, cela nous permet d’avoir une “cartographie” et de dégager des grosses features.

broken image

Atelier 2 : Découpage Elephant Carpaccio

Format : Atelier de découpage des User stories

Pour : PO, QA, DEV

Objectifs de l’atelier :

  • apprendre à découper pour avoir des itérations très rapides

  • apprendre à se poser les bonnes questions :

    • est-ce démontrable ?

    • peut-on passer en prod ? Cela va-t-il créer de la valeur ?

    • est-ce utilisable ?

Pour en savoir plus je vous invite à lire l’article de notre coach Nils qui résume l’atelier : https://medium.com/@nils.lesieur/ciel-mon-backlog-est-d%C3%A9coup%C3%A9-430f3465596a

Contexte : Calculer un prix de commande sur la vente d’un produit

broken image
broken image