Agile Laval 2018 - "Un point, cest tout?"

©2017 Flatirons Solutions, Inc. All rights reserved.1 ©2018 Jouve SA, tous droits réservés.1
Anticiper, innover et inspirer
Un point, c’est tout?
jfpalmier@jouve.com & brobic@jouve.com
Jean-François Palmier & Benjamin Robic

MERCI AUX SPONSORS !

QUI SOMMES-NOUS ?
• PALMIER Jean-François • ROBIC Benjamin
Ingénieur Logiciel & Scrum Master Ingénieur Logiciel & Scrum Master
@jeffpalmier @benjaminrobic

+800 CLIENTS
Les 6 plus
grandes banques
françaises
30 Ministères
et organismes publics
Leader européen
de la gestion des
brevets
1er fournisseur de solutions
d’apprentissage
aux Etats-Unis
Acteur de votre transformation digitale
Expert de vos données métiers
Créateur d’expériences digitales
QUE FAIT JOUVE?

SOMMAIRE
 Les Story Points
 Estimer de manière relative
 Pourquoi estimer (…) ?
 Anti patterns, Exemples
 Mise en pratique
 Questions ?

Rejoignez-nous
sur les réseaux sociaux !
Les Story Points

VOUS AVEZ DIT STORY POINT?
• C'est une mesure arbitraire utilisée par l'équipe de développement afin de pouvoir estimer
l'effort à fournir pour implémenter une fonctionnalité
• S'abstraire de la notion jours/hommes pour s'axer uniquement sur l'effort
• Points importants/primordiaux :
• la notion de mesure
• la notion d'effort

STORY POINT - LA MESURE
• Différents référentiels/échelles
• Classiques :
• Taille de T-shirt (XS, S, M, L, XL)
• Suite de Fibonacci (1,2,3,5,8,…)
• Suite numérique (chiffres de 1 à 10)
• Suite des puissances de 2 (1,2,4,8,16…)
• Plus funky :
• Avec des animaux (fourmi, mouche, souris, lapin, chat, chien, lion,…)

STORY POINT - L'EFFORT
• L'effort nécessaire au développement d'une fonctionnalité
• L'effort peut être affecté par plusieurs facteurs:
• La quantité de travail à réaliser
• La complexité de ce travail
• Les risques et/ou incertitudes possibles
• Le DoD (Definition of Done)
• + de considération == + de précision

L'EFFORT - QUANTITÉ DE TRAVAIL
• Deux formulaires avec la même complexité mais …
• … nécessite plus de travail pour le deuxième

L'EFFORT - COMPLEXITÉ
• UX / Interactions utilisateur
• Formulaire identique, mais complexité différente
• Plus de réflexion, d'essais et d'expérimentations
• Plus de risques d'erreurs
• Plus de potentielles corrections

L'EFFORT - RISQUES ET INCERTITUDES
• Problèmes/Questionnements qui surviennent lors du développement, même après "grooming"
• Règles Fonctionnelles finalement pas claires/pas bien comprises
• Nécessité d'informations du client
• Temps d'attente du retour
• Nombre d'allers/retours
• Partie de l'application "risquée" et "compliquée"
• Archéologie
• TUs pas mis en place
• Dépendances fortes avec d'autres composants...
• Facteur le plus compliqué à évaluer

L'EFFORT - LE DOD
• Attention au DoD, il est trop souvent oublié!!
• Préparation des données
• Mise à disposition des données
• Déploiement sur la plateforme dans certains cas
• Tests unitaires
• Wiki
• …
• L'estimation finale doit également refléter cela

L'EFFORT - LA RÉSULTANTE
• La valeur du SP est la résultante de l'estimation de ces 4 facteurs
TRAVAIL RISQUES COMPLEXITE DoD SP

Rejoignez-nous
Estimer de manière
relative

ESTIMER DE MANIÈRE RELATIVE

ESTIMATION RELATIVE – MONDE DU SOFT
En tant qu’utilisateur,
je veux remplir un bureau
de mousse
je veux remplir un open-
space de mousse
Info : Open space = 3
bureaux
je veux nettoyer toute
cette mousse
Info : bureau
+ open space
Estimation : Estimation : Estimation :1 SP 3 SP 5 SP

PLANNING POKER
• Déroulement :
• La Dev Team pose ses questions
• Chaque membre de la Dev Team
choisit “secrètement” une carte
• Les extrêmes vont expliquer leur
choix
• Atteindre un consensus
• Le PO décrit le besoin fonctionnel
• Un jeu de carte, basé la suite de Fibonacci
• De 0 à 100, carte “?” et “Café”

PLANNING POKER – POURQUOI CA MARCHE ?
Estimations d’experts
différents domaines
discussion améliore la
precision des estimation
Partage des
connaissances

SOLUTION DES JOURS IDÉAUX
Temps ideal : 4 x 10 minutes = 40 minutes
Temps réel : 2 heures

JOURS IDÉAUX DANS LE MONDE DU SOFT
• Si un développeur donne une durée en jours, le client va le
marquer d’une croix rouge sur son calendrier
E-mails Réunions Démonstrations
Téléphone Bug Fixing Aides aux collègues
Réunions Entretiens Livraisons
Analyses Réunions Discussions

