What’s up agile : estimation et agilité

Découvrez tous les tweets les plus marquants de la twittosphère #agile #kanban #scrum.
Dans ce nouveau what’s up agile, les twittos apportent des clés pour améliorer la communication et les interactions dans un environnement Agile.

Lorsque vous êtes en contact avec un artisan pour remplacer une fenêtre, vous demandez généralement un devis. Vous avez besoin de savoir combien cela pourrait vous coûter et combien de temps cela pourrait prendre.

Pour un projet informatique et agile, c’est la même chose. On essaye de rendre les estimations agiles aussi précises que possible pour éviter les mauvaises surprises. Le sujet des estimations est au coeur des débats lorsque l’on se lance dans l’agilité.

Dans cette revue, nous reviendrons sur les questions fréquentes autour de l’estimation.

Comment on estime ?

Une estimation prend en compte : la quantité de travail à fournir, la complexité, le risque et les inconnues.

Plusieurs pratiques permettent aux développeurs d’estimer : le Planning Poker ou l’eXtrême Quotation par exemple. Dans les méthodes traditionnelles, il était courant de donner des estimations en jours-hommes. En agile, il est conseillé d’estimer soit en taille de T-shirt (XS, S, M, L, XL, XXL) ou en  “story points” (points de complexité) suivant le suite de Fibonacci (1, 2, 3, 5, 8…).

Pour les développeurs, ce n’est pas la tâche la plus simple…

Pourquoi on estime ?

La première raison d’estimer est pour pouvoir répondre à la question “Quand est-ce que j’aurai cette fonctionnalité ?” des parties prenantes . Cela permet de prédire “Combien de temps cela va nous prendre ?” et “Qu’est-ce que l’on aura à telle date ?”.

La deuxième raison est que cela facilite la priorisation : on va plutôt faire en premier ce qui a beaucoup de valeur et peu de complexité.

Utilisation d’une matrice de complexité/valeur pour ordonner votre backlog #PMoT #ScrumMaster #ProductOwner

Comment piloter un projet avec de “bonnes” estimations ?

Les estimations ne sont pas un engagement ou une promesse de livraison. Elles aident au pilotage d’un projet afin de :

  • Mesurer la vélocité de l’équipe,
  • Visualiser la quantité de travail à faire en comparaison de la vélocité avec burn down/up chart.

Ces métriques sont mises à jour tout au long du projet afin de se projeter vers une date de livraison et d’agir sur le périmètre si besoin.

Si vous cherchez à avoir des meilleures estimations, voici un conseil révélé par un twittos :

Au lieu de vous concentrer sur de «meilleures» estimations … se concentrer sur: travailler plus petit, intégrer fréquemment, exposer le travail aux utilisateurs / clients plus rapidement, tester les hypothèses plus tôt, limiter les dépendances, avoir un code moins fragile, limiter les transferts. Vos estimations vont s’améliorer.

Qu’est-ce que le #NoEstimates ?

Si vous suivez les réseaux sociaux, le débat #NoEstimates affole la toile depuis quelque temps.

Ce débat est apparu après le constat suivant : sur certains projets, que l’on dimensionne par story point ou par nombre de stories dans un sprint, le suivi de la cadence restait sensiblement le même. Il valait donc mieux se concentrer sur la création de valeur.

D’ailleurs, des octos en ont fait leur retour d’expérience : #NoEstimates : un an de projet, faisons le bilan.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha