Une autre vue sur l'estimation en points, sans la perplexité et la complexité.
Mot-clé - mesures
Fluctuation des indicateurs
08 lundi mars 2010 21:44
Mon livre est sorti depuis presque un mois. La publication est une étape importante et je pensais être libéré une fois que ce serait fait. Mais non, il reste l'inquiétude de savoir s'il sera bien reçu. Je suis à l'affût de tout ce qui pourrait me donner la tendance.
La capacité corrigée des variations saisonnières
21 lundi décembre 2009 08:54
J'avais entendu parler une première fois de coefficient de focalisation en interviewant une équipe il y a quelques mois, sans y prêter une attention particulière. Mais récemment, quand 2 autres équipes Scrum ont évoqué devant moi ce coefficient, je me suis dit que ça venait d'une source unique.
La satisfaction des clients et utilisateurs
08 mardi décembre 2009 12:53
Le dernier paragraphe de l'étude que je relatais dans le billet "il faut abandonner le modèle MOA/MOE dans les DSI" s'intitule "Mesurer la satisfaction des clients". La mesure de la satisfaction, comme la mesure de la valeur (ou utilité), devrait accompagner la mise en œuvre d'une méthode agile, car au cœur de la définition de l'agilité, il y a cette orientation résultats. C'est ce que défend Elisabeth Hendrickson et j'y souscris tout à fait.
Seulement pour avoir des mesures de satisfaction pertinentes, cela prend du temps. Une solution pour avoir plus rapidement une idée de la satisfaction d'utilisateurs et de clients, c'est de venir les écouter. C'est possible pour ceux qui vont assister au SigmaT12 vendredi. Nous aurons deux retours d'expérience différents, avec pour chacun, la présence du client. On verra s'ils sont satisfaits après quelques mois de Scrum...
Pour ceux qui ne pourront pas venir, il existe des enquêtes qui portent sur la satisfaction des clients avec les méthodes agiles, vous en trouverez dans ce billet "Les bénéfices du développement agile".
Le burnup de sprint en tâches
22 dimanche novembre 2009 20:37
Il n'y a pas que le burndown chart de sprint, d'autres indicateurs permettent de suivre le déroulement d'un sprint.
Ma conférence sur les estimations, les mesures et les indicateurs agiles
21 mercredi octobre 2009 23:03
Ma présentation "Estimations, mesures et indicateurs agiles" pour Agile Toulouse c'est demain à 14h30. C'est en plein dans l'heure de la sieste (si j'en vois un qui somnole, je l'envoie dans la session XP Game qui a lieu en parallèle, ça va le réveiller de gonfler des ballons. Ou alors faire du TDD dans le dojo, ça lui apprendra la dure voie de l'agilité).
Oui, il y a 5 sessions en même temps : ma présentation est cataloguée conférence, il y a un retour d'expérience, une présentation d'outil et deux ateliers donc.
Pour guider les hésitants : c'est promis, je ne parlerai pas de CMMI (et pourtant les mesures que je présente, ce pourrait bien être du niveau 4). Je ne parlerai pas d'outil non plus, sauf pour dire qu'un bon outil (Open source par exemple) peut aider à collecter les mesures.
Mon plan pour demain, c'est : d'abord je présente ce qu'il y a de nouveau dans les mesures quand elles sont agiles, puis je parle des estimations en expliquant les notions de timebox, vélocité, capacité et utilité. Ensuite je dis 2 mots sur la collecte pour passer aux indicateurs. Je commence par ceux utiles pour le sprint, puis ceux qui portent sur le produit et finis par ceux intéressant la release. Pour chaque indicateur, je dis à qui il est destiné, pourquoi l'utiliser, la tendance souhaitée et quand l'utiliser.
Bonnes mesures
06 mardi octobre 2009 07:20
Estimations, mesures et indicateurs agiles, c'est le titre de la présentation que j'animerai le 22 octobre à 14Hh30 au cours de l'étape toulousaine de l'Agile Tour. Cette année, il y aura une vingtaine de sessions dans la journée avec 3 ou 4 en parallèle, il faudra choisir.
Pensez à vous inscrire.
Cette présentation s'adresse à des personnes connaissant et appliquant les méthodes agiles. Comme dans les projets traditionnels, les indicateurs d'un projet agile servent à prendre des décisions en connaissance de cause, à savoir quelles améliorations apporter, à motiver l'équipe et assurer la confiance des intervenants. Mais les mesures agiles sont bien différentes des mesures traditionnelles.
Je présenterai les mesures utilisées sur les projets agiles. Nous verrons lesquelles sont les plus pertinentes, selon le contexte du projet, et à quel moment les collecter. Comme des mesures sont basées sur des estimations, nous aborderons les estimations en points utilisées pour évaluer la taille des éléments du backlog. Nous verrons ensuite comment interpréter les indicateurs (graphiques) basés sur ces mesures.
Seront abordées les notions de : estimation en points, valeur ajoutée, backlog, vélocité, timebox, burndown, burnup, parking lot, cumulative flow diagram et de suivi des tests, des builds et du budget.
40% de sprints en moins
22 samedi août 2009 08:46
Avec la canicule qui sévit en ce moment, les footballeurs font moins de sprints. Et pour les équipes Scrum, ça a quel effet la canicule ? Ce n'est pas 40% de sprints en moins, mais cela peut avoir un impact sur la vélocité pour ceux qui n'ont pas la clim (à cause du temps passé pour aller chercher les canettes) ? Des obstacles supplémentaires ?
Dette technique, nique nique
18 lundi mai 2009 21:17
Le terme dette technique revient pas mal en ce moment. On en parle dans les blogs et je l'entends même dans mon équipe.
Il n'est pas récent : il vient d'un article de Ward Cunningham de 1992 pour une conférence OOPSLA.
A l'époque, pas d'agile ! Mais du développement incrémental et orienté objet.
De la vélocité à l'accélération
26 lundi janvier 2009 10:49
La vélocité ne mesure pas la productivité. Et l'accélération de vélocité ?
Variation de périmètre
12 dimanche octobre 2008 11:13
Un burndown chart de release donne une bonne indication du travail qui reste à faire. En y ajoutant la consommation du budget, on obtient des indicateurs permettant de répondre à des questions fondamentales de la gestion d'un projet : où en sommes-nous dans l'avancement du projet, combien de budget avons-nous consommé ?
Seulement, et c'est normal avec une méthode agile, le périmètre initial, représenté par le point de départ d'un burndown chart, évolue toujours. Je définis ici le périmètre comme le total des points des éléments qui constituent le backlog pour une release.
Il évolue toujours, sur tous les projets auquel j'ai participé. La raison la plus évidente est l'ajout d'une nouvelle story qui n'avait pas été prévue au début du projet. Il y en a de nombreuses autres :
- la décomposition, suivie d'une estimation. Il est fréquent que le total des points des éléments décomposés ne soit pas identique au total estimé pour l'élément avant décomposition
- la suppression d'un élément. Il arrive qu'on décide de le reporter pour une prochaine release
- une ré-estimation d'un ou plusieurs éléments du backlog qui avaient été mal compris
- un élément qu'on n'avait pas encore estimé, parce qu'on n'avait pas eu le temps et/ou parce qu'il n'était pas prioritaire. Le simple fait de lui donner une estimation ajoute des points au total et modifie le périmètre.
Le burndown chart classique ne permet pas de voir l'évolution de périmètre. Pour l'avoir, il convient simplement de tenir compte de la vélocité. A la fin de chaque sprint, cela revient à faire 2 mesures : le reste à faire et la vélocité du sprint qui se finit. Les deux comptées en points.
Par exemple :
- fin du sprint 0 : 100 points à faire dans le backlog de produit
- fin du sprint 1: 82, vélocité 16
- fin du sprint 2 : 64, vélocité 19
- fin du sprint 3 : 56, vélocité 18
- fin du sprint 4: 30, vélocité 20
Cela permet de savoir que pendant le sprint 3, l'évolution de périmètre a été de 18 - (64-56) , soit une augmentation de périmètre de 10 points. Au contraire pendant le sprint 4, le périmètre a diminué de (56-30) - 20, soit 6 points.
Cela peut se voir un graphique, en voici un exemple :
En rouge la courbe de reste à faire, le burndown classique. En bleu, le reste à faire si le périmètre était resté constant, obtenu simplement en utilisant la vélocité à partir du reste à faire au départ.
Compter les jours, ça peut servir
16 lundi juin 2008 16:15
Une mesure simple pour montrer le budget consommé par rapport à l'avancement
Evaluation de la collaboration dans une équipe
01 samedi mars 2008 13:53
Le succès d'un projet repose largement sur les personnes qui y participent et sur la façon dont elles travaillent ensemble. Cela est bien connu mais pas toujours appliqué dans nos organisations hiérarchiques. Les méthodes agiles cherchent à favoriser absolument cette idée de collectif, à travers, notamment, les réunions et les travaux en groupe. Comment savoir si ça fonctionne ? Evaluez votre niveau...
Mesures agiles
11 lundi février 2008 19:45
La mesure la plus connue dans les méthodes agiles est probablement la vélocité. Mais il y a d'autres mesures simples à faire lors d'un développement agile permettant d'obtenir des indicateurs et des courbes (burndown charts, courbes diverses).
Au cours de chaque sprint, on peut mesurer :
- tous les jours, le nombre d'heures restant à faire, ce qui permet de produire le burndown chart de sprint qu'on peut analyser selon sa forme
A la fin d'un sprint :
- le nombre de builds produits pendant le sprint, ce qui permet de savoir si des versions ont été produites, notamment pour les tests
- le nombre de problèmes restant à résoudre, ce qui permet de se faire une idée de leur variation au cours du projet
- la vélocité donc, ce qui permet de calculer la vélocité moyenne qui sert à planifier
- le nombre de points restant à faire d'ici la fin de la release, ce qui permet d'obtenir le burndown chart de release
- le nombre de user stories faites pendant le sprint, le nombre de stories restant dans le backlog et le nombre de stories à estimer ce qui permet d'obtenir des indications même s'il n'y a pas d'estimation en points
- le nombre de points des stories dans les différents états, pour produire les burnups et les courbes de croissance
- le nombre de cas de tests écrits, le nombre de cas de tests passés ce qui permet d'obtenir un Big visible chart
Bientôt tout ça disponible dans IceScrum ?
La revue de sprint
25 dimanche novembre 2007 09:35
Une revue qui permet un feedback concret sur le produit (c'est mieux que sur de la documentation).
La vélocité n'est pas une mesure de productivité
18 dimanche novembre 2007 10:45
La vélocité est une mesure typique des méthodes agiles. Elle ne doit pas être confondue avec la productivité
Un nouvel exemple d'agilité à grande échelle
08 lundi octobre 2007 08:52
L'application d'une méthode de développement agile pour toute une organisation
« billets précédents - page 1 de 2
