Evaluation de charge : jouez au poker avec les points de fonction

( Stefen Hawking jouant au poker avec Einstein (Jim Norton) et Newton (John Neville). Extrait de la série "Star Trek, The Next Generation", au début de l'épisode "Descent", Part I. Documents Paramount Pictures, 1993.)


Question lancinante, récurrente , incontournable , posée aux développeurs, responsables de projet et autres: A combien de jour/homme estimez vous cette tâche ?.
Cette question universelle contient les deux incongruités qui pèseront lourdement sur la justesse de la réponse: jour/homme et tâche.

Le contexte.

Imaginons 3 chauffeurs engagés pour conduire un client de Paris à Marseille.

Concernant les Jours/hommes:

La question sur l'estimation serait traduite en :

Combien de temps il vous faut pour faire Paris Marseille . ?
Avec 3 chauffeurs , vous obtiendrez 3 réponses DIFFÉRENTES et elles seront toutes justes... (un chauffeur va rouler à 120 km/h , un autre s'arrête toute les heures etc.)

En revanche à la question suivante : Combien de kilomètre entre Paris et Marseille ? Les trois chauffeurs vont arriver à un chiffre proche.

Ainsi avec les jours/hommes on cumule deux approximations: La quantité de ce qui est à faire et la vitesse de réalisation.






Concernant l'unité utilisée.

L'unité jour/homme est elle même une aberration : qu'est ce qu'une journée idéale ?

Gardons en tête cet exemple plein de bon sens :

1 femme peut faire un enfant en 9 mois mais jamais 9 femmes feront un enfant en 1 mois.

Quand les chiffres annoncés sont du type 300 j/h pour réaliser une tache , j'ai toujours envie de dire : ok on va embaucher 300 personnes et le truc sera terminé après-demain.
Réponse immuable à cette remarque: Ce ne sont pas des mêmes j/h (Pourquoi les additionner alors ?)




Concernant les tâches
La commande passée au chauffeur serait:
a) Aller chercher la voiture au garage
b) Vérifier la pression des pneus
c) Faire le plein
d) rouler 700 km
etc..

Or quelle est la demande du client ? : se rendre de Paris à Marseille tout simplement . En se focalisant sur les tâches et non pas sur les fonctions (vision client) , notre pauvre client se retrouvera soit largué en pleine campagne bretonne soit coincé sur le périphérique.


Les points de fonctions et les méthodes agiles

Au commencement ..

Il existe d'autres unités de mesure des taches, comme les points de fonction utilisés par la méthode éponyme : (ici un très bon lien sur le sujet) . Ici, l'évaluation se place du coté de l'utilisateur. Peu importe si la fonction est réalisée par une usine à gaz (SOA, machine de Rude GOLBERG ) ou un progiciel.

Cette méthode du siècle dernier a été détournée et remise à la mode pour les besoins des méthodes agiles.

La métrique.
On utilise une suite numérique discontinue pour quantifier des charges.

On va s'attacher à évaluer des 'fonctions utilisateurs' et non pas des taches.

Un exemple de bonne suite est celle de Fibonacci :

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55 ...

Étrangement: en demandant moins de précision, on va en obtenir plus.

• Paradoxe 1: La précision d'une évaluation est une fonction en forme de cloche. A partir d'un certain stade, plus on cherche à affiner les évaluations ( plus on passe de temps dessus) et moins on sera efficace dans les estimations.

• Paradoxe 2: Une personne isolée estimera mieux qu'un groupe.

• Paradoxe 3: Un expert relevant du domaine à estimer est le plus à même à faire une bonne estimation. Ainsi,il faut préférer les dires d'experts aux pseudo-méthodes d'évaluation basées sur le nombre d'écran, le nombre de contrôle etc. (§machine de Rude GOLBERG )

L'évaluation par le Poker:


Cette technique arrive à concilier toutes les contraintes de l'évaluation.
Chaque membre de l'équipe dispose d'une série de carte, chaque carte reprenant un nombre de la suite.

Le maitre du jeu détaille la fonction à évaluer (maximum 15 minutes) , puis chaque joueur compose son estimation avec ses cartes. Au signal tout le monde retourne ses cartes.

Une discussion s'engage sur les écarts des estimations (max 15 minutes)

Ainsi , on obtient une liste de fonctionnalité avec leur poids.

Voir le lien wikipedia planning poker.

Détermination de la vitesse de réalisation de l'équipe.

L'itération initiale va donner une première estimation de la vitesse de l'équipe. Plus on réalisera des itérations et plus cette vitesse sera affinée.

Ainsi dans des méthodes agiles, ce qui est important c'est la planification en elle même plus que le plan. La planification est réalisée a chaque itération et non pas de façon macro en début de projet.

Au départ, on peut dire que l'estimation par point est aussi imprécise qu'en jour homme. En revanche par le mécanisme des itérations courtes, l'estimation sera de plus proche de la réalité. L'estimation devient même marginale par rapport au projet. L'équipe ne s'engage que pour des courtes périodes.

Un client voulant aller de Paris à Pékin , se verra proposer avec les méthodes agiles une série d'étape l'amenant vers son point d'arrivée. A tout moment en fin d'étape, le client peut dire stop. Il ne sera pas obligé de rebrousser chemin.

En informatique , le client s'engage pour 1 mois , il pose sa mise sur la table. L'équipe informatique livre en fin d'itération un produit avec une fonctionnalité de base. Le client peut décider de continuer sur un autre cycle avec une nouvelle fonction ou simplement d'arrêter les frais.
Si au bout d'un mois le client n'est pas satisfait, il ne perdra que sa mise de départ, mais il aura une application minimale en état de marche..