27/04/2023

Planning poker accéléré

Le planning poker est un technique d'estimation qui est très répandue dans les équipes agiles.
Je voulais vous proposer une version accélérée pour vous faire gagner du temps.



Etapes

  1. Le Product Owner présente la story.
  2. Les membres de l'équipe posent des questions jusqu'à comprendre la story suffisamment pour la chiffrer.
  3. Les membres de l'équipe donnent une estimation à bulletin secret en utilisant des cartes avec la suite de Fibonacci.
  4. Les cartes sont retournées en même temps.
  5. S'il y a des différences, les plus basses et les plus hautes donnent des arguments pour expliquer leur chiffrage
  6. On fait plusieurs rounds de chiffrage (1 ou 2 suffisent généralement) jusqu'à trouver un consensus

Avantages 

  • Les échanges qui ont lieu durant la session ont beaucoup de valeur pour comprendre le besoin, et identifier au plus tôt les zones de flou.
  • Le chiffrage en story points permet d'utiliser une unité abstraite basée sur la comparaison. Elle permet en scrum de définir la capacité d'une équipe sur un sprint en se basant sur sa production passée, la vélocité. C'est une unité spécifique à une équipe. Ca a été inventé "par erreur", mais c'est utile.
  • Les chiffrage cachés permettent d'éviter que les votant s'influencent et les nombreux biais associés
  • Les écarts de chiffrage permettent d'échanger  sur la conception, avec des approches différentes basé sur des expérience variées, et parfois on découvre une manière plus simple
  • La suite de fibonacci, permet naturellement d'avoir des estimation moins précises pour les grands chiffres, et permet déjà de gagner du temps
  • Un chiffrage trop grand peut être une opportunité de découpage
  • un coté ludique par la manipulation des cartes (souvent remplacé par un outil dans les situations à distance ou en télétravail, d'ailleurs je vous recommande https://hatjitsu.toolforge.org/)

Variante accélérée

Lorsque les cartes sont retournés, si les estimations sont proches, avec 2 ou 3 valeurs continues sur la suite de Fibonacci, on arête là les estimation et on utilise la règle d'arrondi suivante:
Avec 2 valeurs continues, on prend la valeur la plus haute (exemple 5 5 5 5 8 -> 8)
Avec 3 valeurs continues, on prend la valeur du milieu (exemple 2 2 3 3 5 -> 3)
Peu importe le nombre de carte de chaque valeur.

Cela permet de gagner du temps sur les estimations. Une estimation reste un exercice approximatif. Mon expérience personnelle est que cette méthode accélérée amène des chiffrage quasiment identiques en deux fois moins de temps.

Pour aller plus loin, si vous avez un grand nombre de story à chiffrer en même temps, je recommande plutôt de le faire au format extreme quotation.

Note

Certaines équipes font le choix de ne pas estimer du tout.  Soit parce qu'elle arrivent à découper suffisamment pour avoir des story de taille similaire, soit parce qu'elle assument cette variabilité mais font une priorisation. Cela s'appelle du no-estimate.


Sources

Publié par à Aucun commentaire:

17/03/2022

Burndown perpétuel

Je vous propose un outil que j'utilise depuis quelques mois dans mon équipe.
L'idée est partie d'un burndown mais sur lequel j'ai apporté une touche de nouveauté.

Constat

Je reprends les bases, un burndown est une représentation graphique de l'évolution de la taille du backlog produit, au cours du temps. Ca s'appelle burndown parce que dans l'idée, le backlog est consommé (il brule), et ca permet de faire une projection de la date d'atterrissage du projet.

Burndown Produit classique (en théorie) 

mais en pratique un produit qui vit ca serait plutôt ça

... pas très utile alors.

Quoi ? mais on parle de projet ou de produit?

C'est ça l'ambiguité, cet outil vient avec une dissonance: On réalise un produit, mais le projet a une fin.


Pour info, Il existe 2 autres variantes du burndown classique:

Burndown de Sprint: permet de visualiser si les story sont clôturées au fur et à mesure du sprint ou seulement à la fin. C'est généralement lié à la taille des story. Je n'ai jamais trouvé un grand intérêt à cette représentation, car c'est quelque chose que l'équipe ressent sans avoir besoin de le dessiner.
Burndown de Release: permet de projeter la date de fin de release. A supposer que la date de release est modifiable. Dans mon équipe, nous faisons une release prodable tous les 3 sprints. Mais cela peut être différent dans votre équipe.

Proposition

Et maintenant voici ma proposition: le burndown perpétuel



Dans cette représentation, la taille du backlog reste visible, mais nous avons en plus sa décomposition en Epic. Il reste possible de travailler sur plusieurs Epic en parallèle. L'Epic la plus prioritaire est placée en bas, et nous obtenons une projection de la fin de réalisation de cette Epic.

L'outil parfait ?

Compromis entre 2 visions
Je pense que cette représentation est une bon compromis entre le souhait d'avoir un backlog vivant, une approche itérative (orienté valeur) mais aussi d'avoir une visibilité sur l'atterrissage d'un sujet (orienté date).
En particulier quand on a un gros sujet. Perso mon équipe avait une grande refonte d'IHM à faire et le besoin est parti de là.
Synthétique
Il propose une vue agrégée du backlog, c'est une synthèse du contenu du backlog qui donne un ordre de grandeur de la taille des différents sujets. C'est utile pour une partie prenante qui ne veut pas rentrer dans le détail des story du backlog. Cela permet d'aider à la priorisation à moyen terme.
Objectif
Contrairement à un planning classique, il est objectif. Il raconte l'histoire suivante: "Si l'équipe ne rencontre pas d'impondérable, conserve sa capacité actuelle, et n'est pas interrompue par un sujet plus prioritaire, voici la date à laquelle ce sujet devrait être terminé."
On utilise les mesures du passé pour faire une projection de l'avenir.
Pour être représentatif, l'outil a besoin d'un certain nombre de mesures. la vélocité moyenne est calculée sur 3 sprints, mais pour que la tendance soit fiable, il faut environ 5 sprints.
Cela me ferait plaisir que vous le testiez dans votre contexte et que vous me dites si cela vous a été utile.

Comment le faire vous même ?

Les 3 premiers exemples ont été réalisé avec Google spreadsheet.
Voici le fichier docs utilisé pour cet article. 
Il faut utiliser un graphique en aire avec empilement.

Dans Excel il existe une fonctionnalité de tendance qui permet de visualiser la projection. Par contre cela n'est pas compatible avec l'empilement, il faut donc faire l'empilement "à la main" avec des formules pour faire les sommes, puis ajouter la tendance sur les une ou 2 Epic du bas. Voici ce que ça donne.

Pour aller plus loin

A l'étage le plus haut qui correspond au backlog, il est aussi possible d'y ajouter une projection basée sur la vélocité et non sur la tendance.


Enfin, il est possible de construire le nombre de sprints en vision en divisant la taille du backlog par la vélocité moyenne. Cela permet de dire "l'équipe a du travail pour 2 ans". Etes-vous capable de répondre à cette question pour votre équipe ?



Je peux vous envoyer la version excel sur demande.

Content de vous partager cela.

Happy burndown
crédit kc-green







Publié par à 2 commentaires:

04/01/2021

Recommandations Youtube

 Si comme moi vous passez du (trop de) temps sur Youtube, les recommandations que l'algorithme ont pu vous surprendre agréablement parfois, mais vous devriez avoir conscience qu'il vous enferme dans une bulle par rapport aux tendances et ce que vous avez déjà regardé. Imaginons qu'un sujet vous plait, comme par exemple les courses de billes (si si ça existe, https://www.youtube.com/watch?v=fvrGNgY9_i4), et bien vous aurez inévitablement des suggestions de courses de billes pendant des mois ou des années. Quel que soit le sujet.

Donc par rapport à cela j'ai 3 conseils à vous donner:

  • Utiliser le menu abonnements plus souvent que la partie recommandations (qui est la page d'accueil)
  • Bien choisir vos abonnements, et activer les notifications pour celles qui vous passionnent ou pour lesquels il y a une actualité à suivre
  • Remonter le temps des chaînes qui vous plaisent, et même si elle ne publient plus.

Et donc justement, voici un extrait de mes abonnements, pour vous donner de nouveaux horizons. 

Actualités

Mini séries

Graphisme


Vulgarisation scientifique
Dirty biology https://www.youtube.com/channel/UCtqICqGbPSbTN09K1_7VZ3Q
La statistique expliquée à mon chat https://www.youtube.com/channel/UCWty1tzwZW_ZNSp5GVGteaA

Les top10

Ecologie

Dissertations

Cinema

Economie

Développement de jeux vidéos

Robotique

Humour

Interviews

Court-métrages

Agriculture

Escalade

Jeux de société

En 2020, j'ai créé 2 vidéos pour la chaine Alternatiba, une association dont je fais partie. https://www.youtube.com/watch?v=sjywAhaFLEA et https://www.youtube.com/watch?v=ku9rD3HVWjo

Nous ne sommes pas encore complètement déconfinés, alors utilisez au mieux ce temps. Je vous vois déjà vous dire que le meilleur mouvement serait de ne plus utiliser Youtube mais dans l'état actuel, je choisis de l'utiliser au mieux. 

Publié par à Aucun commentaire:

03/01/2019

Exploration du backlog avec des dessins

Lors d'échanges avec des personnes qui découvraient l'agilité, j'ai dessiné un petit schéma représentant la manière dont les Story permettent petit à petit de répondre à un besoin. J'ai trouvé cette image pertinente et qu'il y avait beaucoup de choses que je pouvais expliquer à partir de ce dessin.

Je vous emmène donc vers une exploration du Backlog,  à travers des dessins.


Le nuage représente le besoin utilisateur, qui peut être flou (ou même infini), en particulier en début d'un nouveau produit, car il y a beaucoup d'idées et de questions. Nous allons voir que ce flou n'est pas du tout un problème. Il est même normal que les utilisateurs ne sachent pas exactement ce qu'il veulent, que ce soit seulement en voyant les écrans de la première version qu'ils aient des remarques et des propositions pour la suite. Car ils ont le droit de changer d'avis, et que l'agilité propose un réponse à ce changement constant du produit et de son environnement.

Le carré représente le périmètre d'une User Story tel qu'elle est défini au moment d'un Sprint Planning. Que la story soient définie à l'écrit ou à l'oral. La transparence représente les inconnues de la story. La story a pu murir dans les semaines précédentes pour devenir plus 'opaque'.


Lors de la définition d'une User Story, le Product Owner présente la story, et elle doit être assez précise pour que l'équipe puisse estimer et commencer sa réalisation, disons à 80%. (Ce pourcentage est complètement abstrait, c'est juste pour expliquer mon propos)


Si la story n'est pas suffisement précise, définie seulement à 10% mais qu'elle est quand même prise dans le sprint, le besoin va être complètement découvert durant sa réalisation. L'estimation en story point ne peut être correcte dans ce cas. Il est préférable de faire cette exploration avant la réalisation de la story. Lorsque l'incertitude porte sur des éléments fonctionnels, il est possible de faire des ateliers avec les utilisateurs ou experts fonctionnels. Lorsque l'incertitude porte sur des éléments techniques, il est possible de faire un Spike ou Preuve de concept, c'est à dire une story qui a pour objectif de tester un nouvelle technologie. Lorsque l'incertitude porte sur le design général de l'application, il est possible de faire une maquette ou un 'mock-up'. Cela peut montrer également que le sprint Planning n'a pas été assez préparé. Le Scrum Master peut aider le Product Owner à vérifier que les story soient prêtes. Les séances de Grooming peuvent aider à faire ces vérifications de manière régulière en cours de sprint.


Par contre, si l'on cherche à obtenir des story complètement précise, à 100%, avec une Defition of Ready trop rigide, peu de story pourront être prises. Dans le cas extreme, l'équipe n'a plus de story à mettre dans son sprint. C'est ce qu'on appelle la paralysie d'analyse. En effet l'équipe doit trouver le juste équilibre entre refuser une story car la règle de gestion principale de la fonctionnalité est inconnue, ce qui semble raisonnable, et refuser une story car elle ne connait pas le texte exact d'un bouton, ce que l'on peut qualifier de jusquauboutiste, voire de mauvaise foi.


Une autre erreur possible est d'avoir des story trop grosse. Dans ce cas elle s'étale sur plusieurs sprints, entrainant un effet Tunnel. Il est recommandé de découper cette Story.

Ce dessin montre comment les itérations successive peuvent à un moment s'écarter du besoin réel, mais être réajusté en cours de route à la story suivante.

Idéalement les story successives permettent de couvrir le besoin. Mais le produit peut être utilisé avec une première mise en production rapide, afin que le feedback du terrain (et parfois anomalies détectées), viennent enrichir le backlog de manière encore plus pertinente que les idées du backlog initial.

Ces variations tournent toutes autour de la 'Definition of Ready'. Cette définition doit être partagée dans l'équipe avec le Product Owner. Cette définition peut être régulièrement ajustée au cours des rétrospective, pour être souvent enrichie, parfois adaptée ou allégée. Chaque équipe pourra trouver ce qui convient le mieux à son contexte, son outillage, son niveau d'expérience. 




Publié par à Aucun commentaire:

30/04/2015

Tu fais encore du GWT ?

Ben oui, je fais encore du GWT.
C'est une question que j'ai eu plusieurs fois à Devoxx.
Ce n'est pas du tout 'hype' d'utiliser un outil qui a 10 ans.
Quoi 10 ans! oui, Java a bientôt 20 ans, et GWT bientôt 10 ans.

Samy Jaber leur répond que cette année, c'est le retour en force de GWT.
C'était le titre de sa présentation.
GWT n'est pas mort.
Alors je répète et complète ce qu'il a dit.

Pourquoi c'est un bon outil ?

 - Coder en Java, avec un typage fort
 - Utiliser les IDE Java, en insistant sur la compilation (c'est le feedback le plus rapide pour un dev)
 - Les refactoring sont facilités
 - Multiples vérifications de syntaxe html, de typo de style, et de clé de traduction
 - Utiliser les outils de Test Java
 - Utiliser les outils de build Java
 - Utiliser les outils de mesure de qualité de code Java
 - Les performances pour l'utilisateur final sont optimales
 - La taille du javascript à télécharger pour l'utilisateur final est optimal (élément critique pour une utilisation sur mobile)
 - Les différences des navigateurs sont masquées
 - Google le maintient et l'utilise

Pourquoi il a eu un creux ?

 - Les temps de build étaient long
 - Ce n'est pas parce que l'on code en java que l'on peut se passer de bien comprendre comment fonctionne une page web.
 - Lorsque Google a libéré le projet à la communauté Open Source en 2012, il y a eu comme un flottement.
 - L'API navigateur utilisé par le Dev Mode, NPAPI a été annoncée dépréciée en 2013, elle a été supprimée mi 2014 et n'existe plus sur les dernières versions de chrome et firefox. Et durant cette phase, le super dev mode n'était pas complètement opérationnel.
 - A la meme époque, l'écosystème Node, Javascript a grandit très vite avec des outils de build et une gestion de package comme bower en 2012

Pourquoi il a de l'avenir ?

 - Google continue de l'utiliser, par exemple pour Inbox, mais n'est plus tout seul
 - Le steering comitee et la communauté sont très actifs
 - Une conférence annuelle nommée gwtcreate sur deux sites (Mountain View et Munich)
 - Un nouveau logo, et un nouveau design du site web gwtproject
 - La version 2.7 est d'excellente qualité
 - Le super DevMode permet de faire une compilation partielle, seulement pour la permutation nécessaire, et incrémentale.
 - Debuggage dans le navigateur avec sourcemap ou dans l'IDE IntelliJ ou Eclipse avec SDBG
 - Les temps de build complet on été améliorés, et cela va continuer
 - Les applications hybrides basées sur des vues web
 - les applications android réutilisant du code de l'application web gwt
 - Le language javascript et les API des navigateurs évoluant sans cesse, GWT saura utiliser au maximum les possibilités de chaque navigateur, en utilisant elemental
 - Votre application web est ou va être complexe par les fonctionnalités qu'elles va proposer et les apis du navigateur qu'elle va utiliser

 Que contiendra la version 2.8 ?

 - Les performances au runtime vont continuer de s'améliorer
 - JsInterop va faciliter l'appel de code Javascript (les wrappers)
 - Utilisation des webcomponent
 - Une nouvelle syntaxe pour écrire les feuilles de style, GSS
 - Et surtout, support du JDK 8, qui corrige le côté verbeux de java

Quelques conseil pour commencer ou continuer

- Utiliser activity/presenter & places
- Utiliser des regions
- Tester les activity/presenter
- Utiliser Mockito
- Ne PAS utiliser Jukito
- Utiliser des événements pour communiquer entre les activités/presenter
- Utiliser l'injection avec gin
- N'utiliser les widgets que si nécessaire
- Ne pas mettre du tout de code css dans les ui.xml
- Utiliser RestyGWT
- Utiliser GQuery
- Utiliser Bootstrap
- Utiliser Usefull Logging 

Sources

http://fr.slideshare.net/samijaber/devoxx-fr2015-gwt
http://www.gwtproject.org/
https://en.wikipedia.org/wiki/Google_Web_Toolkit
http://gwtcreate.com/slides/
https://github.com/ronanquillevere/GWT-Multi-Activities
http://gwt-france.blogspot.fr/2014/09/utiliser-le-nouveau-super-dev-mode-avec.html

Publié par à Aucun commentaire:
Inscription à : Articles (Atom)