La racine carrée de la somme des carrés

Houa, ça fait peur!

C'est juste une méthode utilisée pour calculer les buffers de contingence. (Schedule buffer). La marge de temps couvrant les risques.

Ça ne date pas d'aujourd'hui, mais comme je n'avais rien trouvé sur le sujet en Français, alors voilà.

Apparu dans le livre "Agile Estimating and Planning" de Mike Cohn en 2005.

Le but étant de savoir comment garantir un planning avec suffisamment de fiabilité. Mike Cohn propose d'ajouter un buffer de temps (et aussi  un buffer de fonctions, Feature Buffer).

Question : Comment calculer ce buffer.
Réponse : La racine carrée de la somme des carrées des différences.

Mouais, pas trop avancé avec tout ça. C'est pourtant simple.

Imaginez une liste de fonctions à produire: F1, F2, ...
Vous estimez la charge moyenne de chaque fonction. En point fibonacci et planning poker bien entendu ;-). Cette estimation est considérée comme une valeur moyenne, fiable à 50%.
Ensuite, re-estimez le plus mauvais cas, en prenant en compte tous les risques éventuels. Lors du planning poker, on pourrait garder la valeur la plus forte votée. Vous pouvez considérer cette estimation fiable à 90%.

Ensuite, vous prenez votre excel préféré et :

Fonction	50% (a)	90% (w)	(w-a)²
F1	3	5	4
F2	5	8	9
F3	2	5	9
F4	5	13	64
F5	8	13	25
F6	1	1	0
Somme	24	45	111

(a) = average, moyenne, (w) = worst, plus mauvais cas


La somme des carrés des différences faisant 111, la racine carrée est égale à 11 (arrondie)
Le buffer à considérer est donc de 11.
Le total de l'estimation est donc de 24 + 11, soit 35. 10 points de moins que le total des estimations à 90% de fiabilité.

Tout ça c'est des mathématiques, et par définition les estimations étant fausses, ça n’empêche pas de continuer à réfléchir.

A la prochaine.

Projets à releases parallèles : le Burn-Lot

Je travaille actuellement sur un produit mêlant software (SW) et hardware (HW).

L’application des méthodes agiles ne se limite pour l’instant qu’à la partie SW, mais les contraintes H/W sont tout de même à prendre en compte.

Et notamment la nécessité de releases plus longues qu’il faut anticiper côté SW.

Cela entraîne une roadmap produit à releases parallèles. Pour simplifier le projet SW, je n’ai préconisé qu’une seule release SW à la fois.  Chaque release SW doit donc prendre en compte le développement de tout ou partie des releases produits. Dans ce cas, les burn-up et burn-down simples de produit ne sont pas suffisant pour évaluer la tenue des jalons.

Nous avons donc combiné dans une sorte de burn-up « croisé » d’un parking lot, les infos de la release SW et le cumul des restes à faire par release produit. Avec projection de ce qu'il faudrait sur chaque release en tant que vélocité envisagée.

Bon, ce n’est pas un vrai burn-up, puisqu’il ne cumule pas les points obtenus.

D’un côté nous avons une répartition de la production par type : user stories par release ainsi qu’un pool de bugs à corriger. Et de l’autre une projection de la vélocité attendue pour tenir des jalons.

Ce burn-lot apparaît en complément des burn-down et burn-up bien sûr.

Tout ça ne reste pas simple, mais nous donne un peu plus de visibilité !

Estimation par similitude (bis)

Dans son billet l’estimation par similitude d’effort, Claude présente une façon plus rapide d’estimation des user stories.

J’utilise un dérivé de cette méthode qui consiste à placer les cartes de user story sur un tableau présentant la suite de fibonacci.

Je prépare le tableau :

En début de transformation Agile d'une équipe, ça lui permet d’aller un peu plus vite.

Généralement, il faut à peu près 1 heure aux équipes pour placer les 4 ou 5 premières user stories. Je ne dis rien, je laisse faire. Puis micro rétrospective, « 5 user stories en 1 heure, il en reste 30, on mange quand ce soir ? », après ça, l’équipe va plus vite, time boxing oblige.

