Agile Playground #27

Merci encore à GOOD de nous avoir reçu mardi dernier, dans ses locaux pour le premier Agile Playground après les vacances d’été. Nous étions bien plus d’une vingtaine pour cette rentrée Agile Playground. Nous avons commencé la soirée par un petit Icebreaker : le nombre secret, vous connaissez ? Chaque personne note un nombre sur un post-it et le garde secrètement. Il doit ensuite le faire deviner aux autres participants sans parler et sans dessiner ce nombre afin d’obtenir finalement une chaîne ordonnée de personnes du plus petit au plus grand nombre.

Nous avons ensuite commencé les jeux. parmi les jeux proposés, nous avions le choix entre :Carpaccio, mener un sprint planning en DUPLO, utiliser les Rory’s cubes pour une rétrospective, les vaginales; un jeu de cartes sur le concept du mille bornes et traitant du plaisir féminin. C’est bête, je n’ai même pas eu le temps de discuter avec les créateurs du jeu. On aurait pu s’échanger des tuyaux sur la création d’un jeu de cartes.

J’ai pour ma part décidé de participer au jeux de planification de sprint et au jeu d’utilisation des Rory’s cubes pour une rétrospective. Les deux jeux étaient animés par Daniel Paire et la soirée fut riche en information et en enseignements.

Revenons au premier jeu ou comment faire estimer un sprint backlog à l’aide de DUPLO. Daniel nous a expliqué que pour des équipes relativement novices en SCRUM, il modélisait la vélocité réelle d’un sprint en construisant une tour en DUPLO (parce que les DUPLO de sa fille sont plus gros que les Lego classiques et qu’il en faut donc moins pour faire une tour). lego_duplo_5538_z1Une fois la tour de vélocité construire et le PO positionné sous la forme d’un animal au sommet de celle-ci afin de signifier par la symbolique que la tour appartient au PO, Daniel a construit des tours plus petites, de différentes tailles; 1 à n DUPLO afin de modéliser les différents coûts d’une story; XS, S, M, L, XL. Il a ensuite créé une liste de stories et nous avons pu commencer à les évaluer. Il a intentionnellement créé une story de grande taille avec de nombreuses contraintes fonctionnelles afin que nous l’évaluions à la taille XL et que nous puissions nous rendre compte que celle-ci était visuellement plus grande que la moitié de notre tour de vélocité. Nous avons donc découpé cette story en stories plus petites. Les développeurs ne connaissent pas le rapport entre la taille de la tour et la vélocité réelle. ceci permet donc à ceux-ci de pouvoir estimer librement sans être tenté d’effectuer une conversion  en jours/homme. Le jeu permet aussi de donner un rythme différent et d’apporter un peu de nouveauté à ce rituel qui peut parfois être long et fastidieux. Daniel nous l’a affirmé : « si un développeur commence à estimer le rapport de conversion entre la tour DUPLO et la vélocité, alors il le changera aussitôt ». Mais alors me direz-vous , comment savoir si on suit la release planifiée. Daniel possède un fichier Excel qui lui permet de  convertir les DUPLO en vélocité réelle pour détecter toute variation par rapport à la planification! Il envoie la vélocité réelle au Product Owner…

Le deuxième jeu auquel j’ai participé est l’utilisation des Rory’s cubes pour l’animation d’une rétrospective. Ce jeu a tout d’abord été inventé par un psychologue Danois afin de susciter la créativité et l’imagination des enfants qui doivent inventer des histoires à partir de dés.

rorys-story-cubes

Le jeu est constitué de 3 séries de 9 dés. Dans un premier temps, chaque personne de l’équipe va lancer à tour de rôle les trois séries et retenir 3 dés pour chaque série.

  • A partir des 3 premiers dés, la personne doit indiquer quelque chose qu’elle a aimé ou non dans le sprint passé en utilisant le modèle : « dans le dernier sprint j’ai aimé… je n’ai pas aimé… »
  • A partir des 3 dés de la seconde série, la personne doit imaginer une solution pour faire perdurer ce qu’elle à aimé ou résoudre ce qu’elle n’a pas aimé.
  • La troisième série de 3 dés permet de définir une action concrète à réaliser pour mettre en oeuvre les solutions de la seconde série.

Dans un second temps, l’équipe va garder un seul dé de chaque série et inventer une histoire collective; cette seconde partie permet de travailler sur la cohésion d’équipe.

