Démarche générale

Taille, vélocité et calendrier

ü  première étape : estimer la « taille » des fonctionnalités

ü  La « vélocité » permet de déduire la durée de réalisation d’une fonctionnalité

Vélocité = coefficient qui determine en combien de temps je fais une unité (jours d’hommes, etc.)

(d’après Mike Cohn « Agile Estimating and Planning » : www.mountaingoatsoftware.com/)

Une question? Posez-la ici

Estimation Agile : « Story Points »

« Mieux vaut être grossièrement juste que précisément faux. » (John Keynes)

Story Points : mesure relative

Les Story Points sont une unité de mesure exprimant la taille globale d’une fonctionnalité ou d’une tâche.

Seule la valeur relative assignée à un objet compte : une US User Story valant 2 points nécessite deux fois plus d’effort qu’une US valant 1 point (inutile d’être précis !).

Le nombre de points assignés dépend de la quantité de travail nécessaire estimée, ajustée en fonction de la complexité, des risques, etc…

Partir d’une US de taille moyenne, puis en déduire la taille des autres.

Exemples…

Exemple simple: planifier le temps pour faire la vaisselle

Fin de soirée, 5 personnes à diner, il faut faire la vaisselle : combien de temps cela va-t-il prendre ?

5xFourchettes    5xCouteaux        5xVerres              5xAssiettes         2xCasseroles

Estimation. Hypothèse des story points assignés, d’après une demande autour de la table :

1SP                       1SP                       2SP                       2SP                      

Maintenant on assigne un temps à chaque Story point

1 storyPoint=15 secondes

Ce qui nous fait

5xFourchettes    5xCouteaux        5xVerres              5xAssiettes         2xCasseroles

5x15=75              5x15=75              5x2x15=150        5x2x15=150s      2x5x15=150

En tout on a 600 secondes, soit 10 minutes. On peut donc faire la vaisselle en 10 minutes.

On a perdu beaucoup de temps à assigner combien de SP par ustensile, alors qu’au final, meme en donnant des approximations, on arrive à un temps cohérent

Il faut utiliser la fibre de Fibonacci pour les US (1,2,3,5,8)

Plus on a d’US, plus le projet grossit

Une question? Posez-la ici

Effort d’estimation

• Consacrer l’effort juste nécessaire à l’estimation :

ü  Quel que soit l’effort on n’atteindra jamais les 100% d’exactitude

ü  Un effort minimal permet déjà d’obtenir une estimation moyenne

ü  Pousser trop loin l’effort dégrade le résultat

Echelle d’estimation

• Pour les US on peut utiliser la suite de Fibonacci (1, 2, 3, 5, 8)
• Pour les fonctionnalités de haut niveau qui ne seront estimées en détail que plus tard (« Epics », « Themes ») : 13, 20, 40, 100

Techniques d’estimation

• Opinion d’expert
• Analogie avec des US réalisées antérieurement
• Désagréger la US/Feature en ensembles plus petits è augmente largement l’effort
• Planning poker : estimation collective

Ré-estimer

               On peut ré-estimer en cours de projet mais uniquement si la taille relative des US a changé. Sinon, ajuster via la vélocité.

Priorisation Agile

• La priorisation des US se fait selon les critères suivants :
  • La valeur client (cf. section suivante)

ü  valeur financière apportée par la fonctionnalité (accroissement des ventes, économies en interne, …)

ü  « désirabilité » client

• Le coût du développement de la fonctionnalité (cf. estimation taille)
• Les risques levés par le développement de la fonctionnalité
• La connaissance acquise au cours du développement de la fonctionnalité qui permet de réduire les incertitudes

ü  connaissance sur le besoin du client (via les revues et démonstrations)

connaissance sur la maîtrise de l’équipe (notamment la maîtrise de la technologie via les premiers développements)

Une question? Posez-la ici

Combiner les 4 critères

• Exemples

• application grand public
• framework à technologie inconnue

Désirabilité

               On peut classer la désirabilité des fonctionnalités selon les méthodes suivantes :

• Moscow, Modèle de Kano
• Modèle des poids relatifs

               Il est basé sur des estimations (en points relatifs, de 0 à 9) de la désirabilité des fonctionnalités obtenues par questionnaire ou jugement d’expert :

ü  Bénéfice apporté par la fonctionnalité

ü  Pénalité en cas d’absence de la fonctionnalité

Une question? Posez-la ici

Agile Scheduling

Product Roadmap

Premier niveau de planification, établi tout en amont du projet et révisé très occasionnellement

Etabli par des décideurs de haut niveau (direction), des product owners et des team managers (experts projets)  

On y planifie des releases :

releases externes

livrées à l’utilisateur final

releases internes

livrées à quelques key users qui l’utiliseront dans des conditions simulant la production è feedback

Périmètre : Les releases doivent correspondre à des ensembles de fonctions cohérents, exploitables et significatifs pour l’utilisateur (sauf « release » interne à l’équipe, comme un prototype architectural)

Exemple de Product Roadmap

A remplir par le product owner et on valide :

Fréquence et positionnement des releases

Mettre des releases de même temps.

Les releases doivent être assez fréquentes (et donc petites) afin d’apporter :

une réactivité importante au changement ou aux nouveaux besoins

une réduction rapide du risque « compréhension du besoin »

è déterminer la fréquence optimale en fonction du besoin de feedback, de la réactivité du marché, etc…

En général les dates sont fixées et le contenu de la release est estimé (parfois le contraire).

On place les releases à des dates régulières (ex: tous les 4 mois) ou bien selon le marché ou des évènements précis (salon, …).

Une question? Posez-la ici

Release Plan

               Session de 2 jours en début de Release, impliquant toute l’équipe.

Une question? Posez-la ici

Définir l’objectif de la release

Parmi les 3 éléments de l’objectif, on privilégie souvent :

Date de fin : « schedule driven ».

OU

Périmètre : « scope driven ».

Les ressources font l’objet d’hypothèses de départ qui peuvent être ajustées jusqu’à

un certain point.

Choisir la durée des itérations en fonction de :

ü  la durée de la release

ü  besoin de feedback et facilité pour l’obtenir

ü  besoin de reprioriser souvent

moins on a de certitudes sur :

ü  la stabilité du besoin client

ü  la compréhension de ce besoin par l’équipe projet

ü  la performance de l’équipe

               plus on raccourcit les cycles.

Une question? Posez-la ici

Identifier US

Décomposer les Fonctionnalités de haut niveau en US suffisamment petites pour tenir dans une itération.

Techniques de split :

splitter selon les étapes/activités du processus (ex : CRUD)

splitter selon les données manipulées

faire des contraintes de performance et des fonctionnalités transverses (sécurité, login, …) des US à part entièr

splitter en sous-US selon la priorité

Ajouter les Tâches Transverses et work items de haut niveau :

management (éventuellement)

divers spikes (surtout en cas de réflexion Up-Front)

travaux d’infrastructure

préparation de release (doc d’install, formation, …)

Une question? Posez-la ici

Décomposition des US en tâches

• inclure toutes les tâches nécessaires pour la réalisation de la US.
• n’inclure que les tâches à valeur ajoutée et en rapport direct avec le projet
• une tâche doit pouvoir être effectuée en 1 ou 2 jours approximativement

Une question? Posez-la ici

Des questions?