Résultat :

Ensuite, pour évaluer une première vélocité, j’utilise une formule super mathématique qui vaut ce qui vaut, mais faut bien commencer.

L’équipe choisi un échantillon de user stories qu’elle maitrise le mieux, et découpe en tâche, puis estime en heure.

A partir de là, règle de trois entre points et heures et projection en fonction de la disponibilité de l’équipe et un IEH à 5 heures par jour.

L’objectif n’étant pas de définir par défaut une vélocité à atteindre et gravée dans le marbre, mais juste un seuil pour préparer le premier sprint. L’équipe démarre le sprint 0 tout en commençant à pratiquer Scrum. Très bon point pour l’apprentissage itératif

Iteration Plan, Product and Iteration Backlogs

Pour étayer mon précédent post sur les estimations, j’ai mis à disposition un backlog en partage sur Google Docs au format SpreadSheet

Le plan d'itération, au format Gantt (oui, je sais, c'est pas Agile...):


Le burdown du Product Backlog:


Le burndown de l'Itération Backlog:


Les données utilisées ne sont pas cohérentes, mais servent juste à présenter le concept.

Le backlog est publié ici.

Plan estimé vs Task estimé

Estimation descendante vs Estimation montante
Macro planning vs micro planning (même si ce n’est pas un planning)

Le produit est défini par User Stories, les niveaux « L1 ».
Les User Stories sont estimés par la méthode des Use Case points.
Ces estimations permettent la définition du plan d’itération, roadmap de l’application.

Des User Stories aux fonctions élémentaires, c’est l’estimation descendante.
Les User stories sont décomposés Business Scénarios :
Scénario principal (aux), scénarios alternatifs, scénarios d’exception.
Décomposition jusqu’au niveau fonction élémentaire. Affinage de l’estimation, ré-estimation indépendante à chaque étage. Cette étape peut être assimilée à l’analyse fonctionnelle, et doit s’effectuer de manière itérative aussi, en fonction du plan d’itération.

Pour l’itération à venir, on prépare l’estimation montante :
A partir des fonctions élémentaires, décomposition en tâches de « développement ». J’entends par tâche de développement, toute activité nécessaire à la production jusqu’à terme de la fonctionnalité : code, tests unitaires, revue de code, intégration, tests fonctionnels,…

La grande majorité des développements applicatifs se basant dorénavant sur un ou plusieurs frameworks, il est facile d’établir une sorte de check-list des tâches. Pour chaque fonction élémentaire, on peut choisir les tâches applicables issues de cette check-list.

A partir de là, les niveaux « L2 » sont définis, leur estimation est effectuée lors du planning game par l’équipe. C’est l’estimation montante : La somme des estimations des tâches prises en compte pour l’itération est à confronter avec la vélocité. Cela peut avoir un impact sur le plan d’itération du fait que l’estimation montante n’est pas nécessairement égale (voir jamais) à l’estimation descendante.

Pendant le sprint (l’itération), le reste à faire est mise à jour, ainsi que le consommé.
En fin d’itération, il est important de reconsidérer les trois valeurs :

• Plan estimé : estimation macroscopique, estimation descendante
• Task estimé : estimation unitaires des tâches de l’itération, estimation montante
• Effort réel : Temps réellement passé à produire les tâches
  

A partir de ces informations on peut évaluer l’impact sur le plan d’itération, la vie du produit.

La décomposition précise des User Stories en scénarios, puis en fonctions élémentaires, et enfin en tâches, permet à tout intervenant sur le projet

• d’identifier,
• de comprendre,
• d’adhérer

au contenu fonctionnel du produit.

Cela permet dans une certaine mesure de s’affranchir d’une documentation de spécification détaillée proche du code qui alourdi le process.
L’autre mérite est de traiter la traçabilité sans s’en rendre compte, c’est le cas de la combinaison d'utilisation des outils Rally et Eclipse Mylin et SVN (ou CVS).