Une chose est sûre, ces deux activités permettent de rompre la monotonie que l’on peut parfois ressentir lors des rituels SCRUM. Merci Daniel pour cette soirée sympathique et pleine d’enseignements.

 

Publicité

Une autre vision des user stories

Qu’est-ce qu’une bonne user story ? Est-ce un petit morceau de spécifications fonctionnelles ? Quel est le niveau de détail d’une user story ?

Beaucoup d’articles traitent de la construction des user stories mais j’ai récemment compris comment celles-ci expriment les valeurs de l’agilité. J’aime bien le fait qu’une user story soit définie comme une invitation à la communication ; comme un outil de conversation et de collaboration. Donc une user story n’est pas un petit bout de spécifications ; inutile d’essayer de tout préciser sur un petit bout de post-it. Cependant, la user story doit permettre de développer un logiciel ou construire un produit qui correspond aux besoins de l’utilisateur. J’ai récemment suivi un MOOC sur la construction des user stories selon les besoins des utilisateurs que j’ai trouvé intéressant et que je souhaitais partager avec tous ceux qui doivent construire un backlog de stories : ‘Getting Started: Agile Meets Design Thinking’ sur Coursera. Alexander Cowan et son équipe nous apprennent dans ce MOOC comment construire de belles user stories en se basant sur l’expérience utilisateur et sur le Venture Design Process.

2016-09-16-21_37_10-venture-design-process

Le Processus est très bien défini dans le site précédent mais voici pour ma part les quelques éléments que j’ai choisis de retenir selon mon expérience :

Les Personas, quand ils sont construits de manière rigoureuse, permettent de mieux comprendre les besoins utilisateurs. Ils constituent le point de départ du processus. Les Personas sont en général élaborés lors du cadrage du projet et permettent ensuite d’écrire les premières stories du backlog. Quand ils sont enrichis et utilisés tout au long du projet, les Personas sont une véritable source d’inspiration pour définir les user stories.

  • Afin de vous aider à construire les user stories à partir des Personas, vous pouvez commencer par exprimer des scénarios décrivant les problèmes auxquels font face les Personas et les alternatives qu’ils ont trouvées pour les résoudre .
  • Vous pouvez ensuite proposer des solutions qui apporteront une valeur ajoutée par rapport aux alternatives.
  • Puis vous pouvez construire des prototypes sous forme de storyboards pour expliquer la solution et sa valeur ajoutée. Ceci vous permet aussi de revenir et d’affiner votre proposition. L’outil StoryBoardThat permet de construire rapidement des storyboards efficaces qui vous permettront d’expliquer vos solutions.

Quand on respecte rigoureusement ces étapes, on se concentre davantage sur la compréhension des besoins utilisateurs que sur la mise en oeuvre de la solution. Et c’est là que cela devient intéressant. Pourquoi ?  Et bien parce qu’on va éviter le syndrome du « bouton bleu ».  Le syndrome du « bouton bleu », c’est quand on obtient une story du type : « en tant que.. je veux appuyer sur le bouton bleu afin [d’effectuer une action]. « Cette story est précise », me direz-vous ? Oui, un peu trop précise! Cette story ne laisse à l’équipe de développement et au designer, aucune chance d’exprimer leur créativité et d’être force de proposition :

  • Aucune chance d’être force de proposition car on n’a pas la clause qui exprime la plus-value apportée à l’utilisateur.
  • Aucune chance non plus de proposer la solution technique qui permettrait de réaliser la fonctionnalité exprimée.

Vous serez d’accord pour reconnaître que cette story laisse peu de place pour la confiance et la collaboration des personnes. Cette story construite selon le très célèbre format, « en tant que [] je veux [] afin de [] « , ne respecte pas les valeurs de l’agilité et peut être démotivante pour les équipes. Le format ne fait pas tout 😉

Alors d’accord, on va laisser les équipes collaborer et concevoir de manière collective. Mais il y a quand même des contraintes fonctionnelles et métier… Et c’est là que les cas de tests d’acceptance rentrent en jeu, pour exprimer ces règles métier.

Ex : Pour une recherche, s’assurer que l’on peut rechercher par date.

Alors oui, les stories sont INVEST, 3C… mais c’est avant tout un moyen de collaborer et communiquer avec :

  • les utilisateurs ou ceux qui les représentent.
  • les personnes qui vont réaliser les stories.

C’est en quelque sorte le format pivot entre les besoins et le produit réalisé.