JOURS IDÉAUX – CONDITIONS
• Règles pour rapprocher jour idéal de jour réel :
• Je ne travaille que sur cette story
• Tout ce dont j'ai besoin est présent dans la story
• Il n'y aura aucune interruption
• Difficile de différencier les jours idéaux des jours réels

Rejoignez-nous
Pourquoi estimer
(de manière relative) ?

ESTIMATION - PLANNING
• Le planning permet de guider les decisions
pour maximiser la valeur et adapter son
backlog
• Même en process itératif, le planning
a son intérêt
• Un planning pour connaitre l’objectif à atteindre

ABORDONS LA VELOCITÉ
• Somme des points terminés à la fin d’un
sprint
• Permet de planifier la charge de travail pour
le sprint suivant
• Un indicateur pour l'équipe de
développement
• Propre à chaque équipe et ne peux être
comparée

VÉLOCITÉ != PRODUCTIVITÉ
• Vélocité == Rythme
• Productivité == Rendement
• Le but est de livrer de la qualité le plus tôt possible
• L’estimation est relative, la vélocité l’est tout autant.

ESTIMATIONS - CONCLUSION
• Ne pas être trop précis mais limiter la marge d’erreur
• On va créer une unité de mesure relative
• Processus empirique, visant à comparer les items entre eux
• Planifier au mieux les prochaines itérations

Rejoignez-nous
Les Problèmes rencontrés

• Fin de planification, le PO insiste pour que l'équipe réestime une Story afin qu'elle rentre dans le sprint
=> Equipe de développeurs qui n'a pas le dernier mot sur l'estimation
THE POS & STAKEHOLDERS TRIANGULATION
• Confiance dans la Scrum Team (Dev/PO/SM)
• Dev Team responsable de l'estimation
• Si obligatoire, affiner/revoir le scope

• Le fameux : "ça marche sur mon poste"
=> L'US n'est pas totalement terminée
THE DOD FACTOR
• Prendre en compte le DoD
• Rédécouper les US pour assurer

• L'expert maitrise totalement une US et propage l'information à sa manière
=> Se fier à l'expert et se laisser influencer sur l'estimation sans trop réfléchir
THE EXPERT CATALYST
• Eviter les mots/expressions parasites qui influencent:
 "juste"
 "simplement"
 "facile"
 etc...
• Planning Poker pour les estimations
=> chiffrage simultané

• US qui ne rentre pas dans le scope en fin de Sprint Planning
=> Ajuster le chiffrage de celle-ci en fonction de la vélocité
THE VELOCITY EXTRAPOLATION
• Ne surtout pas prendre en compte la vélocité pour
ajuster les estimations
• Continuer de chiffrer sans regarder la vélocité
• Accepter en conscience, pas d'engagement à perte

• US sur un sujet qui par le passé avait été sur/sous estimé
=> Surestimer cette fois-ci? Sous-estimer?
THE EXPERIENCE APPROXIMATION
• Réfléchir plus profondément à l'US
• Allez plus loin dans l'analyse pour lever les loups
avant de s'y confronter en vrai

• Vélocité trop faible pour tenir la roadmap
=> Recalculer une nouvelle vélocité sur 3 jours
THE NOT SO GOOD IDEA
• Ne jamais faire ça :)
• Vélocité complètement biaisée et donc, sprint
complètement planté

• US non terminées sur un sprint
=> Finir ces US en début de sprint ou après Sprint Planning
THE RELIQUAT MINIMIZATION
• Ne pas mettre en péril l'engagement du nouveau sprint
• Remettre l'US dans le sprint suivant avec son estimation

Rejoignez-nous
Mise en pratique

SCRUM BALL POINT GAME
• Vous êtes dans une équipe
• Entre chaque équipier les balles prennent l'air
• Pas de passe àvotre voisin direct
• Le point de départ est le point d'arrivée
• Tous les membres de l'équipe doivent toucher la
balle une seule fois sauf le point de départ qui est
aussi le point d'arrivée
• Une balle qui tombe, touche le sol ou qui ne
respecte pas ces règles est perdue.
Règles
du jeu

SCRUM BALL POINT GAME – FIN D'ITERATION
• Que s'est-il passé ?
• Comment peut-on s'améliorer ?
• Estimation pour la prochaine itération

SCRUM BALL POINT GAME
LE BESOIN A ÉVOLUÉ !!

SCRUM BALL POINT GAME- DEBRIEF

UN POINT, C’EST TOUT ? - CONCLUSION
 Le cerveau humain n’est pas capable d’estimer le temps de manière absolue
 La prise d'initiative est fondamentale
 Performance dépend du système et non des individualités
 L’expérience permet d’estimer de manière plus efficace et de mieux
appréhender le changement
 Merci à tous pour votre présence et votre participation !!

QUESTIONS ?

Rejoignez-nous
Merci !

Agile Laval 2018 - "Un point, cest tout?"

Recommandé

Recommandé

Contenu connexe

Similaire à Agile Laval 2018 - "Un point, cest tout?"

Similaire à Agile Laval 2018 - "Un point, cest tout?" (20)

Dernier

Dernier (20)

Agile Laval 2018 - "Un point, cest tout?"