La DoD aide à déterminer si un item du backlog de sprint (US par exemple) peut être considéré comme terminé.
Elle fluidifie le travail des développeurs (codeur)
Aligne l’équipe technique et métier sur le résultat attendu en fin de sprint.
Évite les allez retours et les déceptions
Elle est garante de la qualité du produit
Un accord sur la notion de terminé
…
Une fois que l’élément de backlog répond à ces critères, il peut être déployé.
Que dit le guide SCRUM
La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait les mesures de qualité requises pour le produit.
Dès qu’un élément du Product Backlog satisfait à la Definition of Done, il se transforme en Increment. La Definition of Done apporte de la transparence en permettant à chacun une compréhension commune du travail Fini dans le cadre de l’Increment. Si un élément du Product Backlog n’est pas conforme à la Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alors renvoyé au Product Backlog pour être pris en compte ultérieurement.
Les critères d’acceptations du ticket sont tous validés
Les différents test ont été réalisés et le résultat accepté par les différents acteurs de la qualité du produit (PO, Codeur, Testeur, …)
La doc nécessaire a été mise à jour
Les maquettes graphiques sont respectées
Livré dans un environnement stable (possible en DevOps)
Il est tout a fait envisageable que selon le contexte (frontend, API, …) des parties de la DoD ne s’appliquent pas à certains ticket. (Storyotype)
Attention tout de même …
La definition of done ne doit pas être une liste infinie de critères impossible à terminé durant le sprint. Elle est un engagement fondamental de l’équipe a fournir un ticket finit et ne dois pas devenir une contrainte (dans le sens difficilement réalisable)
La définition doit rester simple pour être comprise par l’ensemble de l’équipe du projet. Il n’est pas non plus utile de chercher la sur-qualité et de mettre les objectifs de sprint en difficulté. Il est inutile de commencer par une définition super élaborée, nous l’affinerons avec le temps.
Elle évolue
Comme mentionné auparavant, on amendera la définition, donc à un moment, des items réputé « done » ne correspondront pas à cette définition.
Le mot de la fin
La DoD aide à augmenter la qualité d’un ticket
Elle est le fruit d’une discussion ouverte entre tout les membres de l’équipe.
Elle n’est pas figée dans le temps et donc évolue en fonction de la maturité de l’équipe
Ses principaux avantages sont l’optimisation de la rédaction, de l’estimation, le gain de temps lors du sprint planning
Attention, la DoD ne doit pas être un frein, elle ne doit pas être une liste à rallonge de critères qui sont peu ou pas utiles à l’équipe, elle doit être réalisable, ajustable et adaptée à l’équipe du projet.
Réponse courte, il contient tout ce qui est nécessaire à sa réalisation. (Elle était facile celle là.)
Le jardinier
Objectif
Via un atelier et une réflexion, faire émerger de l’équipe qu’il y a 1001 manière différente de (ne pas) comprendre la demande dans un élément du backlog (ticket / post-it / PBI [Product Backlog Item] / what ever …) via une mise en situation sur quelque chose qui est simple en apparence. Au plus il y aura de monde dans l’atelier, au plus il y aura des divergences.
Livrable attendu
En fin d’atelier, nous devrions ressortir avec une structure à appliquer pour les PBI. Ce livrable ne sera probablement pas encore parfait et devra être affiné de temps à autre. C’est une excellente occasion pour embrayer sur un « Definition of Ready » si cette dernière est réclamée par l’équipe. (Attention de ne pas tomber dans le piège de la DoR qui au passage n’existe pas dans SCRUM).
Que dit le guide SCRUM
L’élément de backlog a 3 caractéristiques:
Une description
Une valeur métier
Un ordre de priorité
Autres points d’attention
Ce qui constitue l’élément de backlog est à contextualiser au type d’élément (bug, story, business requirements, spike …) et à ce dont l’équipe à besoin. De ce fait, le résultat de l’atelier sera à chaque fois unique.
Garde également en tête que pour passer dans un sprint, ce dernier doit être assez petit que pour être réalisé entièrement dans ce sprint (par une ou plusieurs personnes au turbin, ce n’est pas précisé), qu’il doit apporter de la valeur au produit (ou réparer une valeur). Il doit également doit être cohérent avec le sprint goal
Choisis un icebreaker qui permettra à tes invités de se sentir en confiance et de se connecter entre eux. Pour ma part, je compte démarrer sur un exercice simple: « Ecrivez-moi un élément de backlog pour débarrasser la table ». Si tu as des enfants dans ton entourage, tu comprends déjà la complexité de cette tâche …
Présentation du contenu par tout le monde – 36 min
Exercice pratique – 36 min
Si nécessaire, ajoute un second round, mais sois claire avec la contrainte de temps, la timebox permet d’assurer une cadence et d’avancer dans l’atelier. Il arrive que la « double pair » ne soit pas réalisable par manque de participants, et bien dans ce cas, on passe l’étape.
Phase de réflexion
Chaque participant réfléchis seul (et en silence) durant un temps déterminé à répondre à la question.
Phase de présentation en pair
Les participants se groupent par 2 présentent le résultat de leur travail et échangent leurs idées autour du sujet.
Phase double pairs
Les pairs se réunissent en double pair (par 4 donc) et confronte le résultat de leur recherche ensemble
Phase de récolte
Chaque groupe tour à tour présente une idée de ce qu’il faut mettre dans un PBI. On évite de présenter une idée déjà sur le tableau mis à part pour ajouter une information sur cette dernière. Une phase de discussion venant juste après, nous prenons tout ce qui est proposé et le notons sur le support choisit. La pertinence du contenu sera discutée ensuite.
Certains groupes donneront une réponse relative à débarrasser la table comme: mettre les assiettes au lave vaisselle, laver la table … il faudra dans une autre étappe transformer celà en critère d’acceptation. D’autre donneront directement quelque chose de générique et exploitable, comme: un titre, une description …
Discussion
Il est temps de laisser les élèves discuter, argumenter sur le résultat de leur travail et déterminer ce dont eux ont besoins dans un item de backlog. Ils discutent également de ce dont ils ne veulent pas dans le ticket.
Cas pratique
Et hop, on repart avec un cas pratique, un ou plusieurs items du backlogs. Si pas, un cas fictif, « Remplir le lave vaisselle ». Et là aussi, on peut s’amuser en famille 🙂
Matériel
Une salle, pouvant accueillir plus de personne que le nombre de participant. Environ 1.5 fois pour pouvoir espacer les groupes.
Des choses à manger et à boire. (Il est très important d’avoir du gras sur les mains, de faire des taches de thé, café …).
Un panier à portable (smartphone / ordinateur).
Du papier et de quoi écrire (un bic, ça tombe en panne, prévois en plus).
Tableau blanc / grande feuille de papier / projecteur ou écran avec Miro ou ppt pour noter
Anciennement appelé PBI pour Product Backlog Item, la version 2020 de scrum parle d’élément de backlog (Backlog element). Nous parlons également de ticket, parfois de tâche, et par abus de langage, « User Story ».
Un élément de backlog est également:
l’expression d’un besoin utilisateur
Une description du produit
Un élément de planification
Un support à l’échange (3c)
Un mécanisme pour retarder la conversation (pour qu’elle soit faite au bon moment, pas pour l’éviter)
Les différents éléments de backlog
Liste non exhaustive d’éléments que nous pouvons trouver dans un backlog
Theme
Épic (Epic / feature)
Histoire utilisateur (User story)
Demande métier (Business requirement)
Tâche (Task)
Activateur (Enabler)
Sous tâche (sub task)
Spike (et là, je n’ai pas la version française).
Dysfonctionnement (Bug)
…
Le détail de ces éléments fera probablement l’objet d’un article dans le futur)
Histoire utilisateur
Contrairement à la croyance populaire, le récit utilisateur / User Story n’est pas originaire de scrum, mais bien de l’extrême programming (XP).
L’affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille. Les attributs varient souvent en fonction du domaine d’activité.
Dans tous les cas, l’item doit être suffisamment petit pour être « done » en un sprint (éventuellement développé par plusieurs personnes).
L’item doit être suffisamment décrit et compris par l’ensemble de l’équipe. Donc, l’item en lui-même n’est pas suffisant, le contenu doit faire l’objet d’une discussion avec les membres de l’équipe. La taille maximum de l’item est donc relative à la longueur du sprint. Gardons à l’esprit qu’avoir un élément qui prend tout le sprint n’est absolument pas une bonne pratique.
Proposition de structure
Je compte ici m’attarder sur le Bug et la demande de fonctionnalité (nouveauté ou changement)
Un titre
Une petite phrase simple qui correspond à ce qui est demandé et permet de distinguer les tickets aisément dans une liste. Ce titre doit avoir du sens, c’est un peu comme le titre d’un livre, d’une histoire, il décrit l’activité qui sera créée.
Une description
Elle est exprimée sous forme d’histoire utilisateur / narration « En tant que {role} je souhaite {une fonctionnalité} afin de {un bénéfice} », et/ou sous forme de texte. C’est d’ici que tout part, c’est sur cette base que l’équipe va avoir une conversation et estimer le travail à faire.
Une estimation
L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.
Pour ce qui est du bug, il n’est estimable que lorsqu’il est bien compris, et donc que la majorité de la complexité est résolue. Un bug n’est donc pas toujours estimable.
Beaucoup plus utile pour le développement d’une fonctionnalité, mais peuvent également être repris pour un bug, après tout, ce sont certainement des choses qui étaient demandées dans le ticket d’origine et qui ne sont plus respectée.
Les critères d’acceptation sont un ensemble de critères décrits du point de vue de l’utilisateur (persona / machine), afin de déterminer si une histoire utilisateur est finie (done) et fonctionne comme prévu. Donc, un ensemble d’exigences qu’un ticket doit satisfaire pour être considéré comme done. Ils sont uniques pour chaque ticket.
Bien entendu, ils vont arriver au fur et à mesure que la story se crée et se précise. Ils changeront donc potentiellement jusqu’à ce que le ticket accède au statut de « ready ».
Basé sur les critères d’acceptation pour le Happy et créé de toute pièce pour le unhappy flow, ils vont aider le codeur à gérer directement tous les cas possibles et orienter au mieux l’utilisateur du système quand il sort du chemin attendu. La présence des tests case avant le développement participe à la qualité du produit et à un développement plus rapide, car ils vont éviter des aller-retour. Nous parlons ici d’un shift left des tests.
Résolution technique
Le résultat des conversations entre les dev pour réaliser l’item. Ceci aide à établir le plan nécessaire à tous les sprints. Ceci est également nécessaire quand le dev en charge de l’analyse technique n’est pas la personne qui développera effectivement la fonctionnalité.
Pour rappelle, l’output d’un sprint sont l’objectif de sprint, le contenu du sprint et un plan de réalisation du dit contenu.
Des liens
Et oui, il est peu probable que ce ticket ne soit pas lié à un autre de l’application, il ajoute une fonctionnalité accessible depuis telle partie de l’application, il améliore telle autre, c’est la version 1 de tel « truc » … Il est également possible que ce ticket soit le résultat de la découpe d’un plus gros, et donc, bien entendu, le tout est lié.
C’est d’autant plus important pour un bug qui cherche à récupérer la valeur perdue (puisque ça ne fonctionne pas) d’un élément du backlog.
Et enfin, ça ajoute du contexte à ce qui doit être développé.
Des documents
Un graphique eml, un document technique, une maquette, la liste des composants déjà créés à réutiliser, une référence vers un wiki, peut importe, tout ce qui aide à la réalisation du ticket.
Attention
Si vous mettez un lien vers un document et non le document lui-même, le système de backlog (jira, azure, …) ne va pas traquer la modification, de plus si vous faites évoluer la cible du lien pour des réalisations futures, mais que l’élément de backlog n’est pas encore réalisé (done), vous allez vous retrouver avec un déphasage. Le corolaire est également ennuyant, quand vous devez utiliser le même document pour plusieurs tickets, vous devez les changer dans tous ces tickets …
Pour conclure
Tous les éléments de backlog sont à contextualiser à leur fonction (histoire utilisateur, bug …), les attributs changeront donc sensiblement.
Chaque équipe doit établir son propre modèle, sa liste d’attribut par type d’élément de backlog.
Last but not least, il ne faut pas remplir un attribut parce qu’il existe, si il n’y a pas de plus value, ignorons le.
Que répondre à une demande d’augmentation de la vélocité?
Comprendre
S’assurer que le demandeur sait de quoi il parle
Est-ce que le demandeur sait de quoi il parle? Sait-il que la vélocité est une mesure qui est utile uniquement à l’équipe, qu’elle ne peut être comparée entre les équipes …
Il y a sur ce site plusieurs articles qui peuvent t’aider à faire comprendre ce qu’est la vélocité
Une personne de l’entreprise a comparé les différentes vélocités?
Il y a une nécessité d’accélération du développement pour réagir et s’adapter au marcher?
…
L’objectif est de trouver une réponse adaptée à la demande, par exemple, s’il faut réagir à un marché changeant, la réponse n’est pas une meilleure vélocité, mais un changement de priorité, un pivot.
Si le client désire une augmentation du résultat, alors, oui, c’est peut être une solution.
Que peux faire l’équipe pour y arriver
Favoriser la communication et la collaboration
Une collaboration et un contact direct entre les gens favorisent généralement la prise de décision et la résolution des problèmes. En effet, quand on se comprend, on passe plus vite à la solution efficace.
Travailler à la réduction des problèmes
Oui, c’est évident, au plus vite les problèmes sont résolus, au moins ils auront d’impact et au plus on a de temps pour autre chose. Des soucis non résolus qui s’accumulent génèrent généralement du travail supplémentaire.
De plus, un esprit léger nous permet de nous concentrer sur le principal, à savoir, la réalisation du produit.
Augmenter la qualité du code
Même si mettre en place un système de production et de revue de code efficace semblera être une perte de temps, il évitera les aller-retour entre le test, le développement, l’acceptation du métier …
Avec un code qualitatif, nous avons moins de bugs, et donc, moins de rework, moins de régression. C’est exactement cela qui donnera de la confiance au client et permettra un meilleur focus de l’équipe sur les choses qu’ils doivent résoudre. Explorer des pratiques comme le pair-review, le Test Driven Développement est donc à envisager.
Tester le code
Comment, ce n’est pas encore fait …
Parmi les raisons pour lesquelles il est important de faire des tests unitaires de son code, on a d’abord;
Les tests unitaires peuvent aider à détecter les bugs dans le code plus rapidement et plus efficacement (d’où une augmentation de la qualité).
En outre, les tests unitaires aident à garantir que le code continue de fonctionner correctement lorsque des modifications sont apportées. Les TU sont rejoués à chaque itération de code
Enfin, les tests unitaires servent également à documenter le comportement attendu du code, ce qui peut faciliter la maintenance et la compréhension du code à long terme.
L’automatisation
Quoi de plus ennuyeux que de devoir lancer les 10 mêmes commandes de compilations encore et encore pour ensuite passer aux tests puis générer un rapport alors qu’il est possible en appuyant sur un bouton de lancer un script qui va aller chercher la dernière version du code, ou une branche, la compiler, remplacer les différents couples utilisateur mot de pass nécessaire à l’environnement à la volée Il est beaucoup plus intéressant de libérer du temps pour des tâches plus créatives.
Et bon, soyons claires, si en plus vous pouvez juste pousser un bouton pour passer en production … 🙂
Automatiser les tâches répétitives : en automatisant les tâches répétitives, l’équipe peut se concentrer sur des tâches plus importantes qui nécessitent une attention humaine.
L’apprentissage en continu
En augmentant son niveau de compétence, via de l’apprentissage, l’équipe sera en mesure de réagir plus vite et probablement mieux face aux obstacles qui se dressent. Ils s’adapteront plus aisément. Ils seront en mesure d’appréhender les nouvelles technologies …
Augmenter le nombre de membres
C’est probablement la chose la plus simple à comprendre et donc, celle à laquelle nous penserons en premier.
Ce n’est pas faux, mais il faut nuancer le propos … Si ajouter un membre qualifié et divise les tickets en plus petits items indépendants pour permettre de répartir les « tâches », alors oui, on devrait augmenter la vélocité à moyen long terme. Il faut également que le nouveau membre soit bien intégré à l’équipe.
Attention, en augmentant la taille d’une équipe, il peut y avoir la naissance de coups supplémentaires suite à des besoins de coordinations. La communication est également plus complexe au fur et à mesure que l’équipe grandit.
La lecture de ces articles te sera certainement utile:
La vélocité, c’est « l’effort » moyen qu’est capable de réaliser une équipe sur une période donnée. (Une quantité de sprint par exemple). Cet effort peut être exprimé au moyen de story points
Exemple de calcul
Voici quelques données nécessaires à la compréhension d’un calcule de vélocité. Comme tu le constates, il y a une grande différence entre les sprints 8 & 9 et les autres. De temps à autre, il arrive que l’équipe ne finisse pas tout ce qu’il y avait dans le sprint, je t’invite à lire l’article Le sprint est fini, et il reste des tickets Les points brûlés correspondent à l’addition des SP des items réalisés. Répondant à la Definition of Done (DoD)
Sprint
Points brulé dans le sprint
Sprint 7
25
Sprint 8
11
Sprint 9
37
Sprint 10
24
Sprint 11
26
Donnée nécessaire à un calcul de vélocité
Nombre total de points pour les 5 sprints: 123 Nombre moyen par sprint / vélocité: 24,6
Est-ce toujours fiable?
Pas nécessairement, c’est une excellente indication, mais certains facteurs vont influencer les chiffres.
Les jours de maladie / congé
Si un développeur ne travaille pas et donc ne développe pas, il y a moins de choses qui sont réalisées au courant du sprint => moins de SP brûlé.
Si nous fonctionnons en flux tendu (c’est-à-dire que le temps entre la rédaction des tickets et leur apparition dans un sprint est relativement court), on pourrait également se retrouver avec moins de choses à faire, ou des choses non encore bien décrit et répondant à la DoR. Dans ce cas, le travail de développement sera également impacté.
Oui, mais bon, tous les développeurs sont au moins une fois malades sur l’année, donc, on peut lisser cette donnée. Ce n’est pas faux, mais ce n’est pas tout à fait vrais non plus, on reviendra sur cela plus loin dans l’article.
Au plus l’équipe est petite, au plus ce facteur aura d’influence (100% pour une équipe de 1 dev).
Les changements dans l’équipe
Alors ici, c’est très simple, si l’équipe n’est pas stable depuis un certain temps, cette information n’a absolument aucun sens, aucune fiabilité, aucune valeur.
En cas de nouveau venu, du temps à consacrer à son intégration, à la place du développement des tickets. En théorie, on reviendra à la situation initiale et à une augmentation après un certain temps. Si ce n’est pas le cas, il y a des questions à se poser.
Un membre de l’équipe part, il y a donc moins de « force de travail » disponible
À tous les coups, un changement dans l’équipe modifie la vélocité.
La spécialisation des membres de l’équipe
Une équipe doit être en mesure de réaliser l’entièreté du produit, cependant, ses membres ont certaines spécialités. Il est tout à fait envisageable dans un projet de développement d’une application ou d’un site qu’un sprint contienne plus de demande front-end que back, dans ce cas, un spécialiste back-end peut se retrouver sans ticket dans sa spécialité. Bien entendu, il ne va pas rester à rien, mais il est certainement moins compétent dans les autres domaines. PS c’est probablement un bon moment pour régler un peu de dette technique (qui ne devrait pas exister) ou aider à l’analyse, ou optimiser du code …
Que peut-on faire avec cette information?
Prévoir le nombre d’item à mettre dans un sprint
Cette mesure nous permet par addition des SP de savoir quelle quantité de tickets nous pouvons mettre dans le sprint.
Planifier
On peut faire un forcast, c’est-à-dire qu’on peut tenter de prédire, d’estimer et donc de planifier quand une fonctionnalité aura été développée.
Considérons qu’en additionnant les story points des tickets nécessaires à la réalisation d’une fonctionnalité, on arrive à 94. Nous savons que notre moyenne / vélocité est de 24,6
94 / 24,6 = 3,82.
Il nous faut donc 3,82 => 4 sprints pour réaliser la fonctionnalité.
Quelle période de temps devons-nous considérer?
On serait aisément tenté de dire qu’au plus la période de référence est longue, au plus la mesure est fiable. Après tout, on a plus de données …
Et bien non, la vélocité va varier avec le temps. Nous avons déjà soulevé le cas de l’augmentation ou diminution du nombre de membres dans l’équipe, nous allons donc considérer que l’équipe reste stable.
Il y a d’autres phénomènes qui feront varier cette information, par exemple, la montée en compétence technique des membres, la manière d’écrire les tickets va évoluer avec le temps, idéalement devenir meilleure, les membres de l’équipe vont mieux se comprendre et l’estimation deviendra plus précise.
On considère l’information comme correcte après 3 à 5 sprints. Sachant que cette valeur évolue légèrement au fil du temps, utiliser un forcast à long terme n’est pas idéale. Au plus le calcule se fait dans le futur, au moins l’information a de valeur.
Donc, on ne peut pas facilement considérer la possible absence d’un membre durant 4 semaines sur l’année ou même un prorata
Il est tentant de comparer les vélocités propres des équipes, ou de faire un prorata par développeur. Hé bien, cela ne fonctionne pas, car les estimations pour l’équipe A ne sont pas les estimations l’équipe B.
La lecture de ces articles te sera certainement utile:
C’est probablement une excellente démarche que d’entreprendre des estimations, cependant, il y a quelques pièges à éviter. Voici une courte liste de points d’attention
Savoir ce qu’est une estimation
Je te conseille la lecture de cet excellent article sur ce que sont les estimations . (Il est excellent car c’est moi qui l’ai rédigé ;))
Avoir un ticket de référence
La dérive des continents estimations. Sans baseline, ou référence comparative, les estimations vont se décaler, de ce fait, la vélocité, le burndown chart et autres indicateurs ne seront plus fiables.
Ne pas convertir les estimations en jour-homme
Les jour-homme créent une complexité inutile et annulent complètement l’intérêt d’estimations relatives qui permettent à tout le monde travaillant à des vitesses différentes de se comprendre et de se mettre d’accord.
Ne pas estimer uniquement en fonction de la complexité
Si on estime uniquement la complexité, une story « simple » mais demandant beaucoup d’effort. (Par exemple une tâche à répéter un certain nombre de fois, des tests longs …). Cela va créer de fausses prédictions et un manque de visibilité sur la quantité / charge de travail à réaliser dans le backlog.
Voici un tableau comparatif « à la suédoise » de la notion de complexité par rapport à la notion d’effort.
Ticket
Remarque
Comp.
Effort
En tant que constructeur, je souhaite monter un tabouret MARIUS afin de poser mes fesses
3 visses à serrer
1
1
En tant que constructeur, je souhaite monter un tabouret SKOGSTA afin de poser mes fesses
Un rien plus complexe que le MARIUS
2
2
En tant que constructeur, je souhaite monter un lit NORDLI afin de pouvoir dormir
C’est bien plus compliqué qu’un tabouret et les tiroirs sont super dur à mettre en place
5
5
En tant que constructeur, je souhaite monter 10 tabourets SKOGSTA afin de poser mes fesses et celles de mes invités
Aussi complexe simple qu’un SKOGSTA . (Nous aurions également pu considérer l’expérience)
2
20
Exemple de la complexité VS l’effort pour la réalisation d’un ticket
Ne pas considérer une estimation comme quelque chose de précis, gravé dans le marbre
Jamais l’équipe et/ou les parties prenantes ne peuvent considérer une estimation comme un contrat. L’estimation est surtout valable au moment où elle a été faite, la solution évoluant au jour le jour, il est envisageable qu’un item soit impacté par la réalisation d’un autre qui n’existait pas au moment de l’estimation. (Si il existait déjà, il faut absolument lier les 2 tickets et marquer le dépendance). Il n’y a pas que l’application qui évolue, les développeurs aussi, dans la plus part des cas, il considérera le ticket comme plus « simple » et tout le monde y gagnera.
Ne pas considérer les estimations comme une mesure de productivité des équipes, ou pire, des développeurs.
Dans ce cas, nous verrons très vite apparaitre des dérives telles que surestimation systématique, sous engagement dans le sprint pour être sûr de le terminer.
Certains développeurs feront des heures supplémentaires et seront donc moins alertes et moins qualitatifs. D’autres simplement bâcleront le travail pour tenir le délai, ce qui générera inévitablement de la dette technique
Les estimations ne sont en aucun cas à utiliser pour contrôler l’équipe et/ou un développeur en particulier
PiPo
Ne pas comparer les estimations de deux équipes
Il est tentant de comparer les performances des équipes en convertissant l’estimation en chiffre et en divisant le total d’un sprint par le nombre de jours de ce dernier (et de faire un prorata par développeur). Hé bien, ça ne fonctionne pas, car une estimation pour l’équipe A n’est pas une estimation pour l’équipe B.
Faire attention aux changement dans l’équipe
Si une personne sort de lʼéquipe, cette dernière aura moins de force de travail, donc, la vélocité va décroitre.
Si une personne rejoint lʼéquipe, dans un premier temps, la vélocité va également décroitre (Lʼonboarding va occuper dʼautres membres de lʼéquipe, la nouvelle personne ne sera pas efficiente à 100% au début …) Sur le long terme, la vélocité devrait croitre et dépasser la vélocité initiale. Si ce n’est pas le cas, il faut absolument comprendre pourquoi.
Ne pas forcer à estimer
Jamais les développeurs ne doivent se forcer / être forcé à estimer un ticket. Si un ticket ne peut être compris, il ne doit pas être estimé. Une fois que l’estimation existe, elle est utilisée par les autres membres de l’équipe, or, si elle n’est pas correcte, elle faussera les travaux de ses utilisateurs.
Ne pas estimer avec une seule personne
Durant une session d’estimation, avec plusieurs participants, nous arrivons de temps à autre à des résultats différents, ce qui permet d’ouvrir un débat et amène généralement des questions sur le travail à effectuer. Nous y gagnions en précisions.
En dehors de cela, avoir une équipe avec un seul développeur n’est pas prudent, imagine l’impact si ce dernier quitte le projet …
L’estimation est une manière de représenter la charge nécessaire à la réalisation d’un item pour arriver au résultat demandé.
C’est pour les équipes qui utilisent les estimations probablement la dernière étape pour passer le ticket en ready (DoR)
Pourquoi estimons-nous?
Réduire au maximum les risques
La session d’estimation sert à mettre au jour et diminuer les zones d’ombre et risques du projet. Une fois ces dernières connues, on peut choisir comment les traiter:
Un Spike. Il est utilisé quand on ne connait pas encore la solution technique qui peut être apportée à un problème (idéalement, on fera un ou plusieurs POC).
Inclure cette inconnue dans l’estimation.
Servir de support à la prise de décision et à la priorisation
Avant de développer une fonctionnalité, il est intéressant d’avoir une idée de son coût. Une entreprise qui investit doit pouvoir estimer son ROI (retour sur investissement), cette information servira également dans la priorisation du backlog, c’est la raison pour laquelle il est possible qu’une story estimée ne soit jamais développée. Quand une application doit être mise en production, en fonction du nombre de sprint disponible et du « coût » de développement, on priorisera différemment certaines features. Faut-il engager plus de développeurs, testeurs, analystes et techniques pour augmenter la valeur livrée?
Établir la confiance
Pour que la confiance règne entre les parties prenantes d’un projet (clients, décisionnaires, PO), il faut que l’équipe soit fiable sur sa capacité à livrer ce qui est promis. Les estimations nous guident dans ce que nous devrions être capables de livrer dans un futur plus ou moins proche. Grâce à cette donnée objective, nous pourrons plus facilement négocier le périmètre des releases
Aligner lʼéquipe et partager lʼinformation
Les estimations permettent de sʼassurer dʼune compréhension commune du périmètre, de la valeur à produire et de se mettre dʼaccord sur la « taille » dʼune fonctionnalité.
Pour découper les User Stories (US)
Quand nous lisons, comprenons et estimons un ticket, nous pouvons parfois nous apercevoir que cette dernière est trop importante. Dans ce cas, nous le divisons en ticket plus petit. Nous augmentons la granularité du backlog et renforçons la prédictibilité du travail.
Pour organiser le sprint backlog produit du point de vue de la valeur, de l’effort.
Si nous connaissons lʼeffort nécessaire à la réalisation dʼun ticket, nous pouvons déterminer si ce dernier est réalisable dans le sprint.
Planification
Cʼest également un bon moyen pour estimer le nombre de sprint nécessaire à la réalisation des tickets souhaités dans une release via un forecast. On peut également communiquer plus facilement les causes d’un changement de plan, par exemple, si l’on découvre que l’intégration d’un système à notre application est plus complexe que prévu, on peut aisément démontrer l’effet sur ce que nous avions prévu.
/!\ Le forecast n’est absolument pas un outil permettant de prévoir avec certitude quand une application serra développée.
Le Jardinier
Que représente une estimation?
Nous allons ici explorer plusieurs hypothèses sur le que/quoi et le comment estimer, selon quelle métrique.
Des jours hommes / du temps?
L’humain est incapable d’estimer correctement son temps
Une date ne prend pas en compte les facteurs externes tels que les emails, les meeting, les conversations informelles, lʼaide apportée par un développeur à un autre … (Habituellement, nous considérons quʼun développeur développe environ 6h/ jour)
Le temps / les dates ont une valeur émotionnelle qui finira par oppresser les développeurs et le poussera soit à diminuer la qualité de son travail pour gagner du temps, soit à augmenter le temps prévu.
Le temps nécessaire pour un développeur ne sera pas le même que pour un autre.
Pour illustrer mon propos
Prenons le cas d’une course à pied selon le point de vue d’un analyste ayant fait un Iron Man et d’un Scrum Master de 110 kg.
Si on demande une estimation en temps pour les 20km de Bruxelles, le premier répondra 2h30, le second 6h (sans certitude de terminer). Ajoutons à cela que c’est une tierce personne qui va courir le jour J, il est totalement impossible de prédire le temps qui sera nécessaire. (Même un calcul savant donnerait une réponse erronée). En revanche, si on demande d’estimer l’effort, la réponse sera pour les deux 20km. Et si demain on parle d’un marathon, on sait que l’effort est peu ou prou le double.
Pour les tickets, c’est la même chose, si on estime en jours/homme, on doit savoir qui fera la tâche.
De la complexité?
Au plus c’est complexe à réaliser, au plus la valeur de l’estimation serait élevée, et inversement. C’est en effet un point de départ intéressant, mais qui a ses limites.
Pour illustrer mon propos
Considérons une équipe de deux personnes composée d’un enfant et d’un chirurgien du pied. Considérons 2 tickets (Nous supposons que les activités prennent le même temps.), construire 1000 personnages Lego et réaliser une reconstitution du pied (le pauvre a marché sur une brique).
Si nous parlons complexité, l’opération du pied aura une estimation bien plus élevée que le montage des personnages. Si le but était de planifier et de savoir quand l’équipe aurait terminé, puisque le temps de réalisation est plus ou moins identique, l’estimation aurait dû être la même. En fait, on peut dire que si la complexité des tâches varie, l’effort à fournir est comparable.
Un risque
Dans cette hypothèse, nous considérons qu’au plus le travail est risqué, au plus l’estimation devrait être élevée, et inversement. C’est assez risqué de prendre uniquement cette donnée pour une estimation.
Pour illustrer mon propos
Considérons l’estimation de la durée du voyage maison boulot en transport en commun et en trottinette. Le transport en commun est plus rapide, mais « risqué » (Présence de bouchon, des gens dans les voies (oui, la SNCB dit bien dans les voies). La trottinette, même électrique, c’est plus « sûr », mais c’est lent (oui bon, on ne va pas prendre en considération le nombre de personnes aux urgences après une chute). Une estimation en risque serait plus élevée pour le transport en commun, cependant, il est tout à fait possible que vous arriviez plus vite en bus qu’en trottinette au boulot demain. (Si demain est un weekend, ne vient pas au bureau).
Mais alors quoi?
Et bien, nous devrions surtout parler d’une notion d’effort qui reprendrait toutes les hypothèses précitées. La quantité de travail à fournir, sa complexité, ses risques et inconnues, le temps.
Quelle mesure pouvons-nous utiliser pour représenter l’effort?
T-shirt sizing
À mon sens, à utiliser pour du haut niveau, par exemple pour se donner une idée avant analyse
Valeurs disponibles: XS, S, M, L, XL …
Les animaux
De nouveau, nous sommes sur quelque chose destiné à du haut niveau. Avant l’analyse, Épic …
Valeurs possibles: Puce, tigre, éléphant …
Les StoryPoints
À utiliser pour des tickets pour lesquelles nous avons beaucoup d’informations, voir, plus d’inconnue.
Valeurs disponibles: 1, 2, 3, 5, 8, 13 …
D’autres articles suivront sur ces différentes mesures.
Quand on estime un ticket, ce n’est pas je qui estime, mais nous. Toutes les estimations sont le résultat d’un travail d’équipe.
Le Jardinier
Pourquoi parler de relativité (E=mc²)?
Reprenons notre exemple de course, si notre première estimation était faite pour une course de 20 km, nous pouvons aisément estimer que l’effort nécessaire à 10km sera de 1/2 tandis que l’effort pour 40km sera le double. De la même manière, les autres mesures permettent à l’équipe un accord sur la taille relative des tickets. Par exemple, la story 2 représente 1/2 des efforts de la 1. La story 3 représente 2 fois la somme d’effort de la première.
Estimer de manière relative prend en compte l’imprécision de nos estimations. En effet, les humains ne sont absolument pas doués pour ce genre de chose, par contre, ils sont tout à fait capables de comparer 2 choses entre elles.
Revenons à nos Lego, en voyant un tas, vous ne seriez pas en mesure de donner le nombre de briques qui le compose, par contre, vous pouvez comparer 2 tas et dire qu’il y en a plus dans celui-ci. Vous pourriez également dire qu’ils sont à peu près identiques …
On peut faire le même exercice avec des verres d’eau (ou de Vodka).
Le premier verre est la référence
Nous pouvons estimer que le second est plus rempli
Le troisième est aussi rempli que le 1er (à moitié vide, ou moitié plein …)
It’s difficult to make prediction, especially about the future
Variation du résultat par rapport au travail à fournir
Nous devons garder à lʼesprit que même si lʼéquipe est normalement capable de développer entièrement le produit, nous travaillons avec des spécialistes. Donc, si durant une période donnée, il y a moins de travail dans un domaine, la quantité de travail fournie par l’équipe va mécaniquement diminuer.
Précisions
Il est impossible d’obtenir un chiffre précis quoi que nous fassions. Par contre, au fil du temps, pour une équipe stable, la corrélation estimation de l’effort et nombre de tickets done dans un sprint sera de plus en plus exacte, et donc, la prédiction moyen terme également.
Last but not least, les estimations, ce n’est pas SCRUM, c’est XP.
Ils déclenchent le processus de réflexion de l’équipe et amènent à penser, à comment une fonctionnalité va se comporter du point de vue de l’utilisateur final (persona)
Souviens toi, une story c’est surtout une amorce à la discussion / réflexion.
Servent de base aux cas de test
Aide l’équipe à écrire des cas de tests précis et sur base des critères accepté par tout le monde et donc cohérent sur l’ensemble de la vie du ticket.
Ils décrivent également des scénarii négatifs , et des unhappy flow
Ils affinent le scope
Définissent la portée, les limites du ticket et réduisent les ambiguïtés. Ils clarifient.
Garantie
Ils garantissent que tous les parties prenantes et utilisateurs ont une compréhension commune et sont satisfaits de ce qu’ils obtiennent.
Ils aident à l’estimation
Ils présentent ce qui doit être exactement développé par l’équipe. Grâce à ces exigences précises, l’équipe peut éventuellement diviser en tâches qui aideront à une estimation globale. (Du coup, ça aide aussi à diviser une story en « sous-story »)
Les critères d’acceptation sont indispensables, car ils évitent les résultats inattendus et mettent tout le monde d’accord sur la manière dont va être implémenté un ticket.
Le Jardinier
Qui rédige les critères d’acceptation?
Le PO bien entendu …
Tout le monde le sait, le PO, il fait beaucoup beaucoup de chose, donc, il délègue. Il délègue a qui veut / peut le faire dans l’équipe.
Les analystes qui connaissent bien le sujet du ticket
Le métier qui en faisant cela s’assurera que le besoin exprimé sera bien rempli
Le développeur qui confirmera sa compréhension du ticket
Le QA qui va chercher la petite bête, l’incohérence dans le récit
La manière la plus efficace de créer les critères d’acceptation est très certainement un savant mélange des différents rôles et compétences.
Le Jardinier
Quand rédiger les critères d’acceptation?
Avant le développement du ticket. (Merci capitaine Obvius)
Durant les exercices d’affinage du backlog
Durant l’analyse d’une demande métier
A la rédaction de la demande métier
Durant une phase de discovery
Le format
La check liste
Critère 1
Critère 2
Critère n
Le(s) scénaro(ii)
Étant donné …
Lorsque …
Alors …
Pour les critères de scénario, gherkin, c’est pas mal du tout
Autre
Libre à toi de créer un format qui correspond à ton équipe.
N’hésite pas à le proposer en commentaire
Quelques exemples
Consulter la fiche d’un livre sur un site d’e-commerce
En tant que client du site, je souhaite chercher un livre en spécifiant ou son auteur, ou son titre, ou son ISBN afin de consulter sa fiche
La description du contenu à afficher pour la fiche descriptive du livre de même que la mise en page de la liste de résultat sont décrites dans d’autres tickets.
Liste
Résultat unique: je peux directement consulter la fiche descriptive du livre
Pas de résultat: je suis invité à effectuer une nouvelle recherche
Plusieurs résultats: Je suis invité à choisir parmi une liste de livres
Scénario
Un seul résultat
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a qu’un résultat Alors je consulte directement la fiche descriptive du livre
Pas de résultat
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il n’y a pas de résultat Alors je suis invité à effectuer une nouvelle recherche
Plusieurs résultats
Étant donné que je suis sur la page de recherche du site e-commerce Lorsque je saisis un auteur, ou un titre, ou un ISBN et que je lance la recherche et qu’il y a plusieurs résultats Alors je vois une liste de résultat et peux choisir celui qui m’intéresse
Il est préférable d’utiliser le « je » dans les critères d’acceptation, cela aide à se mettre dans la peau de l’utilisateur, à garder son point de vue et ses besoins à l’esprit
Le Jardinier
Connexion d’un utilisateur non connecté possédant déjà un compte utilisateur
En tant qu‘utilisateur non connecté, je souhaite introduire mon nom d’utilisateur afin d’avoir accès à mon profile
Liste
Nom d’utilisateur et password correcte: affichage du profile utilisateur
Nom d’utilisateur et / ou password erroné: affichage d’un message d’erreur
Nom d’utilisateur et / ou password erroné pour la troisième fois: affichage blocage compte
Scénario
Nom d’utilisateur et password correcte
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis mon nom d’utilisateur et mon mot de pass (correcte) et que je clique sur le bouton de connexion Alors je suis connecté au site.
Num d’utilisateur ou password incorrecte
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte ».
Num d’utilisateur ou password incorrecte troisième fois
Étant donné que je suis un utilisateur enregistré du site e-commerce et que je suis sur la page de connexion au site Lorsque je saisis une paire d’identifiants incorrecte et que je clique sur le bouton de connexion pour la troisième fois dans un temps de 300 secondes Alors je vois un message d’erreur s’afficher: « Votre couple nom d’utilisateur password est incorrecte, votre compte est maintenant bloqué ».
Ajouter un livre dans le panier
En tant qu‘utilisateur connecté, je souhaite ajouter un livre dans mon panier afin de l’acheter
Liste
Le livre peut être livré dans mon pays: le bouton « Ajouter au panier » est disponible
Le livre ne peut être livré dans mon pays: le bouton n’est pas affiché, à la place se trouve un message stipulant que le livre ne peut être livré dans mon pays
Scénario
Je suis dans une zone géographique permettant la vente
Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre Lorsque je suis sur la fiche du livre Alors le bouton « Ajouter au panier » est visible.
Je suis dans une zone géographique ne permettant pas la vente
Étant donné que je souhaite placer un livre dans mon panier et que je suis dans une zone géographique permettant la livraison du livre Lorsque je suis sur la fiche du livre Alors le bouton « Ajouter au panier » n’est pas visible, à la place, un message m’informe que le livre ne peut pas être livré à ma localisation.
Alors oui, je sais, ce n’est pas le meilleur exemple, on pourrait toujours ajouter le livre sans être connecté …
Oups, nous n’avons pas terminé tout ce que nous avons promis …
Pourquoi est-ce qu’il reste un / des tickets dans le sprint
La première étape est de déterminer pourquoi nous n’avons pas terminé le sprint. Nous devrons également répondre à la question suivante: « Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction ».
Une question de capacité
Dans le cas d’un début de projet, il est probable que nous n’ayons pas encore trouvé notre vitesse de croisière, nous remplissons donc le sprint en tâtonnant jusqu’à savoir ce que nous sommes capables de réaliser au cours de la timebox.
Un changement dans l’équipe entraine une perturbation (dans la force). Une personne en moins diminue d’office la capacité de réalisation de l’équipe, logique me diras tu, cependant, une nouvelle recrue va également diminuer la vélocité (dans un premier temps) Quand un nouveau rejoint le projet, il va devoir prendre connaissance du métier, de la problématique que l’équipe résout par son travail, il va également apprendre le fonctionnement de l’équipe, et pour ce faire, les autres membres de l’équipe vont perdre investir du temps pour le former. Donc, en plus de ne pas bénéficier tout de suite d’une augmentation de vélocité, nous allons également en perdre.
Attention, la perte de vélocité doit être à court voire moyen terme, si cette perte perdure, il faut envisager que la nouvelle recrue a été mal intégrée, qu’elle ne correspond pas au projet ou encore que l’équipe devient trop importante et ne se synchronise plus correctement. Dans tous les cas, il faut agir.
Une mauvaise estimation
Et oui, une estimation reste une science inexacte, de temps à autre, nous nous trompons. Nous surestimons ou sous-estimons. La plupart du temps, nous arrivons à l’équilibre.
Une erreur de compréhension
Nous sommes humains, nous avons plein de possibilités de ne pas nous comprendre, alors, oui, il arrive que nous comprenions une chose alors que ce n’était pas du tout ça.
À la revue par les pairs, nous nous rendons compte que ce n’est pas du tout ce qui était demandé.
Ah zut, je n’avais pas ben compris, et je n’ai pas anticipé ces changements, c’est plus compliqué, ça prend plus de temps …
Ah, en fait, maintenant que j’ai compris, je vois que nous avons une dépendance vis-à-vis d’une autre équipe, d’un autre fournisseur …
Ah, l’équipe a changé entre le moment ou ce ticket est passé à prêt et le développement (Oui oui, ça arrive)
Que faire avec les tickets que nous n’avons pas terminés durant notre sprint?
Il n’y a pas de réponse simple, c’est au cas par cas.
La logique voudrait que s’il y avait un ticket X dans le sprint venant de se terminer, c’est qu’il faut le réaliser, donc, hop sprint suivant. Cependant …
La fonctionnalité à développer arrive trop tard, et n’a donc plus de raison d’être.
Le produit a pivoté, la fonctionnalité n’est donc plus aussi prioritaire, voir, plus nécessaire.
D’autres items ayant une priorité plus élevée sont apparus dans le backlog
L’item ne peut pas être réalisé, car il y a des dépendances non résolues
Pour ma part, je considère que si un ticket a été commencé, il est préférable de le terminer. En effet, si nous laissons les changements tels quels, suite aux autres évolutions, le travail sera probablement entièrement à refaire pour être intégré dans la solution qui aura évolué. (Tout en prenant en compte les points précédemment cités)
Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction
Heu, ben oui, en fait, il sert à quoi le daily, si ce n’est justement faire un topo sur la santé du sprint, inspecter au jour le jour que nous pouvons respecter le sprint goal et réaliser tout le contenu initialement prévu.po Si nécessaire, nous nous devons de réaménager le contenu du sprint en accord avec les dev et le PO tout en respectant le sprint goal.
Tout ça pour dire que ça ne devrait pas arriver car nous devrions avoir géré le problème en amont.
Pour offrir les meilleures expériences, nous utilisons des technologies telles que les cookies pour stocker et/ou accéder aux informations des appareils. Le fait de consentir à ces technologies nous permettra de traiter des données telles que le comportement de navigation ou les ID uniques sur ce site. Le fait de ne pas consentir ou de retirer son consentement peut avoir un effet négatif sur certaines caractéristiques et fonctions.
Fonctionnel
Toujours activé
Le stockage ou l’accès technique est strictement nécessaire dans la finalité d’intérêt légitime de permettre l’utilisation d’un service spécifique explicitement demandé par l’abonné ou l’internaute, ou dans le seul but d’effectuer la transmission d’une communication sur un réseau de communications électroniques.
Préférences
Le stockage ou l’accès technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou la personne utilisant le service.
Statistiques
Le stockage ou l’accès technique qui est utilisé exclusivement à des fins statistiques.Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
Marketing
Le stockage ou l’accès technique est nécessaire pour créer des profils d’internautes afin d’envoyer des publicités, ou pour suivre l’internaute sur un site web ou sur plusieurs sites web ayant des finalités marketing similaires.
